Re: pci_get_device_reverse(), why does Calgary need this?

[Muli Ben-Yehuda]

On Fri, Feb 15, 2008 at 10:28:22AM -0800, Greg KH wrote:

> That would be nice.  Muli, want to make a patch for this?

Sure, I'll put something together.

Cheers,
Muli
--
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: [REGRESSION 2.6.23] no vga console and no messages

[Frans Pop]

Daniel Barkalow wrote:
> For some reason I can't see and don't know how to debug, in 2.6.23 on my
> server I don't get the vga console, but only get the dummy console.

Please check if this bug report matches the issue you are seeing:
http://bugzilla.kernel.org/show_bug.cgi?id=9310

Cheers,
FJP
--
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 3/4] x86_64: Fold pda into per cpu area

[Yinghai Lu]

On Feb 16, 2008 10:22 PM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> On Feb 15, 2008 12:16 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > >  include/asm-generic/vmlinux.lds.h |2 +
> > >  include/linux/percpu.h|9 -
> >
> > couldnt these two generic bits be done separately (perhaps a preparatory
> > but otherwise NOP patch pushed upstream straight away) to make
> > subsequent patches only touch x86 architecture files?
>
> this patch need to apply to mainline asap.
>
> or you need revert to the patch about include/asm-x86/percpu.h
>
> +#ifdef CONFIG_X86_64
> +#include 
> +
> +/* Same as asm-generic/percpu.h, except that we store the per cpu offset
> +   in the PDA. Longer term the PDA and every per cpu variable
> +   should be just put into a single section and referenced directly
> +   from %gs */
> +
> +#ifdef CONFIG_SMP
> +#include 
> +
> +#define __per_cpu_offset(cpu) (cpu_pda(cpu)->data_offset)
> +#define __my_cpu_offset read_pda(data_offset)
> +
> +#define per_cpu_offset(x) (__per_cpu_offset(x))
> +
>  #endif
> +#include 
> +
> +DECLARE_PER_CPU(struct x8664_pda, pda);
> +
> +#else /* CONFIG_X86_64 */
>
> because current tree
> in setup_per_cpu_areas will have
>  cpu_pda(i)->data_offset = ptr - __per_cpu_start;
>
> but at that time all APs will use cpu_pda for boot cpu...,and APs will
> get their pda in do_boot_cpu()

sorry, boot_cpu_pda is array... so that is safe.

YH
--
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.25-rc2-mm1

[Kamalesh Babulal]

Andrew Morton wrote:
> On Sun, 17 Feb 2008 10:38:12 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> 
>> The 2.6.25-rc2-mm1 kernel oopses, followed by softlockup several times (have 
>> pasted
>> only some of them) on the x86_64 machine. The machine has 4 cpu(s).
>>
>> BUG: unable to handle kernel NULL pointer dereference at 0219
>> IP: [] security_inode_getattr+0x4/0x21
>> PGD 1da947067 PUD 1e1803067 PMD 0 
>> Oops:  [1] SMP 
>> last sysfs file: /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed
>> CPU 2 
>> Modules linked in: auth_rpcgss exportfs autofs4 hidp rfcomm l2cap bluetooth 
>> sunrpc ipv6 acpi_cpufreq dm_mirror dm_mod video output sbs sbshc battery 
>> acpi_memhotplug ac parport_pc lp parport sg floppy tg3 button ide_cd_mod 
>> cdrom serio_raw i2c_i801 pcspkr e752x_edac edac_core shpchp i2c_core aic79xx 
>> scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd [last 
>> unloaded: microcode]
>> Pid: 3069, comm: modprobe Not tainted 2.6.25-rc2-mm1-autotest #1
>> RIP: 0010:[]  [] 
>> security_inode_getattr+0x4/0x21
>> RSP: 0018:8101da9e9ea0  EFLAGS: 00010286
>> RAX:  RBX: 8101e1cd7a40 RCX: 0001
>> RDX: 8101da9e9ef8 RSI: 8101e1cd7a40 RDI: 8101e5946dc0
>> RBP: fff7 R08: 0002 R09: 0002
>> R10: 0002 R11: 0246 R12: 
>> R13: 8101da9e9ef8 R14: 8101e5946dc0 R15: 0061a660
>> FS:  7fc33bc746f0() GS:8101e714de40() knlGS:
>> CS:  0010 DS:  ES:  CR0: 8005003b
>> CR2: 0219 CR3: 0001da894000 CR4: 06e0
>> DR0:  DR1:  DR2: 
>> DR3:  DR6: 0ff0 DR7: 0400
>> Process modprobe (pid: 3069, threadinfo 8101da9e8000, task 
>> 8101e51975e0)
>> Stack:  8028e55d 8101e7111300 fff7 8101da9e9ef8
>>  0003 0001 8028e5ca 7fff43c90120
>>  00618e40  8028e5ec 8025b7e3
>> Call Trace:
>>  [] vfs_getattr+0x1a/0x5e
>>  [] vfs_fstat+0x29/0x3a
>>  [] sys_newfstat+0x11/0x29
>>  [] audit_syscall_exit+0x2e4/0x303
>>  [] tracesys+0x71/0xe1
>>  [] tracesys+0xdc/0xe1
>>
>>
>> Code: 8b 98 a8 01 00 00 41 ff e3 31 c0 c3 f6 87 19 02 00 00 02 75 11 48 8b 
>> 05 7d 0d 64 00 4c 8b 98 a0 01 00 00 41 ff e3 c3 48 8b 46 10  80 19 02 00 
>> 00 02 75 11 48 8b 05 5e 0d 64 00 4c 8b 98 98 01 
> 
> Beats me.  Looks like we somehow passed a garbage dentry* into
> security_inode_getattr().  But 0x219?  That could be an offset from an
> accidentally IS_ERR pointer, but sizeof(struct dentry) is only 0xa0 here,
> so the pointer would have to have a value of -0x139 or less, and that's
> outside the range of any sane errnos.
> 
> If it's reproducible then a bisection search would be great, please.
Hi Andrew,

I tried reproducing this panic, but was unsuccessful is reproducing it even 
after four rounds of
try, One of those round i had the following kernel panic 

BUG: unable to handle kernel paging request at 0508fffe
IP: []
PGD 1e382b067 PUD 1e38a9067 PMD 0 
Oops: 0002 [1] SMP 
last sysfs file: /sys/block/hda/removable
CPU 3 
Modules linked in: dm_mirror dm_mod video output sbs sbshc battery 
acpi_memhotplug ac parport_pc lp parport sg floppy tg3 ide_cd_mod button cdrom 
serio_raw i2c_i801 e752x_edac shpchp edac_core i2c_core pcspkr aic79xx 
scsi_transport_spi sd_mod scsi_mod ehci_hcd ohci_hcd uhci_hcd
Pid: 0, comm: swapper Not tainted 2.6.25-rc2-mm1-autotest #1
RIP: 0010:[]  []
RSP: 0018:8101e71dbf08  EFLAGS: 00010282
RAX: 8101e408cb00 RBX: 81000104175f RCX: 
RDX: 0060 RSI: 7fff RDI: 8101e408cb00
RBP: 8101e5839680 R08: 0004 R09: 003c
R10: 8101e711a4c8 R11: 8101e71dbf10 R12: 0002
R13: 0003 R14:  R15: 
FS:  () GS:8101e714d640() knlGS:
CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 0508fffe CR3: 0001e5cbf000 CR4: 06e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process swapper (pid: 0, threadinfo 8101e71d2000, task 8101e71cea70)
Stack:  80260a4c 0001 806800f0 000a
 80260ada 806800e0 80236f33 8101e71d3e88
 0046 8101e71dbf78  
Call Trace:
   [] __rcu_process_callbacks+0x10f/0x17a
 [] rcu_process_callbacks+0x23/0x43
 [] __do_softirq+0x55/0xc4
 [] call_softirq+0x1c/0x28
 [] do_softirq+0x2c/0x68
 [] smp_apic_timer_interrupt+0x8a/0xa3
 [] apic_timer_interrupt+0x66/0x70
   [] default_idle+0x31/0x55
 [] default_idle+0x2c/0x55
 [] default_idle+0x0/0x55
 [] cpu_idle+0x8a/0xac


Code: 00 00 00 00 00 

Re: USB regression (and other failures) in 2.6.2[45]*

[Paul Jackson]

Andrew wrote:
> (Note: I consider it blatantly incorrect to send a reply both to a
> mailing list and directly to the address of someone who is subscribed to
> that list

Regardless of how you consider it, that is how responding to these big
lists -must- work.

There is no practical way for respondents to know, without spending at
a minimum several minutes of their time per reply, whether or not the
explicit receipients of a message are or are not also on one or more of
the receiving lists.

Do you really expect, Andrew, that I should examine the membership lists
of each of linux-scsi, linux-usb and linux-kernel (if they are even open
to the public) to see if you're subscribed to them, before responding to
a message addressed such as this?

As subscribers and submitters to such lists, we just have to learn to
deal with this reality.  For example, I receive an average of a 100
messages per hour on this email address, -after- my employers spam
filters have knocked off over 90% of the incoming.

May I recommend you become an expert in procmail?  That or speed
reading (and speed ignoring ;).

In a separate reply to this message, Alan Stern wrote:
> Everyone has his own taste.

This is not a matter of taste on these big lists.  There is no other
practical alternative.  Most of the burden of ultimate filtering must
be shifted to the recipients, and the senders asked only that they
err on the side of including every individual list or person already
on the address lists.

Joseph Fannin also replied:
> another free mail service which isn't so broken,

I'd recommend fastmail.fm as one of the least broken, most tech savvy
mail services.  I believe that their free side includes IMAP, though
not POP support.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214
--
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] x86_64: get apic_id later in acpi_numa_processor_affinity_init

[Yinghai Lu]

don't need get that at beginning.

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

diff --git a/arch/x86/mm/srat_64.c b/arch/x86/mm/srat_64.c
index ecd91ea..13110f6 100644
--- a/arch/x86/mm/srat_64.c
+++ b/arch/x86/mm/srat_64.c
@@ -132,7 +132,6 @@ acpi_numa_processor_affinity_init(struct 
acpi_srat_cpu_affinity *pa)
int pxm, node;
int apic_id;
 
-   apic_id = pa->apic_id;
if (srat_disabled())
return;
if (pa->header.length != sizeof(struct acpi_srat_cpu_affinity)) {
@@ -148,6 +147,8 @@ acpi_numa_processor_affinity_init(struct 
acpi_srat_cpu_affinity *pa)
bad_srat();
return;
}
+
+   apic_id = pa->apic_id;
apicid_to_node[apic_id] = node;
acpi_numa = 1;
printk(KERN_INFO "SRAT: PXM %u -> APIC %u -> Node %u\n",
--
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.25-rc2-mm1

[Andrew Morton]

On Sat, 16 Feb 2008 22:25:40 -0800 Joel Becker <[EMAIL PROTECTED]> wrote:

> On Sat, Feb 16, 2008 at 12:25:22AM -0800, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
> ...
> > +avoid-divides-in-bits_to_longs.patch
> 
> Andrew,
>   This patch, by introducing sizeof(long) in the BITS_TO_LONGS
> math, changes BITS_TO_LONGS from an int to a unsigned long.  We noticed
> because this printk in fs/ocfs2/dlm/dlmdomain.c:
> 
> mlog(ML_ERROR,
>  "map_size %u != BITS_TO_LONGS(O2NM_MAX_NODES) %u\n",
>  map_size, BITS_TO_LONGS(O2NM_MAX_NODES));
> 
> now gives this warning:
> 
> fs/ocfs2/dlm/dlmdomain.c:938: warning: format '%u' expects type
> 'unsigned int', but argument 7 has type 'long unsigned int'
> 
> We can tweak the printk once the patch goes to Linus, no worries.  I
> just wanted to send a heads up in case the size change affects anything
> else.
> 

Thanks.  That was not intentional and I'll drop the patch.
--
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] x86_64: remove never used nodenumer in pda

[Yinghai Lu]

we don't need copy too. already have x86_cpu_to_node_map

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

diff --git a/arch/x86/mm/numa_64.c b/arch/x86/mm/numa_64.c
index 1aecc65..69b33e3 100644
--- a/arch/x86/mm/numa_64.c
+++ b/arch/x86/mm/numa_64.c
@@ -546,8 +546,6 @@ void __cpuinit numa_set_node(int cpu, int node)
 {
int *cpu_to_node_map = x86_cpu_to_node_map_early_ptr;
 
-   cpu_pda(cpu)->nodenumber = node;
-
if(cpu_to_node_map)
cpu_to_node_map[cpu] = node;
else if(per_cpu_offset(cpu))
diff --git a/include/asm-x86/pda.h b/include/asm-x86/pda.h
index c0305bf..d9dc209 100644
--- a/include/asm-x86/pda.h
+++ b/include/asm-x86/pda.h
@@ -22,7 +22,6 @@ struct x8664_pda {
   offset 40!!! */
 #endif
char *irqstackptr;
-   unsigned int nodenumber;/* number of current node */
unsigned int __softirq_pending;
unsigned int __nmi_count;   /* number of NMI on this CPUs */
short mmu_state;
--
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.25-rc1 xen pvops regression

[Joel Becker]

On Sat, Feb 16, 2008 at 10:46:23PM +1100, Jeremy Fitzhardinge wrote:
>>> What does this EIP correspond to in your kernel?  Also:
>>>
>>> c01687f0 c0417ab6 c040288f c040299a c0403270
>>>
>>> (as guesses of potential callers to try and work out a stack trace).
>>> 
>>
> (My usual technique is use "gdb vmlinux" and "x/i 0x" to do the  
> lookup.) 

Ok, my objdump didn't do a good job.  With gdb I get:

0xc04040bd :mov%edi,(%eax)
0xc01687f0: Cannot access memory at address 0xc01687f0
0xc0417ab6 <__set_fixmap+326>:  pop%ecx
0xc040288f :   lock btsl $0x8,(%eax)
0xc040299a :   lock incb 0xc0766148
0xc0403270 : lock cmpxchg8b (%edi)

Joel

-- 

Life's Little Instruction Book #139

"Never deprive someone of hope; it might be all they have."

Joel Becker
Principal Software Developer
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
--
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.25-rc2-mm1

[Joel Becker]

On Sat, Feb 16, 2008 at 10:25:40PM -0800, Joel Becker wrote:
> On Sat, Feb 16, 2008 at 12:25:22AM -0800, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
> ...
> > +avoid-divides-in-bits_to_longs.patch
> 
> Andrew,
>   This patch, by introducing sizeof(long) in the BITS_TO_LONGS
> math, changes BITS_TO_LONGS from an int to a unsigned long.  We noticed
> because this printk in fs/ocfs2/dlm/dlmdomain.c:

When building on x86_64.  I forgot that bit :-)

Joel

-- 

Life's Little Instruction Book #444

"Never underestimate the power of a kind word or deed."

Joel Becker
Principal Software Developer
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
--
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.25-rc1 xen pvops regression

[Joel Becker]

On Sat, Feb 16, 2008 at 10:46:23PM +1100, Jeremy Fitzhardinge wrote:
> Joel Becker wrote:
>>  ksymoops is no help at all, but I got these from objdump of
>> vmlinux:
>>
>> c04040bd xen_set_pte
>> c0417ab6 set_pte_present
>> c040288f set_bit
>> c040299a __raw_spin_unlock
>> c0403270 __set_64bit
>
> (My usual technique is use "gdb vmlinux" and "x/i 0x" to do the  
> lookup.) 

Thanks for the tip!

> Unfortunately that doesn't narrow down what the kernel was actually  
> trying to do at the time.  Clearly a set_pte; looks like someone is  
> trying to create a writable mapping of an existing pte page.
>
> Does "console=hvc0 earlyprintk=xen" on the kernel command line give any  
> clue about how far it gets before crashing?

Console is already hvc0, but earlyprintk gets us:

--8<-
Reserving virtual address space above 0xf57fe000
Linux version 2.6.25-rc2-bisectme ([EMAIL PROTECTED]) (gcc
version 4.1.2 20070626 (Red Hat 4.1.2-14)) #21 SMP Fri Feb 15 16:28:35
PST 2008
ACPI in unprivileged domain disabled
BIOS-provided physical RAM map:
 Xen:  - 7800 (usable)
console [xenboot0] enabled
1192MB HIGHMEM available.
727MB LOWMEM available.
Started domain ca-test58
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
NX (Execute Disable) protection: active
Zone PFN ranges:
  DMA 0 -> 4096
  Normal   4096 ->   186366
  HighMem186366 ->   491520
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0:0 ->   491520
-->8-

That's it.

Joel

-- 

"The nearest approach to immortality on Earth is a government
 bureau."
- James F. Byrnes

Joel Becker
Principal Software Developer
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
--
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.25-rc2-mm1

[Joel Becker]

On Sat, Feb 16, 2008 at 12:25:22AM -0800, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
...
> +avoid-divides-in-bits_to_longs.patch

Andrew,
This patch, by introducing sizeof(long) in the BITS_TO_LONGS
math, changes BITS_TO_LONGS from an int to a unsigned long.  We noticed
because this printk in fs/ocfs2/dlm/dlmdomain.c:

mlog(ML_ERROR,
 "map_size %u != BITS_TO_LONGS(O2NM_MAX_NODES) %u\n",
 map_size, BITS_TO_LONGS(O2NM_MAX_NODES));

now gives this warning:

fs/ocfs2/dlm/dlmdomain.c:938: warning: format '%u' expects type
'unsigned int', but argument 7 has type 'long unsigned int'

We can tweak the printk once the patch goes to Linus, no worries.  I
just wanted to send a heads up in case the size change affects anything
else.

Joel

-- 

 There are morethings in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.

Joel Becker
Principal Software Developer
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
--
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 3/4] x86_64: Fold pda into per cpu area

[Yinghai Lu]

On Feb 15, 2008 12:16 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> >  include/asm-generic/vmlinux.lds.h |2 +
> >  include/linux/percpu.h|9 -
>
> couldnt these two generic bits be done separately (perhaps a preparatory
> but otherwise NOP patch pushed upstream straight away) to make
> subsequent patches only touch x86 architecture files?

this patch need to apply to mainline asap.

or you need revert to the patch about include/asm-x86/percpu.h

+#ifdef CONFIG_X86_64
+#include 
+
+/* Same as asm-generic/percpu.h, except that we store the per cpu offset
+   in the PDA. Longer term the PDA and every per cpu variable
+   should be just put into a single section and referenced directly
+   from %gs */
+
+#ifdef CONFIG_SMP
+#include 
+
+#define __per_cpu_offset(cpu) (cpu_pda(cpu)->data_offset)
+#define __my_cpu_offset read_pda(data_offset)
+
+#define per_cpu_offset(x) (__per_cpu_offset(x))
+
 #endif
+#include 
+
+DECLARE_PER_CPU(struct x8664_pda, pda);
+
+#else /* CONFIG_X86_64 */

because current tree
in setup_per_cpu_areas will have
 cpu_pda(i)->data_offset = ptr - __per_cpu_start;

but at that time all APs will use cpu_pda for boot cpu...,and APs will
get their pda in do_boot_cpu()

the result is all cpu will have same data_offset, there will share one
per_cpu_data..that is totally wrong!!

that could explain a lot of strange panic recently about NUMA...

YH
--
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] h8300 CONFIG_KALLSYMS fix

[Paul Mundt]

On Sat, Feb 16, 2008 at 11:46:47AM +0100, Sam Ravnborg wrote:
> Something like this:
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 3d72dc3..f2928c5 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -29,3 +29,8 @@ config KPROBES
> 
>  config HAVE_KPROBES
> def_bool n
> +
> +# Architectures where binutils prefix C symbols with
> +# underscore '_' shall select this symbol.
> +config SYMBOL_C_PREFIX
> +   bool
> 
> 
> Then in the relevant architectures we should do a
> 
>  config H8300
> + select SYMBOL_C_PREFIX  # We prefix C symbols with '_'
> 
> And we should do this for all the relevant architectures:
> blackfin, v850 springs to my mind.
> For the other archs as separate patches via the respective
> maintainers.
> 
It's really a product of the toolchain, not the architecture. For SH also
we have some toolchains that do this, and others that don't. (Usually
sh-elf insteatd of sh-linux, the -elf toolchains in general are pretty
common for the nommu targets). In general we've just not supported the
symbol prefixing toolchains, but if there's a way we can handle this
cleanly at compile time then it's certainly worth trying to support.
--
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] h8300 add sci.h

[Paul Mundt]

On Sat, Feb 16, 2008 at 11:41:11PM -0500, Yoshinori Sato wrote:
> This file require sh-sci
> 
> Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]>
> 
>  include/asm-h8300/sci.h |   34 ++
>  1 files changed, 34 insertions(+), 0 deletions(-)
>  create mode 100644 include/asm-h8300/sci.h
> 
Let's just move it to include/linux instead of doing a 100% duplication
for H8..
--
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: include/linux/pcounter.h

[David Miller]

From: Andrew Morton <[EMAIL PROTECTED]>
Date: Sat, 16 Feb 2008 11:26:18 -0800

> On Sat, 16 Feb 2008 13:03:54 +0100 Eric Dumazet <[EMAIL PROTECTED]> wrote:
> 
> > Yes, per connection basis. Some workloads want to open/close more than 1000 
> > sockets per second.
> 
> ie: slowpath

Definitely not slow path in the networking.

Connection rates are definitely as, or more, important than packet
rates for certain workloads.
--
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.25-rc2-mm1 (build failure)

[Andrew Morton]

On Sat, 16 Feb 2008 21:32:25 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote:

> On Sat, 16 Feb 2008 00:25:22 -0800 Andrew Morton wrote:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
> 
> When SMP=n, x86_64 build gets:
> 
> arch/x86/kernel/built-in.o: In function `acpi_save_state_mem':
> (.text+0xfd7f): undefined reference to `setup_trampoline'
> make[1]: *** [.tmp_vmlinux1] Error 1
> 

Thanks.  Say hello to Pavel.
--
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.25-rc2-mm1 (x64 thermal build failure)

[Andrew Morton]

On Sat, 16 Feb 2008 21:16:03 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote:

> On Sat, 16 Feb 2008 00:25:22 -0800 Andrew Morton wrote:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
> 
> ACPI is enabled, but DMI=n.
> 
> linux-2.6.25-rc2-mm1/drivers/acpi/thermal.c: In function 'acpi_thermal_init':
> linux-2.6.25-rc2-mm1/drivers/acpi/thermal.c:1792: error: 'thermal_dmi_table' 
> undeclared (first use in this function)
> linux-2.6.25-rc2-mm1/drivers/acpi/thermal.c:1792: error: (Each undeclared 
> identifier is reported only once
> linux-2.6.25-rc2-mm1/drivers/acpi/thermal.c:1792: error: for each function it 
> appears in.)
> make[3]: *** [drivers/acpi/thermal.o] Error 1
> 

Bustage in x86-configurable-dmi-scanning-code.patch.  Previously, DMI=y was
just hardwired.  Now, it becomes selectable and stuff breaks.

I guess the DMI=n version of dmi_check_system() could become a macro so we
don't emit a reference to its argument, but that might generate
unused-variable warnings elsewhere.

--
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: linux-next: first tree

[Stephen Rothwell]

Hi Robin,

On Sat, 16 Feb 2008 21:23:47 -0500 Robin Getz <[EMAIL PROTECTED]> wrote:
>
> You can grab (i386 rpms and tar ball) that should work from:
> 
> http://blackfin.uclinux.org/gf/project/toolchain/frs/?action=FrsReleaseView_id=375
> 
> You will need:
>  - toolchain blackfin-toolchain-08r1-8.i386.rpm
>  - c library (either one of):
> - blackfin-toolchain-uclibc-default-08r1-8.i386.rpm
> - blackfin-toolchain-uclibc-full-08r1-8.i386.rpm
> 
> Other arch's & packages should appear shortly.

Thanks, I will have a look.  My current build machines are powerpc, so I
may have to wait ...

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]


pgpoUhIVNgIjl.pgp
Description: PGP signature

Re: 2.6.25-rc2-mm1 (build failure)

[Randy Dunlap]

On Sat, 16 Feb 2008 00:25:22 -0800 Andrew Morton wrote:

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/

When SMP=n, x86_64 build gets:

arch/x86/kernel/built-in.o: In function `acpi_save_state_mem':
(.text+0xfd7f): undefined reference to `setup_trampoline'
make[1]: *** [.tmp_vmlinux1] Error 1

---
~Randy
--
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 3/6] h8300 setup.c initrd support fix

[Andrew Morton]

On Sun, 17 Feb 2008 00:09:47 -0500 Yoshinori Sato <[EMAIL PROTECTED]> wrote:

> 
> Sorry. I mistake orign.
> Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]>
> 

Please include a full description of your patches!

> 
> diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c
> index b1f25c2..4dd744f 100644
> --- a/arch/h8300/kernel/setup.c
> +++ b/arch/h8300/kernel/setup.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -99,8 +100,8 @@ void __init setup_arch(char **cmdline_p)
>   /* allow for ROMFS on the end of the kernel */
>   if (memcmp((void *)memory_start, "-rom1fs-", 8) == 0) {
>  #if defined(CONFIG_BLK_DEV_INITRD)
> - initrd_start = memory_start;
> - initrd_end = memory_start += be32_to_cpu(((unsigned long *) 
> (memory_start))[2]);
> + initrd_start = (void *)memory_start;
> + initrd_end = (void *)(memory_start += be32_to_cpu(((unsigned 
> long *) (memory_start))[2]));
>  #else
>   memory_start += be32_to_cpu(((unsigned long *) 
> memory_start)[2]);
>  #endif

This is still wrong.

initrd_start and initrd_end have type `unsigned long'.  But the
right-hand-side of these assignemtns has type void*.  THe compiler will
warn.


--
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: Linux-next (Or Andrew's dream :-))

[Stephen Rothwell]

Hi James,

On Sat, 16 Feb 2008 09:14:32 -0600 James Bottomley <[EMAIL PROTECTED]> wrote:
>
> Do you have the tree and build logs available anywhere?  I'd like to
> turn off the merge tree builds when this is able to replace it.

The tree is at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git - or did
you mean the logs of creating the tree.  I currently ceate the tree
fairly manually (as I slowly script what can be) and so have no logs of
that process.

The build logs that I have some control over are at
http://kisskb.ellerman.id.au/kisskb/branch/9/.  I am hoping to expand on
the arch/config combinations over time (I have to convince my tame cross
compiler builder :-)).  I also hope that others will build this tree for
themselves and publish the results.

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]


pgpCWLR46O0ph.pgp
Description: PGP signature

Re: 2.6.25-rc2-mm1

[Andrew Morton]

On Sun, 17 Feb 2008 10:38:12 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:

> The 2.6.25-rc2-mm1 kernel oopses, followed by softlockup several times (have 
> pasted
> only some of them) on the x86_64 machine. The machine has 4 cpu(s).
> 
> BUG: unable to handle kernel NULL pointer dereference at 0219
> IP: [] security_inode_getattr+0x4/0x21
> PGD 1da947067 PUD 1e1803067 PMD 0 
> Oops:  [1] SMP 
> last sysfs file: /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed
> CPU 2 
> Modules linked in: auth_rpcgss exportfs autofs4 hidp rfcomm l2cap bluetooth 
> sunrpc ipv6 acpi_cpufreq dm_mirror dm_mod video output sbs sbshc battery 
> acpi_memhotplug ac parport_pc lp parport sg floppy tg3 button ide_cd_mod 
> cdrom serio_raw i2c_i801 pcspkr e752x_edac edac_core shpchp i2c_core aic79xx 
> scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd [last 
> unloaded: microcode]
> Pid: 3069, comm: modprobe Not tainted 2.6.25-rc2-mm1-autotest #1
> RIP: 0010:[]  [] 
> security_inode_getattr+0x4/0x21
> RSP: 0018:8101da9e9ea0  EFLAGS: 00010286
> RAX:  RBX: 8101e1cd7a40 RCX: 0001
> RDX: 8101da9e9ef8 RSI: 8101e1cd7a40 RDI: 8101e5946dc0
> RBP: fff7 R08: 0002 R09: 0002
> R10: 0002 R11: 0246 R12: 
> R13: 8101da9e9ef8 R14: 8101e5946dc0 R15: 0061a660
> FS:  7fc33bc746f0() GS:8101e714de40() knlGS:
> CS:  0010 DS:  ES:  CR0: 8005003b
> CR2: 0219 CR3: 0001da894000 CR4: 06e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: 0ff0 DR7: 0400
> Process modprobe (pid: 3069, threadinfo 8101da9e8000, task 
> 8101e51975e0)
> Stack:  8028e55d 8101e7111300 fff7 8101da9e9ef8
>  0003 0001 8028e5ca 7fff43c90120
>  00618e40  8028e5ec 8025b7e3
> Call Trace:
>  [] vfs_getattr+0x1a/0x5e
>  [] vfs_fstat+0x29/0x3a
>  [] sys_newfstat+0x11/0x29
>  [] audit_syscall_exit+0x2e4/0x303
>  [] tracesys+0x71/0xe1
>  [] tracesys+0xdc/0xe1
> 
> 
> Code: 8b 98 a8 01 00 00 41 ff e3 31 c0 c3 f6 87 19 02 00 00 02 75 11 48 8b 05 
> 7d 0d 64 00 4c 8b 98 a0 01 00 00 41 ff e3 c3 48 8b 46 10  80 19 02 00 00 
> 02 75 11 48 8b 05 5e 0d 64 00 4c 8b 98 98 01 

Beats me.  Looks like we somehow passed a garbage dentry* into
security_inode_getattr().  But 0x219?  That could be an offset from an
accidentally IS_ERR pointer, but sizeof(struct dentry) is only 0xa0 here,
so the pointer would have to have a value of -0x139 or less, and that's
outside the range of any sane errnos.

If it's reproducible then a bisection search would be great, please.
--
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.25-rc2-mm1 (x64 thermal build failure)

[Randy Dunlap]

On Sat, 16 Feb 2008 00:25:22 -0800 Andrew Morton wrote:

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/

ACPI is enabled, but DMI=n.

linux-2.6.25-rc2-mm1/drivers/acpi/thermal.c: In function 'acpi_thermal_init':
linux-2.6.25-rc2-mm1/drivers/acpi/thermal.c:1792: error: 'thermal_dmi_table' 
undeclared (first use in this function)
linux-2.6.25-rc2-mm1/drivers/acpi/thermal.c:1792: error: (Each undeclared 
identifier is reported only once
linux-2.6.25-rc2-mm1/drivers/acpi/thermal.c:1792: error: for each function it 
appears in.)
make[3]: *** [drivers/acpi/thermal.o] Error 1


---
~Randy
--
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 3/6] h8300 setup.c initrd support fix

[Yoshinori Sato]

At Sat, 16 Feb 2008 20:55:02 -0800,
Andrew Morton wrote:
> 
> On Sat, 16 Feb 2008 23:39:09 -0500 Yoshinori Sato <[EMAIL PROTECTED]> wrote:
> 
> > At Fri, 15 Feb 2008 22:29:49 -0800,
> > Andrew Morton wrote:
> > > 
> > > On Sat, 16 Feb 2008 01:13:37 -0500 Yoshinori Sato <[EMAIL PROTECTED]> 
> > > wrote:
> > > 
> > > > initrd setting fix.
> > > > 
> > > >  arch/h8300/kernel/setup.c |5 +++--
> > > >  1 files changed, 3 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c
> > > > index b1f25c2..75712ec 100644
> > > > --- a/arch/h8300/kernel/setup.c
> > > > +++ b/arch/h8300/kernel/setup.c
> > > > @@ -57,6 +57,7 @@ extern int _stext, _etext, _sdata, _edata, _sbss, 
> > > > _ebss, _end;
> > > >  extern int _ramstart, _ramend;
> > > >  extern char _target_name[];
> > > >  extern void h8300_gpio_init(void);
> > > > +extern void *initrd_start, *initrd_end;
> > > >  
> > > >  #if (defined(CONFIG_H8300H_SIM) || defined(CONFIG_H8S_SIM)) \
> > > >  && defined(CONFIG_GDB_MAGICPRINT)
> > > > @@ -99,8 +100,8 @@ void __init setup_arch(char **cmdline_p)
> > > > /* allow for ROMFS on the end of the kernel */
> > > > if (memcmp((void *)memory_start, "-rom1fs-", 8) == 0) {
> > > >  #if defined(CONFIG_BLK_DEV_INITRD)
> > > > -   initrd_start = memory_start;
> > > > -   initrd_end = memory_start += be32_to_cpu(((unsigned 
> > > > long *) (memory_start))[2]);
> > > > +   initrd_start = (void *)memory_start;
> > > > +   initrd_end = (void *)(memory_start += 
> > > > be32_to_cpu(((unsigned long *) (memory_start))[2]));
> > > >  #else
> > > > memory_start += be32_to_cpu(((unsigned long *) 
> > > > memory_start)[2]);
> > > >  #endif
> > > 
> > > But include/linux/initrd.h declares:
> > > 
> > >   extern unsigned long initrd_start, initrd_end;
> > > 
> > 
> > fix it.
> 
> I assume this new patch is an addition to the previous one quoted above?
> 
> > Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]>
> > 
> >  arch/h8300/kernel/setup.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c
> > index 75712ec..4dd744f 100644
> > --- a/arch/h8300/kernel/setup.c
> > +++ b/arch/h8300/kernel/setup.c
> > @@ -30,6 +30,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -57,7 +58,6 @@ extern int _stext, _etext, _sdata, _edata, _sbss, _ebss, 
> > _end;
> >  extern int _ramstart, _ramend;
> >  extern char _target_name[];
> >  extern void h8300_gpio_init(void);
> > -extern void *initrd_start, *initrd_end;
> >  
> >  #if (defined(CONFIG_H8300H_SIM) || defined(CONFIG_H8S_SIM)) \
> >  && defined(CONFIG_GDB_MAGICPRINT)
> 
> If so then surely it generated a warning when assigning a void* to an
> unsigned long.
> 
> So please send a complete new fully tested patch.  Please also include a
> changelog which describes what is being fixed, and how it is fixed.  The
> text "initrd setting fix." and "fit it" is not sufficient - it doesn't
> tell us what was wrong with the old code, nor how the change improved it.
> 
> Thanks.

Sorry. I mistake orign.
Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]>

 arch/h8300/kernel/setup.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c
index b1f25c2..4dd744f 100644
--- a/arch/h8300/kernel/setup.c
+++ b/arch/h8300/kernel/setup.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -99,8 +100,8 @@ void __init setup_arch(char **cmdline_p)
/* allow for ROMFS on the end of the kernel */
if (memcmp((void *)memory_start, "-rom1fs-", 8) == 0) {
 #if defined(CONFIG_BLK_DEV_INITRD)
-   initrd_start = memory_start;
-   initrd_end = memory_start += be32_to_cpu(((unsigned long *) 
(memory_start))[2]);
+   initrd_start = (void *)memory_start;
+   initrd_end = (void *)(memory_start += be32_to_cpu(((unsigned 
long *) (memory_start))[2]));
 #else
memory_start += be32_to_cpu(((unsigned long *) 
memory_start)[2]);
 #endif

--
1.5.4.1

-- 
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: 2.6.25-rc2-mm1

[Kamalesh Babulal]

Hi Andrew,

The 2.6.25-rc2-mm1 kernel oopses, followed by softlockup several times (have 
pasted
only some of them) on the x86_64 machine. The machine has 4 cpu(s).

BUG: unable to handle kernel NULL pointer dereference at 0219
IP: [] security_inode_getattr+0x4/0x21
PGD 1da947067 PUD 1e1803067 PMD 0 
Oops:  [1] SMP 
last sysfs file: /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed
CPU 2 
Modules linked in: auth_rpcgss exportfs autofs4 hidp rfcomm l2cap bluetooth 
sunrpc ipv6 acpi_cpufreq dm_mirror dm_mod video output sbs sbshc battery 
acpi_memhotplug ac parport_pc lp parport sg floppy tg3 button ide_cd_mod cdrom 
serio_raw i2c_i801 pcspkr e752x_edac edac_core shpchp i2c_core aic79xx 
scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd [last 
unloaded: microcode]
Pid: 3069, comm: modprobe Not tainted 2.6.25-rc2-mm1-autotest #1
RIP: 0010:[]  [] 
security_inode_getattr+0x4/0x21
RSP: 0018:8101da9e9ea0  EFLAGS: 00010286
RAX:  RBX: 8101e1cd7a40 RCX: 0001
RDX: 8101da9e9ef8 RSI: 8101e1cd7a40 RDI: 8101e5946dc0
RBP: fff7 R08: 0002 R09: 0002
R10: 0002 R11: 0246 R12: 
R13: 8101da9e9ef8 R14: 8101e5946dc0 R15: 0061a660
FS:  7fc33bc746f0() GS:8101e714de40() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 0219 CR3: 0001da894000 CR4: 06e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process modprobe (pid: 3069, threadinfo 8101da9e8000, task 8101e51975e0)
Stack:  8028e55d 8101e7111300 fff7 8101da9e9ef8
 0003 0001 8028e5ca 7fff43c90120
 00618e40  8028e5ec 8025b7e3
Call Trace:
 [] vfs_getattr+0x1a/0x5e
 [] vfs_fstat+0x29/0x3a
 [] sys_newfstat+0x11/0x29
 [] audit_syscall_exit+0x2e4/0x303
 [] tracesys+0x71/0xe1
 [] tracesys+0xdc/0xe1


Code: 8b 98 a8 01 00 00 41 ff e3 31 c0 c3 f6 87 19 02 00 00 02 75 11 48 8b 05 
7d 0d 64 00 4c 8b 98 a0 01 00 00 41 ff e3 c3 48 8b 46 10  80 19 02 00 00 02 
75 11 48 8b 05 5e 0d 64 00 4c 8b 98 98 01 
RIP  [] security_inode_getattr+0x4/0x21
 RSP 
CR2: 0219
---[ end trace ea9acd9e67a1740e ]---
BUG: unable to handle kernel NULL pointer dereference at 00b2
IP: [] dnotify_flush+0x18/0x84
PGD 0 
Oops:  [2] SMP 
last sysfs file: /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed
CPU 0 
Modules linked in: auth_rpcgss exportfs autofs4 hidp rfcomm l2cap bluetooth 
sunrpc ipv6 acpi_cpufreq dm_mirror dm_mod video output sbs sbshc battery 
acpi_memhotplug ac parport_pc lp parport sg floppy tg3 button ide_cd_mod cdrom 
serio_raw i2c_i801 pcspkr e752x_edac edac_core shpchp i2c_core aic79xx 
scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd [last 
unloaded: microcode]
Pid: 3069, comm: modprobe Tainted: G  D   2.6.25-rc2-mm1-autotest #1
RIP: 0010:[]  [] dnotify_flush+0x18/0x84
RSP: 0018:8101da9e9ca8  EFLAGS: 00010292
RAX: 8101e1cd7a40 RBX: 8101e7111300 RCX: 0058
RDX:  RSI: 8101e4488cc0 RDI: 8101e7111300
RBP:  R08: 8101e343d7c0 R09: 81000d80
R10: 0001 R11: 802eed8e R12: 8101e7111300
R13: 8101e4488cc0 R14:  R15: 
FS:  () GS:805b7000() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 00b2 CR3: 00201000 CR4: 06e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process modprobe (pid: 3069, threadinfo 8101da9e8000, task 8101e51975e0)
Stack:  8101e343d7c0 8101e7111300 8101e4488cc0 
 8101e4488cd0 80289c58 8101e4488cc0 0001
  802343a8 8101e343d7c0 0001
Call Trace:
 [] filp_close+0x4a/0x65
 [] put_files_struct+0x66/0xc4
 [] do_exit+0x261/0x6cf
 [] oops_begin+0x0/0x8c
 [] do_page_fault+0x73d/0x7f6
 [] error_exit+0x0/0x51
 [] security_inode_getattr+0x4/0x21
 [] vfs_getattr+0x1a/0x5e
 [] vfs_fstat+0x29/0x3a
 [] sys_newfstat+0x11/0x29
 [] audit_syscall_exit+0x2e4/0x303
 [] tracesys+0x71/0xe1
 [] tracesys+0xdc/0xe1


Code: 5b ff ff ff fe 85 b4 00 00 00 5b 5d 41 5c 41 5d 41 5e c3 41 55 49 89 f5 
41 54 49 89 fc 55 53 48 83 ec 08 48 8b 47 18 48 8b 68 10 <0f> b7 85 b2 00 00 00 
25 00 f0 00 00 3d 00 40 00 00 75 51 48 8d 
RIP  [] dnotify_flush+0x18/0x84
 RSP 
CR2: 00b2
---[ end trace ea9acd9e67a1740e ]---
BUG: unable to handle kernel NULL pointer dereference at 0219
IP: [] security_inode_getattr+0x4/0x21
PGD 0 
Oops:  [3] SMP 
last sysfs file: /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed

Re: [patch 1/6] mmu_notifier: Core code

[Doug Maxey]

On Fri, 15 Feb 2008 19:37:19 PST, Andrew Morton wrote:
> Which other potential clients have been identified and how important it it
> to those?

The powerpc ehea utilizes its own mmu.  Not sure about the importance 
to the driver. (But will investigate :)

++doug

--
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: [BUG] 2.6.25-rc2-mm1 - Kernel panic while bootup caused by signal_group_exit()

[Kamalesh Babulal]

Andrew Morton wrote:
> On Sun, 17 Feb 2008 09:40:33 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> 
>> Hi Andrew,
>>
>> The signals-do_signal_stop-use-signal_group_exit.patch is causing the
>> kernel panic, while booting in to the 2.6.25-rc2-mm1 kernel on x86.
>>
>> There has been discussion on the patch for this panic on 
>> http://lkml.org/lkml/2008/2/16/99 
>>
>> [   25.512919] BUG: unable to handle kernel paging request at 9d74e37b
>> [   25.514926] IP: [] proc_flush_task+0x5b/0x223
>> [   25.516934] Oops:  [#1] SMP 
>> [   25.517918] last sysfs file: /sys/block/hdc/removable
>> [   25.517918] Modules linked in: dm_mirror dm_mod video output sbs sbshc 
>> battery ac parport_pc lp parport floppy sg serio_raw ide_cd_mod cdrom 
>> scb2_flash mtd chipreg button i2c_piix4 i2c_core pcspkr tg3 mptspi mptscsih 
>> mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd 
>> uhci_hcd
>> [   25.517918] 
>> [   25.517918] Pid: 1, comm: init Not tainted (2.6.25-rc2-mm1-autotest #1)
>> [   25.517918] EIP: 0060:[] EFLAGS: 00010282 CPU: 2
>> [   25.517918] EIP is at proc_flush_task+0x5b/0x223
>> [   25.517918] EAX: 9d74e35b EBX: f7881ef0 ECX: f7a5ed84 EDX: a56b6b6b
>> [   25.517918] ESI: f74f76f8 EDI: a56b6b6b EBP: f7881f08 ESP: f7881ec0
>> [   25.517918]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>> [   25.517918] Process init (pid: 1, ti=f7881000 task=f788adf0 
>> task.ti=f7881000)
>> [   25.517918] Stack: f7a5ed84 0001 f7a5ed58 f7a5ed58  a56b6b6b 
>> f7852750 f7a5ed68 
>> [   25.517918]35881ef4 3130 f788b4a4 f788adf0 0012d6c5 0003 
>> f7881ee3 0003 
>> [   25.517918]f7a72df0 f7a72df0 f7881f1c c042676d 0003 01f5 
>> f7a72df0 f7881f78 
>> [   25.517918] Call Trace:
>> [   25.517918]  [] release_task+0x19/0x2d5
>> [   25.517918]  [] do_wait+0x5f2/0x8fc
>> [   25.517918]  [] default_wake_function+0x0/0xd
>> [   25.517918]  [] sys_wait4+0x78/0x8e
>> [   25.517918]  [] sys_waitpid+0x13/0x15
>> [   25.517918]  [] sysenter_past_esp+0x5f/0x99
>> [   25.517918]  ===
>> [   25.517918] Code: 1c 89 4d d4 89 4d c4 89 55 b8 e9 b5 01 00 00 31 ff 83 
>> 7d c4 00 74 06 8b 45 d4 8b 78 1c 8b 55 b8 8b 4d b8 8b 12 89 55 cc 8b 41 04 
>> <8b> 40 20 52 68 33 cd 6f c0 6a 0d 89 45 d0 8d 45 db 50 89 45 f0 
>> [   25.517918] EIP: [] proc_flush_task+0x5b/0x223 SS:ESP 
>> 0068:f7881ec0
>> [   25.517939] ---[ end trace d0df919a64605019 ]---
>> [   25.518925] Kernel panic - not syncing: Attempted to kill init!
>>
> 
> hm, are you sure that signals-do_signal_stop-use-signal_group_exit.patch
> causes this oops?  

sorry signals-do_signal_stop-use-signal_group_exit.patch is not causing the 
problem, not sure of what is causing this panic :-(

--
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: [BUG] 2.6.25-rc2-mm1 - Kernel panic while bootup caused by signal_group_exit()

[Andrew Morton]

On Sun, 17 Feb 2008 09:40:33 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:

> Hi Andrew,
> 
> The signals-do_signal_stop-use-signal_group_exit.patch is causing the
> kernel panic, while booting in to the 2.6.25-rc2-mm1 kernel on x86.
> 
> There has been discussion on the patch for this panic on 
> http://lkml.org/lkml/2008/2/16/99 
> 
> [   25.512919] BUG: unable to handle kernel paging request at 9d74e37b
> [   25.514926] IP: [] proc_flush_task+0x5b/0x223
> [   25.516934] Oops:  [#1] SMP 
> [   25.517918] last sysfs file: /sys/block/hdc/removable
> [   25.517918] Modules linked in: dm_mirror dm_mod video output sbs sbshc 
> battery ac parport_pc lp parport floppy sg serio_raw ide_cd_mod cdrom 
> scb2_flash mtd chipreg button i2c_piix4 i2c_core pcspkr tg3 mptspi mptscsih 
> mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
> [   25.517918] 
> [   25.517918] Pid: 1, comm: init Not tainted (2.6.25-rc2-mm1-autotest #1)
> [   25.517918] EIP: 0060:[] EFLAGS: 00010282 CPU: 2
> [   25.517918] EIP is at proc_flush_task+0x5b/0x223
> [   25.517918] EAX: 9d74e35b EBX: f7881ef0 ECX: f7a5ed84 EDX: a56b6b6b
> [   25.517918] ESI: f74f76f8 EDI: a56b6b6b EBP: f7881f08 ESP: f7881ec0
> [   25.517918]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> [   25.517918] Process init (pid: 1, ti=f7881000 task=f788adf0 
> task.ti=f7881000)
> [   25.517918] Stack: f7a5ed84 0001 f7a5ed58 f7a5ed58  a56b6b6b 
> f7852750 f7a5ed68 
> [   25.517918]35881ef4 3130 f788b4a4 f788adf0 0012d6c5 0003 
> f7881ee3 0003 
> [   25.517918]f7a72df0 f7a72df0 f7881f1c c042676d 0003 01f5 
> f7a72df0 f7881f78 
> [   25.517918] Call Trace:
> [   25.517918]  [] release_task+0x19/0x2d5
> [   25.517918]  [] do_wait+0x5f2/0x8fc
> [   25.517918]  [] default_wake_function+0x0/0xd
> [   25.517918]  [] sys_wait4+0x78/0x8e
> [   25.517918]  [] sys_waitpid+0x13/0x15
> [   25.517918]  [] sysenter_past_esp+0x5f/0x99
> [   25.517918]  ===
> [   25.517918] Code: 1c 89 4d d4 89 4d c4 89 55 b8 e9 b5 01 00 00 31 ff 83 7d 
> c4 00 74 06 8b 45 d4 8b 78 1c 8b 55 b8 8b 4d b8 8b 12 89 55 cc 8b 41 04 <8b> 
> 40 20 52 68 33 cd 6f c0 6a 0d 89 45 d0 8d 45 db 50 89 45 f0 
> [   25.517918] EIP: [] proc_flush_task+0x5b/0x223 SS:ESP 
> 0068:f7881ec0
> [   25.517939] ---[ end trace d0df919a64605019 ]---
> [   25.518925] Kernel panic - not syncing: Attempted to kill init!
> 

hm, are you sure that signals-do_signal_stop-use-signal_group_exit.patch
causes this oops?  
--
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 3/6] h8300 setup.c initrd support fix

[Andrew Morton]

On Sat, 16 Feb 2008 23:39:09 -0500 Yoshinori Sato <[EMAIL PROTECTED]> wrote:

> At Fri, 15 Feb 2008 22:29:49 -0800,
> Andrew Morton wrote:
> > 
> > On Sat, 16 Feb 2008 01:13:37 -0500 Yoshinori Sato <[EMAIL PROTECTED]> wrote:
> > 
> > > initrd setting fix.
> > > 
> > >  arch/h8300/kernel/setup.c |5 +++--
> > >  1 files changed, 3 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c
> > > index b1f25c2..75712ec 100644
> > > --- a/arch/h8300/kernel/setup.c
> > > +++ b/arch/h8300/kernel/setup.c
> > > @@ -57,6 +57,7 @@ extern int _stext, _etext, _sdata, _edata, _sbss, 
> > > _ebss, _end;
> > >  extern int _ramstart, _ramend;
> > >  extern char _target_name[];
> > >  extern void h8300_gpio_init(void);
> > > +extern void *initrd_start, *initrd_end;
> > >  
> > >  #if (defined(CONFIG_H8300H_SIM) || defined(CONFIG_H8S_SIM)) \
> > >  && defined(CONFIG_GDB_MAGICPRINT)
> > > @@ -99,8 +100,8 @@ void __init setup_arch(char **cmdline_p)
> > >   /* allow for ROMFS on the end of the kernel */
> > >   if (memcmp((void *)memory_start, "-rom1fs-", 8) == 0) {
> > >  #if defined(CONFIG_BLK_DEV_INITRD)
> > > - initrd_start = memory_start;
> > > - initrd_end = memory_start += be32_to_cpu(((unsigned long *) 
> > > (memory_start))[2]);
> > > + initrd_start = (void *)memory_start;
> > > + initrd_end = (void *)(memory_start += be32_to_cpu(((unsigned 
> > > long *) (memory_start))[2]));
> > >  #else
> > >   memory_start += be32_to_cpu(((unsigned long *) 
> > > memory_start)[2]);
> > >  #endif
> > 
> > But include/linux/initrd.h declares:
> > 
> > extern unsigned long initrd_start, initrd_end;
> > 
> 
> fix it.

I assume this new patch is an addition to the previous one quoted above?

> Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]>
> 
>  arch/h8300/kernel/setup.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c
> index 75712ec..4dd744f 100644
> --- a/arch/h8300/kernel/setup.c
> +++ b/arch/h8300/kernel/setup.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -57,7 +58,6 @@ extern int _stext, _etext, _sdata, _edata, _sbss, _ebss, 
> _end;
>  extern int _ramstart, _ramend;
>  extern char _target_name[];
>  extern void h8300_gpio_init(void);
> -extern void *initrd_start, *initrd_end;
>  
>  #if (defined(CONFIG_H8300H_SIM) || defined(CONFIG_H8S_SIM)) \
>  && defined(CONFIG_GDB_MAGICPRINT)

If so then surely it generated a warning when assigning a void* to an
unsigned long.

So please send a complete new fully tested patch.  Please also include a
changelog which describes what is being fixed, and how it is fixed.  The
text "initrd setting fix." and "fit it" is not sufficient - it doesn't
tell us what was wrong with the old code, nor how the change improved it.

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: PCI Bursting with PIO

[Dan Gora]

On Feb 15, 2008 10:00 PM, Robert Hancock <[EMAIL PROTECTED]> wrote:
>
> Well, in order for the CPU to batch up more writes you'd have to map the
>   BAR as either write-combining or write-back. If it's not listed in
> /proc/mtrr it will be the default setting of uncacheable.

Ok, this is pretty much what I thought, but I still don't really have
any idea how to do this.  ioremap() doesn't take any flags and I'm not
using ioremap_uncacheable(), plus the BAR is marked prefetchable...

> X has code to
> set up the video memory on the video card as write-combining so it can
> get better write performance, you could do something similar.

Alan mentioned this as well, but I haven't tried to hunt this code
yet.  If you have any pointers as to where I might find this, I would
appreciate it.

> Setting it as write-back might allow you to get the reads to do bursting
> as well (since the CPU will do a cache-line fill instead of individual
> accesses)

I don't see what the cache write policy has to do with the reads.  If
the region is marked cacheable, then all reads should try and read a
cache line, right?  The write-back or write-through policy only has to
do with the writes.  If it's write through then writes go directly to
RAM, if it's write-back then they hit the cache and are flushed when
the  line is flushed (LRU replacement, explicit cache line flush,
etc..), right?

> but this if the device is modifying this memory area, unless
> you add code to invalidate those cache lines before reading the data
> you'll get stale data back.

Yeah this could definitely be tricky, would pci_dma_sync suffice for this?

> You could run into some other less obvious
> issues as well, as normally device memory regions are not mapped write-back.
>
> In general, especially if you need to read data back from the device,
> implementing a DMA engine would be by far the better option. Most
> chipsets seem not at all optimized for handling sequential reads from
> PCI memory from the CPU. (Even in the DMA case, you have to be careful
> with what type of memory read transaction you use when transferring from
> host memory - some chipsets don't like to burst more than one cycle if
> you use normal Memory Read instead of Memory Read Line or Memory Read
> Multiple.)

True enough... Fortunately my device allows me to set these...

What I am trying to avoid is PCI read transactions in general.  PCI
reads are slow pretty much no matter if they are originated from the
device or from the host because of all the multitude of bridges they
have to go through (I've seen 5 in some cases... sheesh).  So
ultimately I like for everything going to the device to be written
from the host, then everything going towards the host be DMA'd into
RAM by the device, at least then we can take advantage of PCI write
posting and you don't have to wait for the write to actually complete
before we plod on.  But this depends on at least getting get write
burst performance from the host so that the time to write the data
from host is less than the time it would take for the device to read
the data out of RAM.

thanks again for your help!
dan
--
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 v2] Re: 2.6.25-rc2-mm1 (wakeup)

[Randy Dunlap]

H. Peter Anvin wrote:

Randy Dunlap wrote:

On Sat, 16 Feb 2008 19:58:06 -0800 H. Peter Anvin wrote:


Randy Dunlap wrote:

Yes, adding -m32 to the X86_32 config ccflags (as is done for the
X86_64 case) makes it build for me.  (like patch below)

It's wrong, though, because you can't assume a 32-bit compiler knows 
about -m32.


You need $(call cc-option,-m32).


-cflags-$(CONFIG_X86_32) :=
+cflags-$(CONFIG_X86_32) := $(call cc-option, -m32)
 cflags-$(CONFIG_X86_64) := -m32


I think this works for both; that's what we do for arch/x86/boot.


OK, that makes sense.  I think I'll let Rafael complete it.

--
~Randy
--
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 v2] Re: 2.6.25-rc2-mm1 (wakeup)

[H. Peter Anvin]

Randy Dunlap wrote:

On Sat, 16 Feb 2008 19:58:06 -0800 H. Peter Anvin wrote:


Randy Dunlap wrote:

Yes, adding -m32 to the X86_32 config ccflags (as is done for the
X86_64 case) makes it build for me.  (like patch below)

It's wrong, though, because you can't assume a 32-bit compiler knows 
about -m32.


You need $(call cc-option,-m32).


-cflags-$(CONFIG_X86_32) :=
+cflags-$(CONFIG_X86_32) := $(call cc-option, -m32)
 cflags-$(CONFIG_X86_64) := -m32


I think this works for both; that's what we do for arch/x86/boot.

-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/

[PATCH] h8300 add sci.h

[Yoshinori Sato]

This file require sh-sci

Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]>

 include/asm-h8300/sci.h |   34 ++
 1 files changed, 34 insertions(+), 0 deletions(-)
 create mode 100644 include/asm-h8300/sci.h

diff --git a/include/asm-h8300/sci.h b/include/asm-h8300/sci.h
new file mode 100644
index 000..4021564
--- /dev/null
+++ b/include/asm-h8300/sci.h
@@ -0,0 +1,34 @@
+#ifndef __ASM_SH_SCI_H
+#define __ASM_SH_SCI_H
+
+#include 
+
+/*
+ * Generic header for SuperH SCI(F)
+ *
+ * Do not place SH-specific parts in here, sh64 and h8300 depend on this too.
+ */
+
+/* Offsets into the sci_port->irqs array */
+enum {
+   SCIx_ERI_IRQ,
+   SCIx_RXI_IRQ,
+   SCIx_TXI_IRQ,
+   SCIx_TEI_IRQ,
+   SCIx_NR_IRQS,
+};
+
+/*
+ * Platform device specific platform_data struct
+ */
+struct plat_sci_port {
+   void __iomem*membase;   /* io cookie */
+   unsigned long   mapbase;/* resource base */
+   unsigned intirqs[SCIx_NR_IRQS]; /* ERI, RXI, TXI, BRI */
+   unsigned inttype;   /* SCI / SCIF / IRDA */
+   upf_t   flags;  /* UPF_* flags */
+};
+
+int early_sci_setup(struct uart_port *port);
+
+#endif /* __ASM_SH_SCI_H */
-- 
1.5.4.1

-- 
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: [PATCH 3/6] h8300 setup.c initrd support fix

[Yoshinori Sato]

At Fri, 15 Feb 2008 22:29:49 -0800,
Andrew Morton wrote:
> 
> On Sat, 16 Feb 2008 01:13:37 -0500 Yoshinori Sato <[EMAIL PROTECTED]> wrote:
> 
> > initrd setting fix.
> > 
> >  arch/h8300/kernel/setup.c |5 +++--
> >  1 files changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c
> > index b1f25c2..75712ec 100644
> > --- a/arch/h8300/kernel/setup.c
> > +++ b/arch/h8300/kernel/setup.c
> > @@ -57,6 +57,7 @@ extern int _stext, _etext, _sdata, _edata, _sbss, _ebss, 
> > _end;
> >  extern int _ramstart, _ramend;
> >  extern char _target_name[];
> >  extern void h8300_gpio_init(void);
> > +extern void *initrd_start, *initrd_end;
> >  
> >  #if (defined(CONFIG_H8300H_SIM) || defined(CONFIG_H8S_SIM)) \
> >  && defined(CONFIG_GDB_MAGICPRINT)
> > @@ -99,8 +100,8 @@ void __init setup_arch(char **cmdline_p)
> > /* allow for ROMFS on the end of the kernel */
> > if (memcmp((void *)memory_start, "-rom1fs-", 8) == 0) {
> >  #if defined(CONFIG_BLK_DEV_INITRD)
> > -   initrd_start = memory_start;
> > -   initrd_end = memory_start += be32_to_cpu(((unsigned long *) 
> > (memory_start))[2]);
> > +   initrd_start = (void *)memory_start;
> > +   initrd_end = (void *)(memory_start += be32_to_cpu(((unsigned 
> > long *) (memory_start))[2]));
> >  #else
> > memory_start += be32_to_cpu(((unsigned long *) 
> > memory_start)[2]);
> >  #endif
> 
> But include/linux/initrd.h declares:
> 
>   extern unsigned long initrd_start, initrd_end;
> 

fix it.
Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]>

 arch/h8300/kernel/setup.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c
index 75712ec..4dd744f 100644
--- a/arch/h8300/kernel/setup.c
+++ b/arch/h8300/kernel/setup.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -57,7 +58,6 @@ extern int _stext, _etext, _sdata, _edata, _sbss, _ebss, _end;
 extern int _ramstart, _ramend;
 extern char _target_name[];
 extern void h8300_gpio_init(void);
-extern void *initrd_start, *initrd_end;
 
 #if (defined(CONFIG_H8300H_SIM) || defined(CONFIG_H8S_SIM)) \
 && defined(CONFIG_GDB_MAGICPRINT)
-- 
1.5.4.1

-- 
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/

[PATCH v2] Re: 2.6.25-rc2-mm1 (wakeup)

[Randy Dunlap]

On Sat, 16 Feb 2008 19:58:06 -0800 H. Peter Anvin wrote:

> Randy Dunlap wrote:
> > 
> > Yes, adding -m32 to the X86_32 config ccflags (as is done for the
> > X86_64 case) makes it build for me.  (like patch below)
> > 
> 
> It's wrong, though, because you can't assume a 32-bit compiler knows 
> about -m32.
> 
> You need $(call cc-option,-m32).

Thanks, Peter.  Tested/works.

---
From: Randy Dunlap <[EMAIL PROTECTED]>

Fix wakeup code build errors on x86_64.

linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: CPU you 
selected does not support x86-64 instruction set
linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: CPU you 
selected does not support x86-64 instruction set
linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: 
-mpreferred-stack-boundary=2 is not between 4 and 12

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 arch/x86/kernel/acpi/realmode/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/acpi/realmode/Makefile
+++ linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/Makefile
@@ -27,7 +27,7 @@ bootsrc   := $(src)/../../../boot
 # How to compile the 16-bit code.  Note we always compile for -march=i386,
 # that way we can complain to the user if the CPU is insufficient.
 # Compile with _SETUP since this is similar to the boot-time setup code.
-cflags-$(CONFIG_X86_32) :=
+cflags-$(CONFIG_X86_32) := $(call cc-option, -m32)
 cflags-$(CONFIG_X86_64) := -m32
 KBUILD_CFLAGS  := $(LINUXINCLUDE) -g -Os -D_SETUP -D_WAKEUP -D__KERNEL__ \
   -I$(srctree)/$(bootsrc) \
--
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: What is "ERROR: "LGUEST_PAGES_guest_gdt_desc" [drivers/lguest/lg.ko] undefined!"

[Randy Dunlap]

On Sun, 17 Feb 2008 08:58:39 +0800 Peter Teoh wrote:

> Can some explain the cause of this error (it has been like this for the 
> last two git pull from linus tree):
> 
> Kernel: arch/x86/boot/bzImage is ready  (#1)
>   Building modules, stage 2.
>   MODPOST 1589 modules
> ERROR: "LGUEST_PAGES_guest_gdt_desc" [drivers/lguest/lg.ko] undefined!
> ERROR: "LGUEST_PAGES_host_gdt_desc" [drivers/lguest/lg.ko] undefined!
> ERROR: "LGUEST_PAGES_host_cr3" [drivers/lguest/lg.ko] undefined!
> ERROR: "LGUEST_PAGES_regs" [drivers/lguest/lg.ko] undefined!
> ERROR: "LGUEST_PAGES_host_idt_desc" [drivers/lguest/lg.ko] undefined!
> ERROR: "LGUEST_PAGES_guest_gdt" [drivers/lguest/lg.ko] undefined!
> ERROR: "LGUEST_PAGES_host_sp" [drivers/lguest/lg.ko] undefined!
> ERROR: "LGUEST_PAGES_regs_trapnum" [drivers/lguest/lg.ko] undefined!
> ERROR: "LGUEST_PAGES_guest_idt_desc" [drivers/lguest/lg.ko] undefined!
> WARNING: modpost: Found 14 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2

Please try the patch at
http://marc.info/?l=linux-kernel=120206956919303=2
and report on its success/failure.  Thanks.

---
~Randy
--
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: Driver removals

[Valdis . Kletnieks]

On Sat, 16 Feb 2008 08:39:08 +0100, Willy Tarreau said:

> I don't understand why kernel developers always think that users spend
> their whole time testing their new stuff. That is mostly true for a lot
> of desktop users, but definitely not for servers. On a server, you may
> *ignore* that a new driver exists for years. The basic make oldconfig
> does the stuff right.

Been there, done that.  We got a number of boxes that sit there for ages
between reboots and even longer between upgrades.  Deploying Solaris 10 was
like a 2-year process for some of our boxes (when the boxes are running the
Oracle databases that house the enterprise business systems, and your
organizational budget is pushing the $1B/year mark, everybody gets *really*
cautious to avoid a CLM while upgrading... ;)  And we may actually manage to
finally kill off our last AIX 4.3.3 box this quarter (4.3.3 was released all
the way back in Sep 1999, and EOL'ed back in 2004 - don't ask. :)

Of course, the difference is that we *expect* that there's a good chance that
if we try to subject that sort of box to 3 year's worth of updates, there's a
good chance we'll discover that some driver has been EOL'ed or otherwise
problematic on now-ancient hardware...

(And yes, there's a *lot* of risk-management going on centered around "What if
we have to patch Server23 for a critical kernel security issue?".  Of course,
if it was actually *feasible* to blindly upgrade-and-reboot twice a month, the
job could be done by a much less expensive patch monkey, so it's good job
security ;)






pgpJDlbRfgsr5.pgp
Description: PGP signature

Re: [PATCH 2/2] kernel/{exit.c, signal.c, power/process.c}: replace !likely(x) by likely(!x)

[Rene Herman]

On 17-02-08 04:56, H. Peter Anvin wrote:


Rene Herman wrote:

On 16-02-08 20:01, H. Peter Anvin wrote:

Roel Kluin wrote:

Not entirely sure who to send this to
---
Replace !likely(x) by likely(!x)


Whoa...

Are you sure this is correct?

!likely(x) is equivalent to unlikely(!x)


Not with respect to its value I believe? likely(x) == !!(x), and 
unlikely(!x) == !!(!x) = !x, so conditions work out differently?


You missed one ! sign:

!likely(x) == !!!(x) == unlikely(!x) == !!(!(x))


Yup, sorry, misread.

Rene.
--
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/

[OT] GMail (was USB regression (and other failures)...)

[Joseph Fannin]

On Sat, Feb 16, 2008 at 08:12:40PM -0500, Andrew Buehler wrote:
> [...] and I would not be in the least surprised if this turned out to
> be yet one more problem with gmail

It is; Gmail will refuse to POP more than one copy of a mail to you,
no matter how many copies it recieves via different paths.  Which copy
you get seems to be dependant on which arrives first, so you can't
even hope a mail exchange will consistently arrive in one mailbox or
another.

Note that this also applies to mails cross-posted to multiple lists
you maybe be suscribed to; this breaks threading fantastically.

Google is aware of the issue, and considers it a feature.  If you find
another free mail service which isn't so broken, I'd love to hear
about it.

---

That said, netiquette on the kernel lists is to *never* drop CC's.
Too much traffic crosses the lists for anyone to read it all and note
anything they might be interested and/or implicated in.  Never
dropping CC's allows busy people to keep track of conversations
they've taken part in or that someone thinks they should see
without the worry of missing any important parts of one.

Or at least it does if your mail system isn't broken.  We get what we
pay for.  :-/

--
Joseph Fannin
[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/

[BUG] 2.6.25-rc2-mm1 - Kernel panic while bootup caused by signal_group_exit()

[Kamalesh Babulal]

Hi Andrew,

The signals-do_signal_stop-use-signal_group_exit.patch is causing the
kernel panic, while booting in to the 2.6.25-rc2-mm1 kernel on x86.

There has been discussion on the patch for this panic on 
http://lkml.org/lkml/2008/2/16/99 

[   25.512919] BUG: unable to handle kernel paging request at 9d74e37b
[   25.514926] IP: [] proc_flush_task+0x5b/0x223
[   25.516934] Oops:  [#1] SMP 
[   25.517918] last sysfs file: /sys/block/hdc/removable
[   25.517918] Modules linked in: dm_mirror dm_mod video output sbs sbshc 
battery ac parport_pc lp parport floppy sg serio_raw ide_cd_mod cdrom 
scb2_flash mtd chipreg button i2c_piix4 i2c_core pcspkr tg3 mptspi mptscsih 
mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
[   25.517918] 
[   25.517918] Pid: 1, comm: init Not tainted (2.6.25-rc2-mm1-autotest #1)
[   25.517918] EIP: 0060:[] EFLAGS: 00010282 CPU: 2
[   25.517918] EIP is at proc_flush_task+0x5b/0x223
[   25.517918] EAX: 9d74e35b EBX: f7881ef0 ECX: f7a5ed84 EDX: a56b6b6b
[   25.517918] ESI: f74f76f8 EDI: a56b6b6b EBP: f7881f08 ESP: f7881ec0
[   25.517918]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   25.517918] Process init (pid: 1, ti=f7881000 task=f788adf0 task.ti=f7881000)
[   25.517918] Stack: f7a5ed84 0001 f7a5ed58 f7a5ed58  a56b6b6b 
f7852750 f7a5ed68 
[   25.517918]35881ef4 3130 f788b4a4 f788adf0 0012d6c5 0003 
f7881ee3 0003 
[   25.517918]f7a72df0 f7a72df0 f7881f1c c042676d 0003 01f5 
f7a72df0 f7881f78 
[   25.517918] Call Trace:
[   25.517918]  [] release_task+0x19/0x2d5
[   25.517918]  [] do_wait+0x5f2/0x8fc
[   25.517918]  [] default_wake_function+0x0/0xd
[   25.517918]  [] sys_wait4+0x78/0x8e
[   25.517918]  [] sys_waitpid+0x13/0x15
[   25.517918]  [] sysenter_past_esp+0x5f/0x99
[   25.517918]  ===
[   25.517918] Code: 1c 89 4d d4 89 4d c4 89 55 b8 e9 b5 01 00 00 31 ff 83 7d 
c4 00 74 06 8b 45 d4 8b 78 1c 8b 55 b8 8b 4d b8 8b 12 89 55 cc 8b 41 04 <8b> 40 
20 52 68 33 cd 6f c0 6a 0d 89 45 d0 8d 45 db 50 89 45 f0 
[   25.517918] EIP: [] proc_flush_task+0x5b/0x223 SS:ESP 0068:f7881ec0
[   25.517939] ---[ end trace d0df919a64605019 ]---
[   25.518925] Kernel panic - not syncing: Attempted to kill init!

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
--
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.25-rc1] jerky mouse cursor and randoooom key repeats

[Chris Holvenstot]

Jiri - 

This is just to confirm that I have been running all day on a kernel
built with CONFIG_GROUP_SCHED turned 'off' and have not seen the problem
with my keyboard (I never noticed a problem with the mouse as others
have)

At slack moments through the day I have taken the oppertunity to perform
7 boots and could not recreate the failure (see my previous note which
has some lame speculation that the conditions for the failure are seeded
at boot time)

If there is anything else you would like to have performed in an attempt
to further isolate this issue I will try my best to provide it.  This
includes going back to a 2.6.25-rc2 kernel with CONFIG_GROUP_SCHED
turned 'on' if you think that further confirmation of the problem is
required or would be useful. 

Once again, thank you for taking the lead on this issue.

Chris




On Sat, 2008-02-16 at 19:08 +0100, Jiri Kosina wrote:
> [ Peter and Ingo added to CC, as this is apparently another instance of 
>   CONFIG_GROUP_SCHED causing mouse/keyboard misbehavior ]
> 
> Thanks for testing, Chris.
> 
> On Sat, 16 Feb 2008, Chris Holvenstot wrote:
> 
> > Jiri - 
> > 
> > 
> > Sorry for the delay in getting this information back to you. I am now up
> > and running on 2.6.25-rc2 with CONFIG_GROUP_SCHED not set (and for the
> > record, I did NOT use the nohpet directive when booting)
> > 
> > 
> > A copy of the dot-config file from this build has been inserted below. 
> > 
> > 
> > So far everything is working nicely with CONFIG_GROUP_SCHED not set.
> > However I have one observation to make, and I am very likely missing
> > something here, is that over the past few days while I have been trying
> > to isolate a broke / not broke point with git bisect it would seem that
> > the conditions which lead to the repeating key failure are seeded at the
> > time of the boot.
> > 
> > 
> > By this I mean that given a specific kernel configuration I can boot it
> > 'x' number of times - out of all those boot cycles I may get one
> > instance of the failure. The rest of the time it works fine.
> > 
> > 
> > On those occasions when I do get the repeating key failure it would
> > appear that the failure lives for the lifespan of the boot. Twice now
> > when I have had the failure I have tried restarting X to see if it
> > clears, but so far I have not had any luck with that.
> > 
> > 
> > I have compared the dmesg output from a good boot to that of a boot
> > where I see the repeating key issue and except for the expected minor
> > differences in the timestamps nothing jumps out at me.
> > 
> > 
> > I built the kernel you requested with the '-j2' option to load up the
> > CPU - I thought that the suggestion made earlier by someone else about
> > this failure happening while the CPU was loaded had some merit - it was
> > one factor I did not take into consideration during my efforts and might
> > explain why I was getting inconsistent results. 
> > 
> > 
> > However, even though both cores were running along at nearly 100% during
> > this build, I did not see the problem. At this point I am about ready to
> > select a previously unused section of wall to bang my head against.
> > 
> > 
> > Thank you for your continued support - 
> > 
> > 
> > Chris
> > 


--
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.25-rc2-mm1 (wakeup)

[H. Peter Anvin]

Randy Dunlap wrote:


Yes, adding -m32 to the X86_32 config ccflags (as is done for the
X86_64 case) makes it build for me.  (like patch below)



It's wrong, though, because you can't assume a 32-bit compiler knows 
about -m32.


You need $(call cc-option,-m32).

-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: 2.6.25-rc1/2 CD/DVD burning broken

[Mark Lord]

Andreas Schwab wrote:

Jeff Garzik <[EMAIL PROTECTED]> writes:


Andreas Schwab wrote:

Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
following error from wodim:

Errno: 0 (Success), write_g1 scsi sendcmd: no error
CDB:  2A 00 00 00 00 00 00 00 1F 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
Sense flags: Blk 0 (not valid) resid: 63488

Does libata on the same hardware work?


There is no libata driver for ide-pmac.

..

What chipset is that..  CMD646 ?
--
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/2] kernel/{exit.c, signal.c, power/process.c}: replace !likely(x) by likely(!x)

[H. Peter Anvin]

Rene Herman wrote:

On 16-02-08 20:01, H. Peter Anvin wrote:

Roel Kluin wrote:

Not entirely sure who to send this to
---
Replace !likely(x) by likely(!x)


Whoa...

Are you sure this is correct?

!likely(x) is equivalent to unlikely(!x)


Not with respect to its value I believe? likely(x) == !!(x), and 
unlikely(!x) == !!(!x) = !x, so conditions work out differently?


You missed one ! sign:

!likely(x) == !!!(x) == unlikely(!x) == !!(!(x))

-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: [BUG] 2.6.25-rc2-mm1 - kernel oops while bootup on s390x

[Kamalesh Babulal]

Thomas Gleixner wrote:
> On Sat, 16 Feb 2008, Thomas Gleixner wrote:
>> On Sat, 16 Feb 2008, Andrew Morton wrote:
 The 2.6.25-rc2-mm1 kernel panic's while boot up on the s390x

 Unable to handle kernel pointer dereference at virtual kernel address 
 00
 00
 Oops: 0004 #1¨ SMP
>>> First question is: does this happen in current mainline?

This is not happening with the current mainline 2.6.24.{1,2}.
>>>
>>> If not, it would be useful if someone could test futex-fix-init-order.patch
>>> and futex-runtime-enable-pi-and-robust-functionality.patch on curent
>>> mainline, because those are planned for 2.6.25.
>> See: http://lkml.org/lkml/2008/2/16/109
>>
>> It unearthed a BUG in the S390 exception fixup tables :)
> 
> Oops, wrong reference.
> 
>   http://lkml.org/lkml/2008/2/16/95
> 
> Thanks,
>   tglx

To conform the patches causing the panic, I tested the 2.6.24.2 kernel with the 
futex-fix-init-order.patch and
futex-runtime-enable-pi-and-robust-functionality.patch applied and they seem to 
cause the kernel
panic.

Unable to handle kernel pointer dereference at virtual kernel address 00
00
Oops: 0004 #1¨ SMP
Modules linked in:
CPU: 0 Not tainted 2.6.25-rc2-mm1-autotest #1
Process swapper (pid: 1, task: 3f83, ksp: 3f83ba48)
Krnl PSW : 0704a0018000 0024b2be (futex_atomic_cmpxchg_std+0x12/0x28
)
   R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:2 CC:2 PM:0 EA:3
Krnl GPRS: 0074 fff2  
    0001  004d0764
    004d8768  3f83bdb0
   0040 00343950 000627e4 3f83bdb0
Krnl Code: 0024b2b2: b90400bf   lgr %r11,%r15
   0024b2b6: a718fff2   lhi %r1,-14
   0024b2ba: b2790100   sacf256
  >0024b2be: ba342000   cs  %r3,%r4,0(%r2)
   0024b2c2: 1813   lr  %r1,%r3
   0024b2c4: b279   sacf0
   0024b2c8: b9140021   lgfr%r2,%r1
   0024b2cc: e3b0b074   lg  %r11,112(%r11)
Call Trace:
(<3f83bda8>¨ 0x3f83bda8)
 <004bdeec>¨ init+0x30/0x104
 <004b0c40>¨ kernel_init+0x1e0/0x370
 <0001a5c6>¨ kernel_thread_starter+0x6/0xc
 <0001a5c0>¨ kernel_thread_starter+0x0/0xc

 <4>--- end trace 561bb236c800851f ¨---
note: swapper1¨ exited with preempt_count 1
Kernel panic - not syncing: Attempted to kill init!

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
--
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: USB regression (and other failures) in 2.6.2[45]*

[Alan Stern]

On Sat, 16 Feb 2008, Andrew Buehler wrote:

> Messages sent to my address directly are explicitly not filtered into
> the folders I have set up for various mailing lists, so that if someone
> does send me a "heads up" reply for a specific topic on a list to which
> I am subscribed it does not get caught by the list filter and fail to
> come to my attention. If a message fails to be filtered into any
> mailing-list folder, then I should be able to conclude that it is
> specifically intended for me, and not part of normal mailing-list
> traffic. The practice of sending replies to both addresses renders this
> an invalid conclusion. I do not think that it is unreasonable to expect
> that conclusion to be valid.

It's not unreasonable.  Neither is Aristotelian physics.  Nevertheless, 
neither one is a good match to reality.

Why not arrange instead that messages sent from a mailing list server
_do_ get filtered into the corresponding folder, even if they were also
sent to your address?  This certainly should make your assumption (that
messages not filtered into any mailing-list folder are specifically
intended for you) much more valid than it is now.

> It's not that I'm not receiving all of this thread's messages via the
> list - it's that I'm not receiving *any* of them via the list, and I
> suspect that the reason is that my address is in both the To:/Cc: and
> the list itself. Something is filtering it such that I do not receive
> "duplicate" replies in this way, but it is doing so by filtering out the
> list copy rather than the direct copy. I have seen mailing lists which
> do this before, but I see no other indication that the LKML is one of
> them, and I would not be in the least surprised if this turned out to be
> yet one more problem with gmail.

Well, I _am_ receiving your messages by way of linux-usb as well as
directly, for whatever that's worth.


> > is an indication that interrupt routing is indeed not working right.
> > Or possibly your EHCI controller isn't working.  You could try
> > blacklisting or unloading ehci-hcd to see if that helps.  Of course
> > then none of your USB devices would be able to run at high speed.
> 
> ehci-hcd is not modular in my current kernel, and if there is a way to
> turn it off without its being modular I am not aware of it.

Go into the /sys/bus/pci/drivers/ehci_hcd directory.  Then for each 
symbolic link to a controller device listed there, write the device's 
name (with "echo -n") to the "unbind" file.  For example,

echo -n :00:1d.7 >unbind

That will have nearly the same effect as unloading ehci-hcd.

> Until this thread, I was not even aware that ACPI was related to USB; I
> had largely conflated it with a similar acronym which I think is related
> to power management and which I can suddenly not even find in my kernel
> config. I will, however, look into linux-acpi.

ACPI isn't directly related to USB; rather it has to do with
transferring information between the OS and the
BIOS/vendor-specific-hardware.  Power management is example where such
a transfer is needed.  In your case, the relevant information is which
IRQ is connected to which motherboard device.  If you don't have ACPI
enabled in your configuration, then perhaps that's the problem -- try
enabling it.

> That will not be helpful for the other two problems, however, since
> neither of them was ever working as far as I am aware. That also leaves
> me hesitant to conclude that they are rooted in the same IRQ issue as
> the USB problem appears to be.

Maybe they aren't.  But when you have multiple bugs, you have to fix
them one at a time.

> Which lists or other addresses would be appropriate for reporting
> problems with AHCI/libata and with networking, specifically with the
> e1000/e1000e drivers? I see a mailing list for e1000 in MAINTAINERS, but
> only the maintainer's address for SATA/libata/whatever else may be
> involved there, and I am reflexively reluctant to bother a maintainer
> directly with as little information as I presently have.

I don't know, but you should wait until the simpler problem is sorted 
out before tackling the more complicated ones.

Alan Stern

--
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] bitmap onto and fold operators for mempolicy extensions

[Paul Jackson]

Thank-you for the kind and prompt review, kosaki-san.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214
--
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 7/7] CGroup API: Update cpusets to use cgroup structured file API

[Paul Jackson]

Ok ... this would (I suspect, just from code reading, no bytes were
harmed in actual testing of this) have a minor change to how white
space is handled writing integer flags to cpuset files, and a minor
inconstency.

 1) Existing cpuset code lets you set a flag (e.g. cpu_exclusive) by doing:
echo '1 rumplestiltskin' > cpu_exclusive   # same as: echo 1 > 
cpu_exclusive
With this patch, that probably fails, EINVAL.

 2) With this patch, one can write "1" or "1\n" to cpuset integer files, but one
cannot successfully write "1\r\n" or "1 " or "1 \n".  However, for the 
cpuset
control files that take strings, not single integers, one -can- have any mix
of trailing white space.

So far as I know, I have no requirement to write rumplestiltskin to cpuset 
files ;).
So I'm content to let the minor change in (1) pass without further comment.

I'd like to recommend consideration of the following patch, to address the
minor inconsistency of (2), and to save a few bytes of kernel text space.

===

From: Paul Jackson <[EMAIL PROTECTED]>

Strip all trailing whitespace (such as carriage returns)
when parsing integer writes to cgroup files, not just
one trailing newline if present.

Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Cc: Paul Menage <[EMAIL PROTECTED]>

---
 kernel/cgroup.c |5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

--- 2.6.24-mm1.orig/kernel/cgroup.c 2008-02-16 04:20:33.0 -0800
+++ 2.6.24-mm1/kernel/cgroup.c  2008-02-16 19:00:41.207478218 -0800
@@ -1321,10 +1321,7 @@ static ssize_t cgroup_write_uint(struct 
return -EFAULT;
 
buffer[nbytes] = 0; /* nul-terminate */
-
-   /* strip newline if necessary */
-   if (nbytes && (buffer[nbytes-1] == '\n'))
-   buffer[nbytes-1] = 0;
+   strstrip(buffer);   /* strip -just- trailing whitespace */
val = simple_strtoull(buffer, , 0);
if (*end)
return -EINVAL;


-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214
--
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: unionfs_copy_attr_times oopses

[Erez Zadok]

In message <[EMAIL PROTECTED]>, Hugh Dickins writes:

> Hi Erez,
> 
> Aside from the occasional "unionfs: new lower inode mtime" messages
> on directories (which I've got into the habit of ignoring now), the
> only problem I'm still suffering with unionfs over tmpfs (not tested
> any other fs's below it recently) is oops in unionfs_copy_attr_times.
> 
> I believe I'm working with your latest: 2.6.24-rc8-mm1 plus the four
> patches you posted to lkml on 26 Jan.  But this problem has been around
> for a while before that: I'd been hoping to debug it myself, but taken
> too long to make too little progress, so now handing over to you.
> 
> The oops occurs while doing repeated "make -j20" kernel builds in a
> unionfs mount of a tmpfs (though I doubt tmpfs is relevant): most of
> my testing was while swapping, but today I find that's irrelevant,
> and it should happen much quicker without.  SMP kernels (4 cpus),
> I haven't tried UP; happens with or without PREEMPT, may just be
> coincidence that it happens quicker on the machines with PREEMPT.
> 
> Most commonly it's unionfs_copy_attr_times called from unionfs_create,
> but that's probably just the most common route in this workload:
> I've seen it also when called from unionfs_rename or unionfs_open or
> unionfs_unlink.  It looks like there's a locking or refcounting bug,
> hence a race: the unionfs_inode_info which unionfs_copy_attr_times
> is working on gets changed underneath it, so it oopses on NULL
> lower_inodes.
[...]

Hugh,

Check out my latest set of patches (which correspond to release 2.2.4 of
Unionfs).  Thanks to your info and the patch, I was able to trigger several
races more frequently, and fix them.  I've tested my code with make -j N
(for N=4 and N=20), on a 4 cpu machine a well as a 2 cpu machine (w/
different amounts of memory and CPU speeds, also 32-bit vs 64-bit); I ran a
kernel compile for ~10-12 hours.  With the patches I just posted, I wasn't
able to trigger any of the WARN_ON's in unionfs_copy_attr_times.  I also
tried it while flushing caches via /proc, and/or performing branch-mgmt
commands in unionfs.

Give it a good shake and let me know what you find.

Thanks,
Erez.
--
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/6] mmu_notifier: Core code

[Andrea Arcangeli]

On Sat, Feb 16, 2008 at 11:21:07AM -0800, Christoph Lameter wrote:
> On Fri, 15 Feb 2008, Andrew Morton wrote:
> 
> > What is the status of getting infiniband to use this facility?
> 
> Well we are talking about this it seems.

It seems the IB folks think allowing RDMA over virtual memory is not
interesting, their argument seem to be that RDMA is only interesting
on RAM (and they seem not interested in allowing RDMA over a ram+swap
backed _virtual_ memory allocation). They've just to decide if
ram+swap allocation for RDMA is useful or not.

> > How important is this feature to KVM?
> 
> Andrea can answer this.

I think I already did in separate email.

> > That sucks big time.  What do we need to do to make get the callback
> > functions called in non-atomic context?

I sure agree given I also asked to drop the lock param and enforce the
invalidate_range_* to always be called in non atomic context.

> We would have to drop the inode_mmap_lock. Could be done with some minor 
> work.

The invalidate may be deferred after releasing the lock, the lock may
not have to be dropped to cleanup the API (and make xpmem life easier).

> That is one implementation (XPmem does that). The other is to simply stop 
> all references when any invalidate_range is in progress (KVM and GRU do 
> that).

KVM doesn't stop new references. It doesn't need to because it holds a
reference on the page (GRU doesn't). KVM can invalidate the spte and
flush the tlb only after the linux pte has been cleared and after the
page has been released by the VM (because the page doesn't go in the
freelist and it remains pinned for a little while, until the spte is
dropped too inside invalidate_range_end). GRU has to invalidate
_before_ the linux pte is cleared so it has to stop new references
from being established in the invalidate_range_start/end critical
section.

> Andrea put this in to check the reference status of a page. It functions 
> like the accessed bit.

In short each pte can have some spte associated to it. So whenever we
do a ptep_clear_flush protected by the PT lock, we also have to run
invalidate_page that will internally invoke a sort-of
sptep_clear_flush protected by a kvm->mmu_lock (equivalent of
page_table_lock/PT-lock). sptes just like ptes maps virtual addresses
to physical addresses, so you can read/write to RAM either through a
pte or through a spte.

Just like it would be insane to have any requirement that
ptep_clear_flush has to run in not-atomic context (forcing a
conversion of the PT lock to a mutex), it's also weird require the
invalidate_page/age_page to run in atomic context.

All troubles start with the xpmem requirements of having to schedule
in its equivalent of the sptep_clear_flush because it's not a
gigaherz-in-cpu thing but a gigabit thing where the network stack is
involved with its own software linux driven skb memory allocations,
schedules waiting for network I/O, etc... Imagine ptes allocated in a
remote node, no surprise its brings a new set of problems (assuming it
can work reliably during oom given its memory requirements in the
try_to_unmap path, no page can ever be freed until the skbs have been
allocated and sent and allocated again to receive the ack).

Furthermore xpmem doesn't associate any pte to a spte, it associates a
page_t to certain remote references, or it would be in trouble with
invalidate_page that corresponds to ptep_clear_flush on a virtual
address that exists thanks to the anon_vma/i_mmap lock held (and not
thanks to the mmap_sem like in all invalidate_range calls).

Christoph's patch is a mix of two entirely separated features. KVM can
live with V7 just fine, but it's a lot more than what is needed by KVM.

I don't think that invalidate_page/age_page must be allowed to sleep
because invalidate_range also can sleep. You've to just ask yourself
if the VM locks shall remain spinlocks, for the VM own good (not for
the mmu notifiers good). It'd be bad to make the VM underperform with
mutex protecting tiny critical sections to please some mmu notifier
user. But if they're spinlocks, then clearly invalidate_page/age_page
based on virtual addresses can't sleep or the virtual address wouldn't
make sense anymore by the time the spinlock is released.

> > This function looks like it was tossed in at the last minute.  It's
> > mysterious, undocumented, poorly commented, poorly named.  A better name
> > would be one which has some correlation with the return value.
> > 
> > Because anyone who looks at some code which does
> > 
> > if (mmu_notifier_age_page(mm, address))
> > ...
> > 
> > has to go and reverse-engineer the implementation of
> > mmu_notifier_age_page() to work out under which circumstances the "..."
> > will be executed.  But this should be apparent just from reading the callee
> > implementation.
> > 
> > This function *really* does need some documentation.  What does it *mean*
> > when the ->age_page() from some of the notifiers returned "1" and the
> > 

[PATCH 11/17] Unionfs: lock parents' branch configuration fixes

[Erez Zadok]

Ensure that we lock the branch configuration of parent and child dentries in
operations which need it, and in the right order.

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/commonfops.c |   31 +---
 fs/unionfs/dentry.c |   26 +---
 fs/unionfs/inode.c  |   58 +++---
 fs/unionfs/union.h  |5 ++-
 fs/unionfs/unlink.c |   11 -
 5 files changed, 91 insertions(+), 40 deletions(-)

diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 96473c4..491e2ff 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -300,8 +300,9 @@ out:
  * Revalidate the struct file
  * @file: file to revalidate
  * @willwrite: true if caller may cause changes to the file; false otherwise.
+ * Caller must lock/unlock dentry's branch configuration.
  */
-int unionfs_file_revalidate(struct file *file, bool willwrite)
+int unionfs_file_revalidate_locked(struct file *file, bool willwrite)
 {
struct super_block *sb;
struct dentry *dentry;
@@ -311,7 +312,6 @@ int unionfs_file_revalidate(struct file *file, bool 
willwrite)
int err = 0;
 
dentry = file->f_path.dentry;
-   unionfs_lock_dentry(dentry, UNIONFS_DMUTEX_CHILD);
sb = dentry->d_sb;
 
/*
@@ -416,7 +416,17 @@ out:
 out_nofree:
if (!err)
unionfs_check_file(file);
-   unionfs_unlock_dentry(dentry);
+   return err;
+}
+
+int unionfs_file_revalidate(struct file *file, bool willwrite)
+{
+   int err;
+
+   unionfs_lock_dentry(file->f_path.dentry, UNIONFS_DMUTEX_CHILD);
+   err = unionfs_file_revalidate_locked(file, willwrite);
+   unionfs_unlock_dentry(file->f_path.dentry);
+
return err;
 }
 
@@ -524,9 +534,18 @@ int unionfs_open(struct inode *inode, struct file *file)
struct dentry *dentry = file->f_path.dentry;
int bindex = 0, bstart = 0, bend = 0;
int size;
+   int valid = 0;
 
unionfs_read_lock(inode->i_sb, UNIONFS_SMUTEX_PARENT);
unionfs_lock_dentry(dentry, UNIONFS_DMUTEX_CHILD);
+   if (dentry != dentry->d_parent)
+   unionfs_lock_dentry(dentry->d_parent, UNIONFS_DMUTEX_PARENT);
+
+   valid = __unionfs_d_revalidate_chain(dentry->d_parent, NULL, false);
+   if (unlikely(!valid)) {
+   err = -ESTALE;
+   goto out_nofree;
+   }
 
file->private_data =
kzalloc(sizeof(struct unionfs_file_info), GFP_KERNEL);
@@ -589,6 +608,8 @@ out_nofree:
unionfs_check_file(file);
unionfs_check_inode(inode);
}
+   if (dentry != dentry->d_parent)
+   unionfs_unlock_dentry(dentry->d_parent);
unionfs_unlock_dentry(dentry);
unionfs_read_unlock(inode->i_sb);
return err;
@@ -797,8 +818,9 @@ int unionfs_flush(struct file *file, fl_owner_t id)
int bindex, bstart, bend;
 
unionfs_read_lock(dentry->d_sb, UNIONFS_SMUTEX_PARENT);
+   unionfs_lock_dentry(dentry, UNIONFS_DMUTEX_CHILD);
 
-   err = unionfs_file_revalidate(file, true);
+   err = unionfs_file_revalidate_locked(file, true);
if (unlikely(err))
goto out;
unionfs_check_file(file);
@@ -824,6 +846,7 @@ int unionfs_flush(struct file *file, fl_owner_t id)
 
 out:
unionfs_check_file(file);
+   unionfs_unlock_dentry(file->f_path.dentry);
unionfs_read_unlock(dentry->d_sb);
return err;
 }
diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index 3bd2dfb..17b297d 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -363,6 +363,7 @@ bool __unionfs_d_revalidate_chain(struct dentry *dentry, 
struct nameidata *nd,
chain_len = 0;
sbgen = atomic_read(_SB(dentry->d_sb)->generation);
dtmp = dentry->d_parent;
+   verify_locked(dentry);
if (dentry != dtmp)
unionfs_lock_dentry(dtmp, UNIONFS_DMUTEX_REVAL_PARENT);
dgen = atomic_read(_D(dtmp)->generation);
@@ -453,7 +454,7 @@ bool __unionfs_d_revalidate_chain(struct dentry *dentry, 
struct nameidata *nd,
 
 out_this:
/* finally, lock this dentry and revalidate it */
-   verify_locked(dentry);
+   verify_locked(dentry);  /* verify child is locked */
if (dentry != dentry->d_parent)
unionfs_lock_dentry(dentry->d_parent,
UNIONFS_DMUTEX_REVAL_PARENT);
@@ -491,24 +492,20 @@ static int unionfs_d_revalidate(struct dentry *dentry, 
struct nameidata *nd)
return err;
 }
 
-/*
- * At this point no one can reference this dentry, so we don't have to be
- * careful about concurrent access.
- */
 static void unionfs_d_release(struct dentry *dentry)
 {
int bindex, bstart, bend;
 
unionfs_read_lock(dentry->d_sb, UNIONFS_SMUTEX_CHILD);
+   /* must lock our branch configuration here */
+   unionfs_lock_dentry(dentry, UNIONFS_DMUTEX_CHILD);
 
   

[PATCH 14/17] Unionfs: stop using iget() and read_inode()

[Erez Zadok]

From: David Howells <[EMAIL PROTECTED]>

Replace unionfs_read_inode() with unionfs_iget(), and call that instead of
iget().  unionfs_iget() then uses iget_locked() directly and returns a
proper error code instead of an inode in the event of an error.

unionfs_fill_super() returns any error incurred when getting the root inode
instead of EINVAL.

Signed-off-by: David Howells <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/main.c  |   11 +--
 fs/unionfs/super.c |   19 ++-
 fs/unionfs/union.h |1 +
 3 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/fs/unionfs/main.c b/fs/unionfs/main.c
index ba3471d..4bc2c66 100644
--- a/fs/unionfs/main.c
+++ b/fs/unionfs/main.c
@@ -104,9 +104,8 @@ struct dentry *unionfs_interpose(struct dentry *dentry, 
struct super_block *sb,
BUG_ON(is_negative_dentry);
 
/*
-* We allocate our new inode below, by calling iget.
-* iget will call our read_inode which will initialize some
-* of the new inode's fields
+* We allocate our new inode below by calling unionfs_iget,
+* which will initialize some of the new inode's fields
 */
 
/*
@@ -128,9 +127,9 @@ struct dentry *unionfs_interpose(struct dentry *dentry, 
struct super_block *sb,
}
} else {
/* get unique inode number for unionfs */
-   inode = iget(sb, iunique(sb, UNIONFS_ROOT_INO));
-   if (!inode) {
-   err = -EACCES;
+   inode = unionfs_iget(sb, iunique(sb, UNIONFS_ROOT_INO));
+   if (IS_ERR(inode)) {
+   err = PTR_ERR(inode);
goto out;
}
if (atomic_read(>i_count) > 1)
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index 175840f..b71fc2a 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -24,11 +24,19 @@
  */
 static struct kmem_cache *unionfs_inode_cachep;
 
-static void unionfs_read_inode(struct inode *inode)
+struct inode *unionfs_iget(struct super_block *sb, unsigned long ino)
 {
int size;
-   struct unionfs_inode_info *info = UNIONFS_I(inode);
+   struct unionfs_inode_info *info;
+   struct inode *inode;
 
+   inode = iget_locked(sb, ino);
+   if (!inode)
+   return ERR_PTR(-ENOMEM);
+   if (!(inode->i_state & I_NEW))
+   return inode;
+
+   info = UNIONFS_I(inode);
memset(info, 0, offsetof(struct unionfs_inode_info, vfs_inode));
info->bstart = -1;
info->bend = -1;
@@ -44,7 +52,8 @@ static void unionfs_read_inode(struct inode *inode)
if (unlikely(!info->lower_inodes)) {
printk(KERN_CRIT "unionfs: no kernel memory when allocating "
   "lower-pointer array!\n");
-   BUG();
+   iget_failed(inode);
+   return ERR_PTR(-ENOMEM);
}
 
inode->i_version++;
@@ -60,7 +69,8 @@ static void unionfs_read_inode(struct inode *inode)
inode->i_atime.tv_sec = inode->i_atime.tv_nsec = 0;
inode->i_mtime.tv_sec = inode->i_mtime.tv_nsec = 0;
inode->i_ctime.tv_sec = inode->i_ctime.tv_nsec = 0;
-
+   unlock_new_inode(inode);
+   return inode;
 }
 
 /*
@@ -1025,7 +1035,6 @@ out:
 }
 
 struct super_operations unionfs_sops = {
-   .read_inode = unionfs_read_inode,
.delete_inode   = unionfs_delete_inode,
.put_super  = unionfs_put_super,
.statfs = unionfs_statfs,
diff --git a/fs/unionfs/union.h b/fs/unionfs/union.h
index 1bf0c09..533806c 100644
--- a/fs/unionfs/union.h
+++ b/fs/unionfs/union.h
@@ -364,6 +364,7 @@ extern int unionfs_fsync(struct file *file, struct dentry 
*dentry,
 extern int unionfs_fasync(int fd, struct file *file, int flag);
 
 /* Inode operations */
+extern struct inode *unionfs_iget(struct super_block *sb, unsigned long ino);
 extern int unionfs_rename(struct inode *old_dir, struct dentry *old_dentry,
  struct inode *new_dir, struct dentry *new_dentry);
 extern int unionfs_unlink(struct inode *dir, struct dentry *dentry);
-- 
1.5.2.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/

[PATCH 06/17] Unionfs: extend dentry branch configuration lock in open

[Erez Zadok]

Dentry branch configuration "info node" lock should extend to calls to
copy_attr_times.

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/commonfops.c |   14 --
 1 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index f37192f..96473c4 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -521,11 +521,12 @@ int unionfs_open(struct inode *inode, struct file *file)
 {
int err = 0;
struct file *lower_file = NULL;
-   struct dentry *dentry = NULL;
+   struct dentry *dentry = file->f_path.dentry;
int bindex = 0, bstart = 0, bend = 0;
int size;
 
unionfs_read_lock(inode->i_sb, UNIONFS_SMUTEX_PARENT);
+   unionfs_lock_dentry(dentry, UNIONFS_DMUTEX_CHILD);
 
file->private_data =
kzalloc(sizeof(struct unionfs_file_info), GFP_KERNEL);
@@ -551,9 +552,6 @@ int unionfs_open(struct inode *inode, struct file *file)
goto out;
}
 
-   dentry = file->f_path.dentry;
-   unionfs_lock_dentry(dentry, UNIONFS_DMUTEX_CHILD);
-
bstart = fbstart(file) = dbstart(dentry);
bend = fbend(file) = dbend(dentry);
 
@@ -573,15 +571,12 @@ int unionfs_open(struct inode *inode, struct file *file)
if (!lower_file)
continue;
 
-   branchput(file->f_path.dentry->d_sb, bindex);
+   branchput(dentry->d_sb, bindex);
/* fput calls dput for lower_dentry */
fput(lower_file);
}
}
 
-   /* XXX: should this unlock be moved to the function bottom? */
-   unionfs_unlock_dentry(dentry);
-
 out:
if (err) {
kfree(UNIONFS_F(file)->lower_files);
@@ -590,12 +585,11 @@ out:
}
 out_nofree:
if (!err) {
-   dentry = file->f_path.dentry;
-   unionfs_copy_attr_times(dentry->d_parent->d_inode);
unionfs_copy_attr_times(inode);
unionfs_check_file(file);
unionfs_check_inode(inode);
}
+   unionfs_unlock_dentry(dentry);
unionfs_read_unlock(inode->i_sb);
return err;
 }
-- 
1.5.2.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/

[PATCH 15/17] Unionfs: embed a struct path into struct nameidata instead of nd dentrymnt

[Erez Zadok]

From: Andrew Morton <[EMAIL PROTECTED]>

Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/inode.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/unionfs/inode.c b/fs/unionfs/inode.c
index 2e791fd..640969d 100644
--- a/fs/unionfs/inode.c
+++ b/fs/unionfs/inode.c
@@ -254,8 +254,8 @@ static struct dentry *unionfs_lookup(struct inode *parent,
 
/* save the dentry & vfsmnt from namei */
if (nd) {
-   path_save.dentry = nd->dentry;
-   path_save.mnt = nd->mnt;
+   path_save.dentry = nd->path.dentry;
+   path_save.mnt = nd->path.mnt;
}
 
/*
@@ -266,8 +266,8 @@ static struct dentry *unionfs_lookup(struct inode *parent,
 
/* restore the dentry & vfsmnt in namei */
if (nd) {
-   nd->dentry = path_save.dentry;
-   nd->mnt = path_save.mnt;
+   nd->path.dentry = path_save.dentry;
+   nd->path.mnt = path_save.mnt;
}
if (!IS_ERR(ret)) {
if (ret)
@@ -885,7 +885,7 @@ static int unionfs_permission(struct inode *inode, int mask,
const int write_mask = (mask & MAY_WRITE) && !(mask & MAY_READ);
 
if (nd)
-   unionfs_lock_dentry(nd->dentry, UNIONFS_DMUTEX_CHILD);
+   unionfs_lock_dentry(nd->path.dentry, UNIONFS_DMUTEX_CHILD);
 
if (!UNIONFS_I(inode)->lower_inodes) {
if (is_file)/* dirs can be unlinked but chdir'ed to */
@@ -960,7 +960,7 @@ out:
unionfs_check_inode(inode);
unionfs_check_nd(nd);
if (nd)
-   unionfs_unlock_dentry(nd->dentry);
+   unionfs_unlock_dentry(nd->path.dentry);
return err;
 }
 
-- 
1.5.2.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/

[PATCH 13/17] Unionfs: use dget_parent in revalidation code

[Erez Zadok]

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/dentry.c |   13 -
 1 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index a956b94..f8f65e1 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -410,15 +410,10 @@ bool __unionfs_d_revalidate_chain(struct dentry *dentry, 
struct nameidata *nd,
goto out;
}
 
-   /*
-* lock all dentries in chain, in child to parent order.
-* if failed, then sleep for a little, then retry.
-*/
-   dtmp = dentry->d_parent;
-   for (i = chain_len-1; i >= 0; i--) {
-   chain[i] = dget(dtmp);
-   dtmp = dtmp->d_parent;
-   }
+   /* grab all dentries in chain, in child to parent order */
+   dtmp = dentry;
+   for (i = chain_len-1; i >= 0; i--)
+   dtmp = chain[i] = dget_parent(dtmp);
 
/*
 * call __unionfs_d_revalidate_one() on each dentry, but in parent
-- 
1.5.2.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/

[PATCH 05/17] Unionfs: initialize path_save variable

[Erez Zadok]

This is not strictly necessary, but it helps quiet a gcc-4.2 warning (a good
optimizer may optimize this initialization away).

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/inode.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/unionfs/inode.c b/fs/unionfs/inode.c
index 0b92da2..8d939dc 100644
--- a/fs/unionfs/inode.c
+++ b/fs/unionfs/inode.c
@@ -246,7 +246,7 @@ static struct dentry *unionfs_lookup(struct inode *parent,
 struct dentry *dentry,
 struct nameidata *nd)
 {
-   struct path path_save;
+   struct path path_save = {NULL, NULL};
struct dentry *ret;
 
unionfs_read_lock(dentry->d_sb, UNIONFS_SMUTEX_CHILD);
-- 
1.5.2.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/

[PATCH 10/17] Unionfs: factor out revalidation routine

[Erez Zadok]

To be used by rest of revalidation code, as well a callers who already
locked the child and parent dentry branch-configurations.

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/dentry.c |   87 +++---
 fs/unionfs/union.h  |3 ++
 2 files changed, 57 insertions(+), 33 deletions(-)

diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index afa2120..3bd2dfb 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -285,6 +285,59 @@ void purge_sb_data(struct super_block *sb)
 }
 
 /*
+ * Revalidate a single file/symlink/special dentry.  Assume that info nodes
+ * of the dentry and its parent are locked.  Assume that parent(s) are all
+ * valid already, but the child may not yet be valid.  Returns true if
+ * valid, false otherwise.
+ */
+bool __unionfs_d_revalidate_one_locked(struct dentry *dentry,
+  struct nameidata *nd,
+  bool willwrite)
+{
+   bool valid = false; /* default is invalid */
+   int sbgen, dgen, bindex;
+
+   verify_locked(dentry);
+   verify_locked(dentry->d_parent);
+
+   sbgen = atomic_read(_SB(dentry->d_sb)->generation);
+   dgen = atomic_read(_D(dentry)->generation);
+
+   if (unlikely(is_newer_lower(dentry))) {
+   /* root dentry special case as aforementioned */
+   if (IS_ROOT(dentry)) {
+   unionfs_copy_attr_times(dentry->d_inode);
+   } else {
+   /*
+* reset generation number to zero, guaranteed to be
+* "old"
+*/
+   dgen = 0;
+   atomic_set(_D(dentry)->generation, dgen);
+   }
+   if (!willwrite)
+   purge_inode_data(dentry->d_inode);
+   }
+   valid = __unionfs_d_revalidate_one(dentry, nd);
+
+   /*
+* If __unionfs_d_revalidate_one() succeeded above, then it will
+* have incremented the refcnt of the mnt's, but also the branch
+* indices of the dentry will have been updated (to take into
+* account any branch insertions/deletion.  So the current
+* dbstart/dbend match the current, and new, indices of the mnts
+* which __unionfs_d_revalidate_one has incremented.  Note: the "if"
+* test below does not depend on whether chain_len was 0 or greater.
+*/
+   if (!valid || sbgen == dgen)
+   goto out;
+   for (bindex = dbstart(dentry); bindex <= dbend(dentry); bindex++)
+   unionfs_mntput(dentry, bindex);
+out:
+   return valid;
+}
+
+/*
  * Revalidate a parent chain of dentries, then the actual node.
  * Assumes that dentry is locked, but will lock all parents if/when needed.
  *
@@ -404,42 +457,10 @@ out_this:
if (dentry != dentry->d_parent)
unionfs_lock_dentry(dentry->d_parent,
UNIONFS_DMUTEX_REVAL_PARENT);
-   dgen = atomic_read(_D(dentry)->generation);
-
-   if (unlikely(is_newer_lower(dentry))) {
-   /* root dentry special case as aforementioned */
-   if (IS_ROOT(dentry)) {
-   unionfs_copy_attr_times(dentry->d_inode);
-   } else {
-   /*
-* reset generation number to zero, guaranteed to be
-* "old"
-*/
-   dgen = 0;
-   atomic_set(_D(dentry)->generation, dgen);
-   }
-   if (!willwrite)
-   purge_inode_data(dentry->d_inode);
-   }
-   valid = __unionfs_d_revalidate_one(dentry, nd);
+   valid = __unionfs_d_revalidate_one_locked(dentry, nd, willwrite);
if (dentry != dentry->d_parent)
unionfs_unlock_dentry(dentry->d_parent);
 
-   /*
-* If __unionfs_d_revalidate_one() succeeded above, then it will
-* have incremented the refcnt of the mnt's, but also the branch
-* indices of the dentry will have been updated (to take into
-* account any branch insertions/deletion.  So the current
-* dbstart/dbend match the current, and new, indices of the mnts
-* which __unionfs_d_revalidate_one has incremented.  Note: the "if"
-* test below does not depend on whether chain_len was 0 or greater.
-*/
-   if (valid && sbgen != dgen)
-   for (bindex = dbstart(dentry);
-bindex <= dbend(dentry);
-bindex++)
-   unionfs_mntput(dentry, bindex);
-
 out_free:
/* unlock/dput all dentries in chain and return status */
if (chain_len > 0) {
diff --git a/fs/unionfs/union.h b/fs/unionfs/union.h
index 0e0ccde..5001b07 100644
--- a/fs/unionfs/union.h
+++ b/fs/unionfs/union.h
@@ -368,6 +368,9 @@ extern int 

[PATCH 08/17] Unionfs: improve debugging in copy_attr_times

[Erez Zadok]

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/subr.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/fs/unionfs/subr.c b/fs/unionfs/subr.c
index 68a6280..1a40f63 100644
--- a/fs/unionfs/subr.c
+++ b/fs/unionfs/subr.c
@@ -247,8 +247,14 @@ void unionfs_copy_attr_times(struct inode *upper)
int bindex;
struct inode *lower;
 
-   if (!upper || ibstart(upper) < 0)
+   if (!upper)
return;
+   if (ibstart(upper) < 0) {
+#ifdef CONFIG_UNION_FS_DEBUG
+   WARN_ON(ibstart(upper) < 0);
+#endif /* CONFIG_UNION_FS_DEBUG */
+   return;
+   }
for (bindex = ibstart(upper); bindex <= ibend(upper); bindex++) {
lower = unionfs_lower_inode_idx(upper, bindex);
if (!lower)
-- 
1.5.2.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/

[PATCH 16/17] Unionfs: use the new path_put

[Erez Zadok]

From: Jan Blunck <[EMAIL PROTECTED]>

* Add path_put() functions for releasing a reference to the dentry and
  vfsmount of a struct path in the right order

* Switch from path_release(nd) to path_put(>path)

* Rename dput_path() to path_put_conditional()

Signed-off-by: Jan Blunck <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Acked-by: Christoph Hellwig <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/main.c  |2 +-
 fs/unionfs/super.c |   12 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/fs/unionfs/main.c b/fs/unionfs/main.c
index 4bc2c66..3585b29 100644
--- a/fs/unionfs/main.c
+++ b/fs/unionfs/main.c
@@ -371,7 +371,7 @@ static int parse_dirs_option(struct super_block *sb, struct 
unionfs_dentry_info
if (err) {
printk(KERN_ERR "unionfs: lower directory "
   "'%s' is not a valid branch\n", name);
-   path_release();
+   path_put();
goto out;
}
 
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index b71fc2a..773623e 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -234,7 +234,7 @@ static noinline int do_remount_mode_option(char *optarg, 
int cur_branches,
if (nd.mnt == new_lower_paths[idx].mnt &&
nd.dentry == new_lower_paths[idx].dentry)
break;
-   path_release();  /* no longer needed */
+   path_put(); /* no longer needed */
if (idx == cur_branches) {
err = -ENOENT;  /* err may have been reset above */
printk(KERN_ERR "unionfs: branch \"%s\" "
@@ -277,7 +277,7 @@ static noinline int do_remount_del_option(char *optarg, int 
cur_branches,
if (nd.mnt == new_lower_paths[idx].mnt &&
nd.dentry == new_lower_paths[idx].dentry)
break;
-   path_release();  /* no longer needed */
+   path_put(); /* no longer needed */
if (idx == cur_branches) {
printk(KERN_ERR "unionfs: branch \"%s\" "
   "not found\n", optarg);
@@ -296,7 +296,7 @@ static noinline int do_remount_del_option(char *optarg, int 
cur_branches,
 * new_data and new_lower_paths one to the left.  Finally, adjust
 * cur_branches.
 */
-   pathput(_lower_paths[idx]);
+   path_put(_lower_paths[idx]);
 
if (idx < cur_branches - 1) {
/* if idx==cur_branches-1, we delete last branch: easy */
@@ -361,7 +361,7 @@ static noinline int do_remount_add_option(char *optarg, int 
cur_branches,
if (nd.mnt == new_lower_paths[idx].mnt &&
nd.dentry == new_lower_paths[idx].dentry)
break;
-   path_release();  /* no longer needed */
+   path_put(); /* no longer needed */
if (idx == cur_branches) {
printk(KERN_ERR "unionfs: branch \"%s\" "
   "not found\n", optarg);
@@ -408,7 +408,7 @@ found_insertion_point:
if (err) {
printk(KERN_ERR "unionfs: lower directory "
   "\"%s\" is not a valid branch\n", optarg);
-   path_release();
+   path_put();
goto out;
}
 
@@ -818,7 +818,7 @@ out_release:
/* no need to cleanup/release anything in tmp_data */
if (tmp_lower_paths)
for (i = 0; i < new_branches; i++)
-   pathput(_lower_paths[i]);
+   path_put(_lower_paths[i]);
 out_free:
kfree(tmp_lower_paths);
kfree(tmp_data);
-- 
1.5.2.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/

[PATCH 12/17] Unionfs: branch management/configuration fixes

[Erez Zadok]

Remove unnecessary calls to update branch m/ctimes, and use them only when
needed.  Update branch vfsmounts after operations that could cause a copyup.

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/commonfops.c |9 +++--
 fs/unionfs/copyup.c |3 ++-
 fs/unionfs/dentry.c |1 +
 fs/unionfs/mmap.c   |   17 -
 fs/unionfs/rename.c |7 +--
 5 files changed, 15 insertions(+), 22 deletions(-)

diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 491e2ff..2add167 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -604,6 +604,7 @@ out:
}
 out_nofree:
if (!err) {
+   unionfs_postcopyup_setmnt(dentry);
unionfs_copy_attr_times(inode);
unionfs_check_file(file);
unionfs_check_inode(inode);
@@ -839,13 +840,9 @@ int unionfs_flush(struct file *file, fl_owner_t id)
 
}
 
-   /* on success, update our times */
-   unionfs_copy_attr_times(dentry->d_inode);
-   /* parent time could have changed too (async) */
-   unionfs_copy_attr_times(dentry->d_parent->d_inode);
-
 out:
-   unionfs_check_file(file);
+   if (!err)
+   unionfs_check_file(file);
unionfs_unlock_dentry(file->f_path.dentry);
unionfs_read_unlock(dentry->d_sb);
return err;
diff --git a/fs/unionfs/copyup.c b/fs/unionfs/copyup.c
index 9beac01..f71bddf 100644
--- a/fs/unionfs/copyup.c
+++ b/fs/unionfs/copyup.c
@@ -819,7 +819,8 @@ begin:
 * update times of this dentry, but also the parent, because if
 * we changed, the parent may have changed too.
 */
-   unionfs_copy_attr_times(parent_dentry->d_inode);
+   fsstack_copy_attr_times(parent_dentry->d_inode,
+   lower_parent_dentry->d_inode);
unionfs_copy_attr_times(child_dentry->d_inode);
 
parent_dentry = child_dentry;
diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index 17b297d..a956b94 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -482,6 +482,7 @@ static int unionfs_d_revalidate(struct dentry *dentry, 
struct nameidata *nd)
unionfs_lock_dentry(dentry, UNIONFS_DMUTEX_CHILD);
err = __unionfs_d_revalidate_chain(dentry, nd, false);
if (likely(err > 0)) { /* true==1: dentry is valid */
+   unionfs_postcopyup_setmnt(dentry);
unionfs_check_dentry(dentry);
unionfs_check_nd(nd);
}
diff --git a/fs/unionfs/mmap.c b/fs/unionfs/mmap.c
index ad770ac..d6ac61e 100644
--- a/fs/unionfs/mmap.c
+++ b/fs/unionfs/mmap.c
@@ -227,20 +227,11 @@ static int unionfs_prepare_write(struct file *file, 
struct page *page,
int err;
 
unionfs_read_lock(file->f_path.dentry->d_sb, UNIONFS_SMUTEX_PARENT);
-   /*
-* This is the only place where we unconditionally copy the lower
-* attribute times before calling unionfs_file_revalidate.  The
-* reason is that our ->write calls do_sync_write which in turn will
-* call our ->prepare_write and then ->commit_write.  Before our
-* ->write is called, the lower mtimes are in sync, but by the time
-* the VFS calls our ->commit_write, the lower mtimes have changed.
-* Therefore, the only reasonable time for us to sync up from the
-* changed lower mtimes, and avoid an invariant violation warning,
-* is here, in ->prepare_write.
-*/
-   unionfs_copy_attr_times(file->f_path.dentry->d_inode);
err = unionfs_file_revalidate(file, true);
-   unionfs_check_file(file);
+   if (!err) {
+   unionfs_copy_attr_times(file->f_path.dentry->d_inode);
+   unionfs_check_file(file);
+   }
unionfs_read_unlock(file->f_path.dentry->d_sb);
 
return err;
diff --git a/fs/unionfs/rename.c b/fs/unionfs/rename.c
index 5ab13f9..cc16eb2 100644
--- a/fs/unionfs/rename.c
+++ b/fs/unionfs/rename.c
@@ -138,6 +138,11 @@ static int __unionfs_rename(struct inode *old_dir, struct 
dentry *old_dentry,
err = vfs_rename(lower_old_dir_dentry->d_inode, lower_old_dentry,
 lower_new_dir_dentry->d_inode, lower_new_dentry);
 out_err_unlock:
+   if (!err) {
+   /* update parent dir times */
+   fsstack_copy_attr_times(old_dir, lower_old_dir_dentry->d_inode);
+   fsstack_copy_attr_times(new_dir, lower_new_dir_dentry->d_inode);
+   }
unlock_rename(lower_old_dir_dentry, lower_new_dir_dentry);
lockdep_on();
 
@@ -526,8 +531,6 @@ int unionfs_rename(struct inode *old_dir, struct dentry 
*old_dentry,
}
}
/* if all of this renaming succeeded, update our times */
-   unionfs_copy_attr_times(old_dir);
-   unionfs_copy_attr_times(new_dir);
unionfs_copy_attr_times(old_dentry->d_inode);
unionfs_copy_attr_times(new_dentry->d_inode);

[PATCH 04/17] Unionfs: uninline unionfs_copy_attr_times and unionfs_copy_attr_all

[Erez Zadok]

This reduces text size by about 6k.

Cc: Hugh Dickins <[EMAIL PROTECTED]>

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/fanout.h |   50 --
 fs/unionfs/subr.c   |   50 ++
 fs/unionfs/union.h  |2 ++
 3 files changed, 52 insertions(+), 50 deletions(-)

diff --git a/fs/unionfs/fanout.h b/fs/unionfs/fanout.h
index 4d9a45f..29d42fb 100644
--- a/fs/unionfs/fanout.h
+++ b/fs/unionfs/fanout.h
@@ -313,54 +313,4 @@ static inline void verify_locked(struct dentry *d)
BUG_ON(!mutex_is_locked(_D(d)->lock));
 }
 
-/* copy a/m/ctime from the lower branch with the newest times */
-static inline void unionfs_copy_attr_times(struct inode *upper)
-{
-   int bindex;
-   struct inode *lower;
-
-   if (!upper || ibstart(upper) < 0)
-   return;
-   for (bindex = ibstart(upper); bindex <= ibend(upper); bindex++) {
-   lower = unionfs_lower_inode_idx(upper, bindex);
-   if (!lower)
-   continue; /* not all lower dir objects may exist */
-   if (unlikely(timespec_compare(>i_mtime,
- >i_mtime) < 0))
-   upper->i_mtime = lower->i_mtime;
-   if (unlikely(timespec_compare(>i_ctime,
- >i_ctime) < 0))
-   upper->i_ctime = lower->i_ctime;
-   if (unlikely(timespec_compare(>i_atime,
- >i_atime) < 0))
-   upper->i_atime = lower->i_atime;
-   }
-}
-
-/*
- * A unionfs/fanout version of fsstack_copy_attr_all.  Uses a
- * unionfs_get_nlinks to properly calcluate the number of links to a file.
- * Also, copies the max() of all a/m/ctimes for all lower inodes (which is
- * important if the lower inode is a directory type)
- */
-static inline void unionfs_copy_attr_all(struct inode *dest,
-const struct inode *src)
-{
-   dest->i_mode = src->i_mode;
-   dest->i_uid = src->i_uid;
-   dest->i_gid = src->i_gid;
-   dest->i_rdev = src->i_rdev;
-
-   unionfs_copy_attr_times(dest);
-
-   dest->i_blkbits = src->i_blkbits;
-   dest->i_flags = src->i_flags;
-
-   /*
-* Update the nlinks AFTER updating the above fields, because the
-* get_links callback may depend on them.
-*/
-   dest->i_nlink = unionfs_get_nlinks(dest);
-}
-
 #endif /* not _FANOUT_H */
diff --git a/fs/unionfs/subr.c b/fs/unionfs/subr.c
index 0a0fce9..68a6280 100644
--- a/fs/unionfs/subr.c
+++ b/fs/unionfs/subr.c
@@ -240,3 +240,53 @@ char *alloc_whname(const char *name, int len)
 
return buf;
 }
+
+/* copy a/m/ctime from the lower branch with the newest times */
+void unionfs_copy_attr_times(struct inode *upper)
+{
+   int bindex;
+   struct inode *lower;
+
+   if (!upper || ibstart(upper) < 0)
+   return;
+   for (bindex = ibstart(upper); bindex <= ibend(upper); bindex++) {
+   lower = unionfs_lower_inode_idx(upper, bindex);
+   if (!lower)
+   continue; /* not all lower dir objects may exist */
+   if (unlikely(timespec_compare(>i_mtime,
+ >i_mtime) < 0))
+   upper->i_mtime = lower->i_mtime;
+   if (unlikely(timespec_compare(>i_ctime,
+ >i_ctime) < 0))
+   upper->i_ctime = lower->i_ctime;
+   if (unlikely(timespec_compare(>i_atime,
+ >i_atime) < 0))
+   upper->i_atime = lower->i_atime;
+   }
+}
+
+/*
+ * A unionfs/fanout version of fsstack_copy_attr_all.  Uses a
+ * unionfs_get_nlinks to properly calcluate the number of links to a file.
+ * Also, copies the max() of all a/m/ctimes for all lower inodes (which is
+ * important if the lower inode is a directory type)
+ */
+void unionfs_copy_attr_all(struct inode *dest,
+  const struct inode *src)
+{
+   dest->i_mode = src->i_mode;
+   dest->i_uid = src->i_uid;
+   dest->i_gid = src->i_gid;
+   dest->i_rdev = src->i_rdev;
+
+   unionfs_copy_attr_times(dest);
+
+   dest->i_blkbits = src->i_blkbits;
+   dest->i_flags = src->i_flags;
+
+   /*
+* Update the nlinks AFTER updating the above fields, because the
+* get_links callback may depend on them.
+*/
+   dest->i_nlink = unionfs_get_nlinks(dest);
+}
diff --git a/fs/unionfs/union.h b/fs/unionfs/union.h
index 786c4be..0e0ccde 100644
--- a/fs/unionfs/union.h
+++ b/fs/unionfs/union.h
@@ -199,6 +199,8 @@ struct unionfs_dir_state {
 
 /* externs needed for fanout.h or sioq.h */
 extern int unionfs_get_nlinks(const struct inode *inode);
+extern void unionfs_copy_attr_times(struct inode *upper);

[PATCH 17/17] VFS/Unionfs: use generic path_get/path_put functions

[Erez Zadok]

Remove unionfs's versions thereof.

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/main.c |   10 +-
 fs/unionfs/super.c|   27 ++-
 include/linux/namei.h |   12 
 3 files changed, 19 insertions(+), 30 deletions(-)

diff --git a/fs/unionfs/main.c b/fs/unionfs/main.c
index 3585b29..8f59fb5 100644
--- a/fs/unionfs/main.c
+++ b/fs/unionfs/main.c
@@ -230,11 +230,11 @@ void unionfs_reinterpose(struct dentry *dentry)
 int check_branch(struct nameidata *nd)
 {
/* XXX: remove in ODF code -- stacking unions allowed there */
-   if (!strcmp(nd->dentry->d_sb->s_type->name, UNIONFS_NAME))
+   if (!strcmp(nd->path.dentry->d_sb->s_type->name, UNIONFS_NAME))
return -EINVAL;
-   if (!nd->dentry->d_inode)
+   if (!nd->path.dentry->d_inode)
return -ENOENT;
-   if (!S_ISDIR(nd->dentry->d_inode->i_mode))
+   if (!S_ISDIR(nd->path.dentry->d_inode->i_mode))
return -ENOTDIR;
return 0;
 }
@@ -375,8 +375,8 @@ static int parse_dirs_option(struct super_block *sb, struct 
unionfs_dentry_info
goto out;
}
 
-   lower_root_info->lower_paths[bindex].dentry = nd.dentry;
-   lower_root_info->lower_paths[bindex].mnt = nd.mnt;
+   lower_root_info->lower_paths[bindex].dentry = nd.path.dentry;
+   lower_root_info->lower_paths[bindex].mnt = nd.path.mnt;
 
set_branchperms(sb, bindex, perms);
set_branch_count(sb, bindex, 0);
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index 773623e..fba1598 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -231,8 +231,8 @@ static noinline int do_remount_mode_option(char *optarg, 
int cur_branches,
goto out;
}
for (idx = 0; idx < cur_branches; idx++)
-   if (nd.mnt == new_lower_paths[idx].mnt &&
-   nd.dentry == new_lower_paths[idx].dentry)
+   if (nd.path.mnt == new_lower_paths[idx].mnt &&
+   nd.path.dentry == new_lower_paths[idx].dentry)
break;
path_put(); /* no longer needed */
if (idx == cur_branches) {
@@ -274,8 +274,8 @@ static noinline int do_remount_del_option(char *optarg, int 
cur_branches,
goto out;
}
for (idx = 0; idx < cur_branches; idx++)
-   if (nd.mnt == new_lower_paths[idx].mnt &&
-   nd.dentry == new_lower_paths[idx].dentry)
+   if (nd.path.mnt == new_lower_paths[idx].mnt &&
+   nd.path.dentry == new_lower_paths[idx].dentry)
break;
path_put(); /* no longer needed */
if (idx == cur_branches) {
@@ -358,8 +358,8 @@ static noinline int do_remount_add_option(char *optarg, int 
cur_branches,
goto out;
}
for (idx = 0; idx < cur_branches; idx++)
-   if (nd.mnt == new_lower_paths[idx].mnt &&
-   nd.dentry == new_lower_paths[idx].dentry)
+   if (nd.path.mnt == new_lower_paths[idx].mnt &&
+   nd.path.dentry == new_lower_paths[idx].dentry)
break;
path_put(); /* no longer needed */
if (idx == cur_branches) {
@@ -425,10 +425,10 @@ found_insertion_point:
memmove(_lower_paths[idx+1], _lower_paths[idx],
(cur_branches - idx) * sizeof(struct path));
}
-   new_lower_paths[idx].dentry = nd.dentry;
-   new_lower_paths[idx].mnt = nd.mnt;
+   new_lower_paths[idx].dentry = nd.path.dentry;
+   new_lower_paths[idx].mnt = nd.path.mnt;
 
-   new_data[idx].sb = nd.dentry->d_sb;
+   new_data[idx].sb = nd.path.dentry->d_sb;
atomic_set(_data[idx].open_files, 0);
new_data[idx].branchperms = perms;
new_data[idx].branch_id = ++*high_branch_id; /* assign new branch ID */
@@ -577,7 +577,7 @@ static int unionfs_remount_fs(struct super_block *sb, int 
*flags,
memcpy(tmp_lower_paths, UNIONFS_D(sb->s_root)->lower_paths,
   cur_branches * sizeof(struct path));
for (i = 0; i < cur_branches; i++)
-   pathget(_lower_paths[i]); /* drop refs at end of fxn */
+   path_get(_lower_paths[i]); /* drop refs at end of fxn */
 
/***
 * For each branch command, do path_lookup on the requested branch,
@@ -1008,9 +1008,10 @@ static int unionfs_show_options(struct seq_file *m, 
struct vfsmount *mnt)
 
seq_printf(m, ",dirs=");
for (bindex = bstart; bindex <= bend; bindex++) {
-   path = d_path(unionfs_lower_dentry_idx(sb->s_root, bindex),
- unionfs_lower_mnt_idx(sb->s_root, bindex),
- tmp_page, PAGE_SIZE);
+   struct path p;
+   p.dentry = 

[PATCH 09/17] Unionfs: revalidation code cleanup and refactoring

[Erez Zadok]

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/dentry.c |   55 --
 1 files changed, 35 insertions(+), 20 deletions(-)

diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index cd15243..afa2120 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -18,6 +18,39 @@
 
 #include "union.h"
 
+
+static inline void __dput_lowers(struct dentry *dentry, int start, int end)
+{
+   struct dentry *lower_dentry;
+   int bindex;
+
+   if (start < 0)
+   return;
+   for (bindex = start; bindex <= end; bindex++) {
+   lower_dentry = unionfs_lower_dentry_idx(dentry, bindex);
+   if (!lower_dentry)
+   continue;
+   unionfs_set_lower_dentry_idx(dentry, bindex, NULL);
+   dput(lower_dentry);
+   }
+}
+
+static inline void __iput_lowers(struct inode *inode, int start, int end)
+{
+   struct inode *lower_inode;
+   int bindex;
+
+   if (start < 0)
+   return;
+   for (bindex = start; bindex <= end; bindex++) {
+   lower_inode = unionfs_lower_inode_idx(inode, bindex);
+   if (!lower_inode)
+   continue;
+   unionfs_set_lower_inode_idx(inode, bindex, NULL);
+   iput(lower_inode);
+   }
+}
+
 /*
  * Revalidate a single dentry.
  * Assume that dentry's info node is locked.
@@ -72,15 +105,7 @@ static bool __unionfs_d_revalidate_one(struct dentry 
*dentry,
/* Free the pointers for our inodes and this dentry. */
bstart = dbstart(dentry);
bend = dbend(dentry);
-   if (bstart >= 0) {
-   struct dentry *lower_dentry;
-   for (bindex = bstart; bindex <= bend; bindex++) {
-   lower_dentry =
-   unionfs_lower_dentry_idx(dentry,
-bindex);
-   dput(lower_dentry);
-   }
-   }
+   __dput_lowers(dentry, bstart, bend);
set_dbstart(dentry, -1);
set_dbend(dentry, -1);
 
@@ -90,17 +115,7 @@ static bool __unionfs_d_revalidate_one(struct dentry 
*dentry,
 
bstart = ibstart(dentry->d_inode);
bend = ibend(dentry->d_inode);
-   if (bstart >= 0) {
-   struct inode *lower_inode;
-   for (bindex = bstart; bindex <= bend;
-bindex++) {
-   lower_inode =
-   unionfs_lower_inode_idx(
-   dentry->d_inode,
-   bindex);
-   iput(lower_inode);
-   }
-   }
+   __iput_lowers(dentry->d_inode, bstart, bend);
kfree(UNIONFS_I(dentry->d_inode)->lower_inodes);
UNIONFS_I(dentry->d_inode)->lower_inodes = NULL;
ibstart(dentry->d_inode) = -1;
-- 
1.5.2.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/

[PATCH 02/17] Unionfs: ensure consistent lower inodes types

[Erez Zadok]

When looking up a lower object in multiple branches, especially for
directories, ignore any existing entries whose type is different than the
type of the first found object (otherwise we'll be trying to, say, call
readdir on a non-dir inode).

Signed-off-by: Himanshu Kanda <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/lookup.c |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/fs/unionfs/lookup.c b/fs/unionfs/lookup.c
index b9ee072..755158e 100644
--- a/fs/unionfs/lookup.c
+++ b/fs/unionfs/lookup.c
@@ -256,6 +256,19 @@ struct dentry *unionfs_lookup_backend(struct dentry 
*dentry,
continue;
}
 
+   /*
+* If we already found at least one positive dentry
+* (dentry_count is non-zero), then we skip all remaining
+* positive dentries if their type is a non-dir.  This is
+* because only directories are allowed to stack on multiple
+* branches, but we have to skip non-dirs (to avoid, say,
+* calling readdir on a regular file).
+*/
+   if (!S_ISDIR(lower_dentry->d_inode->i_mode) && dentry_count) {
+   dput(lower_dentry);
+   continue;
+   }
+
/* number of positive dentries */
dentry_count++;
 
-- 
1.5.2.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/

[PATCH 07/17] Unionfs: follow_link locking fixes

[Erez Zadok]

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/inode.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/fs/unionfs/inode.c b/fs/unionfs/inode.c
index 8d939dc..6377533 100644
--- a/fs/unionfs/inode.c
+++ b/fs/unionfs/inode.c
@@ -820,7 +820,11 @@ static void *unionfs_follow_link(struct dentry *dentry, 
struct nameidata *nd)
err = 0;
 
 out:
-   unionfs_check_dentry(dentry);
+   if (!err) {
+   unionfs_lock_dentry(dentry, UNIONFS_DMUTEX_CHILD);
+   unionfs_check_dentry(dentry);
+   unionfs_unlock_dentry(dentry);
+   }
unionfs_check_nd(nd);
return ERR_PTR(err);
 }
-- 
1.5.2.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/

[PATCH 03/17] Unionfs: document behavior when the lower topology changes

[Erez Zadok]

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 Documentation/filesystems/unionfs/concepts.txt |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/Documentation/filesystems/unionfs/concepts.txt 
b/Documentation/filesystems/unionfs/concepts.txt
index bed69bd..8d9a1c5 100644
--- a/Documentation/filesystems/unionfs/concepts.txt
+++ b/Documentation/filesystems/unionfs/concepts.txt
@@ -210,4 +210,17 @@ there's a lot of concurrent activity on both the upper and 
lower objects,
 for the same file(s).  Lastly, this delayed time attribute detection is
 similar to how NFS clients operate (e.g., acregmin).
 
+Finally, there is no way currently in Linux to prevent lower directories
+from being moved around (i.e., topology changes); there's no way to prevent
+modifications to directory sub-trees of whole file systems which are mounted
+read-write.  It is therefore possible for in-flight operations in unionfs to
+take place, while a lower directory is being moved around.  Therefore, if
+you try to, say, create a new file in a directory through unionfs, while the
+directory is being moved around directly, then the new file may get created
+in the new location where that directory was moved to.  This is a somewhat
+similar behaviour in NFS: an NFS client could be creating a new file while
+th NFS server is moving th directory around; the file will get successfully
+created in the new location.  (The one exception in unionfs is that if the
+branch is marked read-only by unionfs, then a copyup will take place.)
+
 For more information, see .
-- 
1.5.2.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/

[PATCH 01/17] Unionfs: grab lower super_block references

[Erez Zadok]

This prevents the lower super_block from being destroyed too early, when a
lower file system is being unmounted with MNT_FORCE or MNT_DETACH.

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
 fs/unionfs/main.c  |3 +++
 fs/unionfs/super.c |   14 ++
 fs/unionfs/union.h |2 +-
 3 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/fs/unionfs/main.c b/fs/unionfs/main.c
index 23c18f7..ba3471d 100644
--- a/fs/unionfs/main.c
+++ b/fs/unionfs/main.c
@@ -636,6 +636,7 @@ static int unionfs_read_super(struct super_block *sb, void 
*raw_data,
sbend(sb) = bend = lower_root_info->bend;
for (bindex = bstart; bindex <= bend; bindex++) {
struct dentry *d = lower_root_info->lower_paths[bindex].dentry;
+   atomic_inc(>d_sb->s_active);
unionfs_set_lower_super_idx(sb, bindex, d->d_sb);
}
 
@@ -711,6 +712,8 @@ out_dput:
dput(d);
/* initializing: can't use unionfs_mntput here */
mntput(m);
+   /* drop refs we took earlier */
+   atomic_dec(>d_sb->s_active);
}
kfree(lower_root_info->lower_paths);
kfree(lower_root_info);
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index 986c980..175840f 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -116,6 +116,14 @@ static void unionfs_put_super(struct super_block *sb)
}
BUG_ON(leaks != 0);
 
+   /* decrement lower super references */
+   for (bindex = bstart; bindex <= bend; bindex++) {
+   struct super_block *s;
+   s = unionfs_lower_super_idx(sb, bindex);
+   unionfs_set_lower_super_idx(sb, bindex, NULL);
+   atomic_dec(>s_active);
+   }
+
kfree(spd->data);
kfree(spd);
sb->s_fs_info = NULL;
@@ -729,6 +737,12 @@ out_no_change:
 */
purge_sb_data(sb);
 
+   /* grab new lower super references; release old ones */
+   for (i = 0; i < new_branches; i++)
+   atomic_inc(_data[i].sb->s_active);
+   for (i = 0; i < new_branches; i++)
+   atomic_dec(_SB(sb)->data[i].sb->s_active);
+
/* copy new vectors into their correct place */
tmp_data = UNIONFS_SB(sb)->data;
UNIONFS_SB(sb)->data = new_data;
diff --git a/fs/unionfs/union.h b/fs/unionfs/union.h
index 4b4d6c9..786c4be 100644
--- a/fs/unionfs/union.h
+++ b/fs/unionfs/union.h
@@ -127,7 +127,7 @@ struct unionfs_dentry_info {
 
 /* These are the pointers to our various objects. */
 struct unionfs_data {
-   struct super_block *sb;
+   struct super_block *sb; /* lower super_block */
atomic_t open_files;/* number of open files on branch */
int branchperms;
int branch_id;  /* unique branch ID at re/mount time */
-- 
1.5.2.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/

[GIT PULL -mm] 00/17 Unionfs updates/fixes/cleanups

[Erez Zadok]

The following is a series of patchsets related to Unionfs.  The most
significant changes are several fixes to races/locking.  This release also
supports newer APIs in 2.6.25-rc: not using iget/read_inode, using the
changed d_path, using the revised nameidata which embeds a struct path, and
using path_get/put.

These patches were tested (where appropriate) on 2.6.25, MM, as well as the
backports to 2.6.{24,23,22,21,20,19,18,9} on ext2/3/4, xfs, reiserfs,
nfs2/3/4, jffs2, ramfs, tmpfs, cramfs, and squashfs (where available).  Also
tested with LTP-full and with a continuous parallel kernel compile (while
forcing cache flushing, manipulating lower branches, etc.).  See
http://unionfs.filesystems.org/ to download back-ported unionfs code.

Please pull from the 'master' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/ezk/unionfs.git

to receive the following:

Andrew Morton (1):
  Unionfs: embed a struct path into struct nameidata instead of nd dentrymnt

David Howells (1):
  Unionfs: stop using iget() and read_inode()

Erez Zadok (14):
  Unionfs: grab lower super_block references
  Unionfs: ensure consistent lower inodes types
  Unionfs: document behavior when the lower topology changes
  Unionfs: uninline unionfs_copy_attr_times and unionfs_copy_attr_all
  Unionfs: initialize path_save variable
  Unionfs: extend dentry branch configuration lock in open
  Unionfs: follow_link locking fixes
  Unionfs: improve debugging in copy_attr_times
  Unionfs: revalidation code cleanup and refactoring
  Unionfs: factor out revalidation routine
  Unionfs: lock parents' branch configuration fixes
  Unionfs: branch management/configuration fixes
  Unionfs: use dget_parent in revalidation code
  VFS/Unionfs: use generic path_get/path_put functions

Jan Blunck (1):
  Unionfs: use the new path_put

 Documentation/filesystems/unionfs/concepts.txt |   13 +
 fs/unionfs/commonfops.c|   54 ---
 fs/unionfs/copyup.c|3 
 fs/unionfs/dentry.c|  182 ++---
 fs/unionfs/fanout.h|   50 --
 fs/unionfs/inode.c |   78 +++---
 fs/unionfs/lookup.c|   13 +
 fs/unionfs/main.c  |   26 +--
 fs/unionfs/mmap.c  |   17 --
 fs/unionfs/rename.c|7 
 fs/unionfs/subr.c  |   56 +++
 fs/unionfs/super.c |   72 ++---
 fs/unionfs/union.h |   13 +
 fs/unionfs/unlink.c|   11 +
 include/linux/namei.h  |   12 -
 15 files changed, 366 insertions(+), 241 deletions(-)

Thanks.
---
Erez Zadok
[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/

[REGRESSION 2.6.23] no vga console and no messages

[Daniel Barkalow]

For some reason I can't see and don't know how to debug, in 2.6.23 on my 
server I don't get the vga console, but only get the dummy console.

I also noticed that the documentation is wrong and the Kconfig file is 
confused; it's impossible to not have DUMMY_CONSOLE set, because at least 
one of PROM_CONSOLE and VGA_CONSOLE must not be y. Normally (maybe only 
due to the fact that "dummycon" sorts before "promcon", "sticon", and 
"vgacon"), it actually only stays active if your real console doesn't also 
get initialized. This isn't my problem, AFAICT (my kernel panics if I 
disable DUMMY_CONSOLE, presumably for lack of any console at all); it's 
just misleading.

I'm not seeing anything in dmesg to indicate why VGA+ isn't getting 
registered successfully, or anything to suggest it is trying to be, nor do 
I see anything in a 2.6.22 boot about why that seems to work. Any 
suggestions on further things to try?

I haven't tested anything newer than 2.6.23.x, but I looked through the 
git history and didn't find anything that looked relevant, or even anyone 
who might know about it.

-Daniel
*This .sig left intentionally blank*
--
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] More accessible usage of custom flags

[Nicholas Marquez]

I submitted this patch to the zen-sources Gentoo community and got
much praise and has promptly been included.  This kind of thing have
very likely already been done in other patchsets, but I haven't seen
it around, so I've gone ahead and made one.  The idea is that one can
enable -Os and various other options transparently through standard
kernel configuration, so why bar the builder from any other options to
pass on to gcc (et al)?  One can indeed add one's own flags in the
Makefile, but this method is a good deal friendlier.  Granted, this
could be misused by ricers and idiots, but they'll get themselves into
that mess all of their own fault and we'll all go on our merry ways.
It just seems that much use could be made out of this, both in terms
of (sane) optimizations and easier access to enhanced debugging
opportunities.

I see that people who build a Linux kernel are largely of two types:
~the ones that understand and know enough that they could, with some
nudging and learning, become bonafide kernel devs and
~the ones that understand it to some very basic degree and can get
through configuring it without too much trouble (though with limited
understanding)
I believe one of the very simple things that can be addressed is to
make the kernel more "accessible" without harming its integrity or
functionality.  This involves trying to fill the gap between those two
types of people, allowing there to be more understanding,
configuration, and (down the line) development opportunities within
the kernel to better ease these people into learning enough to begin
contributing back.  More developers can only be a Good Thing (tm).
Though a haughty and abstract opinion/goal/thought of mine, this patch
conforms to it and I think that with minimal effort such a vision
could be implemented.  Whilst all other kernel devs are hacking away
at the rough and tumultuous innards of the kernel, a few people of
less confidence and experience (people like me) could polish the
outside to make it more appealing to more people. So that eventually
they too will sink below the surface and join the party.

Anyway, I'm not quite sure that my implementation is as clean as it
could be and any feedback is certainly welcome.  This is my first time
posting to LKML, so I fully expect to be shot down anyway.


~Nicholas (Alex) Marquez
<[EMAIL PROTECTED]>

__
diff -dur original/init/Kconfig modified/init/Kconfig
--- original/init/Kconfig2008-02-16 20:24:22.0 -0500
+++ modified/init/Kconfig2008-02-16 20:53:48.0 -0500
@@ -487,6 +487,52 @@
   option.  If problems are observed, a gcc upgrade may be needed.

   If unsure, say N.
+
+menu "Custom flags"
+
+config CUSTOM_CFLAGS
+string "Custom CFLAGS for kernel"
+default ""
+help
+You can use this to easily set custom gcc CFLAGS to be used for the
+entire kernel (including modules).
+
+ONLY ADD CUSTOM CFLAGS IF YOU KNOW WHAT YOU ARE DOING
+
+If unsure, leave blank.
+
+config CUSTOM_LDFLAGS
+string "Custom LDFLAGS for kernel"
+default ""
+help
+You can use this to easily set custom gcc LDFLAGS to be used for the
+entire kernel (including modules).
+
+ONLY ADD CUSTOM LDFLAGS IF YOU KNOW WHAT YOU ARE DOING
+
+If unsure, leave blank.
+
+config CUSTOM_AFLAGS
+string "Custom AFLAGS for kernel"
+default ""
+help
+You can use this to easily set custom gcc AFLAGS to be used for the
+entire kernel (including modules).
+
+ONLY ADD CUSTOM AFLAGS IF YOU KNOW WHAT YOU ARE DOING
+
+If unsure, leave blank.
+
+config CUSTOM_MAKEFLAGS
+string "Custom MAKEFLAGS for kernel"
+default ""
+help
+You can use this to easily set custom MAKEFLAGS to be used for building
+the entire kernel.
+
+If unsure, leave blank.
+
+endmenu

 config SYSCTL
 bool
diff -dur original/Makefile modified/Makefile
--- original/Makefile2008-02-16 20:15:58.0 -0500
+++ modified/Makefile2008-02-16 20:35:55.0 -0500
@@ -14,7 +14,7 @@
 # o  use make's built-in rules and variables
 #(this increases performance and avoids hard-to-debug behaviour);
 # o  print "Entering directory ...";
-MAKEFLAGS += -rR --no-print-directory
+MAKEFLAGS += -rR --no-print-directory $(CUSTOM_MAKEFLAGS)

 # We are using a recursive build, so we need to do a little thinking
 # to get the ordering right.
@@ -315,11 +315,11 @@

 CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__
-Wbitwise $(CF)
 MODFLAGS= -DMODULE
-CFLAGS_MODULE   = $(MODFLAGS)
-AFLAGS_MODULE   = $(MODFLAGS)
-LDFLAGS_MODULE  =
-CFLAGS_KERNEL=
-AFLAGS_KERNEL=
+CFLAGS_MODULE   = $(MODFLAGS) $(CUSTOM_CFLAGS)
+AFLAGS_MODULE   = $(MODFLAGS) $(CUSTOM_AFLAGS)
+LDFLAGS_MODULE  = $(CUSTOM_LDFLAGS)
+CFLAGS_KERNEL= $(CUSTOM_CFLAGS)
+AFLAGS_KERNEL= $(CUSTOM_AFLAGS)


 # Use LINUXINCLUDE when you must reference the include/ directory.
@@ -525,6 +525,10 @@
 

Re: [RFC] bitmap onto and fold operators for mempolicy extensions

[KOSAKI Motohiro]

Hi Paul,

> > iff?
> > other portions looks good :)
> 
> "iff" -- "if and only if"
> 
> It is from my days, a long long time ago, as a student of mathematical
> logic and set theory.  I was too lazy to spell that one out.  My bad.

not at all.
I did't know the abbreviation, sorry.

I think your patch has no bug.
Thanks.


- kosaki


--
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/2] kernel/{exit.c, signal.c, power/process.c}: replace !likely(x) by likely(!x)

[Rene Herman]

On 16-02-08 20:01, H. Peter Anvin wrote:

Roel Kluin wrote:

Not entirely sure who to send this to
---
Replace !likely(x) by likely(!x)


Whoa...

Are you sure this is correct?

!likely(x) is equivalent to unlikely(!x)


Not with respect to its value I believe? likely(x) == !!(x), and 
unlikely(!x) == !!(!x) = !x, so conditions work out differently?



not the opposite, so this is a functional change...


Rene.
--
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: What's needed for a PCIe card to be recognized?

[Arjan van de Ven]

On Sun, 17 Feb 2008 01:54:53 +0100
Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:

> Am Sat, 16 Feb 2008 14:39:46 -0800
> schrieb Arjan van de Ven <[EMAIL PROTECTED]>:
> 
> > On Sat, 16 Feb 2008 22:59:32 +0100
> > Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:
> > 
> > > I'm playing around with a vanilla 2.6.25-rc1, adding patches to
> > > make it work on an Asus EeePC. That one has the problem that its
> > > Mini PCIe WLAN module doesn't show up in lspci. That brought up a
> > > few questions that I couldn't answer yet:
> > > 
> > > How can they "hide" a PCIe card?
> > > What could be their motive to do that?
> > > How can I make it appear?
> > 
> > 
> > go to the bios, enable the wireless card. 
> > 
> > that did it for me ;)
> 
> It didn't for me. I tried all combinations (booting with/without WLAN
> enabled, enabling WLAN through /proc with/without pciehp loaded and so
> on). What kernel did you use, and which patches did you apply?
> 

I used a pretty much stock Fedora 8 kernel.. no magic patches at all.
Of course there's no driver for the wlan, but that's a different story ;)

-- 
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings, 
visit http://www.lesswatts.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: linux-next: first tree

[Robin Getz]

On Sat 16 Feb 2008 10:33, Stephen Rothwell pondered:
> On Fri, 15 Feb 2008 16:33:50 +0800 "Bryan Wu" <[EMAIL PROTECTED]> wrote:
> >
> > Could you please add Blackfin tree to the linux-next
> > 
> >  git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/blackfin-2.6.git
> > for-linus
> 
> Added, thanks.
> 
> > And do you have the blackfin cross-compile toolchain?
> 
> No, I don't at the moment.

You can grab (i386 rpms and tar ball) that should work from:

http://blackfin.uclinux.org/gf/project/toolchain/frs/?action=FrsReleaseView_id=375

You will need:
 - toolchain blackfin-toolchain-08r1-8.i386.rpm
 - c library (either one of):
- blackfin-toolchain-uclibc-default-08r1-8.i386.rpm
- blackfin-toolchain-uclibc-full-08r1-8.i386.rpm

Other arch's & packages should appear shortly.

-Robin
--
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.25-rc2-mm1 (wakeup)

[Randy Dunlap]

On Sat, 16 Feb 2008 17:22:52 -0800 H. Peter Anvin wrote:

> Rafael J. Wysocki wrote:
> > On Saturday, 16 of February 2008, Randy Dunlap wrote:
> >> On Sat, 16 Feb 2008 00:25:22 -0800 Andrew Morton wrote:
> >>
> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
> >> The ACPI wakeup in C patch (I think) won't build for me on x86_32
> >> (i.e., i386 build on x86_64 system):
> >>
> >> linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: CPU 
> >> you selected does not support x86-64 instruction set
> >> linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: CPU 
> >> you selected does not support x86-64 instruction set
> >> linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: 
> >> -mpreferred-stack-boundary=2 is not between 4 and 12
> >> make[4]: *** [arch/x86/kernel/acpi/realmode/wakeup.o] Error 1
> >> make[3]: *** [arch/x86/kernel/acpi/realmode/wakeup.bin] Error 2
> > 
> > It compiles for me on a native i386.
> > 
> > Can you please give me a hint what to do to reproduce the problem?
> 
> Sounds like you're not adding -m32 to the gcc command line.

Yes, adding -m32 to the X86_32 config ccflags (as is done for the
X86_64 case) makes it build for me.  (like patch below)

Thanks.
---

From: Randy Dunlap <[EMAIL PROTECTED]>

Fix wakeup code build errors on x86_64.

linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: CPU you 
selected does not support x86-64 instruction set
linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: CPU you 
selected does not support x86-64 instruction set
linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: 
-mpreferred-stack-boundary=2 is not between 4 and 12

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 arch/x86/kernel/acpi/realmode/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/acpi/realmode/Makefile
+++ linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/Makefile
@@ -27,7 +27,7 @@ bootsrc   := $(src)/../../../boot
 # How to compile the 16-bit code.  Note we always compile for -march=i386,
 # that way we can complain to the user if the CPU is insufficient.
 # Compile with _SETUP since this is similar to the boot-time setup code.
-cflags-$(CONFIG_X86_32) :=
+cflags-$(CONFIG_X86_32) := -m32
 cflags-$(CONFIG_X86_64) := -m32
 KBUILD_CFLAGS  := $(LINUXINCLUDE) -g -Os -D_SETUP -D_WAKEUP -D__KERNEL__ \
   -I$(srctree)/$(bootsrc) \
--
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/

[RT] 2.6.24 - stuck in serial8250_console_write

[Jon Masters]

Yo,

Anyone seen a 2.6.24 system deadlock unable to printk because another
task is already holding the console lock?

Jon.


--
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.25-rc2-mm1: build failure (x86)

[Rafael J. Wysocki]

On Saturday, 16 of February 2008, Marcin Slusarz wrote:
> On Sat, Feb 16, 2008 at 03:09:49AM -0800, Andrew Morton wrote:
> > On Sat, 16 Feb 2008 11:59:07 +0100 Marcin Slusarz <[EMAIL PROTECTED]> wrote:
> > 
> > > arch/x86/kernel/built-in.o: In function `amd_smp_thermal_interrupt':
> > > (.text+0xe03b): undefined reference to `mce_log_therm_throt_event'
> > > arch/x86/kernel/built-in.o: In function `acpi_save_state_mem':
> > > (.text+0x12239): undefined reference to `setup_trampoline'
> > > 
> > > #
> > > # Automatically generated make config: don't edit
> > > # Linux kernel version: 2.6.25-rc2-mm1
> > > # Sat Feb 16 11:32:49 2008
> > 
> > ho hum, thanks.  I think I'll drop x86-amd-thermal-interrupt-support.patch.
> >  I don't think it's the final version anwyay.
> > 
> Ok, I had to revert x86-remove-pt_regs-arg-from-smp_thermal_interrupt before 
> x86-amd-thermal-interrupt-support.
> 
> Second error vanished when I reverted "suspend: wakeup code in C".

The appended patch should fix the second error.

Thanks,
Rafael

---
On x86-64 the CPU trampoline code is now used while waking up from ACPI
suspend to RAM.  For this reason, make it depend on
(64BIT && ACPI_SLEEP) as well as on SMP, move the relevant declarations
to a separate header and move the definition of setup_trampoline() from
smpboot_64.c .

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 arch/x86/Kconfig |2 +-
 arch/x86/kernel/acpi/sleep.c |1 -
 arch/x86/kernel/acpi/sleep.h |3 ++-
 arch/x86/kernel/e820_64.c|5 +++--
 arch/x86/kernel/setup_64.c   |   16 
 arch/x86/kernel/smpboot_64.c |   23 ++-
 include/asm-x86/smp_64.h |2 --
 include/asm-x86/trampoline.h |   18 ++
 8 files changed, 42 insertions(+), 28 deletions(-)

Index: linux-2.6.25-rc2-mm1/arch/x86/Kconfig
===
--- linux-2.6.25-rc2-mm1.orig/arch/x86/Kconfig
+++ linux-2.6.25-rc2-mm1/arch/x86/Kconfig
@@ -180,7 +180,7 @@ config X86_BIOS_REBOOT
 
 config X86_TRAMPOLINE
bool
-   depends on X86_SMP || (X86_VOYAGER && SMP)
+   depends on X86_SMP || (X86_VOYAGER && SMP) || (64BIT && ACPI_SLEEP)
default y
 
 config KTIME_SCALAR
Index: linux-2.6.25-rc2-mm1/arch/x86/kernel/e820_64.c
===
--- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/e820_64.c
+++ linux-2.6.25-rc2-mm1/arch/x86/kernel/e820_64.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct e820map e820;
 
@@ -58,8 +59,8 @@ struct early_res {
 };
 static struct early_res early_res[MAX_EARLY_RES] __initdata = {
{ 0, PAGE_SIZE, "BIOS data page" }, /* BIOS data 
page */
-#ifdef CONFIG_SMP
-   { SMP_TRAMPOLINE_BASE, SMP_TRAMPOLINE_BASE + 2*PAGE_SIZE, 
"SMP_TRAMPOLINE" },
+#ifdef CONFIG_X86_TRAMPOLINE
+   { TRAMPOLINE_BASE, TRAMPOLINE_BASE + 2 * PAGE_SIZE, "TRAMPOLINE" },
 #endif
{}
 };
Index: linux-2.6.25-rc2-mm1/arch/x86/kernel/smpboot_64.c
===
--- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/smpboot_64.c
+++ linux-2.6.25-rc2-mm1/arch/x86/kernel/smpboot_64.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Number of siblings per CPU package */
 int smp_num_siblings = 1;
@@ -96,13 +97,6 @@ EXPORT_PER_CPU_SYMBOL(cpu_sibling_map);
 DEFINE_PER_CPU(cpumask_t, cpu_core_map);
 EXPORT_PER_CPU_SYMBOL(cpu_core_map);
 
-/*
- * Trampoline 80x86 program as an array.
- */
-
-extern const unsigned char trampoline_data[];
-extern const unsigned char trampoline_end[];
-
 /* State of each CPU */
 DEFINE_PER_CPU(int, cpu_state) = { 0 };
 
@@ -127,19 +121,6 @@ struct task_struct *idle_thread_array[NR
 
 
 /*
- * Currently trivial. Write the real->protected mode
- * bootstrap into the page concerned. The caller
- * has made sure it's suitably aligned.
- */
-
-unsigned long __cpuinit setup_trampoline(void)
-{
-   void *tramp = __va(SMP_TRAMPOLINE_BASE); 
-   memcpy(tramp, trampoline_data, trampoline_end - trampoline_data);
-   return virt_to_phys(tramp);
-}
-
-/*
  * The bootstrap kernel entry code has set these up. Save them for
  * a given CPU
  */
@@ -690,7 +671,7 @@ do_rest:
Dprintk("CPU has booted.\n");
} else {
boot_error = 1;
-   if (*((volatile unsigned char 
*)phys_to_virt(SMP_TRAMPOLINE_BASE))
+   if (*((unsigned char *)phys_to_virt(TRAMPOLINE_BASE))
== 0xA5)
/* trampoline started but...? */
printk("Stuck ??\n");
Index: linux-2.6.25-rc2-mm1/include/asm-x86/smp_64.h
===
--- linux-2.6.25-rc2-mm1.orig/include/asm-x86/smp_64.h
+++ linux-2.6.25-rc2-mm1/include/asm-x86/smp_64.h
@@ -47,8 +47,6 @@ static 

Re: 2.6.25-rc2-mm1 (wakeup)

[H. Peter Anvin]

Rafael J. Wysocki wrote:

On Saturday, 16 of February 2008, Randy Dunlap wrote:

On Sat, 16 Feb 2008 00:25:22 -0800 Andrew Morton wrote:


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/

The ACPI wakeup in C patch (I think) won't build for me on x86_32
(i.e., i386 build on x86_64 system):

linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: CPU you 
selected does not support x86-64 instruction set
linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: CPU you 
selected does not support x86-64 instruction set
linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: 
-mpreferred-stack-boundary=2 is not between 4 and 12
make[4]: *** [arch/x86/kernel/acpi/realmode/wakeup.o] Error 1
make[3]: *** [arch/x86/kernel/acpi/realmode/wakeup.bin] Error 2


It compiles for me on a native i386.

Can you please give me a hint what to do to reproduce the problem?


Sounds like you're not adding -m32 to the gcc command line.

-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: 2.6.25-rc2-mm1 (wakeup)

[Rafael J. Wysocki]

On Saturday, 16 of February 2008, Randy Dunlap wrote:
> On Sat, 16 Feb 2008 00:25:22 -0800 Andrew Morton wrote:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
> 
> The ACPI wakeup in C patch (I think) won't build for me on x86_32
> (i.e., i386 build on x86_64 system):
> 
> linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: CPU you 
> selected does not support x86-64 instruction set
> linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: CPU you 
> selected does not support x86-64 instruction set
> linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/realmode/wakeup.S:0: error: 
> -mpreferred-stack-boundary=2 is not between 4 and 12
> make[4]: *** [arch/x86/kernel/acpi/realmode/wakeup.o] Error 1
> make[3]: *** [arch/x86/kernel/acpi/realmode/wakeup.bin] Error 2

It compiles for me on a native i386.

Can you please give me a hint what to do to reproduce the problem?

Rafael
--
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: USB regression (and other failures) in 2.6.2[45]*

[Andrew Buehler]

On 2/16/2008 6:11 PM, Alan Stern wrote:


On Sat, 16 Feb 2008, Andrew Buehler wrote:


For another, getting two copies of a message is no big deal --


I disagree.


Everyone has his own taste.  Obviously there's no world-wide
consensus, possibly because different people have different workflow
habits and so are affected by duplicate messages to varying extents.


I am well aware that this particular point is opinion. I have had
justifications for and arguments in favor of it in the past, but none of
them come readily to mind at the moment, except for the one gone over
briefly below.


When I receive a message sent directly to me in a discussion which
is on a list, I expect that it is because someone either considered
it important enough to warrant making certain it came to my
attention specifically, or wanted to continue the discussion but
felt that it should not continue to take place on the mailing list.



Sometimes that is the case but often it isn't.  Your expectations are
at variance with other people's behavior; you shouldn't expect
everyone else to change just to match your personal ideals.


Messages sent to my address directly are explicitly not filtered into
the folders I have set up for various mailing lists, so that if someone
does send me a "heads up" reply for a specific topic on a list to which
I am subscribed it does not get caught by the list filter and fail to
come to my attention. If a message fails to be filtered into any
mailing-list folder, then I should be able to conclude that it is
specifically intended for me, and not part of normal mailing-list
traffic. The practice of sending replies to both addresses renders this
an invalid conclusion. I do not think that it is unreasonable to expect
that conclusion to be valid.


On the other hand, I would be perfectly happy to edit your name out
of the reply list -- but since you said you aren't receiving all the
messages in this thread via the list that might not be a good thing
to do at the moment...


It's not that I'm not receiving all of this thread's messages via the
list - it's that I'm not receiving *any* of them via the list, and I
suspect that the reason is that my address is in both the To:/Cc: and
the list itself. Something is filtering it such that I do not receive
"duplicate" replies in this way, but it is doing so by filtering out the
list copy rather than the direct copy. I have seen mailing lists which
do this before, but I see no other indication that the LKML is one of
them, and I would not be in the least surprised if this turned out to be
yet one more problem with gmail.

As far as I am aware, I am seeing all messages posted to the list which
do not have me in To: or Cc:. I suspect that if a reply in this thread
were posted to the list but not sent to me, I would see it on the list.
It might be worth an experiment, but since it would increase traffic for
other list members to no purpose it is probably not worth it overall.


People on LKML who are more familiar with interrupt routing
problems might be able to offer more help.  For now, you can try
things like turning on CONFIG_USB_DEBUG, posting the output from
dmesg, posting the contents of /proc/interrupts (say before and
after a new USB device is plugged in).


In my current testing kernel, which I believe is the one with which
I captured the sole successful non-2.6.23.1 dmesg so far,
CONFIG_USB_DEBUG is on. The associated dmesg (obtained yesterday
from booting with the Flash drive connected) is attached. (The
flood of 'no version magic, tainting kernel' messages between line
600 and line 1160 are a side effect of Novell's custom environment
which I have not yet made the effort to fix; the boot scripts
attempt to detect the network card by modprobing every network
driver available until they find one which works. Here, because the
correct one fails, they wind up trying each one twice.)


The line saying:


ehci_hcd :00:1d.7: Unlink after no-IRQ?  Controller is probably
using the wrong IRQ.


is an indication that interrupt routing is indeed not working right.
Or possibly your EHCI controller isn't working.  You could try
blacklisting or unloading ehci-hcd to see if that helps.  Of course
then none of your USB devices would be able to run at high speed.


ehci-hcd is not modular in my current kernel, and if there is a way to
turn it off without its being modular I am not aware of it. I will have
to jump through a few hoops to be able to obtain a copy of the boot CD
with an updated kernel while not at work, but I will try to do so
sometime tomorrow.

In practical terms, I am frankly not especially bothered by the lack of
support for high-speed USB in Linux on this machine; the primary reason
I am interested in USB there at the moment, aside from a general
philosophy of "unsupported devices are bad and anything I can do to help
them become supported is good", is because getting it working would
allow me to easily get the necessary information out to be able to

Re: What's needed for a PCIe card to be recognized?

[Hans-Jürgen Koch]

Am Sat, 16 Feb 2008 14:39:46 -0800
schrieb Arjan van de Ven <[EMAIL PROTECTED]>:

> On Sat, 16 Feb 2008 22:59:32 +0100
> Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:
> 
> > I'm playing around with a vanilla 2.6.25-rc1, adding patches to make
> > it work on an Asus EeePC. That one has the problem that its Mini
> > PCIe WLAN module doesn't show up in lspci. That brought up a few
> > questions that I couldn't answer yet:
> > 
> > How can they "hide" a PCIe card?
> > What could be their motive to do that?
> > How can I make it appear?
> 
> 
> go to the bios, enable the wireless card. 
> 
> that did it for me ;)

It didn't for me. I tried all combinations (booting with/without WLAN
enabled, enabling WLAN through /proc with/without pciehp loaded and so
on). What kernel did you use, and which patches did you apply?

Yes, I want to make it work, but I'd really like to understand what's
going on there and what's behind it.

Thanks,
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: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?

[Chris Rankin]

[Try this again, except this time I'll force the attachment as inline text!]

Hi,

I have managed to boot 2.6.24.1 on this machine, with the NMI watchdog enabled, 
by using the
"acpi=noirq" option. (There does seem to be some unhappiness with bridge 
symlinks in sysfs,
though.)

Cheers,
Chris

Linux version 2.6.24.1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070925 (Red Hat 
4.1.2-33))
#1 SMP PREEMPT Fri Feb 8 22:41:10 GMT 2008
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 1ffeb000 (usable)
 BIOS-e820: 1ffeb000 - 1ffef000 (ACPI data)
 BIOS-e820: 1ffef000 - 1000 (reserved)
 BIOS-e820: 1000 - 2000 (ACPI NVS)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: fff8 - 0001 (reserved)
511MB LOWMEM available.
Entering add_active_range(0, 0, 131051) 0 entries of 256 used
Zone PFN ranges:
  DMA 0 -> 4096
  Normal   4096 ->   131051
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0:0 ->   131051
On node 0 totalpages: 131051
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 991 pages used for memmap
  Normal zone: 125964 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
DMI 2.3 present.
ACPI: RSDP 000F7B40, 0014 (r0 ASUS  )
ACPI: RSDT 1FFEB000, 0030 (r1 ASUS   TUSL2-C  30303031 MSFT 31313031)
ACPI: FACP 1FFEB100, 0074 (r1 ASUS   TUSL2-C  30303031 MSFT 31313031)
ACPI: DSDT 1FFEB180, 39FA (r1   ASUS TUSL2-C  1000 MSFT  10B)
ACPI: FACS 1000, 0040
ACPI: BOOT 1FFEB040, 0028 (r1 ASUS   TUSL2-C  30303031 MSFT 31313031)
ACPI: APIC 1FFEB080, 005A (r1 ASUS   TUSL2-C  30303031 MSFT 31313031)
ACPI: PM-Timer IO Port: 0xe408
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 17
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
Allocating PCI resources starting at 3000 (gap: 2000:dec0)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130028
Kernel command line: ro root=LABEL=/ nmi_watchdog=1 video=matroxfb:vesa:0x11A
console=ttyS0,115200n8 console=tty0 acpi=noirq
Found and enabled local APIC!
mapped APIC to b000 (fee0)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c035f000 soft=c035b000
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 1005.045 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
console [ttyS0] enabled
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 513484k/524204k available (1577k kernel code, 10128k reserved, 607k 
data, 196k init, 0k
highmem)
virtual kernel memory layout:
fixmap  : 0xfffb5000 - 0xf000   ( 296 kB)
vmalloc : 0xe080 - 0xfffb3000   ( 503 MB)
lowmem  : 0xc000 - 0xdffeb000   ( 511 MB)
  .init : 0xc0327000 - 0xc0358000   ( 196 kB)
  .data : 0xc028a7ca - 0xc03227c4   ( 607 kB)
  .text : 0xc010 - 0xc028a7ca   (1577 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Calibrating delay using timer specific routine.. 2011.90 BogoMIPS (lpj=4023814)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383fbff     
 

CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After all inits, caps: 0383fbff   0040  
 

Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to e000.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 9k freed
ACPI: Core revision 20070126
CPU0: Intel Pentium III (Coppermine) stepping 06
Leaving ESR disabled.
Total of 1 processors activated (2011.90 BogoMIPS).
Brought up 1 CPUs
net_namespace: 64 bytes
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf0e30, last bus=3
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S5)
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI quirk: region e400-e47f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region ec00-ec3f claimed by ICH4 GPIO
PCI: Transparent bridge - :00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: PCI 

Re: 2.6.25-rc1/2 CD/DVD burning broken

[Andreas Schwab]

Jeff Garzik <[EMAIL PROTECTED]> writes:

> Andreas Schwab wrote:
>> Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
>> changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
>> following error from wodim:
>>
>> Errno: 0 (Success), write_g1 scsi sendcmd: no error
>> CDB:  2A 00 00 00 00 00 00 00 1F 00
>> status: 0x2 (CHECK CONDITION)
>> Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
>> Sense Key: 0x5 Illegal Request, Segment 0
>> Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
>> Sense flags: Blk 0 (not valid) resid: 63488
>
> Does libata on the same hardware work?

There is no libata driver for ide-pmac.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?

[Chris Rankin]

Hi,

I have managed to boot 2.6.24.1 on this machine, with the NMI watchdog enabled, 
by using the
"acpi=noirq" option. (There does seem to be some unhappiness with bridge 
symlinks in sysfs,
though.)

Cheers,
Chris





  __
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com


LINUX-2.6.24.1
Description: 1531392240-LINUX-2.6.24.1

Re: 2.6.25-rc2-mm1: build failure (x86)

[Rafael J. Wysocki]

On Saturday, 16 of February 2008, Marcin Slusarz wrote:
> On Sat, Feb 16, 2008 at 03:09:49AM -0800, Andrew Morton wrote:
> > On Sat, 16 Feb 2008 11:59:07 +0100 Marcin Slusarz <[EMAIL PROTECTED]> wrote:
> > 
> > > arch/x86/kernel/built-in.o: In function `amd_smp_thermal_interrupt':
> > > (.text+0xe03b): undefined reference to `mce_log_therm_throt_event'

This one is easily fixed by the appended patch (whether it works is a separate
issue, though).

> > > arch/x86/kernel/built-in.o: In function `acpi_save_state_mem':
> > > (.text+0x12239): undefined reference to `setup_trampoline'
> > > 
> > > #
> > > # Automatically generated make config: don't edit
> > > # Linux kernel version: 2.6.25-rc2-mm1
> > > # Sat Feb 16 11:32:49 2008
> > 
> > ho hum, thanks.  I think I'll drop x86-amd-thermal-interrupt-support.patch.
> >  I don't think it's the final version anwyay.
> > 
> Ok, I had to revert x86-remove-pt_regs-arg-from-smp_thermal_interrupt before 
> x86-amd-thermal-interrupt-support.
> 
> Second error vanished when I reverted "suspend: wakeup code in C".

It will compile if you set CONFIG_SMP.  Working on a fix.

Thanks,
Rafael


---
 arch/x86/kernel/cpu/mcheck/mce_64.c  |4 ++--
 arch/x86/kernel/cpu/mcheck/mce_thermal.h |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

Index: linux-2.6.25-rc2-mm1/arch/x86/kernel/cpu/mcheck/mce_64.c
===
--- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/cpu/mcheck/mce_64.c
+++ linux-2.6.25-rc2-mm1/arch/x86/kernel/cpu/mcheck/mce_64.c
@@ -317,7 +317,7 @@ void do_machine_check(struct pt_regs * r
atomic_dec(_entry);
 }
 
-#ifdef CONFIG_X86_MCE_INTEL
+#ifdef CONFIG_X86_MCE
 /***
  * mce_log_therm_throt_event - Logs the thermal throttling event to mcelog
  * @cpu: The CPU on which the event occurred.
@@ -342,7 +342,7 @@ void mce_log_therm_throt_event(unsigned 
rdtscll(m.tsc);
mce_log();
 }
-#endif /* CONFIG_X86_MCE_INTEL */
+#endif /* CONFIG_X86_MCE */
 
 /*
  * Periodic polling timer for "silent" machine check errors.  If the
Index: linux-2.6.25-rc2-mm1/arch/x86/kernel/cpu/mcheck/mce_thermal.h
===
--- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/cpu/mcheck/mce_thermal.h
+++ linux-2.6.25-rc2-mm1/arch/x86/kernel/cpu/mcheck/mce_thermal.h
@@ -4,5 +4,5 @@
 typedef void (*smp_thermal_interrupt_callback_t)(void);
 extern smp_thermal_interrupt_callback_tsmp_thermal_interrupt;
 
-void mce_log_therm_throt_event(unsigned int cpu, __u64 status);
+extern void mce_log_therm_throt_event(unsigned int cpu, __u64 status);
 
--
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.24 git2/mm1: cpu_to_node mapping to non-existant nodes causing boot failure

[Mike Travis]

Mel Gorman wrote:

> If you send me patches to apply on top of 2.6.25-rc1, I'll give them a spin
> on the machine in question. Reverting didn't work out very well as there are
> too many collisions with patches that were applied later. I eventually got
> the machine booting but it only succeeds because it only brings up one core
> on each processor.  The patch, which is pretty brain damaged is below in case
> it helps you guess what the real problem is. dmesg logs are attached of the
> vanilla failure with acpi=debug and the log with the patch applied showing
> "__cpu_up: bad cpu 1" and "__cpu_up: bad cpu3" (i.e. the second cores of
> each machine).
> 

This should completely undo the change to 16 bit apic ids until we can figure
out the problem with the memory-less nodes.  I checked it on both the numa
and non-numa x86_64 box.

Thanks,
Mike
---
 arch/x86/kernel/acpi/boot.c  |2 +-
 arch/x86/kernel/apic_64.c|2 +-
 arch/x86/kernel/genapic_64.c |4 ++--
 arch/x86/kernel/mpparse_64.c |6 +++---
 arch/x86/mm/numa_64.c|2 +-
 include/asm-x86/smp_64.h |7 ---
 6 files changed, 12 insertions(+), 11 deletions(-)

--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -558,7 +558,7 @@ EXPORT_SYMBOL(acpi_map_lsapic);
 
 int acpi_unmap_lsapic(int cpu)
 {
-   per_cpu(x86_cpu_to_apicid, cpu) = -1;
+   per_cpu(x86_cpu_to_apicid, cpu) = BAD_APICID;
cpu_clear(cpu, cpu_present_map);
num_processors--;
 
--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -1180,7 +1180,7 @@ __cpuinit int apic_is_clustered_box(void
 {
int i, clusters, zeros;
unsigned id;
-   u16 *bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
+   u8 *bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
DECLARE_BITMAP(clustermap, NUM_APIC_CLUSTERS);
 
bitmap_zero(clustermap, NUM_APIC_CLUSTERS);
--- a/arch/x86/kernel/genapic_64.c
+++ b/arch/x86/kernel/genapic_64.c
@@ -25,10 +25,10 @@
 #endif
 
 /* which logical CPU number maps to which CPU (physical APIC ID) */
-u16 x86_cpu_to_apicid_init[NR_CPUS] __initdata
+u8 x86_cpu_to_apicid_init[NR_CPUS] __initdata
= { [0 ... NR_CPUS-1] = BAD_APICID };
 void *x86_cpu_to_apicid_early_ptr;
-DEFINE_PER_CPU(u16, x86_cpu_to_apicid) = BAD_APICID;
+DEFINE_PER_CPU(u8, x86_cpu_to_apicid) = BAD_APICID;
 EXPORT_PER_CPU_SYMBOL(x86_cpu_to_apicid);
 
 struct genapic __read_mostly *genapic = _flat;
--- a/arch/x86/kernel/mpparse_64.c
+++ b/arch/x86/kernel/mpparse_64.c
@@ -67,7 +67,7 @@ unsigned disabled_cpus __cpuinitdata;
 /* Bitmask of physically existing CPUs */
 physid_mask_t phys_cpu_present_map = PHYSID_MASK_NONE;
 
-u16 x86_bios_cpu_apicid_init[NR_CPUS] __initdata
+u8 x86_bios_cpu_apicid_init[NR_CPUS] __initdata
= { [0 ... NR_CPUS-1] = BAD_APICID };
 void *x86_bios_cpu_apicid_early_ptr;
 DEFINE_PER_CPU(u16, x86_bios_cpu_apicid) = BAD_APICID;
@@ -130,8 +130,8 @@ static void __cpuinit MP_processor_info(
}
/* are we being called early in kernel startup? */
if (x86_cpu_to_apicid_early_ptr) {
-   u16 *cpu_to_apicid = x86_cpu_to_apicid_early_ptr;
-   u16 *bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
+   u8 *cpu_to_apicid = x86_cpu_to_apicid_early_ptr;
+   u8 *bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
 
cpu_to_apicid[cpu] = m->mpc_apicid;
bios_cpu_apicid[cpu] = m->mpc_apicid;
--- a/arch/x86/mm/numa_64.c
+++ b/arch/x86/mm/numa_64.c
@@ -619,7 +619,7 @@ void __init init_cpu_to_node(void)
int i;
 
for (i = 0; i < NR_CPUS; i++) {
-   u16 apicid = x86_cpu_to_apicid_init[i];
+   u8 apicid = x86_cpu_to_apicid_init[i];
 
if (apicid == BAD_APICID)
continue;
--- a/include/asm-x86/smp_64.h
+++ b/include/asm-x86/smp_64.h
@@ -26,15 +26,16 @@ extern void unlock_ipi_call_lock(void);
 extern int smp_call_function_mask(cpumask_t mask, void (*func)(void *),
  void *info, int wait);
 
-extern u16 __initdata x86_cpu_to_apicid_init[];
-extern u16 __initdata x86_bios_cpu_apicid_init[];
+extern u8 __initdata x86_cpu_to_apicid_init[];
+extern u8 __initdata x86_bios_cpu_apicid_init[];
 extern void *x86_cpu_to_apicid_early_ptr;
 extern void *x86_bios_cpu_apicid_early_ptr;
+DECLARE_PER_CPU(u8, x86_cpu_to_apicid); /* physical ID */
+extern u8 bios_cpu_apicid[];
 
 DECLARE_PER_CPU(cpumask_t, cpu_sibling_map);
 DECLARE_PER_CPU(cpumask_t, cpu_core_map);
 DECLARE_PER_CPU(u16, cpu_llc_id);
-DECLARE_PER_CPU(u16, x86_cpu_to_apicid);
 DECLARE_PER_CPU(u16, x86_bios_cpu_apicid);
 
 static inline int cpu_present_to_apicid(int mps_cpu)

Re: 2.6.25-rc2: wpa_supplicant BUGs kernel in rwlock recursion

[Alessandro Suardi]

On Feb 17, 2008 12:18 AM, Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> On Feb 16, 2008 6:14 PM, Alessandro Suardi <[EMAIL PROTECTED]> wrote:
> > Feb 16 16:51:49 sandman kernel: BUG: rwlock recursion on CPU#0,
>
> Same thing here, bisected it to:
>
> commit 45b503548210fe6f23e92b856421c2a3f05fd034
> Author: Laszlo Attila Toth  balabit.hu>
> Date:   Tue Feb 12 22:42:09 2008 -0800
>
> [RTNETLINK]: Send a single notification on device state changes.
>
> The revert applies cleanly and fixes the problem.
> Rafael has more details in http://lkml.org/lkml/2008/2/15/542.

Thanks Guillaume,

  I can confirm that the revert of the rtnetlink.c changes does
  indeed fix the problem for me.

Second time in a couple of week I hit the same bugs as Rafael,
 will keep an eye on his new findings ;)

--alessandro

 "We act as though comfort and luxury were the chief requirements
   of life, when all that we need to make us really happy is
   something to be enthusiastic about."

   (Charles Kingsley)
--
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.25-rc1/2 CD/DVD burning broken

[Jeff Garzik]

Andreas Schwab wrote:

Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
following error from wodim:

Errno: 0 (Success), write_g1 scsi sendcmd: no error
CDB:  2A 00 00 00 00 00 00 00 1F 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
Sense flags: Blk 0 (not valid) 
resid: 63488


Does libata on the same hardware work?

Jeff



--
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: Compiling with 2.6.25-rc2 with binutils 2.17 fails?

[Jan Engelhardt]

On Feb 16 2008 17:27, Rob Landley wrote:
>The build does this:
>>   VDSOSYM arch/x86/vdso/vdso32-syms.lds
>> --- -   Fri Feb 15 23:38:41 2008
>> +++ arch/x86/vdso/vdso32-int80-syms.lds Fri Feb 15 23:38:41 2008
>> @@ -0,0 +1,5 @@
>> +VDSO32_PRELINK = 0x0;
>> +VDSO32_rt_sigreturn = 0x040c;
>> +VDSO32_sigreturn = 0x0400;
>> +VDSO32_vsyscall = 0x0414;
>> +VDSO32_vsyscall_eh_frame_size = 0x040;
>> make[1]: *** [arch/x86/vdso/vdso32-syms.lds] Error 1
>> make: *** [arch/x86/vdso] Error 2
>> make: *** Waiting for unfinished jobs
>
>Still trying to track down why, but it works on a toolchain built from 
>binutils 2.18 and gcc 4.1.3, but not with a toolchain from binutils 2.17 and 
>gcc 4.1.2.  And considering where it's failing...
>
>If binutils 2.18 is the only version that now builds the kernel, could we 
>update Documentaiton/Changes to say that instead of 2.12?

I have, as part of opensuse, binutils 2.17.50 and gcc 4.2.1 and that 
works fine.
--
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: Kernel oops with bluetooth usb dongle

[Thomas Gleixner]

On Sat, 16 Feb 2008, Quel Qun wrote:
> > Please also enable CONFIG_DEBUG_LIST=y, which should catch the place
> > where a list corruption happens.
>
> Thank you for the hand holding. I must admit I do not anything
> about kernel debugging.
>
> With or without nohz=off, the crashes are very similar. It looks
> like it fails to execute list_add_tail(>entry, vec), line 294
> of kernel/timer.c.

Yup, that's what I suspected. The list is corrupted:

> list_add corruption. prev->next should be next (c047e704), but was . 
> (prev=ddcca118).

> list_add corruption. prev->next should be next (c047e77c), but was 0001. 
> (prev=f644bd98).

Unfortunately we only see that the list is corrupted but not which
code caused it. This looks like something forgot to delete the timer
before freeing the datastructure which contains it.

Can you please enable CONFIG_SLUB_DEBUG=y and CONFIG_SLUB_DEBUG_ON=y
and give it another try?

If we can not catch it that way, I'll whip up a patch which points us
to the code which added the offending timer.

Thanks,

tglx
--
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.6.25-rc2] Fix double lock in do_setlink introduced by 45b503548210fe6f23e92b856421c2a3f05fd034

[Andrey Borzenkov]

[   58.097923] =
[   58.098883] [ INFO: possible recursive locking detected ]
[   58.099603] 2.6.25-rc2-1avb #1
[   58.100013] -
[   58.100672] wpa_supplicant/2682 is trying to acquire lock:
[   58.100672]  (dev_base_lock){-.--}, at: [] do_setlink+0x327/0x3
[   58.100672]
[   58.100672] but task is already holding lock:
[   58.100672]  (dev_base_lock){-.--}, at: [] do_setlink+0x310/0x3

with final effect

[   58.537509] Kernel panic - not syncing: Aiee, killing interrupt handler!

Signed-off-by: Andrey Borzenkov <[EMAIL PROTECTED]>

---

 net/core/rtnetlink.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index ecb02af..dd9e4da 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -853,7 +853,7 @@ static int do_setlink(struct net_device *dev, struct 
ifinfomsg *ifm,
if (dev->link_mode != nla_get_u8(tb[IFLA_LINKMODE])) {
write_lock_bh(_base_lock);
dev->link_mode = nla_get_u8(tb[IFLA_LINKMODE]);
-   write_lock_bh(_base_lock);
+   write_unlock_bh(_base_lock);
modified = 1;
}
}


signature.asc
Description: This is a digitally signed message part.

[PATCH] maple: add driver for Sega Dreamcast controller

[Adrian McMenamin]

Add support for the SEGA Dreamcast controller as a joystick device. Based on 
Yaegashi Takeshi's old 2.4 driver (never in mainline) with the addition of 
functioning removal (and reinsertion) code.

Signed-off-by: Adrian McMenamin <[EMAIL PROTECTED]>

--- 


diff -ruN a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
--- a/drivers/input/joystick/Kconfig2008-02-16 20:51:49.0 +
+++ b/drivers/input/joystick/Kconfig2008-02-16 21:41:52.0 +
@@ -282,4 +282,17 @@
  This option enables support for the LED which surrounds the Big X on
  XBox 360 controller.
 
+config JOYSTICK_MAPLE
+   tristate "Dreamcast control pad"
+   depends on SH_DREAMCAST
+   select MAPLE
+   help
+ Say Y here if you have a SEGA Dreamcast and want to use your
+ controller.
+
+ Most Dreamcast users will say Y.
+
+ To compile this as a module choose M here: the
+ module will be called maplecontrol.
+
 endif
diff -ruN a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
--- a/drivers/input/joystick/Makefile   2008-02-16 20:51:49.0 +
+++ b/drivers/input/joystick/Makefile   2008-02-16 21:41:52.0 +
@@ -27,5 +27,6 @@
 obj-$(CONFIG_JOYSTICK_TWIDJOY) += twidjoy.o
 obj-$(CONFIG_JOYSTICK_WARRIOR) += warrior.o
 obj-$(CONFIG_JOYSTICK_XPAD)+= xpad.o
+obj-$(CONFIG_JOYSTICK_MAPLE)   += maplecontrol.o
 
 obj-$(CONFIG_JOYSTICK_IFORCE)  += iforce/
diff -ruN a/drivers/input/joystick/maplecontrol.c 
b/drivers/input/joystick/maplecontrol.c
--- a/drivers/input/joystick/maplecontrol.c 1970-01-01 01:00:00.0 
+0100
+++ b/drivers/input/joystick/maplecontrol.c 2008-02-16 21:41:52.0 
+
@@ -0,0 +1,246 @@
+/*
+ * SEGA Dreamcast controller driver
+ * Based on drivers/usb/iforce.c
+ *
+ * Copyright Yaegashi Takeshi, 2001
+ * Porting to 2.6 by Adrian McMenamin, copyright 2008
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_AUTHOR("YAEGASHI Takeshi <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("SEGA Dreamcast controller driver");
+MODULE_LICENSE("GPL");
+
+struct dc_pad {
+   struct input_dev *dev;
+   struct maple_device *mdev;
+   int open;
+};
+
+static void dc_pad_callback_idle(struct mapleq *mq)
+{
+}
+
+static void dc_pad_callback(struct mapleq *mq)
+{
+   unsigned short buttons;
+   struct maple_device *mapledev = mq->dev;
+   struct dc_pad *pad = mapledev->private_data;
+   struct input_dev *dev = pad->dev;
+   unsigned char *res = mq->recvbuf;
+
+   buttons = ~*(unsigned short *)(res+8);
+
+   input_report_abs(dev, ABS_HAT0Y,
+(buttons & 0x0010 ? -1:0) + (buttons & 0x0020 ? 1:0));
+   input_report_abs(dev, ABS_HAT0X,
+(buttons & 0x0040 ? -1:0) + (buttons & 0x0080 ? 1:0));
+   input_report_abs(dev, ABS_HAT1Y,
+(buttons & 0x1000 ? -1:0) + (buttons & 0x2000 ? 1:0));
+   input_report_abs(dev, ABS_HAT1X,
+(buttons & 0x4000 ? -1:0) + (buttons & 0x8000 ? 1:0));
+
+   input_report_key(dev, BTN_C,  buttons & 0x0001);
+   input_report_key(dev, BTN_B,  buttons & 0x0002);
+   input_report_key(dev, BTN_A,  buttons & 0x0004);
+   input_report_key(dev, BTN_START,  buttons & 0x0008);
+   input_report_key(dev, BTN_Z,  buttons & 0x0100);
+   input_report_key(dev, BTN_Y,  buttons & 0x0200);
+   input_report_key(dev, BTN_X,  buttons & 0x0400);
+   input_report_key(dev, BTN_SELECT, buttons & 0x0800);
+
+   input_report_abs(dev, ABS_GAS,   res[10]);
+   input_report_abs(dev, ABS_BRAKE, res[11]);
+   input_report_abs(dev, ABS_X, res[12]);
+   input_report_abs(dev, ABS_Y, res[13]);
+   input_report_abs(dev, ABS_RX,res[14]);
+   input_report_abs(dev, ABS_RY,res[15]);
+}
+
+static int dc_pad_open(struct input_dev *dev)
+{
+   struct dc_pad *pad = dev->private;
+   if (!pad->open)
+   maple_getcond_callback(pad->mdev, dc_pad_callback, HZ/50,
+   MAPLE_FUNC_CONTROLLER);
+   pad->open++;
+   return 0;
+
+}
+
+static void dc_pad_close(struct input_dev *dev)
+{
+   struct dc_pad *pad = dev->private;
+
+   pad->open--;
+   if (pad->open)
+   return;
+
+   /* Almost never call something that does nothing */
+   maple_getcond_callback(pad->mdev, dc_pad_callback_idle, 0x,
+   MAPLE_FUNC_CONTROLLER);
+}
+
+static int dc_pad_connect(struct maple_device *mdev)
+{
+   int i, error;
+   unsigned long data = be32_to_cpu(mdev->devinfo.function_data[0]);
+   struct dc_pad *pad;
+   struct input_dev *dev;
+
+   const short btn_bit[32] = {
+   BTN_C, BTN_B, BTN_A, BTN_START, -1, -1, -1, -1,
+   BTN_Z, BTN_Y, BTN_X, BTN_SELECT, -1, -1, 

Compiling with 2.6.25-rc2 with binutils 2.17 fails?

[Rob Landley]

Is anybody else having trouble compiling the kernel with binutils 2.17?

The build does this:
>   VDSOSYM arch/x86/vdso/vdso32-syms.lds
> --- -   Fri Feb 15 23:38:41 2008
> +++ arch/x86/vdso/vdso32-int80-syms.lds Fri Feb 15 23:38:41 2008
> @@ -0,0 +1,5 @@
> +VDSO32_PRELINK = 0x0;
> +VDSO32_rt_sigreturn = 0x040c;
> +VDSO32_sigreturn = 0x0400;
> +VDSO32_vsyscall = 0x0414;
> +VDSO32_vsyscall_eh_frame_size = 0x040;
> make[1]: *** [arch/x86/vdso/vdso32-syms.lds] Error 1
> make: *** [arch/x86/vdso] Error 2
> make: *** Waiting for unfinished jobs

Still trying to track down why, but it works on a toolchain built from 
binutils 2.18 and gcc 4.1.3, but not with a toolchain from binutils 2.17 and 
gcc 4.1.2.  And considering where it's failing...

If binutils 2.18 is the only version that now builds the kernel, could we 
update Documentaiton/Changes to say that instead of 2.12?

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
--
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] checkpatch.pl: revert wrong --file message

[Thomas Gleixner]

On Sat, 16 Feb 2008, Andy Whitcroft wrote:
> On Sat, Feb 16, 2008 at 12:27:33PM +0200, Pekka Enberg wrote:
> > Hi,
> > 
> > On Feb 16, 2008 12:18 PM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > > People, who do cleanups - I'm not talking about running lindent here -
> > > read through the code while they fix it up.
> > >
> > > Actually they find bugs that way or at least come up with useful
> > > questions about code which is not obvious in the first place.
> > >
> > > Discouraging such cleanups with a pretty offensive warning is
> > > counterproductive.
> > 
> > Well, it's not just about cleanup patches submitted by "newbies". I
> > use checkpatch for development too and the warning is real PITA for
> > that.
> 
> The warning is suppressed on -q as its a pain indeed if one is using it
> to check files and you are not intending a single file cleanup.
> 
> Is the concensus the warning is useful, or unhelpful.

The warning is wrong and annoying. It reflects the personal opinion of
Andi and imposes it on everybody else. 

There was and is no consenus about the usefulness of such patches and
probably never will be. It's up to the maintainer of a particular
subsystem to accept or reject such patches.

It's definitely not the decision of a single kernel developer who has
his own definition of checkpatch.pl correctness:



> Please run your patches through checkpatch.pl.
> 
> ERROR: use tabs not spaces
> #48: FILE: arch/x86/kernel/alternative.c:360:

I saw a lot of these warnings, but disregarded them as obviously
silly. I don't have plans to redo all the patches for that.

http://lkml.org/lkml/2008/1/4/98>


Thanks,

tglx
--
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] maple: allow removal and reinsertion of keyboard driver module

[Adrian McMenamin]

Allow the removal (and subsequent reinsertion) of the maple_keyb (maple 
keyboard) driver by adding a working removal function.

Also tidy long lines.

Signed-off-by: Adrian McMenamin <[EMAIL PROTECTED]>

---



diff -ruN a/drivers/input/keyboard/maple_keyb.c 
b/drivers/input/keyboard/maple_keyb.c
--- a/drivers/input/keyboard/maple_keyb.c   2008-02-16 20:51:49.0 
+
+++ b/drivers/input/keyboard/maple_keyb.c   2008-02-16 21:41:52.0 
+
@@ -2,7 +2,7 @@
  * SEGA Dreamcast keyboard driver
  * Based on drivers/usb/usbkbd.c
  * Copyright YAEGASHI Takeshi, 2001
- * Porting to 2.6 Copyright Adrian McMenamin, 2007
+ * Porting to 2.6 Copyright Adrian McMenamin, 2007, 2008
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -46,39 +46,51 @@
 };
 
 static const unsigned short dc_kbd_keycode[NR_SCANCODES] = {
-   KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_A, KEY_B, 
KEY_C, KEY_D,
-   KEY_E, KEY_F, KEY_G, KEY_H, KEY_I, KEY_J, KEY_K, KEY_L,
-   KEY_M, KEY_N, KEY_O, KEY_P, KEY_Q, KEY_R, KEY_S, KEY_T,
-   KEY_U, KEY_V, KEY_W, KEY_X, KEY_Y, KEY_Z, KEY_1, KEY_2,
-   KEY_3, KEY_4, KEY_5, KEY_6, KEY_7, KEY_8, KEY_9, KEY_0,
-   KEY_ENTER, KEY_ESC, KEY_BACKSPACE, KEY_TAB, KEY_SPACE, KEY_MINUS, 
KEY_EQUAL, KEY_LEFTBRACE,
-   KEY_RIGHTBRACE, KEY_BACKSLASH, KEY_BACKSLASH, KEY_SEMICOLON, 
KEY_APOSTROPHE, KEY_GRAVE, KEY_COMMA,
-   KEY_DOT, KEY_SLASH, KEY_CAPSLOCK, KEY_F1, KEY_F2, KEY_F3, KEY_F4, 
KEY_F5, KEY_F6,
+   KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_A, KEY_B,
+   KEY_C, KEY_D, KEY_E, KEY_F, KEY_G, KEY_H, KEY_I, KEY_J, KEY_K, KEY_L,
+   KEY_M, KEY_N, KEY_O, KEY_P, KEY_Q, KEY_R, KEY_S, KEY_T, KEY_U, KEY_V,
+   KEY_W, KEY_X, KEY_Y, KEY_Z, KEY_1, KEY_2, KEY_3, KEY_4, KEY_5, KEY_6,
+   KEY_7, KEY_8, KEY_9, KEY_0, KEY_ENTER, KEY_ESC, KEY_BACKSPACE,
+   KEY_TAB, KEY_SPACE, KEY_MINUS, KEY_EQUAL, KEY_LEFTBRACE,
+   KEY_RIGHTBRACE, KEY_BACKSLASH, KEY_BACKSLASH, KEY_SEMICOLON,
+   KEY_APOSTROPHE, KEY_GRAVE, KEY_COMMA, KEY_DOT, KEY_SLASH,
+   KEY_CAPSLOCK, KEY_F1, KEY_F2, KEY_F3, KEY_F4, KEY_F5, KEY_F6,
KEY_F7, KEY_F8, KEY_F9, KEY_F10, KEY_F11, KEY_F12, KEY_SYSRQ,
-   KEY_SCROLLLOCK, KEY_PAUSE, KEY_INSERT, KEY_HOME, KEY_PAGEUP, KEY_DELETE,
-   KEY_END, KEY_PAGEDOWN, KEY_RIGHT, KEY_LEFT, KEY_DOWN, KEY_UP,
-   KEY_NUMLOCK, KEY_KPSLASH, KEY_KPASTERISK, KEY_KPMINUS, KEY_KPPLUS, 
KEY_KPENTER, KEY_KP1, KEY_KP2,
-   KEY_KP3, KEY_KP4, KEY_KP5, KEY_KP6, KEY_KP7, KEY_KP8, KEY_KP9, KEY_KP0, 
KEY_KPDOT,
-   KEY_102ND, KEY_COMPOSE, KEY_POWER, KEY_KPEQUAL, KEY_F13, KEY_F14, 
KEY_F15,
-   KEY_F16, KEY_F17, KEY_F18, KEY_F19, KEY_F20,
-   KEY_F21, KEY_F22, KEY_F23, KEY_F24, KEY_OPEN, KEY_HELP, KEY_PROPS, 
KEY_FRONT,
-   KEY_STOP, KEY_AGAIN, KEY_UNDO, KEY_CUT, KEY_COPY, KEY_PASTE, KEY_FIND, 
KEY_MUTE,
-   KEY_VOLUMEUP, KEY_VOLUMEDOWN, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, 
KEY_KPCOMMA, KEY_RESERVED, KEY_RO, KEY_KATAKANAHIRAGANA , KEY_YEN,
-   KEY_HENKAN, KEY_MUHENKAN, KEY_KPJPCOMMA, KEY_RESERVED, KEY_RESERVED, 
KEY_RESERVED,
-   KEY_HANGEUL, KEY_HANJA, KEY_KATAKANA, KEY_HIRAGANA, KEY_ZENKAKUHANKAKU, 
KEY_RESERVED, KEY_RESERVED, KEY_RESERVED,
-   KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, 
KEY_RESERVED, KEY_RESERVED, KEY_RESERVED,
-   KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, 
KEY_RESERVED, KEY_RESERVED, KEY_RESERVED,
-   KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, 
KEY_RESERVED, KEY_RESERVED, KEY_RESERVED,
-   KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, 
KEY_RESERVED, KEY_RESERVED, KEY_RESERVED,
-   KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, 
KEY_RESERVED, KEY_RESERVED, KEY_RESERVED,
-   KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, 
KEY_RESERVED, KEY_RESERVED, KEY_RESERVED,
-   KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, 
KEY_RESERVED, KEY_RESERVED, KEY_RESERVED,
-   KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, 
KEY_RESERVED, KEY_RESERVED, KEY_RESERVED,
-   KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, 
KEY_RESERVED, KEY_RESERVED, KEY_RESERVED,
-   KEY_LEFTCTRL, KEY_LEFTSHIFT, KEY_LEFTALT, KEY_LEFTMETA, KEY_RIGHTCTRL, 
KEY_RIGHTSHIFT, KEY_RIGHTALT, KEY_RIGHTMETA,
-   KEY_PLAYPAUSE, KEY_STOPCD, KEY_PREVIOUSSONG, KEY_NEXTSONG, KEY_EJECTCD, 
KEY_VOLUMEUP, KEY_VOLUMEDOWN, KEY_MUTE,
-   KEY_WWW, KEY_BACK, KEY_FORWARD, KEY_STOP, KEY_FIND, KEY_SCROLLUP, 
KEY_SCROLLDOWN, KEY_EDIT, KEY_SLEEP,
-   KEY_SCREENLOCK, KEY_REFRESH, KEY_CALC, KEY_RESERVED, KEY_RESERVED, 
KEY_RESERVED, KEY_RESERVED
+   KEY_SCROLLLOCK, KEY_PAUSE, KEY_INSERT, KEY_HOME, KEY_PAGEUP,
+   KEY_DELETE, KEY_END, 

[PATCH] maple: remove unused variable

[Adrian McMenamin]

Remove an unused variable from the definition of struct maple_device

Signed-off-by: Adrian McMenamin <[EMAIL PROTECTED]>
---

diff -ruN a/include/linux/maple.h b/include/linux/maple.h
--- a/include/linux/maple.h 2008-02-16 20:52:09.0 +
+++ b/include/linux/maple.h 2008-02-16 21:42:06.0 +
@@ -64,7 +64,6 @@
int (*connect) (struct maple_device * dev);
void (*disconnect) (struct maple_device * dev);
struct device_driver drv;
-   int registered;
 };
 


--
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.25-rc2: wpa_supplicant BUGs kernel in rwlock recursion

[Guillaume Chazarain]

On Feb 16, 2008 6:14 PM, Alessandro Suardi <[EMAIL PROTECTED]> wrote:
> Feb 16 16:51:49 sandman kernel: BUG: rwlock recursion on CPU#0,

Same thing here, bisected it to:

commit 45b503548210fe6f23e92b856421c2a3f05fd034
Author: Laszlo Attila Toth  balabit.hu>
Date:   Tue Feb 12 22:42:09 2008 -0800

[RTNETLINK]: Send a single notification on device state changes.

The revert applies cleanly and fixes the problem.
Rafael has more details in http://lkml.org/lkml/2008/2/15/542.

-- 
Guillaume
--
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: USB regression (and other failures) in 2.6.2[45]*

[Alan Stern]

On Sat, 16 Feb 2008, Andrew Buehler wrote:

> > For another, getting two copies of a message is no big deal --
> 
> I disagree.

Everyone has his own taste.  Obviously there's no world-wide consensus,
possibly because different people have different workflow habits and so
are affected by duplicate messages to varying extents.

> When I receive a message sent directly to me in a discussion which is on
> a list, I expect that it is because someone either considered it
> important enough to warrant making certain it came to my attention
> specifically, or wanted to continue the discussion but felt that it
> should not continue to take place on the mailing list.

Sometimes that is the case but often it isn't.  Your expectations are
at variance with other people's behavior; you shouldn't expect everyone
else to change just to match your personal ideals.

On the other hand, I would be perfectly happy to edit your name out of 
the reply list -- but since you said you aren't receiving all the 
messages in this thread via the list that might not be a good thing to 
do at the moment...


> > People on LKML who are more familiar with interrupt routing problems
> > might be able to offer more help.  For now, you can try things like
> > turning on CONFIG_USB_DEBUG, posting the output from dmesg, posting
> > the contents of /proc/interrupts (say before and after a new USB
> > device is plugged in).
> 
> In my current testing kernel, which I believe is the one with which I
> captured the sole successful non-2.6.23.1 dmesg so far, CONFIG_USB_DEBUG
> is on. The associated dmesg (obtained yesterday from booting with the
> Flash drive connected) is attached. (The flood of 'no version magic,
> tainting kernel' messages between line 600 and line 1160 are a side
> effect of Novell's custom environment which I have not yet made the
> effort to fix; the boot scripts attempt to detect the network card by
> modprobing every network driver available until they find one which
> works. Here, because the correct one fails, they wind up trying each one
> twice.)

The line saying:

> ehci_hcd :00:1d.7: Unlink after no-IRQ?  Controller is probably using the 
> wrong IRQ.

is an indication that interrupt routing is indeed not working right.  
Or possibly your EHCI controller isn't working.  You could try 
blacklisting or unloading ehci-hcd to see if that helps.  Of course 
then none of your USB devices would be able to run at high speed.

> I have transcribed the contents of /proc/interrupts both before and
> after plugging in the Flash drive I have been using for testing, and
> they are also attached. I have been as careful as I could to be sure
> that the contents of the attached 'r61-interrupts-[12].txt' files is the
> same as what was shown on the laptop, but cannot absolutely guarantee
> that I have not missed something. For the record, the '1' is from before
> connecting the drive, and the '2' is from after.

Notice that the interrupt count for IRQ 11 doesn't change when you plug 
in the device.  Obviously something is wrong there.

In fact, it's a little surprising that almost all the USB controllers
are routed to the same IRQ.  However this is beyond my area of 
expertise.  You could try posting a message on the linux-acpi mailing 
list; the people there should know a lot more about these issues.


> > Assuming that the 2.6.23 kernel works on your computer, you can go
> > the extreme route of installing git and doing a bisection to find the
> > first patch causing your difficulty.
> 
> That would require me to learn enough of how git works, as distinct from
> more traditional VCSes, to be able to use it with some confidence. This
> is not impossible - indeed I want to do it at some point - but for the
> time being I have no idea where to start, and indeed I am not especially
> clear on exactly what (from a user's perspective) the differences been
> git and e.g. CVS or Subversion are. I know that the entire concept
> relies around a lack of centralization, but I have not been able to get
> my head around what that means in a practical sense.

There are some excellent tutorials on the web, with detailed
explanations of how to do a bisection to track down a kernel bug.

Alan Stern

--
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] checkpatch.pl: revert wrong --file message

[Andy Whitcroft]

On Sat, Feb 16, 2008 at 12:27:33PM +0200, Pekka Enberg wrote:
> Hi,
> 
> On Feb 16, 2008 12:18 PM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > People, who do cleanups - I'm not talking about running lindent here -
> > read through the code while they fix it up.
> >
> > Actually they find bugs that way or at least come up with useful
> > questions about code which is not obvious in the first place.
> >
> > Discouraging such cleanups with a pretty offensive warning is
> > counterproductive.
> 
> Well, it's not just about cleanup patches submitted by "newbies". I
> use checkpatch for development too and the warning is real PITA for
> that.

The warning is suppressed on -q as its a pain indeed if one is using it
to check files and you are not intending a single file cleanup.

Is the concensus the warning is useful, or unhelpful.

-apw
--
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/