Update spufs to the new linux kernel markers API, which supports connecting more than one probe to a single marker. (compile-tested only) Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Christoph Hellwig <hch@infradead.org> CC: "Frank Ch. Eigler" <fche@redhat.com> CC: Steven Rostedt <rostedt@goodmis.org> CC: Andrew Morton <akpm@linux-foundation.org> --- arch/powerpc/platforms/cell/spufs/sputrace.c | 31 +++++++++------------------ 1 file changed, 11 insertions(+), ...

Hi all, I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day. Unfortunately, I didn't get very far very fast, as the domain just crashed immediately upon booting, without any direct feedback (I did have messages on the xen message buffer, which helped). This even with earlyprintk turned on. After a long, arduous journey, I managed to track this down to the following: ---------- commit 551889a6e2a24a9c06fd453ea03b57b7746ffdc0 x86: construct 32-bit boot time page tables ...

Sure, it certainly is. The bug has been breaking suspend on people's boxes already. Thanks, --

ACK. AFAICT this is 2.6.25 material. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

From: Marcin Slusarz <marcin.slusarz@gmail.com> replace all: big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) + expression_in_cpu_byteorder); with: beX_add_cpu(&big_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: David S. Miller <davem@davemloft.net> --- crypto/lrw.c | 2 +- 1 files changed, 1 insertions(+), 1 ...

From: Marcin Slusarz <marcin.slusarz@gmail.com> replace all: big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) + expression_in_cpu_byteorder); with: beX_add_cpu(&big_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Roman Zippel <zippel@linux-m68k.org> --- fs/hfs/mdb.c | 2 +- fs/hfsplus/super.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git ...

From: Marcin Slusarz <marcin.slusarz@gmail.com> Hi This patchset converts big/little_endian_variable = cpu_to_[bl]eX([bl]eX_to_cpu(big/little_endian_variable) + expression_in_cpu_byteorder); to: [bl]eX_add_cpu(&big/little_endian_variable, expression_in_cpu_byteorder); All patches were generated by spatch, then reviewed and fixed to follow coding style. Semantic patch: @@ expression *X; expression Y; @@ ( - *X = cpu_to_le64(le64_to_cpu(*X) + Y); + le64_add_cpu(X, Y); | - ...

From: Marcin Slusarz <marcin.slusarz@gmail.com> replace all: big/little_endian_variable = cpu_to_[bl]eX([bl]eX_to_cpu(big/little_endian_variable) + expression_in_cpu_byteorder); with: [bl]eX_add_cpu(&big/little_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Christoph Hellwig <hch@infradead.org> --- fs/sysv/sysv.h | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git ...

From: Marcin Slusarz <marcin.slusarz@gmail.com> replace all: little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) + expression_in_cpu_byteorder); with: leX_add_cpu(&little_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: linux-ext4@vger.kernel.org --- fs/ext2/ialloc.c | 12 ++++-------- fs/ext2/super.c | 2 +- fs/ext2/xattr.c | 9 +++------ 3 files changed, 8 ...

From: Marcin Slusarz <marcin.slusarz@gmail.com> replace all: little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) + expression_in_cpu_byteorder); with: leX_add_cpu(&little_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Jan Kara <jack@suse.cz> --- fs/quota_v2.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/quota_v2.c b/fs/quota_v2.c index ...

From: Marcin Slusarz <marcin.slusarz@gmail.com> replace all: big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) + expression_in_cpu_byteorder); with: beX_add_cpu(&big_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Ben Collins <ben.collins@ubuntu.com> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> --- drivers/ieee1394/csr.c | 6 ++---- 1 files changed, 2 insertions(+), 4 ...

From: Marcin Slusarz <marcin.slusarz@gmail.com> replace all: big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) + expression_in_cpu_byteorder); with: beX_add_cpu(&big_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Steven Whitehouse <swhiteho@redhat.com> Cc: cluster-devel@redhat.com --- fs/gfs2/dir.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git ...

From: Marcin Slusarz <marcin.slusarz@gmail.com> replace all: little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) + expression_in_cpu_byteorder); with: leX_add_cpu(&little_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: linux-scsi@vger.kernel.org Cc: aacraid@adaptec.com Cc: James.Bottomley@HansenPartnership.com --- drivers/scsi/aacraid/commsup.c | 2 +- ...

Two pairs of parenthesis were missing around the result cast of cmpxchg64 and cmpxchg64_local. This is a rather stupid mistake in "Cast cmpxchg and cmpxchg_local result for 386 and 486". My bad. This fix should be folded with the previous. Sorry for this trivial bug which should have never appeared in the first place. The aim was to fix cmpxchg and cmpxchg_local, which were used in slub. cmpxchg64 and cmpxchg64_local happen to be only used in LTTng currently. Signed-off-by: Mathieu Desnoyers ...

From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Introduce new proc interface for RTTIME watchdog. It makes administrator able to set RTTIME watchdog to existing real-time applications without impact. $ echo 10000000 > /proc/<pid>/rttime set RTTIME current value to 10000000, it means 10sec. $ echo "10000000 20000000" > /proc/<pid>/rttime set RTTIME current value to 10000000 and max value to 20000000. And /proc/<pid>/task/<tid>/rttime is also accessible. Signed-off-by: Hiroshi ...

There are at least two known suspend regressions, one of which affects the T61 for sure. There's a fix for it, available at: http://lkml.org/lkml/2008/2/11/472 The fix for the second issue is in the works. --

RDMA/cxgb3: Fail loopback connections. The cxgb3 HW and driver don't support loopback RDMA connections. So fail any connection attempt where the destination address is local. Signed-off-by: Steve Wise <swise@opengridcomputing.com> --- drivers/infiniband/hw/cxgb3/iwch_cm.c | 16 ++++++++++++++++ 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c b/drivers/infiniband/hw/cxgb3/iwch_cm.c index e9a08fa..5d82723 100644 --- ...

--

Hi, Is it a known problem? Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1 E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in e1000e). Don't work by default. "pci=nomsi" fixes the problem. 82572EI Gigabit Ethernet Controller (Copper) (rev 06) Subsystem: PRO/1000 PT Desktop Adapter (8086:10b9 subsystem 8086:1083) grep eth0 /proc/interrupts 20: 1945 1 IO-APIC-fasteoi eth0 (without "pci=nomsi": 221: 0 0 ...

Not quite, at least I can't find 2.6.23.y there, even though that branch seems to be maintained... -- Thanks, Feri. --

and 2.6.22.y too -- Thanks, Oliver --

Hi, The answer is at http://kernel.org/ You're welcome, Xav --

When Willy go in 2.6.22.y, then I help it, so far as I 'm possible. -- Thanks, Oliver --

Hi, Looking at http://lxr.linux.no/linux/lib/vsprintf.c#L549 (where vsnprintf in linux/lib/vsprintf.c parses the % format specifier) suggests that the printk format string in http://lxr.linux.no/linux/drivers/ide/setup-pci.c#L657 is correct: printk(KERN_INFO "%s: not 100%% native mode: " "will probe irqs later\n", d->name); Still, in my kern.log the percent sign is doubled: ICH4: not 100%% native mode: will probe irqs later Why? -- Regards, Feri. (Please Cc: ...

From code review the EFI memory map handling has a couple of problems: - The test for _WB memory was reversed so it would set cache able memory to uncached - It would always set a wrong uninitialized zero address to uncached (so I suspect it always set the first few pages in phys memory to uncached, that is why it may have gone unnoticed) - It would call set_memory_x() on a fixmap address that it doesn't handle correctly. - Some other problems I commented in the code (but was unable to ...

Hello, While copying between two DOS-partitions, my screen went haywire saying=20 I found a kernel bug. Since no hits on google when searching for kernel BUG at fs/mpage.c:489! I decided to let you know. Some notes that might be relevant: * I composed the bios out of the original from my asus a7v-133 and some=20 stuff from ECS L7VTA * /dev/hde is on Promise FastTrak "Lite" PDC20265R * I do not use (fake)RAID; I only use it as an extra IDE controller * /dev/hde is old; Seems that it ...

The stack trace I copied down originally was for a 2.6.24 kernel. I can copy down the one .25-pre if that'd be useful, but it sounds like you're reproduced it on your own. (I'm raising the priority of this bug report since it sounds like it affects more than just my hardware.) --=20 see shy jo

well we have no automated way to do so as we are underpowered in terms of bug nrs, it is routine to ask to file upstream. the debian kernel does not carry any x86 specific patch. also it is often much easier if upstream speaks directly sure, ack. so i'll circumvent bugzilla and add the new x86 maintainers on cc to let them know about the 2.6.24 and 2.6.25-rc1 boot error on shiny fujitsu p700 lifebook, with a Crusoe processor. http://bugs.debian.org/464962 686 config attached.

Thought some more about this, and since this probably means gcc will generate this for userspace code as well nowadays, tm5800 should probably be downgraded to a 586-class machine. Hence the Linux policy of promoting it to a 686-class machine for having CMOV is actually incorrect, it doesn't have all the userspace-visible features of a 686-class machine, lacking long NOP. -hpa

Okay, the faulting instruction is the following: c0383360: 0f 1f 40 00 nopl 0x0(%eax) The Crusoe code morphing software apparently doesn't recognize these "long noops", and (presumably) the rest of the hinting NOOP group. gcc didn't use to generate them, and Crusoe/Efficeon generally do not benefit from code alignment anyway. I suspect the best thing to do is to use either a 586 kernel or build a dedicated Crusoe kernel without code alignment. -hpa --

Are you sure that build matches the bug report? The EIP given falls inside the .data segment of that kernel, specifically inside the symbol init_task. -hpa --

Add information about the mapping state of the direct mapping to /proc/meminfo. This way we can see how many large pages are really used for it. [Note this version depends on the gbpages patch in git-x86#mm; but it can be applied without it too by dropping the one hunk that rejects] v2: fix a compiler warning Signed-off-by: Andi Kleen <ak@suse.de> --- arch/x86/mm/init_32.c | 2 ++ arch/x86/mm/init_64.c | 2 ++ arch/x86/mm/pageattr.c | 23 ...

Hello list. Seeking feedback for this patch which adds support for the "fn" key on the new macbook (3,1) and apple aluminum keyboard. I have tested this with kernel 2.6.23 (both 2.6.23.9 and 2.6.23.15) under Fedora 8 and it seems to work for me. The original patch was created by Martin Szulecki (of mactel-linux) and Chris Irwin. I can't take any credit - I've just found that it works and would like to see it tested and committed upstream if possible. I am linking to the patch ...

This is similar to what Mathieu once posted: http://lkml.org/lkml/2007/7/11/13 Not sure the arguments against (no time to read the thread again). But I'd recommend that you read it. -- Steve --

Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- kernel/kthread.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/kernel/kthread.c b/kernel/kthread.c index dcfe724..b193b47 100644 --- a/kernel/kthread.c +++ b/kernel/kthread.c @@ -170,6 +170,7 @@ void kthread_bind(struct task_struct *k, unsigned int cpu) wait_task_inactive(k); set_task_cpu(k, cpu); k->cpus_allowed = cpumask_of_cpu(cpu); + k->nr_cpus_allowed = 1; } EXPORT_SYMBOL(kthread_bind); ...

Hi Ingo, Steven, I had been working on some ideas related to saving context switches in the bottom-half mechanisms on -rt. So far, the ideas have been a flop, but a few peripheral technologies did come out of it. This series is one such idea that I thought might have some merit on its own. The header-comments describe it in detail, so I wont bother replicating that here. This series applies to 24-rt1. Any comments/feedback welcome. -Greg --

From: Johann Felix Soden <johfel@users.sourceforge.net> If the initrd file has zero-length, the error message should contain the filepath. Cc: WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by: Johann Felix Soden <johfel@users.sourceforge.net> Signed-off-by: Jeff Dike <jdike@linux.intel.com> --- arch/um/kernel/initrd.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Index: ...

The macros which extract registers from a struct sigcontext are no longer needed and can be removed. They are starting not to build anyway, given the removal of the 'e' and 'r' from register names during the x86 merge. Cc: Jiri Olsa <olsajiri@gmail.com> Signed-off-by: Jeff Dike <jdike@linux.intel.com> --- arch/um/sys-i386/user-offsets.c | 27 --------------------------- arch/um/sys-x86_64/user-offsets.c | 28 ---------------------------- 2 files changed, 55 deletions(-) Index: ...

Hi Ingo, I've been running the latest sched-git through some tests. Here is essentially what I am doing, 1. Mount the control group 2. Create 3-4 groups 3. Start kernbench inside each group 4. Run cpu hogs in each group Essentially the idea is to see how the system responds under extreme CPU load. This is what I get (and this is in a shell which belongs to the root group) [root@llm11 ~]# time sleep 1 real 0m1.212s user 0m0.004s sys 0m0.000s [root@llm11 ~]# time sleep ...

On Tue, 12 Feb 2008 19:50:12 +0100 the patch works fine for me. Linus, can we please get this merged into .25? it will at least again limit the damage exploits like the vmsplice one can do.. (I think it's also worth it for -stable) --

I will prepare it for my next -fix round. Due in a few days. Sam --

This is a driver for the MMC controller on the AP7000 chips from Atmel. It should in theory work on AT91 systems too with some tweaking, but since the DMA interface is quite different, it's not entirely clear if it's worth it. This driver has been around for a while in BSPs and kernel sources provided by Atmel, but this particular version uses the generic DMA Engine framework (with the slave extensions) instead of an avr32-only DMA controller framework. This driver can also use PIO transfers ...

I suggested something similar here: Adrian had concerns about users enabling NET_DMA when the hardware -- Dan --

This moves the code checking if a DMA channel is in use from show_in_use() into an inline helper function, dma_is_in_use(). DMA controllers can use this in order to give clients exclusive access to channels (usually necessary when setting up slave DMA.) I have to admit that I don't really understand the channel refcounting logic at all... dma_chan_get() simply increments a per-cpu value. How can we be sure that whatever CPU calls dma_chan_is_in_use() sees the same value? Signed-off-by: ...

This patch adds the necessary interfaces to the DMA Engine framework to use functionality found on most embedded DMA controllers: DMA from and to I/O registers with hardware handshaking. In this context, hardware hanshaking means that the peripheral that owns the I/O registers in question is able to tell the DMA controller when more data is available for reading, or when there is room for more data to be written. This usually happens internally on the chip, but these signals may also be ...

On Tue, 12 Feb 2008 14:43:30 -0600 Agree. I'll cook up a patch tomorrow to make it use the new HAVE_* It used to be always available, but then it was changed. Assuming there was a reason for this change, I guess we don't want to change it back. Haavard --

Hi, This change causes attached drives to no longer be detected and function on the PowerPC Buffalo Linkstation machines: <7>pata_sil680 0000:00:0c.0: version 0.4.8 <6>sil680: 133MHz clock. <6>scsi0 : pata_sil680 <6>scsi1 : pata_sil680 <6>ata1: PATA max UDMA/133 irq 18 <6>ata2: PATA max UDMA/133 irq 18 If I roll back this driver to before this change with 2.6.24.2 it works: <7>pata_sil680 0000:00:0c.0: version 0.4.7 <6>sil680: 133MHz clock. <6>scsi0 : pata_sil680 <6>scsi1 : ...

Did anyone fix all the mmio posting bugs in libata-core that were pointed out when I originally NAKked using MMIO, or did they just add the driver. If the latter then you need to grep the various fix this notes in libata-core around reset/probe of an SFF controller in particular. --

From: Pierre Peiffer <pierre.peiffer@bull.net> The IPC_SET command performs the same permission setting for all IPCs. This patch introduces a common ipc_update_perm() function to update these permissions and makes use of it for all IPCs. Signed-off-by: Pierre Peiffer <pierre.peiffer@bull.net> Acked-by: Serge Hallyn <serue@us.ibm.com> --- ipc/msg.c | 5 +---- ipc/sem.c | 5 +---- ipc/shm.c | 5 +---- ipc/util.c | 13 +++++++++++++ ipc/util.h | 1 + 5 files changed, 17 ...

From: Pierre Peiffer <pierre.peiffer@bull.net> semctl_down() takes one unused parameter: semnum. This patch proposes to get rid of it. Signed-off-by: Pierre Peiffer <pierre.peiffer@bull.net> Acked-by: Serge Hallyn <serue@us.ibm.com> --- ipc/sem.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: b/ipc/sem.c =================================================================== --- a/ipc/sem.c +++ b/ipc/sem.c @@ -880,8 +880,8 @@ static inline unsigned long ...

From: Pierre Peiffer <pierre.peiffer@bull.net> Currently, sys_msgctl is not easy to read. This patch tries to improve that by introducing the msgctl_down function to handle all commands requiring the rwmutex to be taken in write mode (ie IPC_SET and IPC_RMID for now). It is the equivalent function of semctl_down for message queues. This greatly changes the readability of sys_msgctl and also harmonizes the way these commands are handled among all IPCs. Signed-off-by: Pierre Peiffer ...

From: Pierre Peiffer <pierre.peiffer@bull.net> Trivial patch which adds some small locking functions and makes use of them to factorize some part of the code and to make it cleaner. Signed-off-by: Pierre Peiffer <pierre.peiffer@bull.net> Acked-by: Serge Hallyn <serue@us.ibm.com> --- ipc/sem.c | 61 +++++++++++++++++++++++++++++++------------------------------ 1 file changed, 31 insertions(+), 30 deletions(-) Index: ...

How's about renaming flag defines to PC_FLAG_* at the same time (like it was done for other ATAPI drivers)? Otherwise looks good. --

The declaration of dmi helper functions is a bit messy and inconsistent at the moment: * On ia64 they are declared in <asm/io.h>. * On x86-64 they are declared in <asm/dmi.h>. * On i386 they are declared both in <asm/io.h> and <asm/dmi.h>. Fix the header files so that the dmi helper functions are consistently defined in <asm/dmi.h>. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Matt Domsch <Matt_Domsch@dell.com> --- Only tested on i386 and x86-64, maybe Matt can test on ia64? ...

Hi Bart, here's a first go at converting ide-floppy to using rq->cmd for packet commands. The code below is pretty rough and from what i can tell needs to be hammered a lot more, for it raises a lot of issues: 1. The command control (pc->callback, request type, etc) is still done using the pc pointer passed to all the functions prior to issuing the command. This, imho, can be done a lot cleaner and easier. What is the rationale here, do we want ide_atapi_pc removed in the long run and get by ...

applied --

This can't be correct without a matching put in the error leg. The difference between the two APIs is that pci_get_device returns a pci_device with a reference taken and pci_find_device doesn't. However, pci_get_device does drop the reference again so as long as you never exit the loop until it returns NULL, it is OK ... it's the exits before pci_get_device() returns NULL that need the put. James --

Fix compilation warning in drivers/scsi/gdth.c, using deprecated pci_find_device. Change it into using pci_get_device instead: drivers/scsi/gdth.c:645: warning: 'pci_find_device' is deprecated (declared at include/linux/pci.h:495) Signed-off-by: Sergio Luis <sergio@larces.uece.br> gdth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -urN linux-2.6.25-rc1-git2.orig/drivers/scsi/gdth.c linux-2.6.25-rc1-git2/drivers/scsi/gdth.c --- ...

Hi all, I'm stuck in a weird situation: I'm unable to go beyond 2.6.23.14, so to fix the splice bug I've had to apply by hand the patch. (x86_64) Basically, with 2.6.24.2 (the same with 2.6.24 and .1), tha machine won't boot due to a problem with cciss driver, that prevents to find the / partition. (bug described here: Kernel Bug Tracker Bug 9859 http://bugzilla.kernel.org/show_bug.cgi?id=9859 ); With kernels 2.6.23, the lastest that I can compile is 2.6.23.14; starting from .15 (and ...

OK, quite easy to reproduce when CONFIG_PM=n. For a temp quick fix, you could enable CONFIG_PM. Len, Rafael: were there any recent patches for the split of ACPI & PM that need to be backported to -stable? Thanks. --- ~Randy --

Not that I know of. Actually, ACPI still depends on PM (in the current mainline as well as in .23.x). Thanks, Rafael --

I'm getting this during bootup: PM: Adding info for No Bus:event6 PM: Adding info for No Bus:uinput PM: Adding info for No Bus:rtc0 proc_dir_entry 'rtc' already registered Pid: 1, comm: swapper Not tainted 2.6.25-rc1 #125 [<c02ac4e0>] proc_register+0xd0/0x150 [<c02ac65f>] create_proc_entry+0x4f/0xb0 [<c055f38e>] rtc_proc_add_device+0x1e/0x40 [<c055e268>] rtc_device_register+0x1d8/0x210 [<c055fc36>] cmos_do_probe+0x126/0x330 [<c03df585>] compare_pnp_id+0x25/0xc0 [<c03df6bf>] ...

Hi Jörn, OK, I can do that. Would the "simple" fix go to the Well, yes that raised a concern to me, the "exit" function returns "void". If the del_mtd_device fails with EBUSY at the moment (such as when a /dev/mtdblock<x> is mounted), we ignore it and go on with freeing everything leaving a dangling mtd. Is there a way around that? Another problem is that it's not easy to check whether a mtd creation was successful or not. Basically, you have to write to a /sys file and then parse ...

ELF_CORE_EFLAGS is already used by the binfmt_elf coredumper to set correct arch specific ELF header flags on coredumps. Use it for kcore aswell. This corrects kcore files for the CRIS arch and I beleive it corrects ordinary coredumps for the H8/300. Signed-off-by: Edgar E. Iglesias <edgar@axis.com> --- diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c index e78c81f..c2370c7 100644 --- a/fs/proc/kcore.c +++ b/fs/proc/kcore.c @@ -23,6 +23,10 @@ #define CORE_STR "CORE" +#ifndef ...

Uhm,.. seems I forgot to refresh after removing the debug info.. :-) --

[This is a replacement for the direct mapping protections patchkit from last week. It is simpler by implementing its own specialized duplicated logic instead of adapting the existing pageattr logic to be usable for this case] The i386 direct mapping support needs to avoid setting NX on pages that are used by the kernel text. This patch improves the checks for that case. - Check the correct range of kernel text not including data only sections at the end. - Check the beginning too ...

Fix following warnings: WARNING: drivers/video/built-in.o(.text+0x7c64a): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/video/built-in.o(.text+0x7c65d): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/video/built-in.o(.text+0x7c679): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: ...

Sorry for the repeated emails. Kindly ignore the previous resend. Please review this instead. Thanks. I have tested this. [PATCH 2/2] mm: various cleanups in get_user_pages() This patch contains various cleanups, including making sure vma is valid, and the return value of follow_hugetlb_page() is validated. Signed-off-by: Eugene Teo <eugeneteo@kernel.sg> --- mm/memory.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/mm/memory.c ...

This patch contains various cleanups, including making sure vma is valid, and the return value of follow_hugetlb_page() is validated. Signed-off-by: Eugene Teo <eugeneteo@kernel.sg> --- mm/memory.c | 26 ++++++++++++++++++-------- 1 files changed, 18 insertions(+), 8 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index 54f951b..49403a8 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1003,7 +1003,9 @@ int get_user_pages(struct task_struct *tsk, struct mm_struct *mm, unsigned int ...

any limitation about size of /initrd.img that saved by populate_rootfs ? i got RAMDISK: Compressed image found at block 0 RAMDISK: incomplete write (-28 != 2048) 134217728 crc error VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 388k freed init_special_inode: bogus i_mode (177777) Warning: unable to open an initial console. init_special_inode: bogus i_mode (177777) init_special_inode: bogus i_mode (177777) Kernel panic - not syncing: No init found. Try passing init= ...

Hi Sam, Le Tue, 12 Feb 2008 14:04:28 +0100, Oops, my usual "find . -name Kconfig" missed it. Thanks for pointing it Doesn't seem so: there's only a doublefault_32.c, no doublefault_64.c. However, I don't know the details of x86_64. Thanks, Thomas --=20 Thomas Petazzoni, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than 1500 pages!)

The fact that you didn't have to add any makefile bits should have been I bet there's some doublefault-handling code hiding somewhere. It's not the sort of thing it'd make sense to take out of the architecture. -- Mathematics is the supreme nostalgia of our time. --

Two callers for send_signal() - the specific_send_sig_info and the __group_send_sig_info - both check for sig to be ignored or already queued. Move these checks into send_signal() and make it return 1 to indicate that the signal is dropped, but there's no error in this. Besides, merge comments and spell-check them. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> --- kernel/signal.c | 37 +++++++++++++++---------------------- 1 files changed, 15 insertions(+), 22 ...

This function doesn't change the ret's value and thus always returns 0, with a single exception of returning -EAGAIN explicitly. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> --- kernel/signal.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/kernel/signal.c b/kernel/signal.c index cc45a6b..21d4751 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -661,7 +661,6 @@ static int send_signal(int sig, struct siginfo *info, struct task_struct *t, struct ...

Signed-off-by: Liam Girdwood <liam.girdwood@wolfsonmicro.com> Signed-off-by: Graeme Gregory <gg@opensource.wolfsonmicro.com> Signed-off-by: Mike Arthur <mike.arthur@wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Dmitry Baryshkov <dbaryshkov@gmail.com> Cc: Stanley Cai <stanley.cai@intel.com> Cc: Rodolfo Giometti <giometti@enneenne.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: Pete MacKay ...

This patch series adds support for the touchscreen controllers provided by Wolfson Microelectronics WM97xx series chips in both polled and streaming modes. These drivers have been maintained out of tree since 2003. During that time the driver the primary maintainer was Liam Girdwood and a number of people have made contributions including Stanley Cai, Rodolfo Giometti, Russell King, Marc Kleine-Budde, Ian Molton, Vincent Sanders, Andrew Zabolotny, Graeme Gregory, Mike Arthur and myself. ...

Signed-off-by: Liam Girdwood <liam.girdwood@wolfsonmicro.com> Signed-off-by: Graeme Gregory <gg@opensource.wolfsonmicro.com> Signed-off-by: Mike Arthur <mike.arthur@wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Dmitry Baryshkov <dbaryshkov@gmail.com> Cc: Stanley Cai <stanley.cai@intel.com> Cc: Rodolfo Giometti <giometti@enneenne.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: Pete MacKay ...

Wrong ... the meaning of that flag is: *THIS* system is a Linux-USB OTG device which came up in B-peripheral role, and then through the magic of HNP morphed into the B-host role. Linux is acting as a host at that point. So either it's being the A-host, or the B-host. That flag says which. If the other device has the A-connector, yet we're the B-host, then right now it is acting as an A-peripheral. That's Again wrong ... if the host side's b_hnp_enable flag is set, that means this is a ...

I see no sarcasm there. People seem to want different degrees of handholding when being told they're wrong. First time gently, second time less so ... I think there are limits to how long you can realistically expect someone (in this case, me) to let that drag on. (You object to "magic"? Most LKML readers know squat about OTG, Why not? The B-host can't proceed in that case. The mechanism for not-proceeding is inside this: if (!is_targeted(udev)) { if ...

True, but allowing hnp nowing we're b_host doesn't sound correct. If we're b_host it can get two scenarios we would get to fall into this state: 1. We asked to become host; or 2. A_device allowed us become host because it can't handle us. In both cases, HNP is quite useless happening again, don't you think? We should at least try to enumerate a_peripheral, if it can't due to our power capabilities i.e. 100mA, we'll fall into overcurrent protection and we'll suspend the bus and ...

Linus, please pull from git://git.infradead.org/~dedekind/ubi-2.6.git master to receive few UBI updates and fixes. Artem Bityutskiy (2): Documentation: add UBI sysfs ABI docs UBI: be verbose when debuggin is enabled S.Çağlar Onur (1): UBI: silence warning Documentation/ABI/stable/sysfs-class-ubi | 212 ++++++++++++++++++++++++++++++ drivers/mtd/ubi/debug.h | 2 + drivers/mtd/ubi/io.c | 4 + drivers/mtd/ubi/vmt.c ...

^^^^ Hi, can please you test this with a more recent kernel. Yours is almost ancient - from Sep. 2006. Thanks. -- Regards/Gruß, Boris. --

Hi, Enclosed patch is an updated version, with proper credits to Matt Mackall and the Linux Tiny project. Sincerly, Thomas --- Turn CONFIG_DMI into a selectable option if EMBEDDED is defined, in order to be able to remove the DMI table scanning code if it's not needed, and then reduce the kernel code size. With CONFIG_DMI (i.e before) : text data bss dec hex filename 1076076 128656 98304 1303036 13e1fc vmlinux Without CONFIG_DMI (i.e after) : text ...

Thanks for working on this. Acked-by: Matt Mackall <mpm@selenic.com> -- Mathematics is the supreme nostalgia of our time. --

Bonjour Since kernel-2.6.24 i cannot connect to internet networking process is not ok ; avahi bad the problem for me in only with Amd64 processor with Dell laptop and pentium4m kernel-2.6.24 and avahi service is ok i sent you syslog 2.6.24.1 and syslog and syslog-2.6.23.14 thanks for back please Roger --

make the intended lines aligned in the output (not in the code) Signed-off-by: Uwe Kleine-K

On Tue, 12 Feb 2008 09:23:17 +0100 What is the network card (lspci) and network settings. -- Stephen Hemminger <stephen.hemminger@vyatta.com> --

What are the general functionalities of net/ipv4/tunnel4.c and net/ipv4/ipip.c? Are these modules necessary and compulsory to implement IPsec by Linux kernel? I mean if I do not load them I can not make IPsec , layer 3 between two points of a network? ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs --

Added linux-scsi for the SCSI ones I think this was fixed by commit e2d435ea4084022ab88efa74214accb45b1f9e92 Apparently bugzilla email is on the fritz again because this bug report This one looks like the usual problem of remove re-add with the SCSI Since this one never apparently worked it's not a regression but an enhancement request, isn't it? However, adding this PCI ID to the driver should be fairly straightforward. Does anyone know what the actual PCI IDs are? James --

My suggestion is that since the parameters are: a. divide the symbols into two group: well-documented vs undocumented (prefixed by "__" eg, __xxxx). this supposedly for sysadmin vs kernel developer. b. for each of the official documented /sys control, provide a one-line description when passed via /sys/help (eg, echo kstack_depth_to_print > /sys/help) and the helpstring will go to the console. On the other hand, this may potentially blow up the vmlinux image size. --

I have it queued up, along with quite a few other things, but for the next couple of days I have logistical problems which are preventing me from doing runtime testing. --

I misread what you meant with the word "from". But my point is still that this is not a regression in the kernel but a problem when using gcc 4.2 on powerpc (no matter whether the kernel or gcc is wrong in this case). Or am I wrong here and you are able to compile older powerpc kernels cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. ...

And this really isn't a regression. It seems Kamalesh has upgraded his gcc to 4.2 between trying 2.6.24-git18 and trying 2.6.25-rc1-git1? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --

this call_for_each_cic/radix_tree_gang_lookup locked up, and all other CPUs deadlocked in stopmachine, due to this one. call_for_each_cic is in ./block/cfq-iosched.c uses RCU, but you've got classic-RCU: CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set so it's not related to the preempt-RCU changes either. It is this part that locks up: do { ... nr = radix_tree_gang_lookup(&ioc->radix_root, (void **) cics, ...

At Tue, 12 Feb 2008 16:06:16 +0900, The patch already presents on ALSA tree. http://lkml.org/lkml/2008/2/11/298 thanks, Takashi --

Maye it's just a lousy error message from distcc for a real failure from ld. I dunno. --

ok - but it never occured before. Ingo --

i've got a build log from a weird build error below: LD init/built-in.o distcc[12023] ERROR: compile (null) on localhost failed make: *** [vmlinux.o] Error 1 make: *** Waiting for unfinished jobs.... LD .tmp_vmlinux1 but there's no actual error visible in the logs. On a second attempt, it built just fine. (unfortunately erasing most evidence of the previous failure.) This happened after a rather long randconfig build series so i doubt it's readily reprodicible. any ...

Use tabs instead of spaces. Signed-off-by: Greg Ungerer <gerg@uclinux.org> --- diff -Naurp linux-2.6.25-rc1/include/asm-m68knommu/cacheflush.h linux-2.6.x/include/asm-m68knommu/cacheflush.h --- linux-2.6.25-rc1/include/asm-m68knommu/cacheflush.h 2008-02-11 14:50:23.000000000 +1000 +++ linux-2.6.x/include/asm-m68knommu/cacheflush.h 2008-02-12 13:58:55.000000000 +1000 @@ -54,28 +54,28 @@ static inline void __flush_cache_all(voi #if defined(CONFIG_M527x) || defined(CONFIG_M528x) __asm__ ...

Modify the extra asm flags for debugger capabilities, use asflags instead for EXTRA_AFLAGS. Suggestion from Sam Ravnborg <sam@ravnborg.org>. Signed-off-by: Greg Ungerer <gerg@uclinux.org> --- diff -Naurp linux-2.6.25-rc1/arch/m68knommu/platform/5206/Makefile linux-2.6.x/arch/m68knommu/platform/5206/Makefile --- linux-2.6.25-rc1/arch/m68knommu/platform/5206/Makefile 2008-01-25 08:58:37.000000000 +1000 +++ linux-2.6.x/arch/m68knommu/platform/5206/Makefile 2008-02-12 14:05:13.000000000 +1000 @@ ...

From: Walter T Gruczka <walter.t.gruczka@boeing.com> Remove bogus conditional jump in return from interrupt path. Reorder the code path now that is not there. Signed-off-by: Greg Ungerer <gerg@uclinux.org> --- diff -Naurp linux-2.6.25-rc1/arch/m68knommu/platform/coldfire/entry.S linux-2.6.x/arch/m68knommu/platform/coldfire/entry.S --- linux-2.6.25-rc1/arch/m68knommu/platform/coldfire/entry.S 2008-02-11 14:50:21.000000000 +1000 +++ ...

Epoll calls rb_set_parent(n, n) to initialize the rb-tree node, but rb_set_parent() accesses node's pointer in its code. This creates a warning in kmemcheck (reported by Vegard Nossum) about an uninitialized memory access. The warning is harmless since the following rb-tree node insert is going to overwrite the node data. In any case I think it's better to not have that happening at all, and fix it by simplifying the code to get rid of a few lines that became superfluous after the previous ...

Ok. I will split them up, and resend. Thanks, Eugene --

Hi, I noticed that Linus has committed your patch. Here's a resend of my patch. Kindly review please. [PATCH] mm: tidy up follow_hugetlb_page() and get_user_pages() This patch extends Jonathan Corbet's patch to avoid buffer overflows in get_user_pages(). It tidies up follow_hugetlb_page(), and get_user_pages() to make sure that vma is also validated, and the code is more readable. Signed-off-by: Eugene Teo <eugeneteo@kernel.sg> --- include/linux/hugetlb.h | 2 +- mm/hugetlb.c ...

From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Thanks for reviewing Paul, I'll apply this. --

stop machine is used for more than just module loading and unloading. I don't think you can just disable it. --

I'm wondering why you insist on offering a git tree that bypasses the regular maintainers. Why not post the patches and walk the normal route? To me this feels rather aggressive, which makes me feel less inclined to You forgot Oleg, he does a lot of the workqueue work. I'm worried by your approach to never start any workqueue on these cpus. Like you said, it breaks Oprofile and others who depend on cpu local workqueues being present. Under normal circumstances these workqueues will ...

Well, not if the code involved in the exploit can pass a zero value, otherwise it's just turning it into a DoS.. --

From: Casey Schaufler <casey@schaufler-ca.com> Smack uses CIPSO labeling, but allows for unlabeled packets by specifying an "ambient" label that is applied to incoming unlabeled packets. Because the other end of the connection may dislike IP options, and ssh is one know application that behaves thus, it is prudent to respond in kind. This patch changes the network labeling behavior such that an outgoing packet that would be given a CIPSO label that matches the ambient label is left unlabeled. ...

Maybe this should go to a more specific list, but I had a question about a dmesg v. Kconfig item. One option under graphics asks about enabling firmware EDID and says should be safe. So it's 'yes' Further down under nVidia FB Support, there is an option "Enable DDC Support" which tries to use i2c for getting EDID info and I should say 'Y'. With those on, in dmesg, I get: i2c-adapter i2c-0: unable to read EDID block. i2c-adapter i2c-0: unable to read EDID block. i2c-adapter i2c-0: unable ...

From: Randy Dunlap <randy.dunlap@oracle.com> Move pipes and splice docbook to filesystems book. kernel-api book is huge (10x most other books) & slow to process. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- Documentation/DocBook/filesystems.tmpl | 20 ++++++++++++++++++++ Documentation/DocBook/kernel-api.tmpl | 20 -------------------- 2 files changed, 20 insertions(+), 20 deletions(-) --- linux-2.6.25-rc1.orig/Documentation/DocBook/filesystems.tmpl +++ ...

From: Randy Dunlap <randy.dunlap@oracle.com> Fix several kernel-doc notation errors in fs/pipe.c. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- fs/pipe.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- linux-2.6.25-rc1.orig/fs/pipe.c +++ linux-2.6.25-rc1/fs/pipe.c @@ -171,7 +171,7 @@ static void anon_pipe_buf_release(struct * * Description: * This function returns a kernel virtual address mapping for the - * passed in @pipe_buffer. If @atomic ...

The description of the interrupt routing doesn't match the (nice) diagram. Signed-off-by: Nick Andrew <nick@nick-andrew.net> Nick. --- a/Documentation/i386/IO-APIC.txt 2007-10-10 06:31:38.000000000 +1000 +++ b/Documentation/i386/IO-APIC.txt 2008-02-12 11:57:08.000000000 +1100 @@ -68,7 +68,7 @@ These INTA-D PCI IRQs are always 'local to the card', their real meaning depends on which slot they are in. If you look at the daisy chaining diagram, -a card in slot4, issuing INTA IRQ, it will ...

On Tue, Feb 12, 2008 at 08:32:18PM +0100, Jarek Poplawski wrote: Jarek P. --

On Tue, Feb 12, 2008 at 08:07:29AM -0800, Paul E. McKenney wrote: Hmm... I got it my way: you - superheroes - sometimes seem to be just like us - common people... (Probably early in the morning, before It seems the above version of this macro uses the barrier for 0, but if I miss something, or for these other: documenting reasons, then of ---------------------------^ + * initialized array element that will be dereferenced by RCU Regards, Jarek P. --

"All programmers are blind, especially me." You are right, Jarek. I ran this through gcc, and the following comes close: #define rcu_assign_pointer(p, v) \ ({ \ if (!__builtin_constant_p(v) || (v)) \ smp_wmb(); \ (p) = (v); \ }) But I am concerned about the following case: rcu_assign_pointer(global_index, 0); . . . x = global_array[rcu_dereference(global_index)]; Since arrays have a zero-th element, we would really want a memory barrier in this case. So how ...

Thank you. Over time we might think about some sort of standard for This is one of the things that linux-next will hopefully let us discover Right. Except that "drop the tree" will probably only mean for a day or so i.e. it will be taken out of the current round but will reappear Excellent! However, I am hoping that these global api changes may be introduced in a more orderly fashion (some of which is happening already) by creating new api's and then switching to them (and them maybe ...

FWIW, that is annoying and painful for us downstream jobbers, since it isn't really how git was meant to be used. You use it more like a patch queue, where commits are very fluid. Unfortunately, if there is any synchronization lag between me and you -- not uncommon -- then I cannot commit changes on top of the changes just sent, in my own local tree. Why? Because you rebase so often, I cannot even locally commit dependent patches due to the end result merge getting so nasty. I ...

Oh, I agree, multiple drivers for the same functionality is not a nice thing from a distro standpoint. The work I'm doing here is for stupid PCI firmware engineers, who have created devices that are different things, all bound up under the same PCI device. I'm thinking of watchdog timers and random number generator and i2c controller on the same PCI device, or even the more basic, frame buffer and DRM access to the same PCI video device. The OLPC is a good example of hardware that needs ...

As noted to Andrew in private email, I think this would be great. akpm's -mm tree tends to have "x+1" changes in it, and also stuff that's not fully baked yet. I would definitely like to see a tree composed of all the sub-trees where maintainers said "yes, I think this is baked and ready for x+1". Then -mm and not-yet-baked git changes can layer on top of that. As others are noting, API changes require some coordination amongst ourselves (should be our job, not yours, really) and ...

Indeed. If you have a multi-function device that shows up as a single PCI function, just make it have its own "private bus", and make it show up as a "devices within a device". Create the fake PCI subdevices that have no "real" counterpart, except as parts of the stupid device that couldn't be bothered to be seen as multiple _real_ functions. That not only solves the infrastructure issues, it's actually The Truth with capital letters. It is, after all, how the device actually works ...

The problem is how do we use a? Usually we need to track your -rc tree as our fixes go in ... some of which affect our development trees. If we stick with (a) as the base, we don't get to pull in the fixes in your tree. If we use your tree we have to pull in (a) creating n Yes, this is effectively what I did with the post merge SCSI tree. However, if you do this rebasing becomes a fact of life because you need to rebase out all the dependencies you have before you merge (in fact, it's a ...

FWIW, I definitely have a (vocal minority) group of contributors who resent all the rebasing. There may be a few cases of 'vanity' represented here, but there are definitely reasonable complaints about not being able to do simple pulls to stay up-to-date and/or having to rebase before they can send patches to me. FWIW, I think it might save a bit of my time as well, although I have become pretty good and "riding the tide" of rebasing... :-( Unfortunately, I don't have any good ...

From: Greg KH <greg@kroah.com> Totally agreed. The fact is there are interdependencies, especially in driver land and you have to either: 1) Make the driver folks work on top of Greg's tree. 2) Constantly rebase the -next tree to deal with the conflicts. There are some other issues related to this which haven't be touched upon greatly yet. I rebase my tree all the time, at least once or twice per week. Why? Firstly, to remove crap. When you have "great idea A" then "oh shit ...

No, you can't have a tree like that. [森林 Not yours. 森林] Let's maximize the profit, by keeping the largest number of trees which do not cause a conflict amongst each other. --

Yes -- the worst case is that people have to work together, and it So people have to work together... darn :) most drivers these days are organized nicely into nicely modular units anyway, making it easy to write a "shell" driver that simply registers each sub-driver, and helps arbitrate/provide resources to sub-units. Consider, for example, a PCI driver that loads, and then fills in platform_data to provide a specific set of resources to a platform driver (a common idiom). You ...

Actually, it sort of does. If you look here: http://www.kernel.org/pub/linux/kernel/people/jejb/merge-tree/ You'll find a merge candidate tree that builds nightly from everyone's git and quilt trees. I'm using it to track merge conflicts (so I only build the patch, I don't check it compiles). You're welcome to the scripts that do this: http://www.kernel.org/pub/linux/kernel/people/jejb/build.pl And the config file that runs ...

I think this statement has been used unfortunately as a hard and fast rule (which we all know how much Linus loves :-) to mean, in its most extreme form, that we should *never* try to do some careful reflection about careful API design, and that the extremes of "no interface without an in-tree user" applies to (a) parameters in a function call (heck, we can always sweep through all the in-tree users to add that extra parameter later, and thats a *good* thing because it breaks those evil ...

I do think that some people rebase too often (and that David is in that number), often with no real discernible reason. I think rebasing is great when you are doing active development (ie you're really acting in "quilt mode") and I actually think git could and should integrate more of the queues modes, but I don't think it should be a default action for an up-stream developer. I also don't think rebasing helps the particular problem under discussion (ie conflicts due to having to ...

OK, I'll address it then (or try to). Just don't eat me please ... I'm I can sort of agree, but I don't think you can say enough == no more API changes. There's the request_irq argument removal patch floating around somewhere for instance ...but as someone said "Every rule always has an exception". I think what's really needed is a balance where it's painful (on the originator) to make an API change. Part of what -mc or -next trees can I think this is exaggerated. By the end of the ...

Well I've already broken the buffering so he'd fix it ;) We have a pile of old ISA drivers that are going to break soon with the locking changes and a pile of USB drivers that when I looked at the locking were so terminally broken I couldn't be bothered to fix them. So it'll be fun, lots of && BROKENs to add --

yup, in many cases that's pretty easy to do. But people dive straight for the end result, which of course provides the cleanest outcome but isn't really very real-wordly. Another thing we could do when these things happen is all gang up on Linus and ask him to merge the API change into mainline. Because often the change can be done in two stages: 1) change the interface then 2) add the code in the callee which _uses_ that changed interface. Part 1 is an obviously-safe do-nothing change and ...

That's how I first tried to do this (old pci-piggy patches in -mm were a result of this...). But, we have the issue of the foolish-in-retrospect sysdev devices. They are an example of "multiple drivers per device" type thing. To clean them up properly, they need to move to the general 'struct device' and if that is going to already support the one-to-many model, well, then any PCI implementation of such an internal bus can also use the same code. This is a lot of handwaving right now, let ...

I used to be in this camp too: seeing rebasing as the ultimate evil. However, what I found was that as I tried to preserve my merge tree's history, I was picking up merge points with non trivial fixups. You can argue that this is how git is supposed to operate, but the problem is that these merge points become immovable objects in the tree history ... I can't rebase the tree at all any more and I can't simply remove a commit (which gets messy for commits duplicated by other trees) They also ...

Note that a lot of these are already in the MAINTAINERS file. But for the record, here's mine, in the order they need to be pulled from. Driver core: kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/ PCI: kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-02-pci/ USB: kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-03-usb/ These are all quilt trees, with the series file in the directory for the order of the patches, and a README saying ...

From: Jeff Garzik <jeff@garzik.org> Understood. One of the key operations that I'm interested in is removing things from the history. If I could do that using GIT without any side effects and in a way that really would remove it from the tree, I would do that in a heartbeat. At 1500 changesets, a merge conflict shows up about once every day or two as 2.6.N nears it's release into final as bug fixes trickle in. I find using GIT to fixup merge errors on a tree of that scale to be really ...

We could simply decide that API changes affecting more than one subsystem Must Be Serialized(tm). Explicitly. As in "any such change is posted and discussed in advance, order of merges decided upon and we have merge window for one decided set of API changes + fallout *ONLY*". With merge window in question normally taking a few days. --

On Mon, 11 Feb 2008 22:02:22 -0800 (PST) I agree with that. There is maybe a middle ground in this -next idea; as very first part of the series, the new api gets added, current users converted and api marked __deprecated. Then there's a second part to the patch, which is a separate tree, which gets added at the very end, which removed the old api. Both will go in at the same merge window, and the next-meister needs to track that no new users show up... but the final tree allows this to ...

Our APIs are written such that the PCI device probe function is the starting point for registering IB and NIC. No need for anything new. Jeff --

Don't get me wrong at all. Rebasing is fine for stuff you have committed yourself (which I assume was the case here). Rebasing is also a fine conflict resolution strategy when you try to basically turn a "big and complex one-time merge conflict" into "multiple much smaller ones by doing them one commit at a time". But what rebasing is _not_ is a fine "default strategy", especially if Right. And it's one of the fundamental differences between git and a patch queue. Patch queues ...

Umm. Have you read a lot of books on evolution? It doesn't sound like you have. The fact is, evolution often does odd (and "suboptimal") things exactly because it does incremental changes that DO NOT BREAK at any point. The examples are legion. The mammalian eye has the retina "backwards", with the blind spot appearing because the fundmanetal infrastructure (the optical nerves) actually being in *front* of the light sensor and needing a hole in the retina to get the information ...

I may be a bit defensive here, but I hope that all of the recent kobject/kset/driver core changes have been done with the thought of "what are we doing wrong". For the kset rework, we went back and looked at how people were trying to use this code, realized that it was way too complex, and reworked it all, making both the implementation simpler, the kernel usage model simpler, and documented the whole thing so that everyone knows exactly what is now going on. To quote the original ...

For your development, possibly, but not for my merge ... there were a lot of other patches besides yours in the bidi tree (it was, in fact, misnamed, but I thought at the time I created it it would only contain Actually, I think you'll find the problem is that we can't build an integration tree that's both stable and long lived, and hence you can't base anything off it that requires a long lived base. So, the way I worked for your patches was to use the -mc tree to identify my conflicts, ...

I don't understand what you mean. This is true whether you pulled (a) or not. If you have any changes what-so-ever in your tree, if you pull in fixes from my tree, you'll get a merge. But if you mean that you cannot rebase (a), then yes. That was what I said. Rebases *do*not*work* (and fundamentally cannot work) in a distributed environment. But why would you merge with my tree in the first place? My tree won't normally have any conflicts or anything like that anyway. With a ...

.. btw: I'd need to know this in advance. I usually don't see the problem until it's too late. And this is very much an area where "Linux-next" can help: if some subsystem causes problems in Linux-next for other maintainers, I really think it shouldn't just be a matter of "drop the git tree that didn't merge cleanly", but it should literally be a question of "maybe we should drop the _earlier_ git tree that caused the later one not to merge cleanly". In other words, maybe things ...

Let me know which USB ones are broken, I'll work to fix them. thanks, greg k-h --

From: Arjan van de Ven <arjan@infradead.org> API trees don't work, just like other changes they will have interdependencies on things like fixups, cleanups, etc. This is why, with the networking, we've just tossed all of the network driver stuff in there too. I can rebase freely, remove changesets, rework them, etc. and this causes a very low amount of pain for Jeff Garzik and John Linville. This may or not be a legitimate thing to do with other heavily dependant subsystems. --

> The other is that once somebody says "ok, I *really* need to cause this > breakage, because there's a major bug or we need it for fundamental reason > XYZ", then that person should > > (a) create a base tree with _just_ that fundamental infrastructure change, > and make sure that base branch is so obviously good that there is no > question about merging it. I don't disagree with this, but I think I should point out that making something "obviously good" may be pretty ...

Ahem... Use of git-cherry-pick preserves commit information just fine. --

Yes, that's exactly what I was suggesting. The __deprecate only lasts for the merge window, and we remove the old API at the end of the merge window. So it's only there for a very short time, and it's only there to make the cleen sweep a little less painful --- not one where "shit hangs around in the tree forever". - Ted --

Except that the individual drivers are a lot of the time written by different people, live in different portions of the tree, and are combined into different combinations depending on the chipset. For i2c devices, I see the scx200_acb, i2c-elektor, i2c-sis5595, and i2c-sis630 drivers needing this. The last one happens to share the pci device with a video driver, that doesn't always need to be / want to be loaded by users just so they can read the temperature of their processors. Oh, the ...

Hrm... How badly is pl2303 broken? I actually use that sucker, so if it needs help - count me in. --

On Tue, 12 Feb 2008 14:55:31 -0800 That I noticed doing an audit for unlocking the mctrl functions: ir-usb: global variables without locking used in per port operations iuu_phoenix: no locking on internal data structures mos7840: ditto option: ditto kobil_sct: ditto These drivers do interesting things (where interesting is probably not too evil on a PC - except ir-usb) involving playing with data structures without locks. It seems there was some kind of evolution along the way as some ...

IMHO, this base tree should typically be based off of linus' tree and kept rebased on top of it. This way you get the mainline fixes through the integration base tree. Benny --

The other way that might work in some circumstances would be if we tried a little harder to avoid API changes that don't involve an interface naming change. That is, instead of adding a new parameter to a function, and then having to sweep through all of the trees to catch all of the users of siad function, we could instead add a new a new interface, __deprecate the old one, and then give enough time for trees to adapt, you can avoid needing to do flag day transitions. If the old interface is ...

2303 is pretty good (in fact by usb serial standards outstanding). It has all the internal locking needed for now and right down to killing lock_kernel entirely outside of open/close (which is going to hit everything). Only fixme I have tagged for it is - if you set an unsupported baud rate it reports it set rather than the one you got Which is a trivial mend for someone who has suitable docs (its marked FIXME: at the right spot) --

No, I might have mistyped previously, but I really do not believe in I agree with this. But I was reacting to your "there are major reasons to stay with an old interface..." portion above, while I feel we should No, not at all. I have tried, and successfully done this many times in the past. The kobject change was one example: add a new function, migrate all users of a direct pointer over to that function, after that work is all done and in, change the structure and do the needed work ...

Yep. I do that with the powerpc tree sometimes, too: I'll ACK a drivers/net change that is obviously PPC-specific, and that drivers/net change will go in via paulus. Like you said, it's done on a per-patch not git tree basis at the moment. That sort of cooperation has become common: in areas of shared responsibility, request an ack, and then the "most obvious" person (generally the one with most merge dependencies) merges that shared-responsibility change along with some other ...

On Mon, 11 Feb 2008 20:43:14 -0800 this is why you need specific trees for just the API change, and these need to EXPLICITLY go first before EVERYTHING ELSE. Yes this needs a bit of coordination, but it's the only way. --

.. but are we expecting it to be finished? That's the point. This whole "Linux-next" discussion so far has almost been predicated on the whole assumption that this is an on-going concern. And it really should NOT be. If it's an on-going concern, we need to tackle *that* issue, not the issue that cross-subsystem merges are hard. They simply seem to happen too much. In other words, I'm not AT ALL interested in the merges we've already done. That's over and done with, and we'll ...

Color me a bit skeptical... we've always had this capability really: for multi-function devices, just register as many subsystems as you need. If your device is a network _and_ SCSI device, you can do that with today's APIs. I just went through a long thread (e1000/e1000e) explaining how much pain multiple drivers for the same PCI ID cause on the distro side of things... its a mess. In each case you must write special case code to resolve the ambiguity. You never know which is ...

I'm getting similar errors on an x86-32 & x86-64 kernel. The x86-64 system (2nd log below w/date+times) was unusable this morning: one or more of the xfs file systems had "gone off line" due to some unknown error (upon reboot, no errors were indicated; all partitions on the same physical disk). I keep ending up with random failures on two systems. The 32-bit sys more often than not just "locks-up" -- no messages, no keyboard response...etc. Nothing to do except reset -- and of course, ...

[Empty message]

Well, tickless is new and shiny and I doubt anyone has done much testing with XFS on tickless kernels. Still, if that's a new config option you set, change it back to what you had for .23 on If you have a multithreaded application that mixes mmap and direct I/O, and you have a simultaneous munmap() call and read() to the same file, you might be able to deadlock access to that file. However, you'd have to be certifiably insane to write an application that did this (mix mmap and direct ...

Thank you very much. Sorry about the email client and wordwrap. I was just about to repost it using a different email client, thanks for cleaning it up for me. Jason --

Hi Jason, Patch applied. Please note that your e-mail client corrupted the patch and I had to edit it manually before it would apply properly. Next time please make sure that the patch is left unchanged so that it applies I left out this last part as it was already sent separately to the PCI subsystem maintainer. I will wait for Greg to pick it before I send the i2c-i801 update upstream. Thanks, -- Jean Delvare --

On Mon, 11 Feb 2008 16:48:35 -0800 When I fixed the reject, compilation failed here. arch/x86/pci/mmconfig-shared.c: In function 'pci_mmcfg_check_hostbridge': arch/x86/pci/mmconfig-shared.c:214: error: 'pci_direct_conf1' undeclared (first use in this function) What kernel are you patching? --

it is in arch/x86/pci/pci.h and arch/x86/pci/mmconf_shared.c has one #include "pci.h" did you compile that for 32 bit? YH http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b6ce06... diff --git a/arch/x86/pci/pci.h b/arch/x86/pci/pci.h index 36cb44c..3431518 100644 (file) --- a/arch/x86/pci/pci.h +++ b/arch/x86/pci/pci.h @@ -85,10 +85,17 @@ extern spinlock_t pci_config_lock; extern int (*pcibios_enable_irq)(struct ...

From: Yinghai Lu <Yinghai.Lu@Sun.COM> Patch x86: validate against ACPI motherboard resources changed the mmconf init sequence, and init MMCONF late in acpi_init. here change it back to old sequence 1. check hostbridge in early 2. check MCFG with e820 in early 3. if all fail, will check MCFg with acpi _CRS in acpi_init So we can make MCONF working again when acpi=off is set if hostbridge support that. Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> Cc: Greg KH <greg@kroah.com> Cc: ...

From: Yinghai Lu <Yinghai.Lu@Sun.COM> For x86_64, need to free pci_mmcfg_virt, and iounmap some pointers when MMCONF is not reserved in E820 or acpi _CRS and get rejected Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> Cc: Greg KH <greg@kroah.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- arch/x86/pci/mmconfig-shared.c | 1 + arch/x86/pci/mmconfig_32.c | 4 ...

Yes, and in fact I had both fixes present in the development branch but had forgotten to cherry pick them over into the upstream branch - thanks for noticing, I'll respin. --

Hi Yinghai, Great, thanks. Mark, please include this patch in your next patch to You must unload the adm1026 driver before dumping (see the "rmmod adm1026" above in my example.) Thanks, -- Jean Delvare --

I certainly could, but then you would laugh at me because 2.6.24 isn't affected by the bug. -- Jean Delvare --

How would that help? Rather while (len > 0) { ... } would do the trick. -- Jiri Kosina --

Yeah, it seems that it fixed suspend troubles. -- Lukáš Hejtmánek --

From: Muli Ben-Yehuda <muli@il.ibm.com> For the 64-bit case what you are suggesting eventually amounts to mapping all available RAM in the IOMMU. Although an extreme version of your suggestion, it would be the most efficient as it would require zero IOMMU flush operations. But we'd lose things like protection and other benefits. --

Yes, have a DMA pool of DMA addresses to use and re-use in the stack instead of setting up and tearing down the PTE's is something we need to look at closely for network and other high DMA traffic stacks. --mgross --

I think that will make a string like below: -- ~Randy --

From: mark gross <mgross@linux.intel.com> Yes, this is a good idea especially for networking. For transmit on 10GB links the IOMMU setup is near the top of the profiles. What a driver could do is determine the maximum number of IOMMU pages it could need to map one maximally sized packet. So then it allocates enough space for all such entries in it's TX ring. This eliminates the range allocation from the transmit path. All that's left is "remap DMA range X to scatterlist Y" And yes it ...

While I don't disagree with this patch in principle (Calgary does the same thing due to expensive IOTLB flushes) the right way to fix it IMHO is to fix the drivers to batch mapping and unmapping operations or map up-front and unmap when done. The streaming DMA-API was designed to conserve IOMMU mappings for machines where IOMMU mappings are a scarce resource, and is a poor fit for a modern IOMMU such as VT-d with a 64-bit IO address space (or even an IOMMU with a 32-bit address space such as ...

=C3=9Chel kenal p=C3=A4eval, E, 2008-02-11 kell 14:53, kirjutas Roland McGr= This fails with clean build. And vdso-syms.lds is not empty. Contents of =EF=BB=BFarch/x86/vdso/vdso-syms.lds: VDSO64_PRELINK =3D 0xffffffffff700000; VDSO64_jiffies =3D 0xffffffffff7004b8; .config attached or can be viewed at http://plaes.org/files/2008-Q1/dot_config_VDSO64_error Hope this helps, Priit

On Mon, 11 Feb 2008 16:28:13 -0600 kernel/softirq.c: In function 'takeover_tasklets': kernel/softirq.c:597: error: 'struct tasklet_head' has no member named 'next' kernel/softirq.c:603: error: 'struct tasklet_head' has no member named 'next' kernel/softirq.c:588: warning: unused variable 'i' --

I noticed this when looking at an openswan issue. Openswan (ab?)uses the tasklet API to defer processing of packets in some situations, with one packet per tasklet_action(). I started noticing sequences of backwards-ordered sequence numbers coming over the wire, since new tasklets are always queued at the head of the list but processed sequentially. Convert it to instead append new entries to the tail of the list. As an extra bonus, the splicing code in takeover_tasklets() no longer has ...

thanks, I'll add. --

Now I just found that the new "Speaker" switch forgets it's value from time to time, ie. it's muted, you go and have lunch, and when you get back and start the music, it's unmuted. It is probably related to aggressive hda-codec powersaving, which I have enabled and set to 20 secs. Matej --

I was actually wrong when saying the "Front" channel did not influence HP-out No, setting Master and/or Front channel to 0% did not mute audio in any version I used. I'm now listening to music with Master=0% and Front=0%, the sound is at well audible volume. Pastebin for this configuraion is here: http://pastebin.ca/901459 However I don't consider it a problem, it's mutable by PCM and HP/Speaker switches. Funny thing is that resulting volume of those 3 setting is equal: * Master=0, ...

Yes, this "slightly better" patch applied on top of your first patch against hda_codec.c did the trick, but with some side-effects: * the "Speaker" switch now mutes/unmutes speakers * muting/unmuting "Front" channel now has zero effect (in 2.6.24 it had the same effect as the "Speaker" switch now has) * changing volume on "Front" channel now affects volume in headphones (was not so in 2.6.24) So there are now 3 vol controls that affect both speakers and headphones: * Master (which ...

At Tue, 12 Feb 2008 15:02:09 +0100, This version might be slightly better... Takashi --- diff -r e84ee72676f0 sound/pci/hda/patch_realtek.c --- a/sound/pci/hda/patch_realtek.c Tue Feb 12 12:11:36 2008 +0100 +++ b/sound/pci/hda/patch_realtek.c Tue Feb 12 15:14:17 2008 +0100 @@ -746,7 +746,6 @@ static void alc_sku_automute(struct hda_ static void alc_sku_automute(struct hda_codec *codec) { struct alc_spec *spec = codec->spec; - unsigned int mute; unsigned int present; ...

At Mon, 11 Feb 2008 21:58:41 +0100, Could you give the output of alsa-info.sh for both working and non-working kernels? http://hg.alsa-project.org/alsa/raw-file/tip/alsa-info.sh thanks, Takashi --

The locations of alsa-info.sh outputs: no sound in headphones: http://pastebin.ca/901022 sound ok: http://pastebin.ca/901016 Both kernels are Linus' tree snapshots as of commit cc13e442952a347f7, the one with working sound has just the f889fa91ad47e commit reverted. Matej Laitl --

Back on the 32-way, in this set of tests we're running 12 disks spread out through the 8 cells of the 32-way. Each disk will have an Ext2 FS placed on it, a clean Linux kernel source untar()ed onto it, then a full make (-j4) and then a make clean performed. The 12 series are done in parallel - so each disk will have: mkfs tar x make make clean performed. This was performed ten times, and the overall averages are presented below - note this is Jens' original patch sequence NOT the kthread one ...

Note quite: Q or C = 0 really means Q or C set to -1 (default), Q or C = 1 means placing that thread on the CPU managing the IRQ. Sorry... <sigh> Alan --

Hi Ahmed, your patch fixes the nfs problem! Thank you! regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 --

Hi Matt, Thanks for your review. Le Mon, 11 Feb 2008 13:01:18 -0600, Andrew seems to already have picked up the patch in -mm (I received an e-mail + x86-configurable-dmi-scanning-code.patch added to -mm tree). If I resend a new one with proper credits, will Andrew pick it up and I was compiling with 4.2.3, which I suppose is a modern gcc. Thanks, Thomas --=20 Thomas Petazzoni, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than ...

Never mind. That was a bad suggestion. I do think it would be a good idea to mark the 'struct page' of ever page we use as bootmem in some way. Perhaps page->private? Otherwise, you can simply try all of the possibilities and consider the remainder bootmem. Did you ever find out if we properly initialize the bootmem 'struct page's? Please have mercy and put this in a helper, first of all. static void free_usemap(unsigned long *usemap) { if (!usemap_ return; if ...

Only problem is, I need to hold pgdat_resize_lock() if pass *ms. If I don't hold the resize_lock, I have to re-evaluate. And also, I need to pass section_nr for decoding the mem_map anyway :( Thanks, Badari --

What's wrong with holding the resize lock? What races, precisely, are See sparse.c::__section_nr(). It takes a mem_section* and returns a section_nr. -- Dave --

I do like how it looks, better, thanks. --

Here is the version with your suggestion. Do you like this better ? Thanks, Badari Generic helper function to remove section mappings and sysfs entries for the section of the memory we are removing. offline_pages() correctly adjusted zone and marked the pages reserved. Issue: If mem_map, usemap allocation could come from different places - kmalloc, vmalloc, alloc_pages or bootmem. There is no easy way to find and free up properly. Especially for bootmem, we need to know which node the ...

I think you need at least a WARN_ON() there. Can none of this ever fail? I also think having a function called __remove_section() that takes a pfn is a bad idea. How about passing an actual 'struct mem_section *' into it? One of the reasons I even made that structure was so that you could hand it around to things and never be confused about pfn vs. paddr I'd like to see some warnings in there if nr_pages or phys_start_pfn are not section-aligned and some other sanity checks. If ...

This driver is broken pretty horribly. It won't even compile for a plain ppc64 kernel: http://sr71.net/~dave/linux/ehea-is-broken.config I know it's used for very specific hardware, but this is the symptom of it not using the proper abstracted interfaces to the VM. In file included from /home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_main.c:42: /home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:44:14: warning: "SECTION_SIZE_BITS" is not ...

No that should be quite all-right. Thanks for testing! --

Tested with CONFIG_RT_GROUP_SCHED set and it also works as expected. Thanks, Rafael --

Hi David: to clarify: I added the "interesting" because I didn't want the "look good" to be interpreted as an informed judgement. I hadn't time to review in detail. I do have some comments, which I'll send in response to the original patch messages [or any later posting thereof, Hmmm, so 'static' means "don't contexutalize"--i.e., don't mask off disallowed or memoryless nodes? That means we'll need to skip them in the interleave node calculation in the allocation path. Perhaps ...

Symptom is that the system shuts down normally and completely, it just does not power off. Here are the last messages on the console: Will now halt. sd 1:0:0:0: [sdb] Synchronizing SCSI cache sd 1:0:0:0: [sdb] Stopping disk sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk ACPI: PCI interrupt for device 0000:01:00.0 disabled Nothing. Only USB kbd/mouse. Note that I've had this issue before with this ...

Well, the caller's ctl_table contains the tunables addresses for the init namspeace in its .data fields. While what needs to be passed in to proc_dointvec() is the tunable address in the caller's namespace. Since all the fields in ipc_kern_table[] are ok but the .data one, imho it's correct to store it in a local copy and change the data field to the appropirate one, before passing it to proc_dointvec(). Regards, Nadia --

On Tue, 12 Feb 2008 16:15:00 +0100 That seems to be a lot of increase. Are you sure you had CONFIG_PROCFS=n in both cases? If so, the patch must have added a lot of code which will never be executed? --

Oops, forgot the patch. Thx Benjamin!

I believe this patch should fix the problem. Can you please verify? Thanks, -hpa

--

Looks good for me and kernel no longer deadlocks with this patch! --

Yes, that I realize now (I'll refer back to the lack of sleep thing 2.6.24.2 seems to fix the issue, so thanks to whoever noticed and fixed that (and if no one fixed anything, then I'm just a raving loon, and you can move on with your day, content that the nice man raving about fictitious bugs is happy again). But FYI and for what its worth, although SELinux was compiled, it isn't being used. Its disabled on boot. Thanks for the reply and help anyways, Nick --

<snip> Fix Build error for xc5000 tuner when built as module. Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> --- Not 100% certain this is correct but it works for me :) Michael? drivers/media/dvb/frontends/xc5000.h | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/frontends/xc5000.h b/drivers/media/dvb/frontends/xc5000.h index e0e8456..32a5f1c 100644 --- a/drivers/media/dvb/frontends/xc5000.h +++ ...

we could make it even lower risk and not move the Kconfig now. Moving the Kconfig is fine for .26; it doesn't really impact anything else --

On Tue, 12 Feb 2008 11:44:52 -0500 OK. But now is basically the worst time for me (or anyone else) to merge large code-motion changes like this, because they need to be carried for two months or more. And even though git can track renames, putting them into a git tree (say, git-kbuild) won't help, because if some other git tree tries to modify a file in its original place, I get to fix up the fallout. Which I _could_ do, and would do if the patches were particularly risky or added/changed ...

I agree; removed From: Thomas Sujith <sujith.thomas@intel.com> Added sanity checks for interface functions in thermal with other modules such as fan, processor, video etc. Using ERR_PTR to return errors. Signed-off-by: Thomas Sujith <sujith.thomas@intel.com> --- drivers/thermal/thermal.c | 63 +++++++++++++++++++++++++++------------------- 1 files changed, 38 insertions(+), 25 deletions(-) Index: ...

This should be asked on linux-hotplug and not linux-kernel, but anyway... This documentation should help you: http://www.reactivated.net/writing_udev_rules.html Daniel --

While I have to respect your decision, please clarify whether you are entitled to remove the SuSE Labs copyright as well. Thanks, tglx --

With the logic pud error i found and that seems currently will stay for the forseeable future in the tree I don't think x86-64 64bit hotadds for more than 1GB have ever worked with the sparsemem method. Older trees (before 2.6.24) had also a different method that did preallocate everything based on the SRAT. That one should have worked for this case. -Andi --

I didn't want to bundle such a clean up into the bug fix because my experience is that you usually reject that categorically. I can send the removal of max_pfn_mapped as a follow up patch if you apply this one. -Andi --

The only effective change is: - if (md->attribute & EFI_MEMORY_WB) + if (!(md->attribute & EFI_MEMORY_WB)) I appreciate that you noticed the reverse logic, which I messed up when I fixed up rejects. I pulled this out as it is a real fix. The rest of this patch is just turning code in circles for nothing, simply because it is functionally completely irrelevant whether does simply: if ((end >> PAGE_SHIFT) <= max_pfn_mapped) va = ...

Too late. It was so obvious that it screamed to be fixed. I applied the inital patch already and cleaned it up myself. :) Thanks, tglx --

I was actually hoping that you'll continue unifying ATAPI handling... [ ide-scsi is orphaned and has (probably) unfixable problems (because of having dependencies on both IDE and SCSI subsystems) so it is not worth IMO but I will of course accept patches... ] Thanks, Bart --

Your patch doesn't include the CVE-2006-0010 hunk. Is this because get_user() implies an access_ok() check (while __copy_from_user() obviously does not)? --

I tested your patch and it fixes the problem here! Thank you very much for your good work, --

It is more than a simple recursion check (which is already in the code) because there are some conditions we can recover from. I'd rather not crash the system out if it can be recovered. kgdb_reenter_check() has the "simple" recursion check with the exception_level variable. It also has several special checks against the breakpoint situation I described before as well as trying to remove all the breakpoints. Ultimately if all those checks fails, it results in panic, because at the end ...

No this is a kgdb integrity check. Basically when you reach this chunk of code it is before the hand off to the source debugger. We cannot continue because there was a breakpoint in a part of the system kgdb was using while doing its normal work. The reality is that KGDB is not self contained. It relies on some external I/O methods, atomic page fault handling and some other pieces. If you take an exception there, the kgdb integrity check absolutely needs to fail. It was the source of ...

This is not a technical argument, but I am not a big fan of hard hanging the system if you cannot sync all the CPUs. The original intent was to at least provide a sync error message to the end user after some reasonable time. Then allow someone to collect any data you can get and you basically have to reboot. The reboot was never forced, but assumed the end users of this knew what they were doing in the first place. Certainly in a completely working system where you use kgdb only ...

Ok I'm trying to understand the code as you describe it. As far as I can see (in kgdb-light-v10) it is: + addr = kgdb_arch_pc(ks->ex_vector, ks->linux_regs); + kgdb_deactivate_sw_breakpoints(); + + /* + * If the break point removed ok at the place exception + * occurred, try to recover and print a warning to the end + * user because the user planted a breakpoint in a place that + * KGDB needs in order to function. + */ + if ...

There was work underway on that before (hw_breakpoint). I'm not entirely sure you want to use fancy stuff like that in kgdb. It's nice for kgdb to be as self-contained as possible, so you can debug everything else with it. If you're going to rely on lots of higher-level infrastructure, it could be using kprobes for its software breakpoint handling, too. At any rate, I think it would be good if the hw breakpoint support in kgdb were chopped out into a separate patch. First make kgdb work ...

Can't be very many because oprofile needs it and it works on most archs now. Anyways, the right thing is to just add it to the architectures Hmm, I'm pretty sure I saw some code that was only useful for the user case. Perhaps you should take all that out then if it doesn't work anyways? Seems wrong intended behaviour to me. If kgdb is active it should have priority The question is less about actually having it as a module, but just if the interfaces are clean enough to allow it as a ...

I agree that it wouldn't be a good idea -- i was just pointing out There tend to be timeouts (e.g. softlock/nmi watchdog at least). I think some of the IPIs eventually time out too. In general losing a lot of time can lead to weird side effects. -Andi --

Note I wrote the one above only as a reply to Linus' proposal, not because I was advocating "live debugging" (or rather I think if you want that just use gdb vmlinux /proc/kcore) I agree with you in principle, but what do you do if one of the CPUs doesn't answer? Ingo seems to think it's ok for the debugger then to just hang too, I think it should eventually time out and debug anyways. Also there are some limits on how much the system should be frozen down. For example if you're ...

i'm glad that there are no other valid-looking (to me) objections left against kgdb-light -v10, other than "it would be nice to have more kgdb (It seems we do have a fundamental disagreement about how kgdb should act: in my opinion it should never break a correct system, while in your opinion apparently it's OK to compromise on that to make debugging easier. (find below more detailed arguments about this.) If you do not change your position about that issue we'll have to agree to ...

I think that part is actually mostly ok now (old kgdb stubs were much worse in this regard) I still think the ultimative proof for this would be working While agreed in theory there are some exceptions: any time an oops happens or a crash dump would happen automatically kgdb should definitely do something very visible. Unfortunately that's not always the case The problem here is that the timeout we were talking about is not integrated into the kgdb event loop, it is rather the ...

indeed it was of a parisc.. :) here is the right one: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc1 # Tue Feb 12 13:11:26 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not ...

Ok fine. Please implement DMA quiescence on kgdb entry then; otherwise the code won't conform to your standards at all. -Andi --

Perhaps we are talking about different things. I will agree that there is no protection against putting a breakpoint in some code that is part of the debugger. That was certainly not what I was talking about. You might be able to perform some protections at the breakpoint set time or request to single step, but that is much more complex than is worth it for the time being. The recursion check guards against basic stupidity or accidental stepping out of a frame you didn't mean to. Also ...

Andi, please refrain from misrepresenting my position, i can speak for myself. As i stated it before, i'm not against adding some configuration on roundup behavior as long as it's clearly add-on optional system policy. In fact i already implemented that in the kgdb-light tree. But if your goal is to create smoke where there is none, then feel free to continue to beat down on this poor strawman, ok? ;-) Meanwhile we'll continue to clean up kgdb to make it ready for an eventual (and ...

yes, that's what i've been doing. When anything became questionable even just a little bit, it was the axe or i changed it to something really obvious and correct. by 2.6.26 kgdb-light will become so neutral to the rest of the kernel yeah. I believe we need to achieve a "known zero impact, 100% trustable" yes - if something locks up, it will be the NMI watchdog starting the debugger eventually - not the other way around. The NMI watchdog is already system policy which can be ...

well, it does not take a mindreader to conclude that nothing we do could possibly result in you "concluding" that kgdb would be ready for a merge ;-) for me it suffices that you've run out of technical arguments and are Ingo --

You're thinking about this totally *wrong*. You definitely do not want to hot-unplug or isolate anything at all. That's explicitly against the whole point of kgdb not changing what it is trying to measure. Just let the other CPU's hang naturally if they need to wait for IPI's etc. What's the downside? That's what you were trying to do in the first place by havign the kgdb callback! So you can't have it both ways. Either serializing other cpu's with kgdb is good (the whole ...

well, this is a small detail, but still you are wrong, and on a correctly working system this will not occur. (if yes, tell me how) KGDB does a very straightforward "all CPUs enter controlled state" transition when the session begins, and at the end an "all CPUs continue" transition. I'm not sure what you mean exactly under "stopping all CPUs for indefinite amount of time" (your statement is sufficiently vague to be hard to counter via specifics) - that does not happen, unless the ...

this is kgdb-light, version -v10 (against Linus-latest), and can be pulled from: git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-kgdb.git shortlog, diffstat and full patch can be found further below. in -v10 i have depleted Andi Kleen's (known ;) pool of last-minute correct (just like SysRq-B can hang) - in -v10 i've fixed this by it's a sensible check, it validates a remote-provided "tid" against the range we accept. (It's a bit superfluous as find_task_by_pid() ...

You more or less just reverted the original patch - so it was obviously more reliable than introducing new stuff as the fix did. But we are at -r1 so I prefer to get the inteded behaviour and not the minmal fix. Sam --

And here comes "no comments" part. ______ --

and by "arbitrary" you mean "like every other kconfig consumer". sounds=20 shell syntax is irrelevant. a bug was introduced and it was fixed. saying= a=20 bug existed is poor reasoning to introduce worse code. =2Dmike

On Feb 12, 2008 4:07 PM, Mike Frysinger <vapier@gentoo.org> wrote: At least this will not crash, if you don't have some variable set. Efficiency there is lesser number of variables(-2 vs +2), that are copied Right. Seems like you are talking about "[quite_]cmd_*", which are commands. Here you've invented such rules for ordinary utility in `filechk`. And by try they've failed due to mixing functionality dependency on having arbitrary variable being set. Shell syntax tried to avoid this, ...

hm, ata_port_wait_eh() started crashing on a testsystem (8-way box): [ 39.324116] Calling initcall 0xc09f41eb: legacy_init+0x0/0x888() [ 39.331868] BUG: unable to handle kernel NULL pointer dereference at 000000e4 [ 39.338811] IP: [<c04a4e11>] ata_port_wait_eh+0x77/0xa2 [ 39.344115] *pde = 00000000 [ 39.347778] Oops: 0000 [#1] SMP [ 39.350769] [ 39.350769] Pid: 1, comm: swapper Not tainted (2.6.25-rc1 #5) [ 39.350769] EIP: 0060:[<c04a4e11>] EFLAGS: 00010246 CPU: 1 [ ...

I think this should be `default y'. So that we don't cause /dev/kmem to magically disappear for `make oldconfig' users. --

On Mon, 11 Feb 2008 14:38:04 -0800 it works great in hiding /dev/kmem ;) And since nothing uses that I didn't notice the other case. Updated patch below From: Arjan van de Ven <arjan@linux.intel.com> Subject: [PATCH] make /dev/kmem a config option This patch makes /dev/kmem a config option; /dev/kmem is VERY rarely used, and when used, it's generally for no good (rootkits tend to be the most common users). With this config option, users have the choice to disable /dev/kmem, saving some ...

Ah, ok. Thanks for testing. :-) Can you please check if the current mainline with the following patch applied works on your box? Thanks, Rafael --- drivers/acpi/hardware/hwsleep.c | 1 + 1 file changed, 1 insertion(+) Index: linux-2.6/drivers/acpi/hardware/hwsleep.c =================================================================== --- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c +++ linux-2.6/drivers/acpi/hardware/hwsleep.c @@ -616,6 +616,7 @@ acpi_status ...

OK, thanks. Since _GTS and _BFS don't seem to be defined in your box's BIOS, please try to apply the appended patch on top of the revert and see if that breaks things again. Thanks, Rafael --- drivers/acpi/hardware/hwsleep.c | 11 ----------- 1 file changed, 11 deletions(-) Index: linux-2.6/drivers/acpi/hardware/hwsleep.c =================================================================== --- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c +++ ...

Confirmed with 0.14-8-g3737366. Thanks! Benny Oh, and I really liked the fact that you print the patch file name --

It's a trivial dumb module which does nothing but loads and unloads. I redid ftest03 later without any suspicious activity and it oopsed the --

<snip testing> Argh, I've submitted an old version of the patch missing changes in dir.c. Below is the missing hunk. Does UDF work for you with it? Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR --- Patch cleaning up UDF directory offset handling missed modifications in dir.c (because I've submitted an old version :(). Fix it. Signed-off-by: Jan Kara <jack@suse.cz> diff --git a/fs/udf/dir.c b/fs/udf/dir.c index 4b44e23..8d8643a 100644 --- a/fs/udf/dir.c +++ ...

Thanks Acked-by: Ron Mercer <ron.mercer@qlogic.com> --

[skipping the populate_rootfs discussion as it seems you have a better handle on that than me] Sorry, I misparsed the comment. I took it for the usual I'm too lazy to put something that could load firmware into initramfs excuse. But thinking about it is there a reason acpi initialization needs to happen so early that we can't even have userspace in initramfs running? But if we can't use real userspace this could should at least be written like the pseudo-userspace in init/do_mounts*.c, ...

Does this not happen with the patch reverted? I'd be really surprised if this had any effect on your fans... You could always just revert the patch you bisected down to from 2.6.24-git20 (it just closes a race in hugetlbfs code, which you're not going to hit with the commands below), Nor am I. You might be able to bisect it down by just putting # CONFIG_HUGETLBFS is no set in your .config and seeing where it was introduced, that will avoid the sysctl that had the BUG ...

Excellent. Your patch fixed it for me. Thanks, Miles --

And how exaclty does it work around ? By setting the binary cmos clock I'm not opposing the patch, I merily asked for a removal of the never Picked the whole lot up. Thanks, tglx --

There is a strong dependency on execution order in this testcase. Between cpu affinity and giving the child a little head start to reduce the chance (100% if child wakes on same CPU and doesn't preempt parent) of busy wait, modified testcase behaves. I don't think I should need the CPU affinity, but I do. If you plunk a usleep(1) in prior to calling thread_func() does your testcase performance change radically? If so, I wonder if the real application has the same kind of ...

On Fri, 08 Feb 2008 15:37:40 -0800 I fixed a bunch of rejects in "[PATCH 1/4] cpufreq: change cpu freq tables to per_cpu variables" and it compiles OK. But this one was beyond my should-i-repair-it threshold, sorry. --

It did not sneak through, because the problem does not exist in the OFED git. The following commit was performed to git://git.openfabrics.org/ofed_1_3/linux-2.6.git on Sept 25, 2007: ======================================= commit 4a5709b81dfd249c98271801ddc01decb7acd466 Author: Eli Cohen <eli@mellanox.co.il> Date: Tue Sep 25 12:41:30 2007 +0200 add missing include file. ia64 requires it. Signed-off-by: Eli Cohen <eli@mellanox.co.il> diff --git a/drivers/net/mlx4/alloc.c ...

c) is out, because this has to be executed after the early generic code and before the late generic code. b) would be my first choice, and yes, it would be a good thing to have a generalized mechanism for this. For the registrant, it's pretty easy: just add a macro that adds a pointer to a named section. We then need a way to get the base address and length of each such section in order to be able to execute each function in sequence. -hpa --

> > Chelsio's T3 HW doesn't support this. > Not so far I guess but it could be equipped with these features right? I don't know anything about the T3 internals, but it's not clear that you could do this without a new chip design in general. Lot's of RDMA devices were designed expecting that when a packet arrives, the HW can look up the bus address for a given memory region/offset and place the packet immediately. It seems like a major change to be able to generate a "page fault" ...

Chelsio's T3 HW doesn't support this. Steve. --

That's really broken then. Common i386 boxes these days have multiple PCI domains, it's not all that uncommon at all. I'm guessing that bad things would happen if you picked the wrong pci I think the spec needs to be fixed. Or at least clarified (is it domain 0 only?) thanks, greg k-h --

On Sat, 09 Feb 2008 08:30:40 -0500 afacit elevator_init() will not trigger a request_module(). And you really do want to trigger the request_module() here. Perhaps the block layer should provide a means of doing so? --

On Fri, 08 Feb 2008 16:04:29 +0000 time_after()? --

test results: i've turned the WMI options back on earlier today on latest -git which has your patch above, and those crashes i reported disappeared. So the problem is fixed. Ingo --

Yes - that's a better fix. -Carlos -- E-Mail: carlos@strangeworlds.co.uk Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D --

Neither of these things exist at the moment so lets stick to the existing code which is scheduled for 2.6.26 and which finally allows removal of ppc specific ide hacks from arch/{powerpc,ppc} (500 LOC gone, patches to be posted this week), not to mention other nice changes in the future... Thanks, Bart --

Pegasos doesn't use the pmac ide which is what we were discussing. It uses a VIA IDE which uses a normal PRD table. So something else must have broken... Ben. --

Well, I have serious problem on a Pegasos which appeared some time between 2.6.24 and 2.6.25-rc1: at boot I get an infinite string of hdb: empty DMA table? I'm trying to bisect it right now. --

On Wed, 13 Feb 2008 08:04:07 +1100 Unfortunately you need a degree in dentistry to open a Macintosh up and fix it otherwise we would have support by now. Alan --

So what you want is all XFS processing (for a given filesystem, presumably) on a limited set of cores (ideally 1) and all block and SCSI processing (for a given device) on a similarly limited set. On Altix, that was far more important than having the interrupt and issue CPU be close to the hardware -- at least with typical LSI or Qlogic controllers where there are only one or two MMIO reads per command issued, and completions can be stacked up. There is still an advantage to being close to ...

Ok you do have a point there. The GPT users win of course, since it uses LBA, not cyls, so the number of lost bytes is generally below a cyl. On the other hand, the H and S of CHS could be lowered and S increased, e.g. divide H by 2, divide S by 2, multiply S by 4. This gives a finer Well it was designed for a different system initially with a different style of booting. --

From: Jan Engelhardt <jengelh@computergmbh.de> You cannot specify partitions on LBA boundaries on sparc, the Sun disk label specifies the partition start points in cylinders. --

From: Chris Mason <chris.mason@oracle.com> Sure. --

The CRC32C implementation in the btrfs progs is different from the one in the kernel, so obviously nothing can possibly work on big-endian. This is getting less and less fun by the minute, I simply wanted to test btrfs on Niagara :-/ Here is a patch to fix that: --- vanilla/btrfs-progs-0.12/crc32c.c 2008-02-06 08:37:45.000000000 -0800 +++ btrfs-progs-0.12/crc32c.c 2008-02-12 01:19:33.000000000 -0800 @@ -91,13 +91,11 @@ static const u32 crc32c_table[256] = { * crc using table. */ ...

It was a request from hpa, and he clearly had something in mind. He kindly offered to review the disk format for bootloaders and other lower level issues but I asked him to wait until I firm it up a bit. From my point of view, 0 is a bad idea because it is very likely to conflict with other things. There are lots of things in the FS that need deep thought,and the perfect system to fully use the first 64k of a 1TB filesystem isn't quite at the top of my list right now ;) Regardless of ...

From: David Miller <davem@davemloft.net> Actually it seems this is only a problem with mkfs.btrfs, it clears out the first 64 4K chunks of the disk for whatever reason. The following patch cures the disk label spamming problem for me: --- vanilla/btrfs-progs-0.12/mkfs.c 2008-02-06 08:37:45.000000000 -0800 +++ btrfs-progs-0.12/mkfs.c 2008-02-12 00:07:43.000000000 -0800 @@ -210,7 +210,8 @@ int main(int ac, char **av) exit(1); } memset(buf, 0, sectorsize); - for(i = 0; i < 64; i++) ...

It is a good idea to remove supers from other filesystems. I also need to add zeroing at the end of the device as well. Looks like I misread the e2fs zeroing code. It zeros the whole external log device, and I assumed it also zero'd out the start of the main FS. So, if Btrfs starts zeroing at 1k, will that be acceptable for you? -chris --

From: Jan Engelhardt <jengelh@computergmbh.de> You actully do unless you want to lose significant chunks of your disk space. The Sun disk label only allows you to specify the start of a partition in cylinders, so if you want to use a filesystem like XFS you have to start the partition on cylinder 1 which can be many blocks into the disk. That entire first cylinder is completely wasted. What XFS does by putting the superblock at zero is simply does not take these kinds of issues into ...

From: Jan Engelhardt <jengelh@computergmbh.de> All of your beliefs are unfortunately without the understanding of restrictions that exist in several partition layouts such as the Sun disk label one. You have to start the superblock somewhere other than zero or else you lose a huge chunk of your disk, and furthermore a zero based partition is what all of the Sun disk label creating programs make by default. "I make a default disk label, I put btrfs or XFS on there, my disk label is ...

x86 MSDOS partition table layout starts counting with sector 1, which is (not so intuitively) starting at 0x7e00 (and there's no sector 0, probably for safety). Well, each ptable format with its own quirks. --

From: Chris Mason <chris.mason@oracle.com> Any page size larger than 4K will not work with btrfs. All of the extent stuff assumes that PAGE_SIZE <= sectorsize. I confirmed this by forcing mkfs.btrfs to use an 8K sectorsize on sparc64 and I was finally able to successfully mount a partition. With 4K there are zero's in the root tree node header, because it's extent's location on disk is at a sub-PAGE_SIZE multiple and the extent code doesn't handle that. You really need to start ...

I've had requests to move the super down to 64k to make room for bootloaders, which may not matter for sparc, but I don't really plan on different locations for different arches. 4k aligned is important given that sector sizes are growing. -chris --

From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Please look at Linus's current tree, I believe I have things in a working state, and the DMA mask portions should be easier to add now. --

On Fri, 8 Feb 2008 23:46:19 -0800 I guess I can put the blame for this on Jens' commit (45711f1a) ;) On a serious note, it seems that two scatter lists per request leaded to this bug. Can the scatter list in struct ub_request be removed? --

boots! For some reason, i had to apply it by hand (to 2.6.24.2), and i was too stupid to examine how to produce a new patch. Looks like i have to read the documentation at kernelnewbies.org... Anyway, the patch fits perfectly and now UDMA/33 (due to 40wire-cable, vendor says UDMA/100 should work either) on a HDD using pata_cs5536 just works =3D) --=20 Jabber: elch@ein-elch.de PGP: 0x63FC728D Tel: 0170/238 30 53 http://www.g-radtke.name

All, Sorry this took so long. I have attached the Kconfig changes requested by Andi, appended to the original patch. -- Russell Leidich

PS: This behavior is undocumented and we shouldn't rely on it. -- Stefan Richter -=====-==--- --=- -==-- http://arcgraph.de/sr/ --

And I agree wholeheartedly with Kristen. Luben --

On Tue, 12 Feb 2008 12:45:35 -0600 You are sort of wrong. we exposed a sysfs entry to enable sofware controlled activity LED, then the driver was responsible for turning it I understand what you are trying to do - I guess I just doubt the value you've added by doing this. I think that there's going to be so much customization that system vendors will want to add, that they are going to wind up adding a custom library regardless, so standardising those few things won't buy us anything. --

It depends ... if you actually have a use for the customisations, yes. If you just want the basics of who (what's in the enclousure), what (activity) and where (locate) then I think it solves your problem almost entirely. So, entirely as a straw horse, tell me what else your enclosures provide that I haven't listed in the four points. The SES standards too provide a huge range of things that no-one ever seems to implement (temperature, power, fan speeds etc). I think the users of ...

As it's now post -rc1 and not a 100% obvious thing, I tend to hang onto such patches for a week or so before sending up to Linus Should this be backported to 2.6.24.x? If so, the reasons for such a relatively stern step should be spelled out in the changelog for the -stable maintiners to evaluate. Thanks. --

Hi Andrew # this is second post of the same patch. this is backport from -mm to mainline. original patch is http://marc.info/?l=linux-kernel&m=120250000001182&w=2 my change is only line number change and remove extra space. please ack. ============================ [PATCH] 2.6.24 - mempolicy: silently restrict nodemask to allowed nodes V2 -> V3: + As suggested by Kosaki Motohito, fold the "contextualization" of policy nodemask into mpol_check_policy(). Looks a little cleaner. ...

PING. -- tejun --

Doh, someone please hand me a brown paper bag. My first series of patches had this but it got dropped when I rebased it over various janitor cleanups. The patch looks obviously correct, thanks. --

The patch: "gdth: switch to modern scsi host registration" missed one simple fact when moving a way from scsi_module.c. That is to call scsi_scan_host() on the probed host. With this the gdth driver from 2.6.24 is again able to see drives and boot. Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Tested-by: Joerg Dorchain: <joerg@dorchain.net> Tested-by: Stefan Priebe <s.priebe@allied-internet.ag> Tested-by: Jon Chelton <jchelton@ffpglobal.com> --- drivers/scsi/gdth.c | 9 ...

Will do, give me a few hours... thanks, greg k-h --

What happens if I ship a binary-only program that uses *either* a GPL library or a custom library with the same API? "If you don't have the Frobozz-Foo library, you'll have to supply your own work-alike".... (Note that this is in fact the *usual* case - very few programs actually check that they are linking against a Genuine GPL(tm) library, they just want the *API*, so providing a work-alike is sufficient....)

I have no preference whether a single /proc/capabilities, or the current approach. However, this idea requires a bit more cost to lookup a capability not sequencially. Thank, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> --

Sysfs does not support to create symbolic links to regular files now. The sysfs_create_link() is a function to create a symbolic link on sysfs. However, it requires two kobjects as its arguments. One is to specify its parent directory, the other is to specify the target of indirection. It means the indicated target have to be a directory. At include/linux/sysfs.h: int __must_check sysfs_create_link(struct kobject *kobj, struct kobject *target, const char ...

Hi, I don't think that's necessarily a contradiction, if we keep it to confronting the problem. A simple patch wouldn't have provided any further understanding of the problem compared to what I already said. You would have seen what the patch does (which I described already differently), but not really why it does that. In this sense I prefer to force the confrontation of the problem. I'm afraid a working patch would encourage to simply ignore the problem, as your problem at hand ...

Hello Nicholas, Are you sure that the LIO-SE kernel module source code is ready for inclusion in the mainstream Linux kernel ? As you know I tried to test the LIO-SE iSCSI target. Already while configuring the target I encountered a kernel crash that froze the whole system. I can reproduce this kernel crash easily, and I reported it 11 days ago on the LIO-SE mailing list (February 4, 2008). One of the call stacks I posted shows a crash in mempool_alloc() called from jbd. Or: the crash is ...

It is a piece of hardware with a firmware/hypervisor abstraction layer on top. The hypervisor provides virtualization interfaces to add and remove ethernet adapters and ports. Each port is represented in the open firmware device tree (OFDT) as a subnode of the ehea adapter node. System P has a userspace DLPAR application communicating with firmware, the kernel, and the hardware management console to change all that on the flight. This tool needs a capability to identify which open ...

Hi Jiri, I tried to fix the compilation warnings on your patch, and was thus successful in getting the Sleep key to work as expected (yay!), i.e. it doesn't repeat endlessly anymore. I can now get my machine to sleep and wake up correctly! However, the TV key is still not seen by the X server (tested using xev and evrouter). I'm attaching 3 files: * hid-input.c.patch: your patch with compilation warnings and errors fixed, against 2.6.24-rc6. * kern0.log: hid-debug and evbug output for ...

Hi Edward, Have you seen the analysis of the Hans Reiser trial at: http://linuxhelp.150m.com/politics/ReiserTrialSummaryAnalysis.htm http://linux.50webs.org/politics/ReiserTrialSummaryAnalysis.htm I am much interested in your views on the article. ________________________________________________________________________ More new features than ever. Check out the new AOL Mail ! - http://webmail.aol.com --