Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes <[EMAIL PROTECTED]> wrote: > On some machines, buggy BIOSes don't properly setup WB MTRRs to > cover all available RAM, meaning the last few megs (or even gigs) > of memory will be marked uncached. Since Linux tends to allocate > from high memory addresses first, this causes the machine to be > unusably slow as soon as the kernel starts really using memory > (i.e. right around init time). > > This patch works around the problem by scanning the MTRRs at > boot and figuring out whether the current end_pfn value (setup > by early e820 code) goes beyond the highest WB MTRR range, and > if so, trimming it to match. A fairly obnoxious KERN_WARNING > is printed too, letting the user know that not all of their > memory is available due to a likely BIOS bug. Wouldn't it be better to correct the MTRR, if possible? As far as I read here (LKML), the BIOS did not merge the entries, and this waste caused the last part of the memory not to be covered. Off cause you can't DTRT for all buggy MTRR setups, but if you're lucky, optionally merging the MTRR and adding the rest of the memory may sometimes do the trick ... -- Funny quotes: 10. Nothing is fool proof to a talented fool. Friß, Spammer: [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 the FAQ at http://www.tux.org/lkml/
Re: ext2 on flash memory
On Tuesday 12 June 2007 23:09, Jason Lunz wrote: > In gmane.linux.kernel, you wrote: > > I was wondering: is there any reason not to use ext2 on an USB > > pendrive? Really my question is not only about USB pendrives, but any > > device whose storage is flash based. Let's assume that the device has a > > good quality flash memory with wear leveling and the like... > > Have a look at the UBI layer. It adds wear-levelling to MTD devices. Of > course, to use it on a regular blockdev like this you'll have to do > something like usb-storage (sd) -> block2mtd -> ubi -> jffs2. But it can > be done afaik. Then you will do some kind of wear leveling (jffs2) over wear leveling (pendrive). Does this makes sense? Juergen - 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/
Re: [PATCH 2/3] [CRYPTO] Add optimized SHA-1 implementation for i486+
>> The names are the order they were written in. "One" is the lib/sha1.c
>> code (547 bytes with -Os). "Four" is a 5x unrolled C version (1106 bytes).
>
> I'd like to see your version four.
Here's the test driver wrapped around the earlier assembly code.
It's an ugly mess of copy & paste code, of course.
I suspect it could be shrunk by allocating the W[] array locally,
thereby freeing up a register. Size is -Os -fomit-frame-pointer.
/*
* SHA transform algorithm, originally taken from code written by
* Peter Gutmann, and placed in the public domain.
*/
#include
#include
#define rol32(x, s) ((x)<<(s) | (x)>>(32-(s)))
static inline uint32_t __attribute__((const))
be32_to_cpu(unsigned x)
{
asm("bswap %0" : "+r"(x));
return x;
}
/* The SHA f()-functions. */
#define f1(x,y,z) (z ^ (x & (y ^ z))) /* x ? y : z */
#define f2(x,y,z) (x ^ y ^ z) /* XOR */
#define f3(x,y,z) ((x & y) + (z & (x ^ y))) /* majority */
/* The SHA Mysterious Constants */
#define K1 0x5A827999L /* Rounds 0-19: sqrt(2) * 2^30 */
#define K2 0x6ED9EBA1L /* Rounds 20-39: sqrt(3) * 2^30 */
#define K3 0x8F1BBCDCL /* Rounds 40-59: sqrt(5) * 2^30 */
#define K4 0xCA62C1D6L /* Rounds 60-79: sqrt(10) * 2^30 */
/**
* sha_transform - single block SHA1 transform
*
* @digest: 160 bit digest to update
* @data: 512 bits of data to hash
* @W: 80 words of workspace (see note)
*
* This function generates a SHA1 digest for a single 512-bit block.
* Be warned, it does not handle padding and message digest, do not
* confuse it with the full FIPS 180-1 digest algorithm for variable
* length messages.
*
* Note: If the hash is security sensitive, the caller should be sure
* to clear the workspace. This is left to the caller to avoid
* unnecessary clears between chained hashing operations.
*/
void sha_transform(uint32_t digest[5], const char in[64], uint32_t W[80])
{
register uint32_t a, b, c, d, e, t, i;
for (i = 0; i < 16; i++)
W[i] = be32_to_cpu(((const uint32_t *)in)[i]);
for (i = 0; i < 64; i++)
W[i+16] = rol32(W[i+13] ^ W[i+8] ^ W[i+2] ^ W[i], 1);
a = digest[0];
b = digest[1];
c = digest[2];
d = digest[3];
e = digest[4];
for (i = 0; i < 20; i++) {
t = f1(b, c, d) + K1 + rol32(a, 5) + e + W[i];
e = d; d = c; c = rol32(b, 30); b = a; a = t;
}
for (; i < 40; i ++) {
t = f2(b, c, d) + K2 + rol32(a, 5) + e + W[i];
e = d; d = c; c = rol32(b, 30); b = a; a = t;
}
for (; i < 60; i ++) {
t = f3(b, c, d) + K3 + rol32(a, 5) + e + W[i];
e = d; d = c; c = rol32(b, 30); b = a; a = t;
}
for (; i < 80; i ++) {
t = f2(b, c, d) + K4 + rol32(a, 5) + e + W[i];
e = d; d = c; c = rol32(b, 30); b = a; a = t;
}
digest[0] += a;
digest[1] += b;
digest[2] += c;
digest[3] += d;
digest[4] += e;
}
#define ROUND(a,b,c,d,e,f,add) \
( e += add + f(b,c,d), \
b = rol32(b, 30), \
e += rol32(a, 5) )
void sha_transform4(uint32_t digest[5], const char in[64], uint32_t W[80])
{
register uint32_t a, b, c, d, e, i;
for (i = 0; i < 16; i++)
W[i] = be32_to_cpu(((const uint32_t *)in)[i]);
for (i = 0; i < 64; i++) {
a = W[i+13] ^ W[i+8] ^ W[i+2] ^ W[i];
W[i+16] = rol32(a, 1);
}
a = digest[0];
b = digest[1];
c = digest[2];
d = digest[3];
e = digest[4];
for (i = 0; i < 20; i += 5) {
ROUND(a,b,c,d,e,f1,W[i ]+K1);
ROUND(e,a,b,c,d,f1,W[i+1]+K1);
ROUND(d,e,a,b,c,f1,W[i+2]+K1);
ROUND(c,d,e,a,b,f1,W[i+3]+K1);
ROUND(b,c,d,e,a,f1,W[i+4]+K1);
}
for (; i < 40; i += 5) {
ROUND(a,b,c,d,e,f2,W[i ]+K2);
ROUND(e,a,b,c,d,f2,W[i+1]+K2);
ROUND(d,e,a,b,c,f2,W[i+2]+K2);
ROUND(c,d,e,a,b,f2,W[i+3]+K2);
ROUND(b,c,d,e,a,f2,W[i+4]+K2);
}
for (; i < 60; i += 5) {
ROUND(a,b,c,d,e,f3,W[i ]+K3);
ROUND(e,a,b,c,d,f3,W[i+1]+K3);
ROUND(d,e,a,b,c,f3,W[i+2]+K3);
ROUND(c,d,e,a,b,f3,W[i+3]+K3);
ROUND(b,c,d,e,a,f3,W[i+4]+K3);
}
for (; i < 80; i += 5) {
ROUND(a,b,c,d,e,f2,W[i ]+K4);
ROUND(e,a,b,c,d,f2,W[i+1]+K4);
ROUND(d,e,a,b,c,f2,W[i+2]+K4);
ROUND(c,d,e,a,b,f2,W[i+3]+K4);
ROUND(b,c,d,e,a,f2,W[i+4]+K4);
}
digest[0] += a;
digest[1] += b;
digest[2] += c;
digest[3] += d;
digest[4]
Re: PCI-Express root complex quirk in virtual P2P bridge
From: Kumar Gala <[EMAIL PROTECTED]> Date: Wed, 13 Jun 2007 01:26:33 -0500 > I was hoping to get some guidance on how to handle a quirk in how the > virtual P2P bridge works on some embedded PowerPC PCI-Express root > complex controllers. In the controllers I'm dealing with when we > change PCI_PRIMARY_BUS in pci_scan_bridge the ability to send config > cycles to the controller itself becomes effected. The controller > only sends config cycles internally if the bus # in the config cycle > matches the PCI_PRIMARY_BUS. We end up going from being 0 to 3 in > the particular setup and at the point we set PCI_PRIMARY_BUS to 3 we > are no longer able to send internal config cycles. > > What we need is that either a quirk or pcibios code needs to get call > right after we set PCI_PRIMARY_BUS so we can fixup the bus number > relationship. I was wondering if anyone had suggestions on how best > to handle this. I would suggest building the PCI device tree using the OF device tree. 64-bit PowerPC does this already, perhaps you can use some of the existing code for your case too. Sparc64 does as 64-bit PowerPC does. I can't even program the PCI-E root controller in PCI config space on sparc64 Niagara systems, so I just virtualize it. - 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/
PCI-Express root complex quirk in virtual P2P bridge
I was hoping to get some guidance on how to handle a quirk in how the virtual P2P bridge works on some embedded PowerPC PCI-Express root complex controllers. In the controllers I'm dealing with when we change PCI_PRIMARY_BUS in pci_scan_bridge the ability to send config cycles to the controller itself becomes effected. The controller only sends config cycles internally if the bus # in the config cycle matches the PCI_PRIMARY_BUS. We end up going from being 0 to 3 in the particular setup and at the point we set PCI_PRIMARY_BUS to 3 we are no longer able to send internal config cycles. What we need is that either a quirk or pcibios code needs to get call right after we set PCI_PRIMARY_BUS so we can fixup the bus number relationship. I was wondering if anyone had suggestions on how best to handle this. thanks - k - 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/
[git pull for 2.6.22-rc4 - resend] kbuild: fix sh64 section mismatch problems
Resend of the below pull request. Sam On Mon, Jun 11, 2007 at 09:55:52PM +0200, Sam Ravnborg wrote: > Hi Linus. > > Please apply following 2 liners fix. > It will fix a lot of false section mismatch warnings on sh64 and > Paul asked to have in included before the relase hit the street. > > Please pull this single patch from: > git://master.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fix.git > > Sam > > Patch below for reference: > > modpost.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > >From 2648a53acf16a837e11836203aadb219bd951a1e Mon Sep 17 00:00:00 2001 > From: Sam Ravnborg <[EMAIL PROTECTED]> > Date: Mon, 11 Jun 2007 21:52:04 +0200 > Subject: [PATCH] kbuild: fix sh64 section mismatch problems > > There's a special .cranges section that is almost always generated, > with data being moved to the appropriate section by the linker at a later > stage. > > To give a bit of background, sh64 has both a native SHmedia instruction > set (32-bit instructions) and SHcompact (which is compatability with > normal SH -- 16-bit, a massively reduced register set, etc.). code ranges > are emitted when we're using the 32-bit ABI, but not the 64-bit one. > > It is a special staging section used solely by binutils where code with > different flags get placed (more specifically differing flags for input > and output sections), before being lazily merged by the linker. > > The closest I've been able to find to documentation is: > > http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/ld/emultempl/sh64elf.em?rev=1.10&content-type=text/x-cvsweb-markup&cvsroot=src > > It's an array of 8-byte Elf32_CRange structure given in > > http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/elf32-sh64.h?rev=1.4&content-type=text/x-cvsweb-markup&cvsroot=src > that describes for which ISA a range is used. > > Silence the warnings by allowing references from .init.text to .cranges. > > The following warnings are fixed: > > WARNING: init/built-in.o(.cranges+0x0): Section mismatch: reference to > .init.text: > WARNING: init/built-in.o(.cranges+0xa): Section mismatch: reference to > .init.text: > WARNING: init/built-in.o(.cranges+0x14): Section mismatch: reference to > .init.text: > WARNING: init/built-in.o(.cranges+0x1e): Section mismatch: reference to > .init.text: > WARNING: init/built-in.o(.cranges+0x28): Section mismatch: reference to > .init.text: > WARNING: init/built-in.o(.cranges+0x32): Section mismatch: reference to > .init.text: > WARNING: kernel/built-in.o(.cranges+0x50): Section mismatch: reference to > .init.text: > WARNING: kernel/built-in.o(.cranges+0x5a): Section mismatch: reference to > .init.text: > WARNING: kernel/built-in.o(.cranges+0x64): Section mismatch: reference to > .init.text: > WARNING: kernel/built-in.o(.cranges+0xfa): Section mismatch: reference to > .init.text: > WARNING: kernel/built-in.o(.cranges+0x104): Section mismatch: reference to > .init.text: > WARNING: kernel/built-in.o(.cranges+0x10e): Section mismatch: reference to > .init.text: > WARNING: kernel/built-in.o(.cranges+0x14a): Section mismatch: reference to > .init.text: > WARNING: kernel/built-in.o(.cranges+0x154): Section mismatch: reference to > .init.text: > WARNING: kernel/built-in.o(.cranges+0x15e): Section mismatch: reference to > .init.text: > WARNING: mm/built-in.o(.cranges+0x6e): Section mismatch: reference to > .init.text: > WARNING: mm/built-in.o(.cranges+0x78): Section mismatch: reference to > .init.text: > WARNING: mm/built-in.o(.cranges+0x82): Section mismatch: reference to > .init.text: > WARNING: mm/built-in.o(.cranges+0xaa): Section mismatch: reference to > .init.text: > WARNING: fs/built-in.o(.cranges+0x136): Section mismatch: reference to > .init.text: > WARNING: fs/built-in.o(.cranges+0x140): Section mismatch: reference to > .init.text: > WARNING: fs/built-in.o(.cranges+0x14a): Section mismatch: reference to > .init.text: > WARNING: fs/built-in.o(.cranges+0x168): Section mismatch: reference to > .init.text: > WARNING: fs/built-in.o(.cranges+0x1f4): Section mismatch: reference to > .init.text: > WARNING: fs/built-in.o(.cranges+0x1fe): Section mismatch: reference to > .init.text: > WARNING: net/built-in.o(.cranges+0x302): Section mismatch: reference to > .init.text: > WARNING: net/built-in.o(.cranges+0x30c): Section mismatch: reference to > .init.text: > WARNING: net/built-in.o(.cranges+0x316): Section mismatch: reference to > .init.text: > WARNING: net/built-in.o(.cranges+0x3a2): Section mismatch: reference to > .init.text: > WARNING: net/built-in.o(.cranges+0x3ac): Section mismatch: reference to > .init.text: > WARNING: net/built-in.o(.cranges+0x4ce): Section mismatch: reference to > .init.text: > WARNING: net/built-in.o(.cranges+0x4d8): Section mismatch: reference to > .init.text: > > Signed-off-by: Paul Mundt <[EMAIL PROTECTED]> > Cc: Kaz Kojima <[EMAIL PROTECTED]> > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> > --- > scripts/mod/modp
[git pull] Input updates for 2.6.22-rc4
Hi Linus,
Please consider pulling from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for input subsystem.
Changelog:
--
Dmitry Torokhov (3):
Input: i8042 - add ASUS P65UP5 to the noloop list
Input: i8042 - add ULI EV4873 to noloop list
Input: move input-polldev to drivers/input
Ondrej Zary (1):
Input: usbtouchscreen - fix fallout caused by move from drivers/usb
Diffstat:
-
drivers/input/Kconfig | 13
drivers/input/Makefile |1 +
drivers/input/{misc => }/input-polldev.c |0
drivers/input/misc/Kconfig | 11 ---
drivers/input/misc/Makefile|1 -
drivers/input/serio/i8042-x86ia64io.h | 18 +++
drivers/input/touchscreen/usbtouchscreen.c | 44 ++--
7 files changed, 54 insertions(+), 34 deletions(-)
rename drivers/input/{misc => }/input-polldev.c (100%)
--
Dmitry
-
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/
Re: [PATCH] random: fix folding
On Wed, Jun 13, 2007 at 01:45:21AM -0400, [EMAIL PROTECTED] wrote: > > Folding is done to minimize the theoretical possibility of systematic > > weakness in the particular bits of the SHA1 hash output. The result of > > this bug is that 16 out of 80 bits are un-folded. Without a major new > > vulnerability being found in SHA1, this is harmless, but still worth > > fixing. > > Actually, even WITH a major new vulnerability found in SHA1, it's > harmless. Sorry to put BUG in caps earlier; it actually doesn't warrant > the sort of adjective I used. The purpose of the folding is to ensure that > the feedback includes bits underivable from the output. Just outputting > the first 80 bits and feeding back all 160 would achieve that effect; > the folding is of pretty infinitesimal benefit. Well we're actually not feeding back those 160 bits. But we are hashing over the entire pool and feeding -that- back beforehand, which is equivalent. > Note that last five rounds have as major outputs e, d, c, b, and a, > in that order. Thus, the first words are the "most hashed" and > the ones most worth using as output... which happens naturally with > no folding. Indeed, though we actually want to keep random.c agnostic as to the type of hash actually used. > The folding is a submicroscopic bit of additional mixing. > Frankly, the code size savings probably makes it worth deleting it. > (That would also give you more flexibility to select the output/feedback > ratio in whatever way you like.) I'd tend to agree with you. Even if we did no folding at all in this last stage, we already do plenty of feedback. For every 80 bits extracted, we feed back at least.. 320. -- Mathematics is the supreme nostalgia of our time. - 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/
How to diagnose this error?
Hello. Something is wrong with my guest Linux on VMware. Host: CentOS5 (2.6.18-8.1.4.el5) on x86_64 (ThinkPad X60) Guest: CentOS5 (2.6.18-8.1.4.el5) on x86_64 on VMware Workstation 5.5.4 using 2 CPUs BUG messages appear frequently (several times per a minute) on the guest, while they never appear on the host. --- dmesg start --- BUG: soft lockup detected on CPU#0! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] apic_timer_interrupt+0x66/0x6c BUG: soft lockup detected on CPU#1! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] default_idle+0x0/0x50 [] apic_timer_interrupt+0x66/0x6c [] default_idle+0x29/0x50 [] cpu_idle+0x95/0xb8 [] start_secondary+0x45a/0x469 BUG: soft lockup detected on CPU#0! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] default_idle+0x0/0x50 [] apic_timer_interrupt+0x66/0x6c [] default_idle+0x29/0x50 [] cpu_idle+0x95/0xb8 [] start_kernel+0x220/0x225 [] _sinittext+0x237/0x23e BUG: soft lockup detected on CPU#1! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] default_idle+0x0/0x50 [] apic_timer_interrupt+0x66/0x6c [] default_idle+0x29/0x50 [] cpu_idle+0x95/0xb8 [] start_secondary+0x45a/0x469 BUG: soft lockup detected on CPU#1! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] default_idle+0x0/0x50 [] apic_timer_interrupt+0x66/0x6c [] default_idle+0x29/0x50 [] cpu_idle+0x95/0xb8 [] start_secondary+0x45a/0x469 BUG: soft lockup detected on CPU#0! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] default_idle+0x0/0x50 [] apic_timer_interrupt+0x66/0x6c [] default_idle+0x29/0x50 [] cpu_idle+0x95/0xb8 [] start_kernel+0x220/0x225 [] _sinittext+0x237/0x23e BUG: soft lockup detected on CPU#0! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] default_idle+0x0/0x50 [] apic_timer_interrupt+0x66/0x6c [] default_idle+0x29/0x50 [] cpu_idle+0x95/0xb8 [] start_kernel+0x220/0x225 [] _sinittext+0x237/0x23e BUG: soft lockup detected on CPU#1! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] default_idle+0x0/0x50 [] apic_timer_interrupt+0x66/0x6c [] default_idle+0x29/0x50 [] cpu_idle+0x95/0xb8 [] start_secondary+0x45a/0x469 BUG: soft lockup detected on CPU#0! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] default_idle+0x0/0x50 [] apic_timer_interrupt+0x66/0x6c [] default_idle+0x29/0x50 [] cpu_idle+0x95/0xb8 [] start_kernel+0x220/0x225 [] _sinittext+0x237/0x23e BUG: soft lockup detected on CPU#1! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] default_idle+0x0/0x50 [] apic_timer_interrupt+0x66/0x6c [] default_idle+0x29/0x50 [] cpu_idle+0x95/0xb8 [] start_secondary+0x45a/0x469 BUG: soft lockup detected on CPU#1! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] default_idle+0x0/0x50 [] apic_timer_interrupt+0x66/0x6c [] default_idle+0x29/0x50 [] cpu_idle+0x95/0xb8 [] start_secondary+0x45a/0x469 BUG: soft lockup detected on CPU#0! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] apic_timer_interrupt+0x66/0x6c [] :ext3:ext3_get_block+0x0/0xe3 [] :ext3:ext3_get_block+0x0/0xe3 [] __block_write_full_page+0x0/0x2eb [] :ext3:ext3_ordered_writepage+0xf1/0x198 [] mpage_writepages+0x1ab/0x34c [] :ext3:ext3_ordered_writepage+0x0/0x198 [] do_readv_writev+0x272/0x295 [] do_writepages+0x29/0x2f [] __filemap_fdatawrite_range+0x51/0x5b [] do_fsync+0x2f/0xa3 [] __do_fsync+0x23/0x36 [] tracesys+0xd1/0xdc BUG: soft lockup detected on CPU#1! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] default_idle+0x0/0x50 [] apic_timer_interrupt+0x66/0x6c [] default_idle+0x29/0x50 [] cpu
Include hrtimer.h in tick.h.
From: Tony Breeds <[EMAIL PROTECTED]> struct tick_shed in tick.h uses struct hrtimer, explictly include the hrtimer header file to make sure this is defined. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- include/linux/tick.h |1 + 1 file changed, 1 insertion(+) Index: working/include/linux/tick.h === --- working.orig/include/linux/tick.h +++ working/include/linux/tick.h @@ -7,6 +7,7 @@ #define _LINUX_TICK_H #include +#include #ifdef CONFIG_GENERIC_CLOCKEVENTS Yours Tony linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/ Jan 28 - Feb 02 2008 The Australian Linux Technical Conference! - 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/
[PATCH] Add per clocksource hook to settimeofday().
I'm working on a clocksource implementation for all powerpc platforms.
some of these platforms needs to do a little work as part of the
settimeofday() syscall and I can't see a way to do that without adding
this hook to clocksource.
From: Tony Breeds <[EMAIL PROTECTED]>
Add per clocksource hook to settimeofday().
Some clocksources need to do extra work as part of the settimeofday call, this
hook make it easy to do so.
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---
include/linux/clocksource.h |3 +++
kernel/time/timekeeping.c |3 +++
2 files changed, 6 insertions(+)
Index: working/include/linux/clocksource.h
===
--- working.orig/include/linux/clocksource.h
+++ working/include/linux/clocksource.h
@@ -50,6 +50,7 @@ struct clocksource;
* @flags: flags describing special properties
* @vread: vsyscall based read
* @resume:resume function for the clocksource, if necessary
+ * @settimeofday: [Optional] Do arch specific work during do_settimeofday
* @cycle_interval:Used internally by timekeeping core, please ignore.
* @xtime_interval:Used internally by timekeeping core, please ignore.
*/
@@ -68,6 +69,8 @@ struct clocksource {
cycle_t (*vread)(void);
void (*resume)(void);
+ void (*settimeofday)(struct clocksource *cs, struct timespec *ts);
+
/* timekeeping specific data, ignore */
cycle_t cycle_interval;
u64 xtime_interval;
Index: working/kernel/time/timekeeping.c
===
--- working.orig/kernel/time/timekeeping.c
+++ working/kernel/time/timekeeping.c
@@ -151,6 +151,9 @@ int do_settimeofday(struct timespec *tv)
clock->error = 0;
ntp_clear();
+ if (clock->settimeofday)
+ clock->settimeofday(clock, tv);
+
update_vsyscall(&xtime, clock);
write_sequnlock_irqrestore(&xtime_lock, flags);
Yours Tony
linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
-
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/
Re: [PATCH] CONFIG_INET depend on CONFIG_SYSCTL
From: Yoshinori Sato <[EMAIL PROTECTED]> Date: Wed, 13 Jun 2007 14:59:16 +0900 > At Tue, 12 Jun 2007 01:08:55 -0700 (PDT), > David Miller wrote: > > > 2) It is much better to add the appropriate CONFIG_SYSCTL > >ifdefs to the INET code than to force it on for everyone. > > It examined that, but many corrections become necessary. I understand, but embedded people will not be happy that SYSFS is a requirement for IPV4 networking. Every little bit of space savings matters for them. - 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/
Re: [RFC][PATCH 1/1] support for user-space buffers in kfifo
Le mardi 12 juin 2007 à 21:21 -0500, Nelson Castillo a écrit : > On 6/12/07, Stelian Pop <[EMAIL PROTECTED]> wrote: > > Le mardi 12 juin 2007 à 11:24 -0500, Nelson Castillo a écrit : > > > On 6/12/07, Stelian Pop <[EMAIL PROTECTED]> wrote: > > > (cut) > > > > accessing userspace memory with a spinlock taken (moreover an > > > > irqsave() > > > > one) is bad bad bad. > > > > > > Hi Stelian. > > > > > > I'm sending the new patch without kfifo_put_user and kfifo_get_user. > > > > Ok, I have a few formatting/documentation comments: > > Applied, thanks. > > > Other than that I'm ok with this patch. > > Submitting. > > Regards, Nelson.- > > Signed-off-by: Nelson Castillo <[EMAIL PROTECTED]> Signed-off-by: Stelian Pop <[EMAIL PROTECTED]> Thanks, Stelian. -- Stelian Pop <[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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CONFIG_INET depend on CONFIG_SYSCTL
At Tue, 12 Jun 2007 01:08:55 -0700 (PDT), David Miller wrote: > > From: Yoshinori Sato <[EMAIL PROTECTED]> > Date: Tue, 12 Jun 2007 16:38:55 +0900 > > > It cannot build with CONFIG_SYSCTL=n and CONFIG_INET=y. > > In case of CONFIG_INET=y it should become CONFIG_SYSCTL=y. > > > > Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]> > > 1) Please post networking patches to [EMAIL PROTECTED] >which has been added to the CC: It was understood. > 2) It is much better to add the appropriate CONFIG_SYSCTL >ifdefs to the INET code than to force it on for everyone. It examined that, but many corrections become necessary. -- Yoshinori Sato <[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 the FAQ at http://www.tux.org/lkml/
Re: Proposal: change keycode for scancode e0 32 from 150 to 172
H. Peter Anvin wrote: Hans de Goede wrote: In order to be able to better test / develop this I've bought 2 cheap such keyboards today, one ps2 and one both usb and ps2 capable. When comparing usb vs ps2 / testing the keycodes generated for the easy access keys on my trust (microsoft compatible) keyboard. I noticed the homepage key sends keycode 150 with ps2 and 172 with USB, or for those who don't know the keycodes by head with ps2 it sends KEY_WWW and with usb it sends KEY_HOMEPAGE I just tested this using Microsoft Natural Keyboard Pro, which is a dual-mode (USB-PS/2) keyboard. This key is labelled Web/Home and has a picture of a house on the keycap. In PS/2 mode it reports E0 32 which gets converted to keycode 150. In USB mode it reports E0 02 which gets converted to keycode 172. Thanks, that confirms that the ps/2 translation (which assumes a microsoft or compatible keyboard) is wrong. I don't know if it's the keyboard itself that's being inconsistent, or if it is the table in usbkbd.c that's broken (in which case it should be fixed to be consistent with the keyboard in PS/2 mode.) See below. I personally believe that the usb behaviour is correct and that the ps/2 code should be modified to match for consistency. The ps/2 scancode to keycode mapping is set up to handle easy access / internet keys for microsoft compatible keyboards. So what is the right code to send here, tricky, see: http://www.s2.com.br/s2arquivos/361/Imagens/555Image.jpg http://www.keyboardco.com/keyboard_images/microsoft_ergonomic_keyboard_4000_black_usb_large.jpg The logo on the key is a homepage logo, the text below is www/homepage. So what to send? I believe that for consistency with the usb codes send it should be KEY_HOMEPAGE, but thats based on a sample of 1 usb keyboard. Input on what other usb keyboards send for the key with the homepage iocn is very much welcome. You seem to be of the opinion that "usb behaviour is correct", but don't give any motivation why usb should take precedence. Offhand, I would expect there to be fewer translation layers for PS/2 and would therefore assume PS/2 is more inherently correct. I'm of the opinion that the USB behaviour is correct, because usb generates the 172 / KEY_HOMEPAGE in accordance with: http://www.usb.org/developers/devclass_docs/Hut1_12.pdf Page 84 Where as in the ps2 world there is no official scancode mapping for these special keys, hence I talk about microsoft and compatibles. Also the number of layers of translation in both cases is just 1: one table (ps2) versus one switch statement (usb) Regards, Hans - 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/
Re: [PATCH 5/9] readahead: on-demand readahead logic
On Wed, 2007-06-13 at 12:00 +0800, Fengguang Wu wrote:
> On Wed, Jun 13, 2007 at 11:40:33AM +1000, Rusty Russell wrote:
> > +/* If page has PG_readahead flag set, call async readahead logic. */
> > +static inline void
> > +page_cache_check_readahead_page(struct address_space *mapping,
> > + struct file_ra_state *ra,
> > + struct file *filp,
> > + struct page *pg,
> > + pgoff_t offset,
> > + unsigned long size)
> > +{
> > + if (!PageReadahead(pg))
> > + return;
> > + page_cache_async_readahead(mapping, ra, filp, pg, offset, size);
> > +}
>
> This function might not be necessary?
> I guess the explicit code is clear enough.
Hi Fengguang,
Yes, I think you're right.
> > static unsigned long
> > ondemand_readahead(struct address_space *mapping,
> >struct file_ra_state *ra, struct file *filp,
> > - struct page *page, pgoff_t offset,
> > + bool hit_lookahead_marker, pgoff_t offset,
>
> Or use names like async/is_async for hit_lookahead_marker?
I wasn't sure. The argument says "we've hit a marker, so do readahead
even if doesn't look sequential.". Now, you and I know that only
happens if it's an async readahead, but that's not really relevant to
this function.
> Seems that you have accepted the 'lookahead' term ;)
Yes, but I shouldn't, because marker is still called PG_readahead 8) I
changed this to "hit_readahead_marker" instead.
> > +/**
> > + * page_cache_async_readahead - file readahead for marked pages
> > + * @mapping: address_space which holds the pagecache and I/O vectors
> > + * @ra: file_ra_state which holds the readahead state
> > + * @filp: passed on to ->readpage() and ->readpages()
> > + * @page: the page at @offset which has the PageReadahead flag set
>
>^PG_readahead
Oh, yes.
> > + * @offset: start offset into @mapping, in PAGE_CACHE_SIZE units
> > + * @req_size: hint: total size of the read which the caller is performing
> > in
> > + *PAGE_CACHE_SIZE units
>
> ^in pagecache pages?
> //Christoph is changing the fixed PAGE_CACHE_SIZE to variable ones.
This came from your patch, but it sounds like a good change. Also the
PAGE_CACHE_SIZE units above.
> I like this new comment!
Heh, maybe that means I finally understand the code 8).
OK, here is revised patch with your changes:
Split ondemand readahead interface into two functions. I think this
makes it a little clearer for non-readahead experts (like Rusty).
Internally they both call ondemand_readahead(), but the page argument
is changed to an obvious boolean flag.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r e96f11f61577 fs/ext3/dir.c
--- a/fs/ext3/dir.c Sun Jun 10 18:25:28 2007 +1000
+++ b/fs/ext3/dir.c Wed Jun 13 15:16:49 2007 +1000
@@ -139,10 +139,10 @@ static int ext3_readdir(struct file * fi
pgoff_t index = map_bh.b_blocknr >>
(PAGE_CACHE_SHIFT - inode->i_blkbits);
if (!ra_has_index(&filp->f_ra, index))
- page_cache_readahead_ondemand(
+ page_cache_sync_readahead(
sb->s_bdev->bd_inode->i_mapping,
&filp->f_ra, filp,
- NULL, index, 1);
+ index, 1);
filp->f_ra.prev_index = index;
bh = ext3_bread(NULL, inode, blk, 0, &err);
}
diff -r e96f11f61577 fs/ext4/dir.c
--- a/fs/ext4/dir.c Sun Jun 10 18:25:28 2007 +1000
+++ b/fs/ext4/dir.c Wed Jun 13 15:16:49 2007 +1000
@@ -138,10 +138,10 @@ static int ext4_readdir(struct file * fi
pgoff_t index = map_bh.b_blocknr >>
(PAGE_CACHE_SHIFT - inode->i_blkbits);
if (!ra_has_index(&filp->f_ra, index))
- page_cache_readahead_ondemand(
+ page_cache_sync_readahead(
sb->s_bdev->bd_inode->i_mapping,
&filp->f_ra, filp,
- NULL, index, 1);
+ index, 1);
filp->f_ra.prev_index = index;
bh = ext4_bread(NULL, inode, blk, 0, &err);
}
diff -r e96f11f61577 fs/splice.c
--- a/fs/splice.c Sun Jun 10 18:25:28 2007 +1000
+++ b/fs/splice.c Wed Jun 13 15:16:49 2007 +1000
@@ -312,8 +312,8 @@ __generic_file_splice_read(struct file *
*/
page = find_get_page(mapping, index);
if (!page) {
- page_cache_readahead_onde
Re: [PATCH 2/3] [CRYPTO] Add optimized SHA-1 implementation for i486+
On Tue, Jun 12, 2007 at 01:05:44AM -0400, [EMAIL PROTECTED] wrote: > > I got this code from Nettle, originally, and I never looked at the SHA-1 > > round structure very closely. I'll give that approach a try. > > Attached is some (tested, working, and public domain) assembly code for > three different sha_transform implementations. Compared to C code, the > timings to hash 10 MiB on a 600 MHz PIII are: > > The names are the order they were written in. "One" is the lib/sha1.c > code (547 bytes with -Os). "Four" is a 5x unrolled C version (1106 bytes). I'd like to see your version four. -- Mathematics is the supreme nostalgia of our time. - 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/
Re: [PATCH] random: fix folding
> Folding is done to minimize the theoretical possibility of systematic > weakness in the particular bits of the SHA1 hash output. The result of > this bug is that 16 out of 80 bits are un-folded. Without a major new > vulnerability being found in SHA1, this is harmless, but still worth > fixing. Actually, even WITH a major new vulnerability found in SHA1, it's harmless. Sorry to put BUG in caps earlier; it actually doesn't warrant the sort of adjective I used. The purpose of the folding is to ensure that the feedback includes bits underivable from the output. Just outputting the first 80 bits and feeding back all 160 would achieve that effect; the folding is of pretty infinitesimal benefit. Note that last five rounds have as major outputs e, d, c, b, and a, in that order. Thus, the first words are the "most hashed" and the ones most worth using as output... which happens naturally with no folding. The folding is a submicroscopic bit of additional mixing. Frankly, the code size savings probably makes it worth deleting it. (That would also give you more flexibility to select the output/feedback ratio in whatever way you like.) - 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/
Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS
Neat! It's great to see somebody else waking up to the idea that storage media is NOT to be trusted. Judging by the design paper, it looks like your structs have some alignment problems. The usual wishlist: * inode-to-pathnames mapping * a subvolume that is a single file (disk image, database, etc.) * directory indexes to better support Wine and Samba * secure delete via destruction of per-file or per-block random crypto keys * fast (seekless) access to normal-sized SE Linux data * atomic creation of copy-on-write directory trees * immutable bits like UFS has * hole punch ability * insert/delete ability (add/remove a chunk in the middle of a file) - 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/
[PATCH] random: fix folding
On Tue, Jun 12, 2007 at 01:05:44AM -0400, [EMAIL PROTECTED] wrote: > I also noticed a glaring BUG in the folding at the end of extract_buf at > drivers/char/random.c:797. That should be: > > /* >* In case the hash function has some recognizable >* output pattern, we fold it in half. >*/ > > buf[0] ^= buf[4]; > buf[1] ^= buf[3]; > buf[2] ^= rol32(buf[2], 16);// <--- Bug was here > memcpy(out, buf, EXTRACT_SIZE); > memset(buf, 0, sizeof(buf)); > > if the code is to match the comment. Conveniently, the random.c maintainer is reading this thread. Good spotting, not sure how I bungled that. random: fix output buffer folding (As reported by [EMAIL PROTECTED]) Folding is done to minimize the theoretical possibility of systematic weakness in the particular bits of the SHA1 hash output. The result of this bug is that 16 out of 80 bits are un-folded. Without a major new vulnerability being found in SHA1, this is harmless, but still worth fixing. Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> Index: mm/drivers/char/random.c === --- mm.orig/drivers/char/random.c 2007-06-12 23:50:54.0 -0500 +++ mm/drivers/char/random.c2007-06-12 23:51:51.0 -0500 @@ -794,7 +794,7 @@ static void extract_buf(struct entropy_s buf[0] ^= buf[3]; buf[1] ^= buf[4]; - buf[0] ^= rol32(buf[3], 16); + buf[2] ^= rol32(buf[2], 16); memcpy(out, buf, EXTRACT_SIZE); memset(buf, 0, sizeof(buf)); } -- Mathematics is the supreme nostalgia of our time. - 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/
Re: [PATCH 4/6] include linux pci_id-h add amd northbridge defines
--- Dave Jones <[EMAIL PROTECTED]> wrote: > On Mon, Jun 11, 2007 at 04:49:47PM -0700, Greg Kroah-Hartman wrote: > > On Mon, Jun 11, 2007 at 04:30:11PM -0700, Doug Thompson wrote: > > > I am working with the k8 driver and its dealing with a race with the > mcelog device as both > access > > > the K8 NB. The K8 driver does use these regs and it currently has > #ifndef s in it for both > of > > > them. > > > > > > I guess I could have submitted the patch when the K8 driver was > submitted. > > > > That would be preferable, thanks. > > Even better (IMO), if they're not used by any other driver (which seems > to be the case), keep the defines local to the driver. > > Dave There are 4 K8 Memory Controller registers, 2 of which are already in pci_ids.h (and are used by others) and 2 more that I need. I define the 2 I need now in the file, but was worried when someone else might add them to the pci_ids.h file. Just figured that it would be better to keep all 4 together. So is the model of such placement to locate the #define near to the sole consumer of that item? And if used by others, to move it to the pci_ids.h file? thanks doug t - 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/
Re: [PATCH 1/5] Add the explanation and sample of RapidIO DTS sector to the document of booting-without-of.txt file.
+ k) RapidIO + + Required properties: + +- device_type : Should be "rapidio" There is no OF binding, so no. +- compatible : Should be "fsl,rapidio-v0.0" or "fsl,rapidio-v1.0" + and so on. The version number is got from IP Block Revision + Register of RapidIO controller. It's better to use real device names, just like everyone else. +- #address-cells : Address representation for "rapidio" devices. + This field represents the number of cells needed to represent + the RapidIO address of the registers. For supporting more than + 36-bits RapidIO address, this field should be <2>. More than 32 bit? +- interrupt-parent : the phandle for the interrupt controller that + services interrupts for this device. Not required, depends on the interrupt tree of the system. +- interrupts : where a is the interrupt number and b is a + field that represents an encoding of the sense and level + information for the interrupt. No. The format of an "interrupts" entry is defined by the interrupt domain this device sits in, not by the device itself. For this sector, interrupts order should be + . That's to be defined in the binding for your specific device, not in a more generic rapidio binding. + #address-cells = <2>; You want a #size-cells as well. Hope this helps, Segher - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 12, 2007, Greg KH <[EMAIL PROTECTED]> wrote: > (see previous long thread about v3 and why the kernel developers > hate it, it all still applys to the final draft.) You mean all the misunderstandings? ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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/
Re: [PATCHSET 2.6.22-rc4] sysfs: fix race conditions
Greg KH wrote: > On Mon, Jun 11, 2007 at 03:15:39PM +0900, Tejun Heo wrote: >> Andrew Morton wrote: This patchset contains three minimal backports of fixes in -mm. With all patches in the patchset and sysfs-races.patch applied, kernel survived ~20 hours of stress test without any problem. >>> So these are being proposed for 2.6.22? >> Yeap. >> >>> I do wonder about Rafael's bug which he bisected down to >>> gregkh-driver-sysfs-use-singly-linked-list-for-sysfs_dirent-tree.patch. >>> >>> If that won't be a problem in this patchset then I spose it's probably best >>> to go ahead with a 2.6.22 merge, but it's more a Greg thing than a me >>> thing. >> I'm currently debugging that and it's irrelevant to these fixes. The >> bug is introduced far after the fixes. >> >>> I don't have a tree to merge these patches into, unless I drop all the >>> patches which are in Greg's tree. >>> >>> Greg, can I leave it up to you to decide how we are to proceed here? >> I can rebase all sysfs patches in -mm on top of linus#master + these >> fixes if necessary. > > Ok, I've sent these to Linus, so if he takes them, can you rebase your > patches on top of this and resend the whole tree to me (or just the ones > that needed to be modified, if that's easier.) Sure thing. > thanks again for this fix, I really appreciate it. :-) -- tejun - 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/
Re: [PATCH] x86: fix improper .init-type section references
> > Yup, we were only discussing possibility that modpost not complain > about .init -> .exit references that will never go oops (because the arch > guarantees that). And there are no good reasosns why the rules should be different for i386 and powerpc. This type of special casing is always bad. Think about it a little. Someone writes a generic driver and test it on i386 - OK. But for powerpc it result in a build failure. It would be so much better to warn about this situation early. We had this exact issue in loop.c recently - so it is not a made up example. [I recall it was ia64 that had a build failure but the example still holds ture] Sam - 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/
[PATCH] Force rcutorture tasks to spread over CPUs
Of late, the scheduler seems to have decided to make things too easy for
RCU -- on some configurations, all of the rcutorture tasks end up on the
same CPU, which doesn't do a very good job of torturing RCU. This patch
helps the scheduler spread these tasks out by forcing a 20-millisecond
burst of CPU-bound execution on each of rcutorture's tasks, which seems
to work reasonably well in practice.
My challenge for those working on the scheduler is to make this patch
unnecessary. ;-)
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
rcutorture.c | 20
1 file changed, 20 insertions(+)
diff -urpNa -X dontdiff linux-2.6.21.4-rt13/kernel/rcutorture.c
linux-2.6.21.4-rt13-rcutorturespread/kernel/rcutorture.c
--- linux-2.6.21.4-rt13/kernel/rcutorture.c 2007-06-12 09:19:02.0
-0700
+++ linux-2.6.21.4-rt13-rcutorturespread/kernel/rcutorture.c2007-06-12
21:05:05.0 -0700
@@ -102,6 +102,8 @@ struct rcu_torture {
};
static int fullstop = 0; /* stop generating callbacks at test end. */
+static int startwriters; /* force load-balancing of writers. */
+static int startreaders; /* force load-balancing of readers. */
static LIST_HEAD(rcu_torture_freelist);
static struct rcu_torture *rcu_torture_current = NULL;
static long rcu_torture_current_version = 0;
@@ -525,6 +527,8 @@ rcu_torture_writer(void *arg)
static DEFINE_RCU_RANDOM(rand);
VERBOSE_PRINTK_STRING("rcu_torture_writer task started");
+ while (!startwriters)
+ barrier(); /* Force scheduler to spread over CPUs. */
set_user_nice(current, 19);
current->flags |= PF_NOFREEZE;
@@ -565,6 +569,8 @@ rcu_torture_fakewriter(void *arg)
DEFINE_RCU_RANDOM(rand);
VERBOSE_PRINTK_STRING("rcu_torture_fakewriter task started");
+ while (!startwriters)
+ barrier(); /* Force scheduler to spread over CPUs. */
set_user_nice(current, 19);
current->flags |= PF_NOFREEZE;
@@ -596,6 +602,8 @@ rcu_torture_reader(void *arg)
int pipe_count;
VERBOSE_PRINTK_STRING("rcu_torture_reader task started");
+ while (!startreaders)
+ barrier(); /* Force scheduler to spread over CPUs. */
set_user_nice(current, 19);
current->flags |= PF_NOFREEZE;
@@ -929,6 +937,8 @@ rcu_torture_init(void)
/* Start up the kthreads. */
+ startwriters = 0;
+ barrier();
VERBOSE_PRINTK_STRING("Creating rcu_torture_writer task");
writer_task = kthread_run(rcu_torture_writer, NULL,
"rcu_torture_writer");
@@ -956,6 +966,12 @@ rcu_torture_init(void)
goto unwind;
}
}
+ barrier();
+ startwriters = 1;
+ schedule_timeout_interruptible(round_jiffies_relative(HZ/50));
+
+ startreaders = 0;
+ barrier();
reader_tasks = kzalloc(nrealreaders * sizeof(reader_tasks[0]),
GFP_KERNEL);
if (reader_tasks == NULL) {
@@ -974,6 +990,10 @@ rcu_torture_init(void)
goto unwind;
}
}
+ schedule_timeout_interruptible(round_jiffies_relative(HZ/50));
+ barrier();
+ startreaders = 1;
+
if (stat_interval > 0) {
VERBOSE_PRINTK_STRING("Creating rcu_torture_stats task");
stats_task = kthread_run(rcu_torture_stats, NULL,
-
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/
[PATCH] Export radix_tree_preload()
Upcoming XFS functionality [1] uses radix trees and uses the preload functions. XFS can be built as a module and hence we need radix_tree_preload() exported. radix_tree_preload_end() is a static inline, so it doesn't need exporting. [1] http://marc.info/?l=linux-xfs&m=118170839531601&w=2 Signed-Off-By: Dave Chinner <[EMAIL PROTECTED]> --- lib/radix-tree.c |1 + 1 file changed, 1 insertion(+) Index: 2.6.x-xfs-new/lib/radix-tree.c === --- 2.6.x-xfs-new.orig/lib/radix-tree.c 2007-03-29 19:00:53.802804161 +1000 +++ 2.6.x-xfs-new/lib/radix-tree.c 2007-03-29 19:07:10.297495640 +1000 @@ -151,6 +151,7 @@ int radix_tree_preload(gfp_t gfp_mask) out: return ret; } +EXPORT_SYMBOL(radix_tree_preload); static inline void tag_set(struct radix_tree_node *node, unsigned int tag, int offset) - 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/
[PATCH]is_power_of_2-hfs/mdb.c
Replacing (n & (n-1)) in the context of power of 2 checks with is_power_of_2 Signed-off-by: vignesh babu <[EMAIL PROTECTED]> --- diff --git a/fs/hfs/mdb.c b/fs/hfs/mdb.c index b4651e1..8bda11d 100644 --- a/fs/hfs/mdb.c +++ b/fs/hfs/mdb.c @@ -11,6 +11,7 @@ #include #include #include +#include #include "hfs_fs.h" #include "btree.h" @@ -106,7 +107,7 @@ int hfs_mdb_get(struct super_block *sb) size = min(HFS_SB(sb)->alloc_blksz, (u32)PAGE_SIZE); /* size must be a multiple of 512 */ - while (size & (size - 1)) + while (!is_power_of_2(size)) size -= HFS_SECTOR_SIZE; sect = be16_to_cpu(mdb->drAlBlSt) + part_start; /* align block size to first sector */ -- Vignesh Babu BM _ "Why is it that every time I'm with you, makes me believe in magic?" - 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/
Re: [PATCH 5/9] readahead: on-demand readahead logic
On Wed, Jun 13, 2007 at 11:40:33AM +1000, Rusty Russell wrote:
> On Tue, 2007-06-12 at 18:35 +0800, Fengguang Wu wrote:
> > > This seems a little like two functions crammed into one. Do you think
> > > page_cache_readahead_ondemand() should be split into
> > > "page_cache_readahead()" which doesn't take a page*, and
> > > "page_cache_check_readahead_page()" which is an inline which does the
> > > PageReadahead(page) check as well?
> >
> > page_cache_check_readahead_page(..., page) is a good idea.
> > But which part of the code should we put to page_cache_readahead()
> > that does not take a page param?
>
> OK, here's my attempt. I also made them return void, since none of the
> callers seem to mind. I didn't change the internals much: I think
> they're pretty clear and I didn't want to clash if you decided to rename
> the "ra" fields. It compiles and boots.
>
> Thoughts?
Thank you, comments follow.
> +void page_cache_sync_readahead(struct address_space *mapping,
> +struct file_ra_state *ra,
> +struct file *filp,
> +pgoff_t offset,
> +unsigned long size);
> +
> +void page_cache_async_readahead(struct address_space *mapping,
> + struct file_ra_state *ra,
> + struct file *filp,
> + struct page *pg,
> + pgoff_t offset,
> + unsigned long size);
Got your idea: it looks like a nice split.
> +/* If page has PG_readahead flag set, call async readahead logic. */
> +static inline void
> +page_cache_check_readahead_page(struct address_space *mapping,
> + struct file_ra_state *ra,
> + struct file *filp,
> + struct page *pg,
> + pgoff_t offset,
> + unsigned long size)
> +{
> + if (!PageReadahead(pg))
> + return;
> + page_cache_async_readahead(mapping, ra, filp, pg, offset, size);
> +}
This function might not be necessary?
I guess the explicit code is clear enough.
> static unsigned long
> ondemand_readahead(struct address_space *mapping,
> struct file_ra_state *ra, struct file *filp,
> -struct page *page, pgoff_t offset,
> +bool hit_lookahead_marker, pgoff_t offset,
Or use names like async/is_async for hit_lookahead_marker?
Seems that you have accepted the 'lookahead' term ;)
> unsigned long req_size)
> {
> unsigned long max; /* max readahead pages */
> @@ -379,7 +379,7 @@ ondemand_readahead(struct address_space
>* Standalone, small read.
>* Read as is, and do not pollute the readahead state.
>*/
> - if (!page && !sequential) {
> + if (!hit_lookahead_marker && !sequential) {
> return __do_page_cache_readahead(mapping, filp,
> offset, req_size, 0);
> }
> @@ -400,7 +400,7 @@ ondemand_readahead(struct address_space
>* E.g. interleaved reads.
>* Not knowing its readahead pos/size, bet on the minimal possible one.
>*/
> - if (page) {
> + if (hit_lookahead_marker) {
> ra_index++;
> ra_size = min(4 * ra_size, max);
> }
> +/**
> + * page_cache_async_readahead - file readahead for marked pages
> + * @mapping: address_space which holds the pagecache and I/O vectors
> + * @ra: file_ra_state which holds the readahead state
> + * @filp: passed on to ->readpage() and ->readpages()
> + * @page: the page at @offset which has the PageReadahead flag set
^PG_readahead
> + * @offset: start offset into @mapping, in PAGE_CACHE_SIZE units
> + * @req_size: hint: total size of the read which the caller is performing in
> + *PAGE_CACHE_SIZE units
^in pagecache pages?
//Christoph is changing the fixed PAGE_CACHE_SIZE to variable ones.
> + *
> + * page_cache_async_ondemand() should be called when a page is used which
> + * has the PageReadahead flag: this is a marker to suggest that the
> application
^PG_readahead
> + * has used up enough of the readahead window that we should start pulling in
> + * more pages. */
> +void
> +page_cache_async_readahead(struct address_space *mapping,
> +struct file_ra_state *ra, struct file *filp,
> +struct page *page, pgoff_t offset,
> +unsigned long req_size)
> +{
> + /* no read-ahead */
> + if (!ra->ra_pages)
> + return;
> +
> + /*
> + * Same bit is used for PG_readahead and PG_reclaim.
I like this new comment!
> + */
> + if (PageWriteback(page))
> + return;
> +
> + ClearPageReadahead(page);
Thank you,
Fengguang
-
To unsubscribe
Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS
> "Chris" == Chris Mason <[EMAIL PROTECTED]> writes: Chris> After the last FS summit, I started working on a new filesystem Chris> that maintains checksums of all file data and metadata. Many Chris> thanks to Zach Brown for his ideas, and to Dave Chinner for his Chris> help on benchmarking analysis. Chris> The basic list of features looks like this: Chris> * Extent based file storage (2^64 max file size) Chris> * Space efficient packing of small files Chris> * Space efficient indexed directories Chris> * Dynamic inode allocation Chris> * Writable snapshots Chris> * Subvolumes (separate internal filesystem roots) Chris> - Object level mirroring and striping Chris> * Checksums on data and metadata (multiple algorithms available) Chris> - Strong integration with device mapper for multiple device support Chris> - Online filesystem check Chris> * Very fast offline filesystem check Chris> - Efficient incremental backup and FS mirroring So, can you resize a filesystem both bigger and smaller? Or is that implicit in the Object level mirroring and striping? As a user of Netapps, having quotas (if only for reporting purposes) and some way to migrate non-used files to slower/cheaper storage would be great. Ie. being able to setup two pools, one being RAID6, the other being RAID1, where all currently accessed files are in the RAID1 setup, but if un-used get migrated to the RAID6 area. And of course some way for efficient backups and more importantly RESTORES of data which is segregated like this. John - 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/
Re: drbd 8.0.2/3 doesn't load under kernel 2.6.21
It turns out I was adding the web100 patch (http://www.web100.org) to the 2.6.21 kernel and that's what causes the symbol resolving problem below. Adding the corresponding version of the web100 patch to the 2.6.20 kernel makes this problem appear there as well. On fresh versions of the kernel, this problem does not occur. At the moment, it's not possible to have a current kernel that contains both drbd and web100. On a 64-bit Gentoo system with Gentoo's 2.6.21 kernel, drbd 8.0.2/3 complains when I try to load the module: [ 134.141363] drbd: Unknown symbol cn_fini [ 134.141399] drbd: Unknown symbol cn_init It works fine when I compile it and load in the previous kernel version, 2.6.20 and the symbols are present in the map file ./System.map-genkernel-x86_64-2.6.21-gentoo-r2:802935aa t cn_fini ./System.map-genkernel-x86_64-2.6.21-gentoo-r2:8029362a t cn_init I am c'cing the kernel mailing list because this appears to be a problem with how any module accesses symbols in the kernel, not just drbd. Source was compiled with Gentoo gcc-4.1.2, glibc-2.5-r3. -- Maurice Volaski, [EMAIL PROTECTED] Computing Support, Rose F. Kennedy Center Albert Einstein College of Medicine of Yeshiva University - 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/
Re: [ck] Re: kernel scedular
Martin Steigerwald wrote: Am Sonntag 10 Juni 2007 schrieb Linus Torvalds: Hi Linus! Ehh.. It was tested extensively by lots of people. It was in -mm for a while, and yes, there have been tons of people testing both. I've followed it, and it seems fair to say that yes, Ingo took a lot of ideas from SD, but CFS seems to have gotten more people involved, and we had several people compare the two, and CFS was generally better. Well actually I did not see that general result yet. I have seen quite some testings and quite some reports on the ck patch mailinglist also where in favor of SD. If it matters I will collect those, but I think Ingo already did include most of them in his summary. I'd just like to say that last time I tested CFS it was very slow on context switching. I don't know if this has been improved, but I think it should be. I'm not talking about context switching with heaps of tasks, but about lmbench 2-task ping pongs and such. Also it used pretty small timeslices to achieve interactivity, which didn't seem like a good idea. I wonder if that's been fixed? -- SUSE Labs, Novell Inc. - 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/
Re: [GIT PATCH] sysfs fixes for 2.6.22-rc4
Greg KH wrote: > Eric Sandeen (1): > sysfs: store sysfs inode nrs in s_ino to avoid readdir oopses To be fair, Tejun wrote that one too, I just backported & tried to simplify it a bit for -stable. :) > Tejun Heo (2): > sysfs: fix condition check in sysfs_drop_dentry() > sysfs: fix race condition around sd->s_dentry, take#2 > Glad to see these are making their way out, we've had people hit these bugs too. And they beat on this basic patchset quite a lot, with good results. Thanks! -Eric - 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/
Re: [PATCH] x86: fix improper .init-type section references
Hi Sam,
On 6/12/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
On Tue, Jun 12, 2007 at 07:39:30PM +0530, Satyam Sharma wrote:
> On 6/12/07, Jan Beulich <[EMAIL PROTECTED]> wrote:
> >>> And from a purely theoretical
> >>> perspective I don't think such references should be considered bad -
> >>> .exit.* should be discarded together with .init.* if unloading is
> >>> impossible (built-in or configured off), not before module/kernel
> >>> initialization.
> >>
> >>Hmm, but that's not how things are, presently. __exit marked
> >>functions are simply not linked into the kernel (when that module
> >>is being built-in) at all -- this "discard" happens at _build time_
> >>(to save on kernel image size).
> >
> >Not really, at least not for i386 and x86-64 - see their vmlinux.lds.S
> >files.
>
> For those archs, yes, you're right that modpost should be
> special-casing (based on arch) before complaining for
> .init -> .exit references.
No.
References from __init to __exit is wrong independent on architecture.
[...]
So for the latter we will have an oops where we for the first have a build
time failure.
Is that (oops possibility on i386) really true? (.exit.{text, data}) is also
between __init_begin and __init_end and hence will be discarded
_along_ with (not before) .init.{text, data} during run-time I think,
which means .init -> .exit reference modpost warnings (on said
archs) are truly bogus ...
powerpc discards them at buildtime, i386 at runtime.
Yup, we were only discussing possibility that modpost not complain
about .init -> .exit references that will never go oops (because the arch
guarantees that).
Satyam
-
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/
Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS
On Tue, Jun 12, 2007 at 04:14:39PM -0400, Chris Mason wrote:
> > Aside from folding snapshot history into the origin's namespace... It
> > could be possible to have a mount.btrfs that allows subvolumes and/or
> > snapshot volumes to be mounted as unique roots? I'd imagine a bind
> > mount _could_ provide this too? Anyway, I'm just interested in
> > understanding the vision for managing the potentially complex nature
> > of a Btrfs namespace.
>
> One option is to put the real btrfs root into some directory in
> (/sys/fs/btrfs/$device?) and then use tools in userland to mount -o bind
> outside of that. I wanted to wait to get fancy until I had a better
> idea of how people would use the feature.
We already support mounting into subdirectories of a filesystem for
nfs connection sharing. The patch below makes use of this to allow
mounting any subdirectory of a btrfs filesystem by specifying it in
the form of /dev/somedevice:directory and when no subdirectory
is specified uses 'default'. To make this more useful btrfs directories
should grow some way to be marked head of a subvolume, and we'd need
a more useful way to actually create subvolumes and snapshots without
fugly ioctls.
Btw, do create a subvolume with my patch you need to escape back to
the global root which is done by specifing /dev/somedevice:. as the
device on the mount command line.
Index: btrfs-0.2/super.c
===
--- btrfs-0.2.orig/super.c 2007-06-13 03:44:38.0 +0200
+++ btrfs-0.2/super.c 2007-06-13 03:48:35.0 +0200
@@ -17,6 +17,7 @@
*/
#include
+#include
#include
#include
#include
@@ -26,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -135,11 +137,114 @@ static void btrfs_write_super(struct sup
sb->s_dirt = 0;
}
+/*
+ * This is almost a copy of get_sb_bdev in fs/super.c.
+ * We need the local copy to allow direct mounting of
+ * subvolumes, but this could be easily integrated back
+ * into the generic version. --hch
+ */
+
+/* start copy & paste */
+static int set_bdev_super(struct super_block *s, void *data)
+{
+ s->s_bdev = data;
+ s->s_dev = s->s_bdev->bd_dev;
+ return 0;
+}
+
+static int test_bdev_super(struct super_block *s, void *data)
+{
+ return (void *)s->s_bdev == data;
+}
+
+int btrfs_get_sb_bdev(struct file_system_type *fs_type,
+ int flags, const char *dev_name, void *data,
+ int (*fill_super)(struct super_block *, void *, int),
+ struct vfsmount *mnt, const char *subvol)
+{
+ struct block_device *bdev = NULL;
+ struct super_block *s;
+ struct dentry *root;
+ int error = 0;
+
+ bdev = open_bdev_excl(dev_name, flags, fs_type);
+ if (IS_ERR(bdev))
+ return PTR_ERR(bdev);
+
+ /*
+* once the super is inserted into the list by sget, s_umount
+* will protect the lockfs code from trying to start a snapshot
+* while we are mounting
+*/
+ down(&bdev->bd_mount_sem);
+ s = sget(fs_type, test_bdev_super, set_bdev_super, bdev);
+ up(&bdev->bd_mount_sem);
+ if (IS_ERR(s))
+ goto error_s;
+
+ if (s->s_root) {
+ if ((flags ^ s->s_flags) & MS_RDONLY) {
+ up_write(&s->s_umount);
+ deactivate_super(s);
+ error = -EBUSY;
+ goto error_bdev;
+ }
+
+ close_bdev_excl(bdev);
+ bdev = NULL;
+ } else {
+ char b[BDEVNAME_SIZE];
+
+ s->s_flags = flags;
+ strlcpy(s->s_id, bdevname(bdev, b), sizeof(s->s_id));
+ sb_set_blocksize(s, block_size(bdev));
+ error = fill_super(s, data, flags & MS_SILENT ? 1 : 0);
+ if (error) {
+ up_write(&s->s_umount);
+ deactivate_super(s);
+ goto error;
+ }
+
+ s->s_flags |= MS_ACTIVE;
+ }
+
+ if (subvol) {
+ root = lookup_one_len(subvol, s->s_root, strlen(subvol));
+ if (!root) {
+ error = -ENXIO;
+ goto error_bdev;
+ }
+ } else {
+ root = dget(s->s_root);
+ }
+
+ mnt->mnt_sb = s;
+ mnt->mnt_root = root;
+ return 0;
+
+error_s:
+ error = PTR_ERR(s);
+error_bdev:
+ if (bdev)
+ close_bdev_excl(bdev);
+error:
+ return error;
+}
+/* end copy & paste */
+
static int btrfs_get_sb(struct file_system_type *fs_type,
- int flags, const char *dev_name, void *data, struct vfsmount *mnt)
+ int flags, const char *identifier, void *data, struct vfsmount *mnt)
{
- return get_sb_bdev(fs_type, flags, dev_name, data,
- btrfs_fill_super, mnt);
+ char *_identifier = kstrdup(identif
Re: [PATCH 4/9] readahead: data structure and routines
Hi Rusty, On Wed, Jun 13, 2007 at 10:27:19AM +1000, Rusty Russell wrote: > On Tue, 2007-06-12 at 20:07 +0800, Fengguang Wu wrote: > > or preferably: > > > > pgoff_t start; /* where readahead started */ > > unsigned long size;/* # of readahead pages */ > > unsigned long async_size; /* do asynchronous readahead when there > > are only # of pages ahead */ > > > > unsigned long async_size_old; /* TODO: this one is not needed for now > > */ > > > > Any opinions? Thanks. > > These names and comments are really nice. I think the code will become > more readable after this, too. Thank you! > Did you want me to try to make this patch, or did you want to do it? I'll make it, after your patch, hehe. Fengguang - 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/
[git patches] net driver fixes
This is a resend of the submission from June 9th, along with added stuff: * big update to new (in 2.6.22) wireless driver libertas * revert e100 's-bit' change; see commit message for more info * more myri, NetXen fixes Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus to receive the following updates: drivers/net/e100.c | 72 ++- drivers/net/ehea/ehea.h|2 +- drivers/net/ehea/ehea_main.c | 12 +- drivers/net/ibmveth.c | 80 +- drivers/net/myri10ge/myri10ge.c| 29 +- drivers/net/netxen/netxen_nic.h| 48 +- drivers/net/netxen/netxen_nic_ethtool.c|8 +- drivers/net/netxen/netxen_nic_hw.c | 12 +- drivers/net/netxen/netxen_nic_init.c | 44 +- drivers/net/netxen/netxen_nic_isr.c| 24 + drivers/net/netxen/netxen_nic_main.c |7 + drivers/net/netxen/netxen_nic_niu.c|8 +- drivers/net/phy/marvell.c | 62 +- drivers/net/usb/Kconfig|4 +- drivers/net/via-velocity.c |2 +- drivers/net/wireless/Kconfig | 19 +- drivers/net/wireless/libertas/11d.c| 152 ++-- drivers/net/wireless/libertas/11d.h|6 +- drivers/net/wireless/libertas/Makefile |4 +- drivers/net/wireless/libertas/README | 52 +- drivers/net/wireless/libertas/assoc.c | 358 +--- drivers/net/wireless/libertas/assoc.h | 10 +- drivers/net/wireless/libertas/cmd.c| 559 +-- drivers/net/wireless/libertas/cmdresp.c| 376 drivers/net/wireless/libertas/debugfs.c| 432 drivers/net/wireless/libertas/decl.h | 20 +- drivers/net/wireless/libertas/defs.h | 101 ++- drivers/net/wireless/libertas/dev.h| 99 +- drivers/net/wireless/libertas/ethtool.c| 55 +- drivers/net/wireless/libertas/fw.c | 111 +-- drivers/net/wireless/libertas/fw.h | 13 - drivers/net/wireless/libertas/host.h | 17 +- drivers/net/wireless/libertas/hostcmd.h| 392 drivers/net/wireless/libertas/if_bootcmd.c |6 +- drivers/net/wireless/libertas/if_usb.c | 448 + drivers/net/wireless/libertas/if_usb.h | 32 +- drivers/net/wireless/libertas/ioctl.c | 286 -- drivers/net/wireless/libertas/join.c | 464 - drivers/net/wireless/libertas/join.h | 13 +- drivers/net/wireless/libertas/main.c | 690 ++--- drivers/net/wireless/libertas/rx.c | 64 +- drivers/net/wireless/libertas/sbi.h| 40 - drivers/net/wireless/libertas/scan.c | 1529 +--- drivers/net/wireless/libertas/scan.h | 81 +- drivers/net/wireless/libertas/thread.h |8 +- drivers/net/wireless/libertas/tx.c | 74 +- drivers/net/wireless/libertas/types.h | 63 +- drivers/net/wireless/libertas/wext.c | 778 --- drivers/net/wireless/libertas/wext.h | 13 +- 49 files changed, 4001 insertions(+), 3778 deletions(-) delete mode 100644 drivers/net/wireless/libertas/fw.h delete mode 100644 drivers/net/wireless/libertas/sbi.h Brian King (2): ibmveth: Fix h_free_logical_lan error on pool resize ibmveth: Automatically enable larger rx buffer pools for larger mtu Brice Goglin (3): myri10ge: limit the number of recoveries myri10ge: report when the link partner is running in Myrinet mode myri10ge: update driver version Chris Ball (1): libertas: wakeup both mesh and normal wakeup when getting out of scan Dan Williams (26): libertas: call SET_NETDEV_DEV from common code libertas: replace 'macaddress' with 'bssid' libertas: correctly unregister mesh netdev on error libertas: don't tear down netdev in libertas_activate_card libertas: make scan result handling more flexible libertas: fix 'keep previous scan' behavior libertas: move channel changing into association framework libertas: make association paths consistent libertas: use MAC_FMT and MAC_ARG where appropriate libertas: use compare_ether_addr() rather than memcmp() where appropriate libertas: fix debug enter/leave prints for libertas_execute_next_command libertas: correctly balance locking in libertas_process_rx_command libertas: correct error report paths for wlan_fwt_list_ioctl libertas: fix deadlock SIOCGIWSCAN handler libertas: fix default adhoc channel libertas: honor specific channel requests during association libertas: send SIOCGIWSCAN event after partial scans too libertas: debug print spacing fixes in assoc.c libertas: add more verbose debugging to libertas_cmd_80211_authenticate libertas: Make WPA work through supplicant handshake libertas: sparse fixes libertas:
Re: libata passthru: support PIO multi commands
Alan Cox wrote: >>ata_scsi_pass_thru() is not executed at ioctl submission time (block >>queue submission time), but rather immediately before it is issued to >>the drive. At that point you know the bus is idle, all other commands >>have finished executing, and dev->multi_count is fresh not stale. The >>code path goes from ata_scsi_pass_thru() to ata_qc_issue() without >>releasing the spinlock, even. > > > Think up to user space > > Poorusersapp set multicount to 4 > > Evilproprietarytuningdaemon set multicount to 8 > > Poorusersapp issue I/O > > at which point an error is indeed best. > > >>But the last point is true -- we should error rather than just warn >>there, AFAICS. > > > Definitely. We've been asked "please do something stupid" and not even in > a case where the requester may know better. > It looks like the ATA passthru commands contain more information than what libata needs to execute a command. e.g. protocol number: libata could possibly infer the protocol from the command opcode. e.g. multi_count: libata caches dev->multi_count. Passing multi_count along with each passthru command looks useless for libata. e.g. t_dir: libata could possible infer the direction from the command opcode or from the protocol number (e.g. 4: PIO_IN / 5: PIO_OUT). Due to the redundant info, there is possiblely inconsistency between the parameters. e.g. t_dir vs protocol. e.g. command vs protocol. It seems the "redundant" parameters are designed to allow stateless SATL implementation: The application/passthru command tells the stateless SATL implementation the protocol and the multi_count, etc. Then SATL just follows the instruction blindly, even if asked to do something stupid. Currently libata - uses the passthru protocol number blindly (even if the application issues a DMA command with wrong PIO protocol.) - checks and warns about multi_count - ignores t_dir, byte_block and so on. Maybe we need a strategy to deal with incorrect passed-thru commands? say, - check and reject if something wrong - mimimal check and warn/ignore, if it doesn't hurt command execution -- albert - 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/
RE: [PATCH 2/5] Add RapidIO sector to MPC8641HPCN board dts file.
Hi, Phil,
> > +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > @@ -329,6 +329,19 @@
> > >;
> > };
> >
> > + [EMAIL PROTECTED] {
> > + device_type = "rapidio";
> > + compatible = "fsl,rapidio-v1.0";
> > + #address-cells = <2>;
> > + reg = ;
> > + ranges = <0 0 c000 2000>;
>
> Don't understand the range setup... The code uses c000 as
> the start
> and 2000 as the size for the rapidio law. So whats the 0 0 for?
> At first I thought address-cells 2 means that the range numbers are
> pairs expressing 64-bit numbers, eg start 0 0, size c000 2000
> but thats not right...
>
RapidIO address width is 34bits, so we use <2> for #address-cells.
"0 0" is the RapidIO bus address, since the #address-cells is 2, it's
double zero. "c000" is the parent bus address, which is memory
address. "2000" is the size.
So, they means mapping the address of memory 0xc000 to RapidIO bus
address 0x0 and the size is 0x2000.
> Sorry if I'm asking stupid questions
>
> And thanks for the patch, just what I need.
>
> BTW do you have any notes/documentation on the space
> allocation routines
> intended use. I'm trying to work it out but I don't see any
> actual users
> of it yet... I need something like it for my distributed DMA driver,
> hence the interest.
Sorry, there is no documentation now. But I'll post an example for using
them.
>
> Cheers
> Phil
>
> > + interrupt-parent = <&mpic>;
> > + /* err_irq bell_outb_irq bell_inb_irq
> > + msg1_tx_irq msg1_rx_irq
> > + msg2_tx_irq
> msg2_rx_irq */
> > + interrupts = <30 2 31 2 32 2 35 2 36 2
> 37 2 38 2>;
> > + };
> > +
> > mpic: [EMAIL PROTECTED] {
> > clock-frequency = <0>;
> > interrupt-controller;
>
>
>
-
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/
Re: [PATCH] trim memory not covered by WB MTRRs
On Tuesday, June 12, 2007 6:11:21 Eric W. Biederman wrote: > Jesse Barnes <[EMAIL PROTECTED]> writes: > > On some machines, buggy BIOSes don't properly setup WB MTRRs to > > cover all available RAM, meaning the last few megs (or even gigs) > > of memory will be marked uncached. Since Linux tends to allocate > > from high memory addresses first, this causes the machine to be > > unusably slow as soon as the kernel starts really using memory > > (i.e. right around init time). > > > > This patch works around the problem by scanning the MTRRs at > > boot and figuring out whether the current end_pfn value (setup > > by early e820 code) goes beyond the highest WB MTRR range, and > > if so, trimming it to match. A fairly obnoxious KERN_WARNING > > is printed too, letting the user know that not all of their > > memory is available due to a likely BIOS bug. > > A quick update. This patch is horribly incorrect on a socket F > opteron/Athlon 64 with memory above 4GB. > > In particular those cpus are capable of mapping all of memory > above 4GB as write back without using a single MTRR. > > So examining MTRRs is insufficient. Hm, yuck. What do you suggest? Should we only run this check when Intel chips are present? Checking only the bottom 4G isn't sufficient since we've seen platforms that have issues above that range... Thanks, Jesse - 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/
Re: [RFC][PATCH 1/1] support for user-space buffers in kfifo
On 6/12/07, Stelian Pop <[EMAIL PROTECTED]> wrote:
> Le mardi 12 juin 2007 à 11:24 -0500, Nelson Castillo a écrit :
> > On 6/12/07, Stelian Pop <[EMAIL PROTECTED]> wrote:
> > (cut)
> > > accessing userspace memory with a spinlock taken (moreover an
> > > irqsave()
> > > one) is bad bad bad.
> >
> > Hi Stelian.
> >
> > I'm sending the new patch without kfifo_put_user and kfifo_get_user.
>
> Ok, I have a few formatting/documentation comments:
Applied, thanks.
> Other than that I'm ok with this patch.
Submitting.
Regards, Nelson.-
Signed-off-by: Nelson Castillo <[EMAIL PROTECTED]>
---
diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
index 404f446..5c4c416 100644
--- a/include/linux/kfifo.h
+++ b/include/linux/kfifo.h
@@ -41,8 +41,13 @@ extern struct kfifo *kfifo_alloc(unsigned int size, gfp_t
gfp_mask,
extern void kfifo_free(struct kfifo *fifo);
extern unsigned int __kfifo_put(struct kfifo *fifo,
unsigned char *buffer, unsigned int len);
+extern int __kfifo_put_user(struct kfifo *fifo,
+ const unsigned char __user *buffer,
+ unsigned int len);
extern unsigned int __kfifo_get(struct kfifo *fifo,
unsigned char *buffer, unsigned int len);
+extern int __kfifo_get_user(struct kfifo *fifo, unsigned char __user *buffer,
+ unsigned int len);
/**
* __kfifo_reset - removes the entire FIFO contents, no locking version
diff --git a/kernel/kfifo.c b/kernel/kfifo.c
index cee4191..b11024e 100644
--- a/kernel/kfifo.c
+++ b/kernel/kfifo.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
/**
@@ -150,6 +151,61 @@ unsigned int __kfifo_put(struct kfifo *fifo,
EXPORT_SYMBOL(__kfifo_put);
/**
+ * __kfifo_put_user - puts some data into the FIFO, from userspace
+ * We don't have a locking version because copy_from_user
+ * might sleep and you must not sleep holding a spinlock.
+ *
+ * @fifo: the fifo to be used.
+ * @buffer: the user space data to be added.
+ * @len: the length of the data to be added.
+ *
+ * This function copies at most @len bytes from the @buffer into
+ * the FIFO depending on the free space, and returns the number of
+ * bytes copied or -EFAULT if copy_from_user fails.
+ *
+ * Note that with only one concurrent reader and one concurrent
+ * writer, you don't need extra locking to use these functions.
+ */
+int __kfifo_put_user(struct kfifo *fifo, const unsigned char __user *buffer,
+unsigned int len)
+{
+ unsigned int l;
+
+ len = min(len, fifo->size - fifo->in + fifo->out);
+
+ /*
+* Ensure that we sample the fifo->out index -before- we
+* start putting bytes into the kfifo.
+*/
+
+ smp_mb();
+
+ /* first put the data starting from fifo->in to buffer end */
+ l = min(len, fifo->size - (fifo->in & (fifo->size - 1)));
+
+ if (copy_from_user(fifo->buffer + (fifo->in & (fifo->size - 1)),
+ buffer, l))
+ return -EFAULT;
+
+
+ /* then put the rest (if any) at the beginning of the buffer */
+ if (copy_from_user(fifo->buffer, buffer + l, len - l))
+ return -EFAULT;
+
+ /*
+* Ensure that we add the bytes to the kfifo -before-
+* we update the fifo->in index.
+*/
+
+ smp_wmb();
+
+ fifo->in += len;
+
+ return (int)len;
+}
+EXPORT_SYMBOL(__kfifo_put_user);
+
+/**
* __kfifo_get - gets some data from the FIFO, no locking version
* @fifo: the fifo to be used.
* @buffer: where the data must be copied.
@@ -194,3 +250,57 @@ unsigned int __kfifo_get(struct kfifo *fifo,
return len;
}
EXPORT_SYMBOL(__kfifo_get);
+
+/**
+ * __kfifo_get_user - gets some data from the FIFO to userspace
+ * We don't have a locking version because copy_to_user
+ * might sleep and you must not sleep holding a spinlock.
+ * @fifo: the fifo to be used.
+ * @buffer: user space buffer where the data must be copied.
+ * @len: the size of the destination buffer.
+ *
+ * This function copies at most @len bytes from the FIFO into the
+ * @buffer and returns the number of bytes copied or -EFAULT if
+ * copy_to_user fails.
+ *
+ * Note that with only one concurrent reader and one concurrent
+ * writer, you don't need extra locking to use these functions.
+ */
+
+int __kfifo_get_user(struct kfifo *fifo,
+unsigned char __user *buffer, unsigned int len)
+{
+ unsigned int l;
+
+ len = min(len, fifo->in - fifo->out);
+
+ /*
+* Ensure that we sample the fifo->in index -before- we
+* start removing bytes from the kfifo.
+*/
+
+ smp_rmb();
+
+ /* first get the data from fifo->out until the end of the buffer */
+ l = min(len, fifo->size - (fifo->out & (fifo->size - 1)));
+
+ if (copy_to_user(buffer, fifo->buff
Re: [kbuild-devel] [patch] kbuild: remember ARCH in the object directory
Sam Ravnborg wrote: > > If we go the "save important parts of the config" I prefer > something along the suggestion by hpa with a config file. > The config file should though be named along the lines > of Kbuild.config and the syntax should be future proof. > I like the syntax of the .git/config file and > it should be along these lines. > It's actually derived from the Windows 3.x config file. I think it's massive overkill for this purpose; since the variables can be set on the command line we're not dealing with multiple namespaces, and it would be better to have a make-like syntax. -hpa - 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/
RE: call for more SD versus CFS comparisons (was: Re: [ck] Mainline plans)
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > Fortier,Vincent [Montreal] > Envoyé : 12 juin 2007 21:36 > À : Miguel Figueiredo; linux kernel mailing list; [EMAIL PROTECTED] > Cc : Con Kolivas; Ingo Molnar > Objet : RE: call for more SD versus CFS comparisons (was: Re: > [ck] Mainline plans) > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] De la part de Miguel > > Figueiredo Envoyé : 11 juin 2007 20:30 > > > > Hi all, > > > > some results based on massing_intr.c by Satoru, can be found on > > http://people.redhat.com/mingo/cfs-scheduler/tools/massive_intr.c > > > > > > I know that other people, who read lkml, also tested the > same way, it > > would be nice if they also post their data. > > > > For the pleasure of comparing CPU schedulers, both CFS v16 & > full CK2 patched pre-built kernels for Fedora 7 using latest > build 3194 are now available at http://linux-dev.qc.ec.gc.ca > > There is also a not yet fully tuned YUM repository > configuration file available at > http://linux-dev.qc.ec.gc.ca/kernel/fedora/alt-sched.repo > Although I suggest you download the rpm's directly from the > web page & install both manually using rpm -ivh --force > > Have fun. > Also, now that I think of it, here are my results: Test: ./massive_intr 20 6000 Hardware: - Athlon 64 4200+ - 2GB ram - nVidia 6600GT using latest Beta driver NVIDIA-Linux-x86_64-100.14.06-pkg2.run - SATA drive - On-board audio (00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)) Kernels: CFS v16 2.6.21 FC7 build 3194 CK2 2.6.21 FC7 build 3194 Here is what the TOP output was looking like for both case: top - 13:36:22 up 38 min, 4 users, load average: 20.41, 13.43, 7.49 Tasks: 172 total, 21 running, 150 sleeping, 0 stopped, 1 zombie Cpu0 : 99.7%us, 0.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 94.7%us, 4.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.3%hi, 0.3%si, 0.0%st Mem: 2058860k total, 1217132k used, 841728k free,56456k buffers Swap: 1959888k total,0k used, 1959888k free, 781636k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 6099 megalout 20 0 7860 224 136 R 10 0.0 0:26.12 massive_intr 6102 megalout 20 0 7860 224 136 R 10 0.0 0:26.27 massive_intr 6104 megalout 20 0 7860 224 136 R 10 0.0 0:26.51 massive_intr 6105 megalout 20 0 7860 224 136 R 10 0.0 0:26.32 massive_intr 6107 megalout 20 0 7860 224 136 R 10 0.0 0:26.62 massive_intr 6112 megalout 20 0 7860 224 136 R 10 0.0 0:26.32 massive_intr 6116 megalout 20 0 7860 224 136 R 10 0.0 0:26.26 massive_intr 6109 megalout 20 0 7860 224 136 R 10 0.0 0:26.32 massive_intr 6115 megalout 20 0 7860 224 136 R 10 0.0 0:26.50 massive_intr 6118 megalout 20 0 7860 224 136 R9 0.0 0:26.37 massive_intr 6100 megalout 20 0 7860 224 136 R9 0.0 0:26.51 massive_intr 6103 megalout 20 0 7860 224 136 R9 0.0 0:26.24 massive_intr 6106 megalout 20 0 7860 224 136 R9 0.0 0:26.32 massive_intr 6108 megalout 20 0 7860 224 136 R9 0.0 0:26.32 massive_intr 6110 megalout 20 0 7860 224 136 R9 0.0 0:26.54 massive_intr 6111 megalout 20 0 7860 224 136 R9 0.0 0:26.37 massive_intr 6113 megalout 20 0 7860 224 136 R9 0.0 0:26.56 massive_intr 6114 megalout 20 0 7860 224 136 R9 0.0 0:26.30 massive_intr 6117 megalout 20 0 7860 224 136 R9 0.0 0:26.34 massive_intr 6101 megalout 20 0 7860 224 136 R9 0.0 0:26.31 massive_intr 4681 root 20 0 196m 67m 12m S8 3.4 4:06.00 X 6036 megalout 20 0 694m 53m 32m S2 2.6 0:07.82 amarokapp 4904 megalout 20 0 271m 9.9m 6948 S1 0.5 0:18.16 gkrellm 5054 megalout 20 0 160m 45m 20m S1 2.2 0:10.90 firefox-bin 5201 megalout 20 0 160m 9304 5480 S1 0.5 0:01.42 emerald 5210 megalout 20 0 240m 12m 6284 S1 0.6 0:33.29 beryl CFS v16: - beryl interractivity way too unresponsive.. - window decoration highlight taking around 5-10 secs to switch between windows focus - window movement either impossible or animation laggy enough to not being seen at all. - Cube rotation still possible using mouse scroll although really really really laggy Amarok MP3 music: - No audio skips at all. Playing really well! CK2 patchset: - Beryl interractivity almost totally unresponsive... In fact mouse movement was near-impossible to control. - window movement totally impossible - Cube rotation still possible using mouse scroll although there was no animation at all Amarok MP3 music: - Same as CFS, no skips at all. Playing really well! I'll quote Martin on the Ck mailing list: > According to Ingo most of the interactivity issues should be fixed by
[PATCH] Separate performance counter reservation from nmi watchdog
On 2007.06.12 21:07:30 +0200, Björn Steinbrink wrote:
> On 2007.06.12 08:02:46 -0700, Stephane Eranian wrote:
> > * the fill_in_addresses() callback for X86 invokes the NMI watchdog
> >reserve_*_nmi() register allocation routines. This is done regardless
> >of whether the NMI watchdog is active. When the NMI watchdog is not
> >active, the allocator will satisfy the allocation for the first MSR
> >of each type (counter or control), but then it will reject any
> >request for the others. You end up working with a single
> >counter/control register.
>
> Hm, ouch. I'll try to move the reservation parts into a separate system.
Ok, here's the first try. The performance counter reservation system has
been moved into its own file and separated from the nmi watchdog. Also,
the probing rules were relaxed a bit, as they were more restrictive in
the watchdog code than in the oprofile code.
The new code never allows to reserve a performance counter or event
selection register when the probing failed, instead of allowing one
random register to be reserved.
While moving the code around, I noticed that the PerfMon nmi watchdog
actually reserved the wrong MSRs, as the generic reservation function
always took the base register. As the respective attributes are no
longer used as base regs, we can now store the correct value there and
keep using the generic function.
Being unfamiliar with the kernel init process, I simply put the probing
call right before the nmi watchdog initialization, but that's probably
wrong (and dependent on local APIC on i386), so I'd be glad if someone
could point out a better location.
Thanks,
Björn
From: Björn Steinbrink <[EMAIL PROTECTED]>
Separate the performance counter reservation system from the nmi
watchdog to allow usage of all performance counters even if the nmi
watchdog is not used.
Fixed the reservation of the wrong performance counter for the PerfMon
based nmi watchdog along the way.
Signed-off-by: Björn Steinbrink <[EMAIL PROTECTED]>
---
diff --git a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
index 67824f3..88b74e3 100644
--- a/arch/i386/kernel/apic.c
+++ b/arch/i386/kernel/apic.c
@@ -1009,6 +1009,7 @@ void __devinit setup_local_APIC(void)
value |= (APIC_LVT_MASKED | LOCAL_TIMER_VECTOR);
apic_write_around(APIC_LVTT, value);
+ probe_performance_counters();
setup_apic_nmi_watchdog(NULL);
apic_pm_activate();
}
diff --git a/arch/i386/kernel/cpu/Makefile b/arch/i386/kernel/cpu/Makefile
index 74f27a4..882364d 100644
--- a/arch/i386/kernel/cpu/Makefile
+++ b/arch/i386/kernel/cpu/Makefile
@@ -18,4 +18,4 @@ obj-$(CONFIG_X86_MCE) += mcheck/
obj-$(CONFIG_MTRR) += mtrr/
obj-$(CONFIG_CPU_FREQ) += cpufreq/
-obj-$(CONFIG_X86_LOCAL_APIC) += perfctr-watchdog.o
+obj-$(CONFIG_X86_LOCAL_APIC) += perfctr.o perfctr-watchdog.o
diff --git a/arch/i386/kernel/cpu/perfctr-watchdog.c
b/arch/i386/kernel/cpu/perfctr-watchdog.c
index 2b04c8f..6187097 100644
--- a/arch/i386/kernel/cpu/perfctr-watchdog.c
+++ b/arch/i386/kernel/cpu/perfctr-watchdog.c
@@ -8,9 +8,7 @@
Original code for K7/P6 written by Keith Owens */
#include
-#include
#include
-#include
#include
#include
#include
@@ -36,105 +34,8 @@ struct wd_ops {
static struct wd_ops *wd_ops;
-/* this number is calculated from Intel's MSR_P4_CRU_ESCR5 register and it's
- * offset from MSR_P4_BSU_ESCR0. It will be the max for all platforms (for
now)
- */
-#define NMI_MAX_COUNTER_BITS 66
-
-/* perfctr_nmi_owner tracks the ownership of the perfctr registers:
- * evtsel_nmi_owner tracks the ownership of the event selection
- * - different performance counters/ event selection may be reserved for
- * different subsystems this reservation system just tries to coordinate
- * things a little
- */
-static DECLARE_BITMAP(perfctr_nmi_owner, NMI_MAX_COUNTER_BITS);
-static DECLARE_BITMAP(evntsel_nmi_owner, NMI_MAX_COUNTER_BITS);
-
static DEFINE_PER_CPU(struct nmi_watchdog_ctlblk, nmi_watchdog_ctlblk);
-/* converts an msr to an appropriate reservation bit */
-static inline unsigned int nmi_perfctr_msr_to_bit(unsigned int msr)
-{
- return wd_ops ? msr - wd_ops->perfctr : 0;
-}
-
-/* converts an msr to an appropriate reservation bit */
-/* returns the bit offset of the event selection register */
-static inline unsigned int nmi_evntsel_msr_to_bit(unsigned int msr)
-{
- return wd_ops ? msr - wd_ops->evntsel : 0;
-}
-
-/* checks for a bit availability (hack for oprofile) */
-int avail_to_resrv_perfctr_nmi_bit(unsigned int counter)
-{
- BUG_ON(counter > NMI_MAX_COUNTER_BITS);
-
- return (!test_bit(counter, perfctr_nmi_owner));
-}
-
-/* checks the an msr for availability */
-int avail_to_resrv_perfctr_nmi(unsigned int msr)
-{
- unsigned int counter;
-
- counter = nmi_perfctr_msr_to_bit(msr);
- BUG_ON(counter > NMI_MAX_COUNTER_BITS);
-
- return (!test_bit(counter, perfctr_nmi_owner));
-}
-
-int reserve_per
Re: [PATCH 5/9] readahead: on-demand readahead logic
On Tue, 2007-06-12 at 18:35 +0800, Fengguang Wu wrote:
> > This seems a little like two functions crammed into one. Do you think
> > page_cache_readahead_ondemand() should be split into
> > "page_cache_readahead()" which doesn't take a page*, and
> > "page_cache_check_readahead_page()" which is an inline which does the
> > PageReadahead(page) check as well?
>
> page_cache_check_readahead_page(..., page) is a good idea.
> But which part of the code should we put to page_cache_readahead()
> that does not take a page param?
OK, here's my attempt. I also made them return void, since none of the
callers seem to mind. I didn't change the internals much: I think
they're pretty clear and I didn't want to clash if you decided to rename
the "ra" fields. It compiles and boots.
Thoughts?
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 3c8ae0c37063 fs/ext3/dir.c
--- a/fs/ext3/dir.c Tue Jun 12 17:17:25 2007 +1000
+++ b/fs/ext3/dir.c Wed Jun 13 11:17:42 2007 +1000
@@ -139,10 +139,10 @@ static int ext3_readdir(struct file * fi
pgoff_t index = map_bh.b_blocknr >>
(PAGE_CACHE_SHIFT - inode->i_blkbits);
if (!ra_has_index(&filp->f_ra, index))
- page_cache_readahead_ondemand(
+ page_cache_sync_readahead(
sb->s_bdev->bd_inode->i_mapping,
&filp->f_ra, filp,
- NULL, index, 1);
+ index, 1);
filp->f_ra.prev_index = index;
bh = ext3_bread(NULL, inode, blk, 0, &err);
}
diff -r 3c8ae0c37063 fs/ext4/dir.c
--- a/fs/ext4/dir.c Tue Jun 12 17:17:25 2007 +1000
+++ b/fs/ext4/dir.c Wed Jun 13 11:19:56 2007 +1000
@@ -138,10 +138,10 @@ static int ext4_readdir(struct file * fi
pgoff_t index = map_bh.b_blocknr >>
(PAGE_CACHE_SHIFT - inode->i_blkbits);
if (!ra_has_index(&filp->f_ra, index))
- page_cache_readahead_ondemand(
+ page_cache_sync_readahead(
sb->s_bdev->bd_inode->i_mapping,
&filp->f_ra, filp,
- NULL, index, 1);
+ index, 1);
filp->f_ra.prev_index = index;
bh = ext4_bread(NULL, inode, blk, 0, &err);
}
diff -r 3c8ae0c37063 fs/splice.c
--- a/fs/splice.c Tue Jun 12 17:17:25 2007 +1000
+++ b/fs/splice.c Wed Jun 13 11:18:38 2007 +1000
@@ -312,8 +312,8 @@ __generic_file_splice_read(struct file *
*/
page = find_get_page(mapping, index);
if (!page) {
- page_cache_readahead_ondemand(mapping, &in->f_ra, in,
- NULL, index, nr_pages - spd.nr_pages);
+ page_cache_sync_readahead(mapping, &in->f_ra, in,
+ index, nr_pages - spd.nr_pages);
/*
* page didn't exist, allocate one.
@@ -360,8 +360,7 @@ __generic_file_splice_read(struct file *
this_len = min_t(unsigned long, len, PAGE_CACHE_SIZE - loff);
page = pages[page_nr];
- if (PageReadahead(page))
- page_cache_readahead_ondemand(mapping, &in->f_ra, in,
+ page_cache_check_readahead_page(mapping, &in->f_ra, in,
page, index, nr_pages - page_nr);
/*
diff -r 3c8ae0c37063 include/linux/mm.h
--- a/include/linux/mm.hTue Jun 12 17:17:25 2007 +1000
+++ b/include/linux/mm.hWed Jun 13 11:25:10 2007 +1000
@@ -1146,12 +1146,34 @@ int do_page_cache_readahead(struct addre
pgoff_t offset, unsigned long nr_to_read);
int force_page_cache_readahead(struct address_space *mapping, struct file
*filp,
pgoff_t offset, unsigned long nr_to_read);
-unsigned long page_cache_readahead_ondemand(struct address_space *mapping,
- struct file_ra_state *ra,
- struct file *filp,
- struct page *page,
- pgoff_t offset,
- unsigned long size);
+
+void page_cache_sync_readahead(struct address_space *mapping,
+ struct file_ra_state *ra,
+ struct file *filp,
+ pgoff_t offset,
+ unsigned long size);
+
+void page_cache_async_readahead(struct address_space *mapping,
+ struct file_ra_state *ra,
+
RE: v2.6.21.4-rt11
On Tue, 2007-12-06 at 06:00 -0700, Pallipadi, Venkatesh wrote: > > >-Original Message- > Yes. Force_hpet part is should have worked.. > Eric: Can you send me the output of 'lspci -n on your system. > We need to double check we are covering all ICH7 ids. Here it is: 00:00.0 0600: 8086:2770 (rev 02) 00:02.0 0300: 8086:2772 (rev 02) 00:1b.0 0403: 8086:27d8 (rev 01) 00:1c.0 0604: 8086:27d0 (rev 01) 00:1c.1 0604: 8086:27d2 (rev 01) 00:1d.0 0c03: 8086:27c8 (rev 01) 00:1d.1 0c03: 8086:27c9 (rev 01) 00:1d.2 0c03: 8086:27ca (rev 01) 00:1d.3 0c03: 8086:27cb (rev 01) 00:1d.7 0c03: 8086:27cc (rev 01) 00:1e.0 0604: 8086:244e (rev e1) 00:1f.0 0601: 8086:27b8 (rev 01) 00:1f.1 0101: 8086:27df (rev 01) 00:1f.2 0101: 8086:27c0 (rev 01) 00:1f.3 0c05: 8086:27da (rev 01) 01:0a.0 0604: 3388:0021 (rev 11) 02:0c.0 0c03: 1033:0035 (rev 41) 02:0c.1 0c03: 1033:0035 (rev 41) 02:0c.2 0c03: 1033:00e0 (rev 02) 02:0d.0 0c00: 1106:3044 (rev 46) 03:00.0 0200: 8086:109a Adding the id for PCI_DEVICE_ID_INTEL_ICH7_0 (27b8) should do the trick. I've patched my kernel and was ready to test it, but in the meantime I did a BIOS upgrade (bad idea...) and with the new version the HPET timer is detected via ACPI. Unfortunately it seems that downgrading the BIOS is a lot more trouble than upgrading it. So I cannot easily test the force enable anymore. Anyway it works now. Here is my patch if it's any use to you: diff -uprN linux-2.6.21.4.orig/arch/i386/kernel/quirks.c linux-2.6.21.4/arch/i386/kernel/quirks.c --- linux-2.6.21.4.orig/arch/i386/kernel/quirks.c Tue Jun 12 10:03:18 2007 +++ linux-2.6.21.4/arch/i386/kernel/quirks.cTue Jun 12 10:08:02 2007 @@ -149,6 +149,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_I ich_force_enable_hpet); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1, ich_force_enable_hpet); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_0, + ich_force_enable_hpet); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_1, ich_force_enable_hpet); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_31, Best regards, - Eric - 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/
RE: call for more SD versus CFS comparisons (was: Re: [ck] Mainline plans)
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > Miguel Figueiredo > Envoyé : 11 juin 2007 20:30 > > Hi all, > > some results based on massing_intr.c by Satoru, can be found > on http://people.redhat.com/mingo/cfs-scheduler/tools/massive_intr.c > > > I know that other people, who read lkml, also tested the same > way, it would be nice if they also post their data. > For the pleasure of comparing CPU schedulers, both CFS v16 & full CK2 patched pre-built kernels for Fedora 7 using latest build 3194 are now available at http://linux-dev.qc.ec.gc.ca There is also a not yet fully tuned YUM repository configuration file available at http://linux-dev.qc.ec.gc.ca/kernel/fedora/alt-sched.repo Although I suggest you download the rpm's directly from the web page & install both manually using rpm -ivh --force Have fun. - vin - 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/
Re: v2.6.21.4-rt11
On Tue, Jun 12, 2007 at 11:37:58PM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
>
> > Not a biggie for me, since I can easily do the taskset commands to
> > force the processes to spread out, but I am worried that casual users
> > of rcutorture won't know to do this -- thus not really torturing RCU.
> > It would not be hard to modify rcutorture to affinity the tasks so as
> > to spread them, but this seems a bit ugly.
>
> does it get any better if you renice them from +19 to 0? (and then back
> to +19?)
Interesting!
That did spread them evenly across two CPUs, but not across all four.
I took a look at CFS, which seems to operate in terms of milliseconds.
Since the rcu_torture_reader() code enters the scheduler on each
interation, it would not give CFS millisecond-scale bursts of CPU
consumption, perhaps not allowing it to do reasonable load balancing.
So I inserted the following code at the beginning of rcu_torture_reader():
set_user_nice(current, 19);
set_user_nice(current, 0);
for (idx = 0; idx < 1000; idx++) {
udelay(10);
}
set_user_nice(current, 19);
This worked much better:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
18600 root 39 19 000 R 50 0.0 0:09.57 rcu_torture_rea
18599 root 39 19 000 R 50 0.0 0:09.56 rcu_torture_rea
18598 root 39 19 000 R 49 0.0 0:10.33 rcu_torture_rea
18602 root 39 19 000 R 49 0.0 0:10.34 rcu_torture_rea
18596 root 39 19 000 R 47 0.0 0:09.48 rcu_torture_rea
18601 root 39 19 000 R 46 0.0 0:09.56 rcu_torture_rea
18595 root 39 19 000 R 45 0.0 0:09.23 rcu_torture_rea
18597 root 39 19 000 R 44 0.0 0:10.92 rcu_torture_rea
18590 root 39 19 000 R 10 0.0 0:02.23 rcu_torture_wri
18591 root 39 19 000 D2 0.0 0:00.34 rcu_torture_fak
18592 root 39 19 000 D2 0.0 0:00.35 rcu_torture_fak
18593 root 39 19 000 D2 0.0 0:00.35 rcu_torture_fak
18594 root 39 19 000 D2 0.0 0:00.33 rcu_torture_fak
18603 root 15 -5 000 S1 0.0 0:00.06 rcu_torture_sta
(The first eight tasks are readers, while the last six tasks are update
and statistics threads that don't consume so much CPU, so the above is
pretty close to optimal.)
I stopped and restarted rcutorture several times, and it spread nicely
each time, at least aside from the time that makewhatis decided to fire
up just as I started rcutorture.
But this is admittedly a -very- crude hack.
One approach would be to make them all spin until a few milliseconds
after the last one was created. I would like to spread the readers
separately from the other tasks, which could be done by taking a two-stage
approach, spreading the writer and fakewriter tasks first, then spreading
the readers. This seems a bit nicer, and I will play with it a bit.
In the meantime, thoughts on more-maintainable ways of making this work?
Thanx, Paul
-
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/
Re: beeping patch for debugging acpi sleep
Hi. On Tue, 2007-06-12 at 14:11 +0200, Rafael J. Wysocki wrote: > Hi, > > On Tuesday, 12 June 2007 00:42, Nigel Cunningham wrote: > > Hi. > > > > Wouldn't it be much more useful if it was unconditionally compiled in > > and controlled instead by a sysfs entry? That way it will be far more > > useful to $user who doesn't know or want to know how to compile and > > install a kernel, but wants to do what they can to get provide helpful > > debugging info and perhaps even get it going. > > I like this idea. > > > Yes, Pavel, I'll supply a patch if you (plural) agree. > > I agree. :-) Ok. I'll take Pavel's silence as agreement too. I'll be a little slow (as usual, nowadays!), but will try to get it done next week. I think I can in clear conscience do it on Redhat time if I don't manage it beforehand. Regards, Nigel signature.asc Description: This is a digitally signed message part
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes <[EMAIL PROTECTED]> writes: > On some machines, buggy BIOSes don't properly setup WB MTRRs to > cover all available RAM, meaning the last few megs (or even gigs) > of memory will be marked uncached. Since Linux tends to allocate > from high memory addresses first, this causes the machine to be > unusably slow as soon as the kernel starts really using memory > (i.e. right around init time). > > This patch works around the problem by scanning the MTRRs at > boot and figuring out whether the current end_pfn value (setup > by early e820 code) goes beyond the highest WB MTRR range, and > if so, trimming it to match. A fairly obnoxious KERN_WARNING > is printed too, letting the user know that not all of their > memory is available due to a likely BIOS bug. A quick update. This patch is horribly incorrect on a socket F opteron/Athlon 64 with memory above 4GB. In particular those cpus are capable of mapping all of memory above 4GB as write back without using a single MTRR. So examining MTRRs is insufficient. Eric - 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/
Re: [PATCH 4/9] readahead: data structure and routines
On Tue, 2007-06-12 at 20:07 +0800, Fengguang Wu wrote: > Hi Rusty, Hi Fengguang, > or preferably: > > pgoff_t start; /* where readahead started */ > unsigned long size;/* # of readahead pages */ > unsigned long async_size; /* do asynchronous readahead when there > are only # of pages ahead */ > > unsigned long async_size_old; /* TODO: this one is not needed for now > */ > > Any opinions? Thanks. These names and comments are really nice. I think the code will become more readable after this, too. Did you want me to try to make this patch, or did you want to do it? Thanks, Rusty. - 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/
Re: sata_nv adma issues
Charles Shannon Hendrix wrote: Ah... I thought I put the error in my post. Here is an example: Jun 10 19:47:21 daydream kernel: [ 174.432000] ata4: timeout waiting for ADMA IDLE, stat=0x400 Jun 10 19:47:21 daydream kernel: [ 174.432000] ata4: timeout waiting for ADMA LEGACY, stat=0x400 Jun 10 19:47:21 daydream kernel: [ 174.432000] res 40/00:00:00:00:00/0 0:00:00:00:00/00 Emask 0x4 (timeout) Looks like a line or two is missing here, there should be one saying what the failed command was. Can you post the full dmesg output from the start with these occurrences in it? Jun 10 19:47:21 daydream kernel: [ 174.744000] ata4: soft resetting port Jun 10 19:47:21 daydream kernel: [ 174.90] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Jun 10 19:47:21 daydream kernel: [ 174.908000] ATA: abnormal status 0xD0 on port 0xf885659c Jun 10 19:47:21 daydream kernel: [ 174.92] ATA: abnormal status 0xD0 on port 0xf885659c Jun 10 19:47:21 daydream last message repeated 2 times Jun 10 19:47:21 daydream kernel: [ 174.936000] ata4.00: ata_hpa_resize 1: sectors = 156301488, hpa_sectors = 156301488 Jun 10 19:47:21 daydream kernel: [ 174.944000] ata4.00: ata_hpa_resize 1: sectors = 156301488, hpa_sectors = 156301488 Jun 10 19:47:21 daydream kernel: [ 174.944000] ata4.00: configured for UDMA/133 Jun 10 19:47:21 daydream kernel: [ 174.944000] ata4: EH complete Jun 10 19:47:21 daydream kernel: [ 174.944000] SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB) Jun 10 19:47:21 daydream kernel: [ 174.944000] sdb: Write Protect is off Jun 10 19:47:21 daydream kernel: [ 174.944000] SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA A lot of people reported this problem. Basically the driver does this a few times, and then stops. If sata_nv is built modular, then you may need to put: options sata_nv adma=0 It is, but I thought the kernel command line was still supposed to be able to pass options to a module. That's not correct? It really should, but I don't think it does. Anyway, I'll create a new init ramdisk with the module option set and see how that works. However I should point out that adma=0 is a poor workaround, it would be better to find the real cause of the problem. Agreed. However, I tried all the patches and workarounds before, and had to give up to get work done. It has happened across two different motherboards, and on two drives. Right now it happens with my second drive (I have two identical Seagate SATA drives). The last time I had adma enabled, it was the first drive. No idea why it would be one drive one time and the other one a different time. Please post the dmesg output from when this happens. If it starts working after the kernel disables NCQ, then it might mean that your drive has some problems with NCQ.. See above for dmesg output. If that were true, then why would NCQ work perfectly under Windows? Neither drive has issues there. If the drives are at fault, then shouldn't they have the problem regardless of the OS running? FreeBSD had no trouble either. Linux didn't have trouble until the 2.6.20 kernel. There was no support for ADMA or NCQ on these controllers in Linux until 2.6.20. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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/
Re: Fix empty macros in acpi.
On Tue, Jun 12, 2007 at 08:21:15PM -0400, Dave Jones wrote:
> On Wed, Jun 13, 2007 at 01:00:29AM +0100, Al Viro wrote:
> > On Tue, Jun 12, 2007 at 07:33:09PM -0400, Dave Jones wrote:
> > > +#define DBG(x...) do { } while(0)
> >
> > Eh... Please, stop it - if you want a function-call-like no-op returning
> void,
> > use ((void)0). At least that way one can say DBG(),foo(), etc.
>
> They both end up compiled to nothing anyway, so I'm not bothered
> either way.. I'm not sure I follow why the syntax of that last part
> is a good thing. It looks like something we'd want to avoid rather
> than promote?
If on one side of ifdef it's a void-valued expression, so it should be
on another; the reason is that we don't get surprise differences between
the builds...
IOW, if it doesn't build in some context, it should consistently fail to
build in that context.
-
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/
Re: [PATCH] trim memory not covered by WB MTRRs
On 6/12/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
On Tue 2007-06-12 14:38:28, Ray Lee wrote:
> Panicking when it's not necessary is anti-social. If the kernel can
> continue, then it should, unless it's a correctness issue that may
> cause data corruption. Given that the kernel can even work around the
> problem now, throwing a panic is even less warranted.
Printk("*** WARNING")
is anti-social, too.
Pavel, this warning isn't even going to print on any of your systems.
So it's completely different than the straw-man you're proposing (that
I snipped).
Look, if you want to argue that the stars should go away, then sure,
I'm not going to stop you. But panicking over a BIOS misconfiguration
issue? One that can be corrected by the kernel? That's just plain
stupid.
Ray
-
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/
Re: Fix empty macros in acpi.
On Wed, Jun 13, 2007 at 01:00:29AM +0100, Al Viro wrote:
> On Tue, Jun 12, 2007 at 07:33:09PM -0400, Dave Jones wrote:
> > +#define DBG(x...) do { } while(0)
>
> Eh... Please, stop it - if you want a function-call-like no-op returning
> void,
> use ((void)0). At least that way one can say DBG(),foo(), etc.
They both end up compiled to nothing anyway, so I'm not bothered
either way.. I'm not sure I follow why the syntax of that last part
is a good thing. It looks like something we'd want to avoid rather
than promote?
Dave
--
http://www.codemonkey.org.uk
-
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/
Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
Nick Piggin wrote: > The question is, why is that not enough (I haven't looked at these > patches enough to work out if there is anything more they provide). I think, it just takes trying things out. From reading the code, I think this should work well for the filemap_xip code with no struct page. Also, we need eliminate nopage() to get rid of the struct page. Unfortunately I don't find time to try this out for now, and on 390 we can live with struct page for the time being. In contrast to the embedded platforms, the mem_mep array gets swapped out to disk by our hypervisor. Can you help me understand the comment about nopage()? Do you mean set xip_file_vm_ops.nopage to NULL? - 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/
Re: Fix empty macros in acpi.
On Tue, Jun 12, 2007 at 07:33:09PM -0400, Dave Jones wrote:
> +#define DBG(x...) do { } while(0)
Eh... Please, stop it - if you want a function-call-like no-op returning void,
use ((void)0). At least that way one can say DBG(),foo(), etc.
-
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/
Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Monday 11 June 2007 16:33, Stephen Smalley wrote: >From a userland perspective, audit and inotify allow you to specify > watches on pathnames, and those watches trigger actions by the audit and > inotify subsystems when those files are accessed. The kernel mechanism > however is inode-based, not pathname-based; the pathname is merely > looked up when the watch is added and mapped to an inode. That's my > point - why should AA be different? Audit watches are not entirely object based (contrary to what the man page says): with simple file renames the watches sticks with the names; with directory renames, watches below the directory get dropped. That's rather weird, and I would say bad for audit. Inotify really watches objects. I can imagine cases where this is exactly what you want, and others where this is exactly what you don't want -- it's pick your poison. AppArmor deliberately is pathname based. There are good reasons for that, and we really, definitely want this pathname based model, with all its benefits and disadvantages. Arguing that AppArmor shouldn't be pathname based because other parts of the kernel try to balance names vs. objects differently, and not even always the same way either, is pretty narrow-minded. If one thing is clear from this entire discussion, it is that there is no agreement on the One True Model, and different solutions are being used. > Would you really recommend that audit or inotify call d_path() on each > open and glob match the result against a list of audit or inotify watches? I don't remember doing so. Thanks, Andreas - 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/
Re: [PATCHSET 2.6.22-rc4] sysfs: fix race conditions
On Mon, Jun 11, 2007 at 03:15:39PM +0900, Tejun Heo wrote: > Andrew Morton wrote: > >> This patchset contains three minimal backports of fixes in -mm. With > >> all patches in the patchset and sysfs-races.patch applied, kernel > >> survived ~20 hours of stress test without any problem. > > > > So these are being proposed for 2.6.22? > > Yeap. > > > I do wonder about Rafael's bug which he bisected down to > > gregkh-driver-sysfs-use-singly-linked-list-for-sysfs_dirent-tree.patch. > > > > If that won't be a problem in this patchset then I spose it's probably best > > to go ahead with a 2.6.22 merge, but it's more a Greg thing than a me > > thing. > > I'm currently debugging that and it's irrelevant to these fixes. The > bug is introduced far after the fixes. > > > I don't have a tree to merge these patches into, unless I drop all the > > patches which are in Greg's tree. > > > > Greg, can I leave it up to you to decide how we are to proceed here? > > I can rebase all sysfs patches in -mm on top of linus#master + these > fixes if necessary. Ok, I've sent these to Linus, so if he takes them, can you rebase your patches on top of this and resend the whole tree to me (or just the ones that needed to be modified, if that's easier.) thanks again for this fix, I really appreciate it. greg k-h - 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/
Re: fix placement of inline keyword.
On Wed, Jun 13, 2007 at 01:38:42AM +0200, Adrian Bunk wrote: > On Tue, Jun 12, 2007 at 07:30:35PM -0400, Dave Jones wrote: > > > gcc gets whiney about the placement of 'inline' at some warning levels. > >... > > Since most of them are in C files, can you remove these when you are at it? I'm not that motivated. I did these to reduce some warning noise a while back. I just wanted to toss this out there before I dropped it on the floor. If it gets applied, great, if not, I'm not going to be too bothered. In many cases, there are lots of other inlines in those drivers too, so it's a bigger job than the obvious fix that I did. Dave -- http://www.codemonkey.org.uk - 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/
[patch 02/03] kbuild, asm-values: successor of asm-offsets
Some asm-offsets files define not only offsets, thus make it clear.
Legacy files are supported, but may be freely changed to new scheme.
rfc-by: Oleg Verych
---
If somebody agrees, of course.
Kbuild | 68 ---
1 file changed, 24 insertions(+), 44 deletions(-)
Index: linux-2.6.22-rc4-mm2/Kbuild
===
--- linux-2.6.22-rc4-mm2.orig/Kbuild2007-06-13 01:25:27.696264750 +0200
+++ linux-2.6.22-rc4-mm2/Kbuild 2007-06-13 01:28:10.306427250 +0200
@@ -1,60 +1,40 @@
#
-# Kbuild for top-level directory of the kernel
-# This file takes care of the following:
-# 1) Generate asm-offsets.h
-# 2) Check for missing system calls
-
-#
-# 1) Generate asm-offsets.h
+# Kbuild for top-level directory of the Linux
#
+# 1) Generate (if needed) asm-values.h (former asm-offsets) for ARCH
+# 2) Check for missing system calls
-offsets-file := include/asm-$(ARCH)/asm-offsets.h
+
+# 1)
-always := $(offsets-file)
-targets := $(offsets-file)
-targets += arch/$(ARCH)/kernel/asm-offsets.s
-clean-files := $(addprefix $(objtree)/,$(targets))
-
-# Default sed regexp - multiline due to syntax constraints
-define sed-y
- "/^->/{s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:;
s:->::; p;}"
-endef
-# Override default regexp for specific architectures
-sed-$(CONFIG_MIPS) := "/^@@@/{s/^@@@//; s/ \#.*\$$//; p;}"
-
-quiet_cmd_offsets = GEN $@
-define cmd_offsets
- (set -e; \
-echo "#ifndef __ASM_OFFSETS_H__"; \
-echo "#define __ASM_OFFSETS_H__"; \
-echo "/*"; \
-echo " * DO NOT MODIFY."; \
-echo " *"; \
-echo " * This file was generated by Kbuild"; \
-echo " *"; \
-echo " */"; \
-echo ""; \
-sed -ne $(sed-y) $<; \
-echo ""; \
-echo "#endif" ) > $@
-endef
+# legacy asm-offsets support (FIXME: convert all archs and remove this)
+old = $(shell test -e $(srctree)/arch/$(ARCH)/kernel/asm-offsets.c && echo yes)
+ifeq ($(old),yes)
+asm-values =asm-offsets
+else
+asm-values =asm-values
+endif
+asm-values_c := $(src)/arch/$(ARCH)/kernel/$(asm-values).c
+asm-values_h := $(obj)/include/asm-$(ARCH)/$(asm-values).h
+asm-values := $(obj)/arch/$(ARCH)/kernel/$(asm-values).s
+include $(srctree)/scripts/Makefile.asm
-# We use internal kbuild rules to avoid the "is up to date" message from make
-arch/$(ARCH)/kernel/asm-offsets.s: arch/$(ARCH)/kernel/asm-offsets.c FORCE
+$(asm-values): $(asm-values_c) FORCE
$(Q)mkdir -p $(dir $@)
$(call if_changed_dep,cc_s_c)
-$(obj)/$(offsets-file): arch/$(ARCH)/kernel/asm-offsets.s Kbuild
+$(asm-values_h): $(asm-values) Kbuild
$(Q)mkdir -p $(dir $@)
- $(call cmd,offsets)
+ $(call cmd,mkasm-values,$(ARCH))
-#
-# 2) Check for missing system calls
-#
+
+# 2)
quiet_cmd_syscalls = CALL$<
cmd_syscalls = $(CONFIG_SHELL) $< $(CC) $(c_flags)
-PHONY += missing-syscalls
missing-syscalls: scripts/checksyscalls.sh FORCE
$(call cmd,syscalls)
+
+PHONY += missing-syscalls
+.PHONY: $(PHONY)
--
-
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/
[patch 01/03] kbuild, asm-values: infrastructure
* header with widely used value definitions
* handle all asm-related things in one file (Makefile.asm)
* move some asm bits from Makefile.build there
(rule %.s:%.c)
* add script to generate headers from assembles output
(hopefully better output, MIPS testing/joining to all arch
probably needed)
rfc-by: Oleg Verych
---
See next patches, to know how to use it
include/asm-generic/asm-values.h |7
scripts/Makefile.asm | 26 ++
scripts/Makefile.build |6
scripts/mkasm-values.sh | 55 +
4 files changed, 88 insertions(+), 6 deletions(-)
Index: linux-2.6.22-rc4-mm2/scripts/Makefile.asm
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.22-rc4-mm2/scripts/Makefile.asm 2007-06-12 23:43:41.070624500
+0200
@@ -0,0 +1,26 @@
+#
+# Help generate definitions needed by assembly language modules.
+#
+ifndef asm-values_h
+asm-values := $(shell test -e $(srctree)/$(src)/asm-values.c && echo ok)
+ifneq ($(asm-values),)
+ asm-values_h := asm-values.h
+ asm-values := asm-values.s
+endif
+endif
+
+always += $(asm-values_h)
+targets+= $(asm-values_h) $(asm-values)
+mkasm-values := $(srctree)/scripts/mkasm-values.sh
+
+quiet_cmd_mkasm-values = GEN $@
+ cmd_mkasm-values = $(CONFIG_SHELL) $(mkasm-values) $< $@ $(2)
+
+quiet_cmd_cc_s_c = CC $(quiet_modtag) $@
+ cmd_cc_s_c = $(CC) $(c_flags) -fverbose-asm -S -o $@ $<
+
+$(obj)/asm-values.h: $(obj)/asm-values.s
+ $(call cmd,mkasm-values,$(ASM_NS))
+
+$(obj)/%.s: $(src)/%.c FORCE
+ $(call if_changed_dep,cc_s_c)
Index: linux-2.6.22-rc4-mm2/scripts/Makefile.build
===
--- linux-2.6.22-rc4-mm2.orig/scripts/Makefile.build2007-06-13
00:45:54.195930250 +0200
+++ linux-2.6.22-rc4-mm2/scripts/Makefile.build 2007-06-12 22:10:31.481297000
+0200
@@ -145,10 +145,4 @@ $(multi-objs-y:.o=.s) : modname = $(mo
$(multi-objs-y:.o=.lst) : modname = $(modname-multi)
-quiet_cmd_cc_s_c = CC $(quiet_modtag) $@
-cmd_cc_s_c = $(CC) $(c_flags) -fverbose-asm -S -o $@ $<
-
-$(obj)/%.s: $(src)/%.c FORCE
- $(call if_changed_dep,cc_s_c)
-
quiet_cmd_cc_i_c = CPP $(quiet_modtag) $@
cmd_cc_i_c = $(CPP) $(c_flags) -o $@ $<
Index: linux-2.6.22-rc4-mm2/scripts/mkasm-values.sh
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.22-rc4-mm2/scripts/mkasm-values.sh2007-06-12
21:49:05.096903000 +0200
@@ -0,0 +1,55 @@
+#!/bin/sh
+
+# Input file "*.s", made by Kbuild from a "*.c" source, where values of
+# interest are calculated, is processed in a suitable output header file.
+#
+# $1 - input filename;
+# $2 - output filename;
+# $3 - generate (private) file with given namespace (optional)
+
+set -e
+
+[ -z "$1" ] || [ -z "$2" ] && {
+ echo "$0:
+
+Two parameters needed. Exiting.
+"
+ exit 1
+}
+
+NS=`echo $3 | tr a-z A-Z`
+case $NS in
+ MIPS)
+SED_SCRIPT='
+/^@@@/{
+s|^@@@||;
+s| #.*$||;
+p;
+}' ;;
+ *)
+TAB="`printf '\t'`"
+SED_SCRIPT="
+/^->/{
+s|^->||;
+s|^\([^ ]*\) [\$#]*\([^ ]*\) \([^$TAB]*\).*|#define \1 \2$TAB/* \3 */|;
+p;
+}" ;;
+esac
+
+NS=__ASM_VALUES_${NS:=H}__
+
+exec 1>$2
+echo "\
+#if !defined($NS)
+#define $NS
+
+/*
+ * $2
+ * was generated from
+ * $1
+ */
+"
+sed -ne "$SED_SCRIPT" $1
+
+echo "
+#endif"
Index: linux-2.6.22-rc4-mm2/include/asm-generic/asm-values.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.22-rc4-mm2/include/asm-generic/asm-values.h 2007-06-12
23:33:34.176696000 +0200
@@ -0,0 +1,7 @@
+#define DEFINE(sym, val) \
+ asm volatile("\n->" #sym " %0 " #val : : "i" (val))
+
+#define BLANK() asm volatile("\n->" : : )
+
+#define OFFSET(sym, str, mem) \
+ DEFINE(sym, offsetof(struct str, mem));
--
-
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/
[patch 03/03] kbuild, asm-values: private for lguest
A small example of how it can be used privately.
rfc-by: Oleg Verych
---
TODO: change lguest files to use it.
drivers/lguest/Makefile |4
drivers/lguest/asm-values.c | 24
2 files changed, 28 insertions(+)
Index: linux-2.6.22-rc4-mm2/drivers/lguest/Makefile
===
--- linux-2.6.22-rc4-mm2.orig/drivers/lguest/Makefile 2007-06-13
01:25:17.931654500 +0200
+++ linux-2.6.22-rc4-mm2/drivers/lguest/Makefile2007-06-13
01:29:01.337616500 +0200
@@ -1,2 +1,6 @@
+# Generate private asm-values.h
+ASM_NS = LGUEST
+include $(srctree)/scripts/Makefile.asm
+
# Guest requires the paravirt_ops replacement and the bus driver.
obj-$(CONFIG_LGUEST_GUEST) += lguest.o lguest_asm.o lguest_bus.o
Index: linux-2.6.22-rc4-mm2/drivers/lguest/asm-values.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.22-rc4-mm2/drivers/lguest/asm-values.c2007-06-13
01:29:01.337616500 +0200
@@ -0,0 +1,24 @@
+/*
+ * Private definitions needed by lguest's assembly language modules.
+ */
+
+#include
+#include "lg.h"
+#include
+
+void fell_guest(void);
+
+void fell_guest(void)
+{
+ OFFSET(LGUEST_DATA_irq_enabled, lguest_data, irq_enabled);
+ OFFSET(LGUEST_PAGES_host_gdt_desc, lguest_pages, state.host_gdt_desc);
+ OFFSET(LGUEST_PAGES_host_idt_desc, lguest_pages, state.host_idt_desc);
+ OFFSET(LGUEST_PAGES_host_cr3, lguest_pages, state.host_cr3);
+ OFFSET(LGUEST_PAGES_host_sp, lguest_pages, state.host_sp);
+ OFFSET(LGUEST_PAGES_guest_gdt_desc, lguest_pages,state.guest_gdt_desc);
+ OFFSET(LGUEST_PAGES_guest_idt_desc, lguest_pages,state.guest_idt_desc);
+ OFFSET(LGUEST_PAGES_guest_gdt, lguest_pages, state.guest_gdt);
+ OFFSET(LGUEST_PAGES_regs_trapnum, lguest_pages, regs.trapnum);
+ OFFSET(LGUEST_PAGES_regs_errcode, lguest_pages, regs.errcode);
+ OFFSET(LGUEST_PAGES_regs, lguest_pages, regs);
+}
--
-
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/
[patch 00/03] kbuild, asm-values: not only offsets, not only for $ARCH
Version number zer0. -- -o--=O`C #oo'L O <___=E M - 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/
Re: fix placement of inline keyword.
On Tue, Jun 12, 2007 at 07:30:35PM -0400, Dave Jones wrote:
> gcc gets whiney about the placement of 'inline' at some warning levels.
>...
Since most of them are in C files, can you remove these when you are at it?
> --- linux-2.6.20.noarch/arch/ia64/sn/pci/pcibr/pcibr_ate.c~ 2007-04-04
> 19:34:50.0 -0400
> +++ linux-2.6.20.noarch/arch/ia64/sn/pci/pcibr/pcibr_ate.c2007-04-04
> 19:34:56.0 -0400
> @@ -138,7 +138,7 @@ static inline u64 __iomem *pcibr_ate_add
> /*
> * Update the ate.
> */
> -void inline
> +inline void
> ate_write(struct pcibus_info *pcibus_info, int ate_index, int count,
> volatile u64 ate)
> {
>...
And some are even non-static inline functions...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
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/
Re: 2.6.22-rc[23]: blinking capslock led, stuck keys?
On Tue, June 12, 2007 07:42, Dmitry Torokhov wrote: > For what it worth I finally tried that setleds loop on my laptop. I am > not getting any lost keypresses/releases. But then I don't have EC > (or at least it is not exported via ACPI). This is an old Dell notebook. Well, as I said before, I've the "stuck key"/repeated output too (as well as a warping PS/2 mouse), but no blinking led problem, so I believe the two things are totally unrelated. Greetings, Indan - 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/
Fix empty macros in acpi.
ACPI has a ton of macros which make a bunch of empty if's
when configured in non-debug mode.
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 4334c20..5955cfd 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -16,7 +16,7 @@
#if ACPI_GLUE_DEBUG
#define DBG(x...) printk(PREFIX x)
#else
-#define DBG(x...)
+#define DBG(x...) do { } while(0)
#endif
static LIST_HEAD(bus_type_list);
static DECLARE_RWSEM(bus_type_sem);
diff --git a/include/acpi/acmacros.h b/include/acpi/acmacros.h
index 8948a64..e64a748 100644
--- a/include/acpi/acmacros.h
+++ b/include/acpi/acmacros.h
@@ -599,26 +599,26 @@
#define ACPI_DEBUG_EXEC(a)
#define ACPI_NORMAL_EXEC(a) a;
-#define ACPI_DEBUG_DEFINE(a)
-#define ACPI_DEBUG_ONLY_MEMBERS(a)
-#define ACPI_FUNCTION_NAME(a)
-#define ACPI_FUNCTION_TRACE(a)
-#define ACPI_FUNCTION_TRACE_PTR(a,b)
-#define ACPI_FUNCTION_TRACE_U32(a,b)
-#define ACPI_FUNCTION_TRACE_STR(a,b)
-#define ACPI_FUNCTION_EXIT
-#define ACPI_FUNCTION_STATUS_EXIT(s)
-#define ACPI_FUNCTION_VALUE_EXIT(s)
-#define ACPI_FUNCTION_ENTRY()
-#define ACPI_DUMP_STACK_ENTRY(a)
-#define ACPI_DUMP_OPERANDS(a,b,c,d,e)
-#define ACPI_DUMP_ENTRY(a,b)
-#define ACPI_DUMP_TABLES(a,b)
-#define ACPI_DUMP_PATHNAME(a,b,c,d)
-#define ACPI_DUMP_RESOURCE_LIST(a)
-#define ACPI_DUMP_BUFFER(a,b)
-#define ACPI_DEBUG_PRINT(pl)
-#define ACPI_DEBUG_PRINT_RAW(pl)
+#define ACPI_DEBUG_DEFINE(a) do { } while(0)
+#define ACPI_DEBUG_ONLY_MEMBERS(a) do { } while(0)
+#define ACPI_FUNCTION_NAME(a) do { } while(0)
+#define ACPI_FUNCTION_TRACE(a) do { } while(0)
+#define ACPI_FUNCTION_TRACE_PTR(a,b) do { } while(0)
+#define ACPI_FUNCTION_TRACE_U32(a,b) do { } while(0)
+#define ACPI_FUNCTION_TRACE_STR(a,b) do { } while(0)
+#define ACPI_FUNCTION_EXIT do { } while(0)
+#define ACPI_FUNCTION_STATUS_EXIT(s) do { } while(0)
+#define ACPI_FUNCTION_VALUE_EXIT(s)do { } while(0)
+#define ACPI_FUNCTION_ENTRY() do { } while(0)
+#define ACPI_DUMP_STACK_ENTRY(a) do { } while(0)
+#define ACPI_DUMP_OPERANDS(a,b,c,d,e) do { } while(0)
+#define ACPI_DUMP_ENTRY(a,b) do { } while(0)
+#define ACPI_DUMP_TABLES(a,b) do { } while(0)
+#define ACPI_DUMP_PATHNAME(a,b,c,d)do { } while(0)
+#define ACPI_DUMP_RESOURCE_LIST(a) do { } while(0)
+#define ACPI_DUMP_BUFFER(a,b) do { } while(0)
+#define ACPI_DEBUG_PRINT(pl) do { } while(0)
+#define ACPI_DEBUG_PRINT_RAW(pl) do { } while(0)
#define return_VOID return
#define return_ACPI_STATUS(s) return(s)
--
http://www.codemonkey.org.uk
-
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/
fix placement of inline keyword.
gcc gets whiney about the placement of 'inline' at some warning levels.
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/arch/i386/oprofile/op_model_p4.c b/arch/i386/oprofile/op_model_p4.c
index 4792592..cf6d792 100644
--- a/arch/i386/oprofile/op_model_p4.c
+++ b/arch/i386/oprofile/op_model_p4.c
@@ -47,7 +47,7 @@ static inline void setup_num_counters(void)
#endif
}
-static int inline addr_increment(void)
+static inline int addr_increment(void)
{
#ifdef CONFIG_SMP
return smp_num_siblings == 2 ? 2 : 1;
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 4fb5938..7dc7773 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -429,14 +429,14 @@ static int __init prom_next_node(phandle *nodep)
}
}
-static int inline prom_getprop(phandle node, const char *pname,
+static inline int prom_getprop(phandle node, const char *pname,
void *value, size_t valuelen)
{
return call_prom("getprop", 4, 1, node, ADDR(pname),
(u32)(unsigned long) value, (u32) valuelen);
}
-static int inline prom_getproplen(phandle node, const char *pname)
+static inline int prom_getproplen(phandle node, const char *pname)
{
return call_prom("getproplen", 2, 1, node, ADDR(pname));
}
diff --git a/drivers/acpi/tables/tbfadt.c b/drivers/acpi/tables/tbfadt.c
index 807c711..727ec23 100644
--- a/drivers/acpi/tables/tbfadt.c
+++ b/drivers/acpi/tables/tbfadt.c
@@ -48,7 +48,7 @@
ACPI_MODULE_NAME("tbfadt")
/* Local prototypes */
-static void inline
+static inline void
acpi_tb_init_generic_address(struct acpi_generic_address *generic_address,
u8 bit_width, u64 address);
@@ -122,7 +122,7 @@ static struct acpi_fadt_info fadt_info_table[] = {
*
**/
-static void inline
+static inline void
acpi_tb_init_generic_address(struct acpi_generic_address *generic_address,
u8 bit_width, u64 address)
{
diff --git a/drivers/isdn/hardware/eicon/divasmain.c
b/drivers/isdn/hardware/eicon/divasmain.c
index 5e862e2..49bc3e7 100644
--- a/drivers/isdn/hardware/eicon/divasmain.c
+++ b/drivers/isdn/hardware/eicon/divasmain.c
@@ -448,32 +448,32 @@ void divasa_unmap_pci_bar(void __iomem *bar)
/*
** I/O port access
*/
-byte __inline__ inpp(void __iomem *addr)
+inline byte inpp(void __iomem *addr)
{
return (inb((unsigned long) addr));
}
-word __inline__ inppw(void __iomem *addr)
+inline word inppw(void __iomem *addr)
{
return (inw((unsigned long) addr));
}
-void __inline__ inppw_buffer(void __iomem *addr, void *P, int length)
+inline void inppw_buffer(void __iomem *addr, void *P, int length)
{
insw((unsigned long) addr, (word *) P, length >> 1);
}
-void __inline__ outppw_buffer(void __iomem *addr, void *P, int length)
+inline void outppw_buffer(void __iomem *addr, void *P, int length)
{
outsw((unsigned long) addr, (word *) P, length >> 1);
}
-void __inline__ outppw(void __iomem *addr, word w)
+inline void outppw(void __iomem *addr, word w)
{
outw(w, (unsigned long) addr);
}
-void __inline__ outpp(void __iomem *addr, word p)
+inline void outpp(void __iomem *addr, word p)
{
outb(p, (unsigned long) addr);
}
diff --git a/drivers/isdn/hardware/eicon/platform.h
b/drivers/isdn/hardware/eicon/platform.h
index ff09f07..6ef28c8 100644
--- a/drivers/isdn/hardware/eicon/platform.h
+++ b/drivers/isdn/hardware/eicon/platform.h
@@ -275,13 +275,13 @@ void diva_os_get_time (dword* sec, dword* usec);
** atomic operation, fake because we use threads
*/
typedef int diva_os_atomic_t;
-static diva_os_atomic_t __inline__
+static inline diva_os_atomic_t
diva_os_atomic_increment(diva_os_atomic_t* pv)
{
*pv += 1;
return (*pv);
}
-static diva_os_atomic_t __inline__
+static inline diva_os_atomic_t
diva_os_atomic_decrement(diva_os_atomic_t* pv)
{
*pv -= 1;
diff --git a/drivers/media/common/ir-functions.c
b/drivers/media/common/ir-functions.c
index cbf7c05..14bf46b 100644
--- a/drivers/media/common/ir-functions.c
+++ b/drivers/media/common/ir-functions.c
@@ -125,7 +125,7 @@ u32 ir_extract_bits(u32 data, u32 mask)
return value;
}
-static int inline getbit(u32 *samples, int bit)
+static inline int getbit(u32 *samples, int bit)
{
return (samples[bit/32] & (1 << (31-(bit%32 ? 1 : 0;
}
diff --git a/drivers/media/video/cx88/cx88-core.c
b/drivers/media/video/cx88/cx88-core.c
index d86813b..49c9d65 100644
--- a/drivers/media/video/cx88/cx88-core.c
+++ b/drivers/media/video/cx88/cx88-core.c
@@ -636,22 +636,22 @@ int cx88_reset(struct cx88_core *core)
/* -- */
-static unsigned int inline norm_swidth(v4l2_
[PATCH 1/3] sysfs: store sysfs inode nrs in s_ino to avoid readdir oopses
From: Eric Sandeen <[EMAIL PROTECTED]>
Backport of
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/broken-out/gregkh-driver-sysfs-allocate-inode-number-using-ida.patch
For regular files in sysfs, sysfs_readdir wants to traverse
sysfs_dirent->s_dentry->d_inode->i_ino to get to the inode number.
But, the dentry can be reclaimed under memory pressure, and there is
no synchronization with readdir. This patch follows Tejun's scheme of
allocating and storing an inode number in the new s_ino member of a
sysfs_dirent, when dirents are created, and retrieving it from there
for readdir, so that the pointer chain doesn't have to be traversed.
Tejun's upstream patch uses a new-ish "ida" allocator which brings
along some extra complexity; this -stable patch has a brain-dead
incrementing counter which does not guarantee uniqueness, but because
sysfs doesn't hash inodes as iunique expects, uniqueness wasn't
guaranteed today anyway.
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
fs/sysfs/dir.c | 16 +++-
fs/sysfs/inode.c |1 +
fs/sysfs/mount.c |1 +
fs/sysfs/sysfs.h |1 +
4 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 85a6686..17a8191 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -30,6 +30,14 @@ static struct dentry_operations sysfs_dentry_ops = {
.d_iput = sysfs_d_iput,
};
+static unsigned int sysfs_inode_counter;
+ino_t sysfs_get_inum(void)
+{
+ if (unlikely(sysfs_inode_counter < 3))
+ sysfs_inode_counter = 3;
+ return sysfs_inode_counter++;
+}
+
/*
* Allocates a new sysfs_dirent and links it to the parent sysfs_dirent
*/
@@ -41,6 +49,7 @@ static struct sysfs_dirent * __sysfs_new_dirent(void *
element)
if (!sd)
return NULL;
+ sd->s_ino = sysfs_get_inum();
atomic_set(&sd->s_count, 1);
atomic_set(&sd->s_event, 1);
INIT_LIST_HEAD(&sd->s_children);
@@ -509,7 +518,7 @@ static int sysfs_readdir(struct file * filp, void * dirent,
filldir_t filldir)
switch (i) {
case 0:
- ino = dentry->d_inode->i_ino;
+ ino = parent_sd->s_ino;
if (filldir(dirent, ".", 1, i, ino, DT_DIR) < 0)
break;
filp->f_pos++;
@@ -538,10 +547,7 @@ static int sysfs_readdir(struct file * filp, void *
dirent, filldir_t filldir)
name = sysfs_get_name(next);
len = strlen(name);
- if (next->s_dentry)
- ino = next->s_dentry->d_inode->i_ino;
- else
- ino = iunique(sysfs_sb, 2);
+ ino = next->s_ino;
if (filldir(dirent, name, len, filp->f_pos, ino,
dt_type(next)) < 0)
diff --git a/fs/sysfs/inode.c b/fs/sysfs/inode.c
index bdd30e7..082e2d4 100644
--- a/fs/sysfs/inode.c
+++ b/fs/sysfs/inode.c
@@ -141,6 +141,7 @@ struct inode * sysfs_new_inode(mode_t mode, struct
sysfs_dirent * sd)
inode->i_mapping->a_ops = &sysfs_aops;
inode->i_mapping->backing_dev_info = &sysfs_backing_dev_info;
inode->i_op = &sysfs_inode_operations;
+ inode->i_ino = sd->s_ino;
lockdep_set_class(&inode->i_mutex, &sysfs_inode_imutex_key);
if (sd->s_iattr) {
diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c
index 23a48a3..00ab912 100644
--- a/fs/sysfs/mount.c
+++ b/fs/sysfs/mount.c
@@ -33,6 +33,7 @@ static struct sysfs_dirent sysfs_root = {
.s_element = NULL,
.s_type = SYSFS_ROOT,
.s_iattr= NULL,
+ .s_ino = 1,
};
static void sysfs_clear_inode(struct inode *inode)
diff --git a/fs/sysfs/sysfs.h b/fs/sysfs/sysfs.h
index a77c57e..1966e1a 100644
--- a/fs/sysfs/sysfs.h
+++ b/fs/sysfs/sysfs.h
@@ -5,6 +5,7 @@ struct sysfs_dirent {
void* s_element;
int s_type;
umode_t s_mode;
+ ino_t s_ino;
struct dentry * s_dentry;
struct iattr* s_iattr;
atomic_ts_event;
--
1.5.2.1
-
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/
[PATCH 2/3] sysfs: fix condition check in sysfs_drop_dentry()
From: Tejun Heo <[EMAIL PROTECTED]>
The condition check doesn't make much sense as it basically always
succeeds. This causes NULL dereferencing on certain cases. It seems
that parentheses are put in the wrong place. Fix it.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
fs/sysfs/inode.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/sysfs/inode.c b/fs/sysfs/inode.c
index 082e2d4..38bbe07 100644
--- a/fs/sysfs/inode.c
+++ b/fs/sysfs/inode.c
@@ -252,7 +252,7 @@ void sysfs_drop_dentry(struct sysfs_dirent * sd, struct
dentry * parent)
if (dentry) {
spin_lock(&dcache_lock);
spin_lock(&dentry->d_lock);
- if (!(d_unhashed(dentry) && dentry->d_inode)) {
+ if (!d_unhashed(dentry) && dentry->d_inode) {
inode = dentry->d_inode;
spin_lock(&inode->i_lock);
__iget(inode);
--
1.5.2.1
-
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/
[PATCH 3/3] sysfs: fix race condition around sd->s_dentry, take#2
From: Tejun Heo <[EMAIL PROTECTED]>
Allowing attribute and symlink dentries to be reclaimed means
sd->s_dentry can change dynamically. However, updates to the field
are unsynchronized leading to race conditions. This patch adds
sysfs_lock and use it to synchronize updates to sd->s_dentry.
Due to the locking around ->d_iput, the check in sysfs_drop_dentry()
is complex. sysfs_lock only protect sd->s_dentry pointer itself. The
validity of the dentry is protected by dcache_lock, so whether dentry
is alive or not can only be tested while holding both locks.
This is minimal backport of sysfs_drop_dentry() rewrite in devel
branch.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
fs/sysfs/dir.c | 22 --
fs/sysfs/inode.c | 18 +-
fs/sysfs/sysfs.h |1 +
3 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 17a8191..c4342a0 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -13,14 +13,26 @@
#include "sysfs.h"
DECLARE_RWSEM(sysfs_rename_sem);
+spinlock_t sysfs_lock = SPIN_LOCK_UNLOCKED;
static void sysfs_d_iput(struct dentry * dentry, struct inode * inode)
{
struct sysfs_dirent * sd = dentry->d_fsdata;
if (sd) {
- BUG_ON(sd->s_dentry != dentry);
- sd->s_dentry = NULL;
+ /* sd->s_dentry is protected with sysfs_lock. This
+* allows sysfs_drop_dentry() to dereference it.
+*/
+ spin_lock(&sysfs_lock);
+
+ /* The dentry might have been deleted or another
+* lookup could have happened updating sd->s_dentry to
+* point the new dentry. Ignore if it isn't pointing
+* to this dentry.
+*/
+ if (sd->s_dentry == dentry)
+ sd->s_dentry = NULL;
+ spin_unlock(&sysfs_lock);
sysfs_put(sd);
}
iput(inode);
@@ -247,7 +259,10 @@ static int sysfs_attach_attr(struct sysfs_dirent * sd,
struct dentry * dentry)
}
dentry->d_fsdata = sysfs_get(sd);
+ /* protect sd->s_dentry against sysfs_d_iput */
+ spin_lock(&sysfs_lock);
sd->s_dentry = dentry;
+ spin_unlock(&sysfs_lock);
error = sysfs_create(dentry, (attr->mode & S_IALLUGO) | S_IFREG, init);
if (error) {
sysfs_put(sd);
@@ -269,7 +284,10 @@ static int sysfs_attach_link(struct sysfs_dirent * sd,
struct dentry * dentry)
int err = 0;
dentry->d_fsdata = sysfs_get(sd);
+ /* protect sd->s_dentry against sysfs_d_iput */
+ spin_lock(&sysfs_lock);
sd->s_dentry = dentry;
+ spin_unlock(&sysfs_lock);
err = sysfs_create(dentry, S_IFLNK|S_IRWXUGO, init_symlink);
if (!err) {
dentry->d_op = &sysfs_dentry_ops;
diff --git a/fs/sysfs/inode.c b/fs/sysfs/inode.c
index 38bbe07..5266eec 100644
--- a/fs/sysfs/inode.c
+++ b/fs/sysfs/inode.c
@@ -246,9 +246,23 @@ static inline void orphan_all_buffers(struct inode *node)
*/
void sysfs_drop_dentry(struct sysfs_dirent * sd, struct dentry * parent)
{
- struct dentry * dentry = sd->s_dentry;
+ struct dentry *dentry = NULL;
struct inode *inode;
+ /* We're not holding a reference to ->s_dentry dentry but the
+* field will stay valid as long as sysfs_lock is held.
+*/
+ spin_lock(&sysfs_lock);
+ spin_lock(&dcache_lock);
+
+ /* dget dentry if it's still alive */
+ if (sd->s_dentry && sd->s_dentry->d_inode)
+ dentry = dget_locked(sd->s_dentry);
+
+ spin_unlock(&dcache_lock);
+ spin_unlock(&sysfs_lock);
+
+ /* drop dentry */
if (dentry) {
spin_lock(&dcache_lock);
spin_lock(&dentry->d_lock);
@@ -268,6 +282,8 @@ void sysfs_drop_dentry(struct sysfs_dirent * sd, struct
dentry * parent)
spin_unlock(&dentry->d_lock);
spin_unlock(&dcache_lock);
}
+
+ dput(dentry);
}
}
diff --git a/fs/sysfs/sysfs.h b/fs/sysfs/sysfs.h
index 1966e1a..502c949 100644
--- a/fs/sysfs/sysfs.h
+++ b/fs/sysfs/sysfs.h
@@ -33,6 +33,7 @@ extern const unsigned char * sysfs_get_name(struct
sysfs_dirent *sd);
extern void sysfs_drop_dentry(struct sysfs_dirent *sd, struct dentry *parent);
extern int sysfs_setattr(struct dentry *dentry, struct iattr *iattr);
+extern spinlock_t sysfs_lock;
extern struct rw_semaphore sysfs_rename_sem;
extern struct super_block * sysfs_sb;
extern const struct file_operations sysfs_dir_operations;
--
1.5.2.1
-
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/
[GIT PATCH] sysfs fixes for 2.6.22-rc4
Here are some sysfs fixes for 2.6.22-rc4 They are based on a set of patches from Tejun that have been in the -mm tree for a while and fix a nasty sysfs problem that people have been hitting in the real world (Google has hit this a lot and spent a lot of time and effort in tracking this down, I'd really like to say thanks for the help here.) Tejun and Eric have backported a small set of patches that fix this for your current tree, with the larger, more intrusive patches queued up for after 2.6.22 is out. Tejun and I have beat on these patches a lot and have not found any problems. I know it's late in the series for them, but under the circumstances, it seems reasonable. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ Patches will be sent as a follow-on to this message to lkml for people to see. thanks, greg k-h fs/sysfs/dir.c | 38 +++--- fs/sysfs/inode.c | 21 +++-- fs/sysfs/mount.c |1 + fs/sysfs/sysfs.h |2 ++ 4 files changed, 53 insertions(+), 9 deletions(-) --- Eric Sandeen (1): sysfs: store sysfs inode nrs in s_ino to avoid readdir oopses Tejun Heo (2): sysfs: fix condition check in sysfs_drop_dentry() sysfs: fix race condition around sd->s_dentry, take#2 - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 12, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Tue, 12 Jun 2007, Alexandre Oliva wrote: >> >> Per this reasoning, Sun wouldn't be waiting for GPLv3, and it would >> have already released the OpenSolaris kernel under GPLv2, would it >> not? ;-) > Umm. You are making the fundamental mistake of thinking that Sun is in > this to actually further some open-source agenda. Err, no. I was merely questioning Ingo's reasoning that Sun wanted Linux's drivers as badly as he made it seem. All the fuss about waiting for and going to GPLv3 wouldn't get them that. Moving to GPLv2 would, and still, they aren't doing it. That was my point. FWIW, I share most of your assessment and wait-and-see attitude about Sun's situation. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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/
[-mm patch] drivers/cpuidle/governors/menu.c: make a struct static
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.22-rc4-mm1:
>
> git-acpi.patch
>...
> git trees
>...
This patch makes the needlessly global struct menu_governor static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
--- linux-2.6.22-rc4-mm2/drivers/cpuidle/governors/menu.c.old 2007-06-13
00:25:03.0 +0200
+++ linux-2.6.22-rc4-mm2/drivers/cpuidle/governors/menu.c 2007-06-13
00:25:13.0 +0200
@@ -123,7 +123,7 @@
data->deepest_bm_state = i - 1;
}
-struct cpuidle_governor menu_governor = {
+static struct cpuidle_governor menu_governor = {
.name = "menu",
.scan = menu_scan_device,
.select = menu_select,
-
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/
Re: [PATCH 2/5] Add RapidIO sector to MPC8641HPCN board dts file.
On Tue, 2007-06-12 at 17:02 +0800, Zhang Wei wrote:
> Add RapidIO sector to the MPC8641HPCN board dts file.
>
> Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 13 +
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> index 04626b1..e2ce06e 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -329,6 +329,19 @@
> >;
> };
>
> + [EMAIL PROTECTED] {
> + device_type = "rapidio";
> + compatible = "fsl,rapidio-v1.0";
> + #address-cells = <2>;
> + reg = ;
> + ranges = <0 0 c000 2000>;
Don't understand the range setup... The code uses c000 as the start
and 2000 as the size for the rapidio law. So whats the 0 0 for?
At first I thought address-cells 2 means that the range numbers are
pairs expressing 64-bit numbers, eg start 0 0, size c000 2000
but thats not right...
Sorry if I'm asking stupid questions
And thanks for the patch, just what I need.
BTW do you have any notes/documentation on the space allocation routines
intended use. I'm trying to work it out but I don't see any actual users
of it yet... I need something like it for my distributed DMA driver,
hence the interest.
Cheers
Phil
> + interrupt-parent = <&mpic>;
> + /* err_irq bell_outb_irq bell_inb_irq
> + msg1_tx_irq msg1_rx_irq
> + msg2_tx_irq msg2_rx_irq */
> + interrupts = <30 2 31 2 32 2 35 2 36 2 37 2 38 2>;
> + };
> +
> mpic: [EMAIL PROTECTED] {
> clock-frequency = <0>;
> interrupt-controller;
-
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/
[-mm patch] drivers/ata/sata_nv.c: make 3 functions static
This patch makes 3 needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/ata/sata_nv.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- linux-2.6.22-rc4-mm2/drivers/ata/sata_nv.c.old 2007-06-13
00:02:18.0 +0200
+++ linux-2.6.22-rc4-mm2/drivers/ata/sata_nv.c 2007-06-13 00:03:12.0
+0200
@@ -314,7 +314,7 @@
static int nv_ncqintr_dmasetupfis(struct ata_port *ap);
static void ncq_clear_singlefis(struct ata_port *ap, u32 val);
static u32 ncq_ownfisintr_value (struct ata_port *ap);
-void ncq_hotplug(struct ata_port *ap, u32 fis);
+static void ncq_hotplug(struct ata_port *ap, u32 fis);
static irqreturn_t nv_mcp55_interrupt(int irq, void *dev_instance);
static int ncq_interrupt(struct ata_port *ap, u32 fis);
static int nv_scsi_queuecmd(struct scsi_cmnd *cmd,
@@ -1931,7 +1931,7 @@
ncq_clear(ap);
}
-int nv_std_prereset(struct ata_port *ap, unsigned long deadline)
+static int nv_std_prereset(struct ata_port *ap, unsigned long deadline)
{
struct ata_eh_context *ehc = &ap->eh_context;
@@ -2265,7 +2265,7 @@
return 0;
}
-u32 ncq_valid_dhfisflag(struct nv_port_priv *pp)
+static u32 ncq_valid_dhfisflag(struct nv_port_priv *pp)
{
u32 valid = (pp->dhfis_flags == pp->qc_active);
@@ -2332,7 +2332,7 @@
#endif
-void ncq_hotplug(struct ata_port *ap, u32 fis)
+static void ncq_hotplug(struct ata_port *ap, u32 fis)
{
u32 serror;
struct ata_eh_info *ehi = &ap->eh_info;
-
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/
[-mm patch] drivers/acpi/processor_throttling.c: make 2 functions static
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.22-rc4-mm1:
>
> git-acpi.patch
>...
> git trees
>...
This patch makes 2 needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/acpi/processor_throttling.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- linux-2.6.22-rc4-mm2/drivers/acpi/processor_throttling.c.old
2007-06-12 23:57:53.0 +0200
+++ linux-2.6.22-rc4-mm2/drivers/acpi/processor_throttling.c2007-06-12
23:58:22.0 +0200
@@ -410,7 +410,8 @@
return pr->throttling.acpi_processor_get_throttling(pr);
}
-int acpi_processor_set_throttling_fadt(struct acpi_processor *pr, int state)
+static int acpi_processor_set_throttling_fadt(struct acpi_processor *pr,
+ int state)
{
u32 value = 0;
u32 duty_mask = 0;
@@ -482,7 +483,8 @@
return 0;
}
-int acpi_processor_set_throttling_ptc(struct acpi_processor *pr, int state)
+static int acpi_processor_set_throttling_ptc(struct acpi_processor *pr,
+int state)
{
u32 value = 0;
-
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/
[-mm patch] make drivers/char/selection.c:store_utf8() static
This patch makes the needlessly global store_utf8() static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
--- linux-2.6.22-rc4-mm2/drivers/char/selection.c.old 2007-06-13
00:23:09.0 +0200
+++ linux-2.6.22-rc4-mm2/drivers/char/selection.c 2007-06-13
00:23:20.0 +0200
@@ -112,7 +112,7 @@
}
/* stores the char in UTF8 and returns the number of bytes used (1-3) */
-int store_utf8(u16 c, char *p)
+static int store_utf8(u16 c, char *p)
{
if (c < 0x80) {
/* 0*** */
-
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/
[-mm patch] make drivers/acpi/osl.c:osi_linux static
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote: >... > Changes since 2.6.22-rc4-mm1: > > git-acpi.patch >... > git trees >... This patch makes the needlessly global osi_linux static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- --- linux-2.6.22-rc4-mm2/drivers/acpi/osl.c.old 2007-06-12 23:55:27.0 +0200 +++ linux-2.6.22-rc4-mm2/drivers/acpi/osl.c 2007-06-12 23:55:37.0 +0200 @@ -78,9 +78,9 @@ static char osi_additional_string[OSI_STRING_LENGTH_MAX]; #ifdef OSI_LINUX_ENABLED -int osi_linux = 1; /* enable _OSI(Linux) by default */ +static int osi_linux = 1; /* enable _OSI(Linux) by default */ #else -int osi_linux; /* disable _OSI(Linux) by default */ +static int osi_linux; /* disable _OSI(Linux) by default */ #endif - 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/
Re: 2.6.22-rc4-mm2: GPF during suspend to RAM on HPC nx6325
On Wednesday, 13 June 2007 00:09, Rafael J. Wysocki wrote: > On Tuesday, 12 June 2007 23:55, Rafael J. Wysocki wrote: > > On Monday, 11 June 2007 09:17, Tejun Heo wrote: > > > Hello, Rafael. > > > > > > Rafael J. Wysocki wrote: > > > > gregkh-driver-sysfs-use-singly-linked-list-for-sysfs_dirent-tree.patch > > > > breaks > > > > suspend to RAM on HPC nx6325 (x86_64). > > > > > > > > With this patch applied I get a general protection fault in > > > > mutex_lock+0x15 > > > > (kernel/mutex.c:91), called by sysfs_hash_and_remove() > > > > (fs/sysfs/inode.c:298), > > > > called by threshold_cpu_callback(), called from _cpu_down(). > > > > > > I'm not sure whether this is bug in sysfs or in sysfs handling code in > > > mce_amd and I can't test mce_amd here. Can you please apply the > > > attached patch and post the resulting dmesg including oops? > > > > I've applied the patch, but the oops is a kernel panic, so I can't generate > > a > > dmesg including it. ;-) > > > > Here's the dmesg output from a fresh boot (runlevel 2): > > > > http://www.sisk.pl/kernel/debug/2.6.22-rc4-mm2/dmesg.log > > > > Here's a picture of the oops taken after a failed attempt to suspend: > > > > http://www.sisk.pl/kernel/debug/2.6.22-rc4-mm2/during_suspend.jpg > > > > Here's a picture of the oops taken after a failed attempt to offline CPU1 > > using 'echo 1 > /sys/devices/system/cpu/cpu1/online': > > > > http://www.sisk.pl/kernel/debug/2.6.22-rc4-mm2/after_offlining_cpu1.jpg > > > > [Sorry for the quality of pictures, I couldn't get anything better.] > > More information: > > With the debug patch applied the oops is a NULL pointer dereference > at sysfs_hash_and_remove+0x16, which according to gdb is > > (gdb) l *sysfs_hash_and_remove+0x16 > 0x802d4bff is in sysfs_hash_and_remove > (/home/rafael/src/mm/linux-2.6.22-rc4-mm2/fs/sysfs/inode.c:294). > 289 int found = 0; > 290 > 291 if (!dir) > 292 return -ENOENT; > 293 > 294 if (dir->d_inode == NULL) > 295 /* no inode means this hasn't been made visible yet */ > 296 return -ENOENT; > 297 > 298 mutex_lock_nested(&dir->d_inode->i_mutex, I_MUTEX_PARENT); Update: I've managed to obtain a dmesg output containing the oops, which is appended. I've slightly modified your debug patch before (attached), by adding a printk() in mce_amd.c:617 . Greetings, Rafael --- Initializing container subsys cpuset Linux version 2.6.22-rc4-mm2 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #30 SMP Wed Jun 13 00:42:53 CEST 2007 Command line: root=/dev/sda3 vga=792 resume=/dev/sda1 2 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 77fd (usable) BIOS-e820: 77fd - 77fe5600 (reserved) BIOS-e820: 77fe5600 - 77ff8000 (ACPI NVS) BIOS-e820: 77ff8000 - 8000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec02000 (reserved) BIOS-e820: ffbc - ffcc (reserved) BIOS-e820: fff0 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 491472) 1 entries of 256 used end_pfn_map = 1048576 DMI 2.4 present. ACPI: RSDP 000F7D30, 0024 (r2 HP) ACPI: XSDT 77FE57B4, 0054 (r1 HP 0944 6070620 HP 1) ACPI: FACP 77FE5684, 00F4 (r4 HP 09443 HP 1) ACPI: DSDT 77FE58DC, EE7A (r1 HPSB4001 MSFT 10E) ACPI: FACS 77FF7E80, 0040 ACPI: APIC 77FE5808, 0062 (r1 HP 09441 HP 1) ACPI: MCFG 77FE586C, 003C (r1 HP 09441 HP 1) ACPI: TCPA 77FE58A8, 0032 (r2 HP 09441 HP 1) ACPI: SSDT 77FF4756, 0059 (r1 HP HPQNLP1 MSFT 10E) ACPI: SSDT 77FF47AF, 0206 (r1 HP PSSTBLID1 HP 1) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 491472) 1 entries of 256 used No mptable found. sizeof(struct page) = 56 Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 491472 On node 0 totalpages: 491375 Node 0 memmap at 0x81000100 size 27525120 first pfn 0x81000100 DMA zone: 56 pages used for memmap DMA zone: 1382 pages reserved DMA zone: 2561 pages, LIFO batch:0 DMA32 zone: 6663 pages used for memmap DMA32 zone: 480713 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap ATI board detected. Disabling timer routing over 8254. ACPI: P
Re: [-mm patch] #if 0 mm/backing-dev.c:congestion_wait_interruptible()
On Tue, Jun 12, 2007 at 02:40:06PM +0200, Jesper Juhl wrote: > On 12/06/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: >> congestion_wait_interruptible() is no longer used. >> > Remind me again why it is that we add all these #if 0 blocks instead > of simply removing the unused code? > > It's just creating a janitorial task to go and remove all the #if 0 > bits at a later time, seems like pointless churn to me. If the code > needs to go, let's just get rid of it in one go instead of two. The #if 0 also handles all "I want to use this code in 6 months" comments that might come (and in some rare cases it even gets used later). My primary intention is to remove dead code from bloating the kernel image, and this way the probability of patch acceptance is higher. > Jesper Juhl cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: [PATCH] x86: Document the hotplug code is incompatible with x86 irq handling
On Wednesday, 13 June 2007 00:24, Siddha, Suresh B wrote: > On Wed, Jun 13, 2007 at 12:16:08AM +0200, Rafael J. Wysocki wrote: > > On Tuesday, 12 June 2007 23:56, Siddha, Suresh B wrote: > > > On Tue, Jun 12, 2007 at 10:52:09PM +0200, Rafael J. Wysocki wrote: > > > > On Tuesday, 12 June 2007 20:19, Eric W. Biederman wrote: > > > > > Because you are calling unfixably broken code. That should be a > > > > > decent > > > > > incentive to do something else won't it? > > > > > > > > Can you please tell me _what_ else can be done? > > > > > > > > > IOAPICs do not support what the code is doing here. There is lots of > > > > > practical evidence including bad experiences and practical tests that > > > > > support this. > > > > > > > > Well, AFAICS, Suresh has tried to debug one failing case recently > > > > without > > > > any consistent conclusions. I don't know of any other test cases > > > > (links, > > > > please?). > > > > > > Rafael, Darrick Wong's issue looks different and hence I was motivated to > > > look and fix if it was a SW issue. For now, I am not able to comprehend > > > what is happening on Darrick Wong's system. Need more help from Darrick > > > as he has the golden failing system. > > > > > > Meanwhile I talked to our hardware folks about the irq migration in > > > general. > > > > > > One good news is that future versions of chipsets will have an Interrupt > > > Remapping feature(for more details please refer to > > > http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf) > > > where in we can reliably migrate the irq to someother cpu in the process > > > context. > > > > > > And for the existing platforms, chipset folks don't see a reason why the > > > Eric's algorithm(specified below) should fail. > > > > > > Eric's algorithm for level triggered(edge triggered should be easier than > > > level triggered): > > > - Mask the irq in process context. > > > - Poll RIRR until an ack of for the irq was not pending. > > > - Migrate the irq. > > > > > > Eric had a problem of stuck remote IRR on E75xx chipset with this > > > algorithm > > > and my next step is to reproduce this issue on this platform and > > > understand > > > the behavior. > > > > OK > > > > In that case, do I understand correctly that we are going to implement the > > Eric's algorithm above for the CPU hotunplugging on x86 once you've figured > > out what's the E75xx issue? > > That is the idea. Thanks. OK, thanks. Eric, would you agree to follow this plan without making the entire CPU hotplug (on x86) depend on BROKEN? Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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/
Re: 2.6.22-rc4-mm2: kvm compile breakage with X86_CMPXCHG64=n
On Tue, Jun 12, 2007 at 03:43:45PM -0700, Andrew Morton wrote: > On Tue, 12 Jun 2007 18:16:29 -0400 > Dave Jones <[EMAIL PROTECTED]> wrote: > > > > > # Read KERNELRELEASE from include/config/kernel.release (if it > > exists) > > > > > > This causes the i386 allmodconfig build to fail: > > > > Seems to be doing its job rather effectively. > > err, hang on. I had a different patch in there which hilariously broke > the build all over the place, and dropping that has made your patch > come good. I'll put it back. This was all just a cunning trick to make me download and build an -mm kernel wasn't it ? :-) Dave -- http://www.codemonkey.org.uk - 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/
Re: 2.6.22-rc4-mm2: kvm compile breakage with X86_CMPXCHG64=n
On Tue, 12 Jun 2007 18:16:29 -0400 Dave Jones <[EMAIL PROTECTED]> wrote: > > > # Read KERNELRELEASE from include/config/kernel.release (if it exists) > > > > This causes the i386 allmodconfig build to fail: > > Seems to be doing its job rather effectively. err, hang on. I had a different patch in there which hilariously broke the build all over the place, and dropping that has made your patch come good. I'll put it back. - 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/
Re: 2.6.22-rc4-mm2: kvm compile breakage with X86_CMPXCHG64=n
On Tue, Jun 12, 2007 at 03:03:57PM -0700, Andrew Morton wrote: > On Mon, 11 Jun 2007 23:22:24 -0400 > Dave Jones <[EMAIL PROTECTED]> wrote: > > > Add -Werror-implicit-function-declaration > > This makes builds fail sooner if something is implicitly defined instead > > of having to wait half an hour for it to fail at the linking stage. > > > > Signed-off-by: Dave Jones <[EMAIL PROTECTED]> > > > > --- linux-2.6/Makefile~ 2007-06-04 16:46:24.0 -0400 > > +++ linux-2.6/Makefile 2007-06-04 16:46:53.0 -0400 > > @@ -313,7 +313,8 @@ LINUXINCLUDE:= -Iinclude \ > > CPPFLAGS:= -D__KERNEL__ $(LINUXINCLUDE) > > > > CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ > > - -fno-strict-aliasing -fno-common > > + -fno-strict-aliasing -fno-common \ > > + -Werror-implicit-function-declaration > > AFLAGS := -D__ASSEMBLY__ > > > > # Read KERNELRELEASE from include/config/kernel.release (if it exists) > > This causes the i386 allmodconfig build to fail: > > include/linux/uaccess.h: In function 'pagefault_disable': > include/linux/uaccess.h:23: error: implicit declaration of function > '__memory_barrier' > > I didn't look to see why... I have -Werror-implicit-function-declaration in the CFLAGS of my testbuilds for ages without ever hitting this. Perhaps some change in your working tree? Can you verify this problem with 2.6.22-rc4-mm2? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: Proposal: change keycode for scancode e0 32 from 150 to 172
Hans de Goede wrote: > > In order to be able to better test / develop this I've bought 2 cheap > such keyboards today, one ps2 and one both usb and ps2 capable. > > When comparing usb vs ps2 / testing the keycodes generated for the easy > access > keys on my trust (microsoft compatible) keyboard. I noticed the homepage > key sends keycode 150 with ps2 and 172 with USB, or for those who don't > know the keycodes by head with ps2 it sends KEY_WWW and with usb it > sends KEY_HOMEPAGE I just tested this using Microsoft Natural Keyboard Pro, which is a dual-mode (USB-PS/2) keyboard. This key is labelled Web/Home and has a picture of a house on the keycap. In PS/2 mode it reports E0 32 which gets converted to keycode 150. In USB mode it reports E0 02 which gets converted to keycode 172. I don't know if it's the keyboard itself that's being inconsistent, or if it is the table in usbkbd.c that's broken (in which case it should be fixed to be consistent with the keyboard in PS/2 mode.) > I personally believe that the usb behaviour is correct and that the ps/2 > code should be modified to match for consistency. The ps/2 scancode to > keycode mapping is set up to handle easy access / internet keys for > microsoft compatible keyboards. So what is the right code to send here, > tricky, see: > http://www.s2.com.br/s2arquivos/361/Imagens/555Image.jpg > http://www.keyboardco.com/keyboard_images/microsoft_ergonomic_keyboard_4000_black_usb_large.jpg > > The logo on the key is a homepage logo, the text below is www/homepage. > So what to send? I believe that for consistency with the usb codes send > it should be KEY_HOMEPAGE, but thats based on a sample of 1 usb > keyboard. Input on what other usb keyboards send for the key with the > homepage iocn is very much welcome. You seem to be of the opinion that "usb behaviour is correct", but don't give any motivation why usb should take precedence. Offhand, I would expect there to be fewer translation layers for PS/2 and would therefore assume PS/2 is more inherently correct. -hpa - 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/
Re: [PATCH] x86: Document the hotplug code is incompatible with x86 irq handling
On Wed, Jun 13, 2007 at 12:16:08AM +0200, Rafael J. Wysocki wrote: > On Tuesday, 12 June 2007 23:56, Siddha, Suresh B wrote: > > On Tue, Jun 12, 2007 at 10:52:09PM +0200, Rafael J. Wysocki wrote: > > > On Tuesday, 12 June 2007 20:19, Eric W. Biederman wrote: > > > > Because you are calling unfixably broken code. That should be a decent > > > > incentive to do something else won't it? > > > > > > Can you please tell me _what_ else can be done? > > > > > > > IOAPICs do not support what the code is doing here. There is lots of > > > > practical evidence including bad experiences and practical tests that > > > > support this. > > > > > > Well, AFAICS, Suresh has tried to debug one failing case recently without > > > any consistent conclusions. I don't know of any other test cases (links, > > > please?). > > > > Rafael, Darrick Wong's issue looks different and hence I was motivated to > > look and fix if it was a SW issue. For now, I am not able to comprehend > > what is happening on Darrick Wong's system. Need more help from Darrick > > as he has the golden failing system. > > > > Meanwhile I talked to our hardware folks about the irq migration in general. > > > > One good news is that future versions of chipsets will have an Interrupt > > Remapping feature(for more details please refer to > > http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf) > > where in we can reliably migrate the irq to someother cpu in the process > > context. > > > > And for the existing platforms, chipset folks don't see a reason why the > > Eric's algorithm(specified below) should fail. > > > > Eric's algorithm for level triggered(edge triggered should be easier than > > level triggered): > > - Mask the irq in process context. > > - Poll RIRR until an ack of for the irq was not pending. > > - Migrate the irq. > > > > Eric had a problem of stuck remote IRR on E75xx chipset with this algorithm > > and my next step is to reproduce this issue on this platform and understand > > the behavior. > > OK > > In that case, do I understand correctly that we are going to implement the > Eric's algorithm above for the CPU hotunplugging on x86 once you've figured > out what's the E75xx issue? That is the idea. Thanks. - 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/
Re: [PATCH] fix memory leak in UBI scanning unit
On 10/05/07, Artem Bityutskiy <[EMAIL PROTECTED]> wrote: On Thu, 2007-05-10 at 00:26 +0200, Jesper Juhl wrote: > In drivers/mtd/ubi/scan.c::paranoid_check_si() there's a memory leak. > If the call > err = ubi_io_is_bad(ubi, pnum); > returns <0, then we'll return with out freeing (and thus leak) buf. > This patch eliminates the memory leak by freeing buf before returning. > > Problem spotted by the Coverity checker. It was already reported and fixed in our git tree. But thanks anyway. Any idea when you'll be merging with Linus? I just checked mainline git and the bug is still there :-( -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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/
Re: 2.6.22-rc4-mm2: kvm compile breakage with X86_CMPXCHG64=n
On Tue, Jun 12, 2007 at 03:03:57PM -0700, Andrew Morton wrote: > On Mon, 11 Jun 2007 23:22:24 -0400 > Dave Jones <[EMAIL PROTECTED]> wrote: > > > Add -Werror-implicit-function-declaration > > This makes builds fail sooner if something is implicitly defined instead > > of having to wait half an hour for it to fail at the linking stage. > > > > Signed-off-by: Dave Jones <[EMAIL PROTECTED]> > > > > --- linux-2.6/Makefile~2007-06-04 16:46:24.0 -0400 > > +++ linux-2.6/Makefile 2007-06-04 16:46:53.0 -0400 > > @@ -313,7 +313,8 @@ LINUXINCLUDE:= -Iinclude \ > > CPPFLAGS:= -D__KERNEL__ $(LINUXINCLUDE) > > > > CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ > > - -fno-strict-aliasing -fno-common > > + -fno-strict-aliasing -fno-common \ > > + -Werror-implicit-function-declaration > > AFLAGS := -D__ASSEMBLY__ > > > > # Read KERNELRELEASE from include/config/kernel.release (if it exists) > > This causes the i386 allmodconfig build to fail: Seems to be doing its job rather effectively. > include/linux/uaccess.h: In function 'pagefault_disable': > include/linux/uaccess.h:23: error: implicit declaration of function > '__memory_barrier' > > I didn't look to see why... include/linux/compiler.h .. /* Optimization barrier */ #ifndef barrier # define barrier() __memory_barrier() #endif We shouldn't be hitting this, because barrier should be getting defined in the compiler specific headers above.. #if __GNUC__ >= 4 # include #elif __GNUC__ == 3 && __GNUC_MINOR__ >= 2 # include #else # error Sorry, your compiler is too old/not recognized. #endif both of those include linux/compiler-gcc.h, which defines barrier. How strange. What compiler version is this? Dave -- http://www.codemonkey.org.uk - 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/
Re: raid5: coding style cleanup / refactor
> I assume that you're prepared to repair all that damage to your tree, but > it seems a bit masochistic? It's either this or have an inconsistent coding style throughout raid5.c. I figure it is worth it to have reduced code duplication between raid5 and raid6, and it makes it easier to add new cache features going forward. I have a few more cleanups to add for a rev2 of this patch, but I will hold that off until the rebase is done. In other words, it seemed like a good idea at the time, but I am open to suggestions. - 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/
Re: [PATCH] x86: Document the hotplug code is incompatible with x86 irq handling
On Tuesday, 12 June 2007 23:56, Siddha, Suresh B wrote: > On Tue, Jun 12, 2007 at 10:52:09PM +0200, Rafael J. Wysocki wrote: > > On Tuesday, 12 June 2007 20:19, Eric W. Biederman wrote: > > > Because you are calling unfixably broken code. That should be a decent > > > incentive to do something else won't it? > > > > Can you please tell me _what_ else can be done? > > > > > IOAPICs do not support what the code is doing here. There is lots of > > > practical evidence including bad experiences and practical tests that > > > support this. > > > > Well, AFAICS, Suresh has tried to debug one failing case recently without > > any consistent conclusions. I don't know of any other test cases (links, > > please?). > > Rafael, Darrick Wong's issue looks different and hence I was motivated to > look and fix if it was a SW issue. For now, I am not able to comprehend > what is happening on Darrick Wong's system. Need more help from Darrick > as he has the golden failing system. > > Meanwhile I talked to our hardware folks about the irq migration in general. > > One good news is that future versions of chipsets will have an Interrupt > Remapping feature(for more details please refer to > http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf) > where in we can reliably migrate the irq to someother cpu in the process > context. > > And for the existing platforms, chipset folks don't see a reason why the > Eric's algorithm(specified below) should fail. > > Eric's algorithm for level triggered(edge triggered should be easier than > level triggered): > - Mask the irq in process context. > - Poll RIRR until an ack of for the irq was not pending. > - Migrate the irq. > > Eric had a problem of stuck remote IRR on E75xx chipset with this algorithm > and my next step is to reproduce this issue on this platform and understand > the behavior. OK In that case, do I understand correctly that we are going to implement the Eric's algorithm above for the CPU hotunplugging on x86 once you've figured out what's the E75xx issue? Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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/
Re: [RFC][PATCH 1/1] support for user-space buffers in kfifo
Le mardi 12 juin 2007 à 11:24 -0500, Nelson Castillo a écrit : > On 6/12/07, Stelian Pop <[EMAIL PROTECTED]> wrote: > (cut) > > accessing userspace memory with a spinlock taken (moreover an > > irqsave() > > one) is bad bad bad. > > Hi Stelian. > > I'm sending the new patch without kfifo_put_user and kfifo_get_user. Ok, I have a few formatting/documentation comments: > + * This function copies at most @len bytes from the @buffer into > + * the FIFO depending on the free space, and returns the number of > + * bytes copied. ... or -EFAULT if copy_from_user fails > + * > + * Note that with only one concurrent reader and one concurrent > + * writer, you don't need extra locking to use these functions. > + */ > +int __kfifo_put_user(struct kfifo *fifo, const unsigned char __user *buffer, > + unsigned int len) spacing ? > + if(copy_from_user(fifo->buffer + (fifo->in & (fifo->size - 1)), > + buffer, l)) leave a space after the if please > + * This function copies at most @len bytes from the FIFO into the > + * @buffer and returns the number of copied bytes. or -EFAULT > + * > + * Note that with only one concurrent reader and one concurrent > + * writer, you don't need extra locking to use these functions. > + */ > + > +int __kfifo_get_user(struct kfifo *fifo, > + unsigned char __user *buffer, unsigned int len) spacing. Other than that I'm ok with this patch. Thanks, Stelian. -- Stelian Pop <[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 the FAQ at http://www.tux.org/lkml/
Re: [INPUT] i8042 not detecting AUX port
> Hi, > > Sorry for the delay with my reply. Coudl youplease try the attached > patch and tell me if it works for you without i8042.noloop on the > command line? Hello, Tested and work fine as intended. Many Thanks! Regards, Emmanuel. --- Créez votre adresse électronique [EMAIL PROTECTED] 1 Go d'espace de stockage, anti-spam et anti-virus intégrés. - 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/
Re: PC speaker
> So, the idea was raised about seeing if there was a way to blow the PC > speaker by loading a kernel module. If so, a mass-deployment of a > kernel module overnight would take care of the PC speaker problem once > and for all. No way. None of the conceivable ways of burning out hardware are sufficiently safe to intentionally mass employ them like this. If you could overload the coil, the only imaginable way to burn out a speaker, it could start a fire. This risk is at least significant enough that it's easier to open the case than take it. DS - 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/
Re: VIA C7 / VIA PC-1 (PC2500) anyone?
On Tue, Jun 12, 2007 at 11:59:36PM +0200, Jan Engelhardt wrote: > > On Jun 12 2007 17:01, Michael Tokarev wrote: > > > >Claas Langbehn wrote: > >>> Hmm. I wonder how to *enable* it in the first place.. ;) > >>> e_powersaver.ko and acpi_cpufreq gives "No such device" > >>> > >> cat /proc/cpuinfo and have a look at the flags. Does it support "eps"? > > > >I've looked at e_powersaver sources and noticied the second test in > >init function (after checking for CPU model) - it fails on this very > >test: > > Actually you may want to try longhaul.ko No, he doesn't. Esther doesn't have longhaul. The lack of EST in the feature flags is probably something being disabled in the BIOS (or a crap BIOS). Dave -- http://www.codemonkey.org.uk - 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/
Re: 2.6.22-rc4-mm2: kvm compile breakage with X86_CMPXCHG64=n
On Mon, 11 Jun 2007 23:22:24 -0400 Dave Jones <[EMAIL PROTECTED]> wrote: > Add -Werror-implicit-function-declaration > This makes builds fail sooner if something is implicitly defined instead > of having to wait half an hour for it to fail at the linking stage. > > Signed-off-by: Dave Jones <[EMAIL PROTECTED]> > > --- linux-2.6/Makefile~ 2007-06-04 16:46:24.0 -0400 > +++ linux-2.6/Makefile2007-06-04 16:46:53.0 -0400 > @@ -313,7 +313,8 @@ LINUXINCLUDE:= -Iinclude \ > CPPFLAGS:= -D__KERNEL__ $(LINUXINCLUDE) > > CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ > - -fno-strict-aliasing -fno-common > +-fno-strict-aliasing -fno-common \ > +-Werror-implicit-function-declaration > AFLAGS := -D__ASSEMBLY__ > > # Read KERNELRELEASE from include/config/kernel.release (if it exists) This causes the i386 allmodconfig build to fail: include/linux/uaccess.h: In function 'pagefault_disable': include/linux/uaccess.h:23: error: implicit declaration of function '__memory_barrier' I didn't look to see why... - 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/
Re: 2.6.22-rc4-mm2: GPF during suspend to RAM on HPC nx6325
On Tuesday, 12 June 2007 23:55, Rafael J. Wysocki wrote: > On Monday, 11 June 2007 09:17, Tejun Heo wrote: > > Hello, Rafael. > > > > Rafael J. Wysocki wrote: > > > gregkh-driver-sysfs-use-singly-linked-list-for-sysfs_dirent-tree.patch > > > breaks > > > suspend to RAM on HPC nx6325 (x86_64). > > > > > > With this patch applied I get a general protection fault in > > > mutex_lock+0x15 > > > (kernel/mutex.c:91), called by sysfs_hash_and_remove() > > > (fs/sysfs/inode.c:298), > > > called by threshold_cpu_callback(), called from _cpu_down(). > > > > I'm not sure whether this is bug in sysfs or in sysfs handling code in > > mce_amd and I can't test mce_amd here. Can you please apply the > > attached patch and post the resulting dmesg including oops? > > I've applied the patch, but the oops is a kernel panic, so I can't generate a > dmesg including it. ;-) > > Here's the dmesg output from a fresh boot (runlevel 2): > > http://www.sisk.pl/kernel/debug/2.6.22-rc4-mm2/dmesg.log > > Here's a picture of the oops taken after a failed attempt to suspend: > > http://www.sisk.pl/kernel/debug/2.6.22-rc4-mm2/during_suspend.jpg > > Here's a picture of the oops taken after a failed attempt to offline CPU1 > using 'echo 1 > /sys/devices/system/cpu/cpu1/online': > > http://www.sisk.pl/kernel/debug/2.6.22-rc4-mm2/after_offlining_cpu1.jpg > > [Sorry for the quality of pictures, I couldn't get anything better.] More information: With the debug patch applied the oops is a NULL pointer dereference at sysfs_hash_and_remove+0x16, which according to gdb is (gdb) l *sysfs_hash_and_remove+0x16 0x802d4bff is in sysfs_hash_and_remove (/home/rafael/src/mm/linux-2.6.22-rc4-mm2/fs/sysfs/inode.c:294). 289 int found = 0; 290 291 if (!dir) 292 return -ENOENT; 293 294 if (dir->d_inode == NULL) 295 /* no inode means this hasn't been made visible yet */ 296 return -ENOENT; 297 298 mutex_lock_nested(&dir->d_inode->i_mutex, I_MUTEX_PARENT); That doesn't make much sense to me, but it's 100% reproducible. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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/
Re: [PATCH] x86: Document the hotplug code is incompatible with x86 irq handling
On Tue, Jun 12, 2007 at 10:52:09PM +0200, Rafael J. Wysocki wrote: > On Tuesday, 12 June 2007 20:19, Eric W. Biederman wrote: > > Because you are calling unfixably broken code. That should be a decent > > incentive to do something else won't it? > > Can you please tell me _what_ else can be done? > > > IOAPICs do not support what the code is doing here. There is lots of > > practical evidence including bad experiences and practical tests that > > support this. > > Well, AFAICS, Suresh has tried to debug one failing case recently without > any consistent conclusions. I don't know of any other test cases (links, > please?). Rafael, Darrick Wong's issue looks different and hence I was motivated to look and fix if it was a SW issue. For now, I am not able to comprehend what is happening on Darrick Wong's system. Need more help from Darrick as he has the golden failing system. Meanwhile I talked to our hardware folks about the irq migration in general. One good news is that future versions of chipsets will have an Interrupt Remapping feature(for more details please refer to http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf) where in we can reliably migrate the irq to someother cpu in the process context. And for the existing platforms, chipset folks don't see a reason why the Eric's algorithm(specified below) should fail. Eric's algorithm for level triggered(edge triggered should be easier than level triggered): - Mask the irq in process context. - Poll RIRR until an ack of for the irq was not pending. - Migrate the irq. Eric had a problem of stuck remote IRR on E75xx chipset with this algorithm and my next step is to reproduce this issue on this platform and understand the behavior. thanks, suresh - 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/
Re: Can we get rid of zImage this time?
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Can we please kill zImage? In addition to be completely useless for > modern kernels, it causes unnecessary complexity in boot loaders. I hope so. BTW: I'd just kill old zImage and make it identical to bzImage (I mean "make zImage" would now produce arch/i386/zImage identical to arch/i386/bzImage made by "make bzImage"). Then we could use zImage as for other platforms. -- Krzysztof Halasa - 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/
Re: VIA C7 / VIA PC-1 (PC2500) anyone?
On Jun 12 2007 17:01, Michael Tokarev wrote: > >Claas Langbehn wrote: >>> Hmm. I wonder how to *enable* it in the first place.. ;) >>> e_powersaver.ko and acpi_cpufreq gives "No such device" >>> >> cat /proc/cpuinfo and have a look at the flags. Does it support "eps"? > >I've looked at e_powersaver sources and noticied the second test in >init function (after checking for CPU model) - it fails on this very >test: Actually you may want to try longhaul.ko Jan -- - 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/
