From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Use asm/syscall.h interfaces that do the same things. Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> --- arch/x86/kernel/signal_32.c | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c index b21070e..3e4a688 100644 --- a/arch/x86/kernel/signal_32.c +++ b/arch/x86/kernel/signal_32.c @@ -27,6 +27,7 @@ #include <asm/uaccess.h> #include ...

From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> make NR_restart_syscall macro for cosmetic unification of handle_signal(). Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> --- arch/x86/kernel/signal_32.c | 3 ++- arch/x86/kernel/signal_64.c | 6 +++--- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c index 76d05d7..bd9b650 100644 --- a/arch/x86/kernel/signal_32.c +++ ...

From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> implement signal_fault() for 32bit. Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> --- arch/x86/kernel/signal_32.c | 18 +++++++++++++++++- include/asm-x86/ptrace.h | 4 ++-- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c index 3e4a688..76d05d7 100644 --- a/arch/x86/kernel/signal_32.c +++ b/arch/x86/kernel/signal_32.c @@ -243,7 +243,7 @@ ...

Sam, allmodconfig automatic testing is on fire! I use KCONFIG_ALLCONFIG= heavily to pin some config options to N and now CONFIG_MODULES aren't set to y after allmodconfig. Step to reproduce: rm .config rm 1 touch 1 make KCONFIG_ALLCONFIG=1 allmodconfig >/dev/null grep CONFIG_MODULES .config CONFIG_MODULES is =n after this patch, which is strange given definition of allmodconfig. If KCONFIG_ALLCONFIG= is removed, MODULES are back to ...

* Cleanup cpumask_t usages in smp_call_function_mask to remove stack overflow problem when NR_CPUS=4096. This removes over 1000 bytes from the stack with NR_CPUS=4096. Based on 2.6.27-rc5-git6. Applies to linux-2.6.tip/master (with FUZZ). Signed-off-by: Mike Travis <travis@sgi.com> --- kernel/smp.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) --- linux-2.6.orig/kernel/smp.c +++ linux-2.6/kernel/smp.c @@ -303,7 +303,7 @@ static int ...

* With the previous cleanups, NR_CPUS=4096 can now be enabled again. Based on 2.6.27-rc5-git6. Applies to linux-2.6.tip/master (with FUZZ). Signed-off-by: Mike Travis <travis@sgi.com> --- arch/x86/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- linux-2.6.orig/arch/x86/Kconfig +++ linux-2.6/arch/x86/Kconfig @@ -587,8 +587,8 @@ config MAXSMP If unsure, say N. config NR_CPUS - int "Maximum number of CPUs (2-512)" if !MAXSMP - range 2 512 + int ...

Hi Andrew, I found that 2.6.27-rc5-mm1 does not compile with gcc 3.4.6. The error is: CC kernel/sched.o kernel/sched.c: In function `start_rt_bandwidth': kernel/sched.c:208: sorry, unimplemented: inlining failed in call to 'rt_bandwidth_enabled': function body not available kernel/sched.c:214: sorry, unimplemented: called from here make[1]: *** [kernel/sched.o] Error 1 make: *** [kernel] Error 2 It seems that the gcc 3.4.6 requires full inline definition before first usage. The ...

Hello. That also will do. Though 'struct pci_dev' seems preferrable as it's always pre-calculated by the callers and otherwise needed in them in 4 Could be just: MBR, Sergei --

Looks fine to me now, as far as I've looked, I guess there'll be some odd fixes required etc. but we can figure that out. johannes

Hi all, We're hitting some bad behavior in NFS v3. The situation is this: machine A - NFS server machine B - NFS client (writer) machine C - NFS client (reader) (all machines x86 SMP) machine A exports a directory on ext3 filesystem: /srv/home 192.168.0.0/24(rw,sync,no_subtree_check) machines B and C mount that directory normally mount A:/srv/home /mntpnt machine B opens a file and writes to it (think a log file) machine C stats that ...

I have the latest Fedora 9 kernels on two clients, mounting via NFSv3 using "actimeo=600" (for other reasons). The server is OpenSolaris 2008.5. reader.py reported zeroes in the test file after about 5 minutes. Looking at the file a little later, I don't see any problems with it. Since your scripts are not using any kind of serialization (ie file locking) between the clients, I wonder if non-determinant behavior is to be expected. -- Chuck ...

Hi, Awesome. Thanks for testing! Our actime is much shorter which is Hmm... yep. I don't know what guarantees we want to make. The behavior doesn't seem to be consistent with older kernels though... so I'm thinking it might be a bug. We hit this particular issue because we have scripts which essentially 'tail -f' log files looking for errors. They miss log messages (and see corrupted ones) b/c of the NULLs. That's also why there is no serialization.... we don't need it when ...

Hum, kernel says: http://img177.imageshack.us/my.php?image=overlappingus2.jpg Overlapping early reservations b98000-eff266 RAMDISK to 200000-d09cf7 TEXT DATA BSS It would appear that the initramfs is overlapping the kernel itself, is the boot loader (LILO) doing something stupid? Luca --

Linus, Please pull the latest x86-fixes-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus which fixes sporadic boot-time lockups on certain boxes. Thanks, Ingo ------------------> Chuck Ebbert (1): x86: add io delay quirk for Presario F700 arch/x86/kernel/io_delay.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/io_delay.c ...

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git fixes ...to receive: commit de24125dd0a452bfd4502fc448e3534c5d2e87aa Author: Yuri Tikhonov <yur@emcraft.com> Date: Fri Sep 5 08:15:47 2008 -0700 async_tx: fix the bug in async_tx_run_dependencies Should clear the next pointer of the TX if we are sure that the next TX (say NXT) will be submitted to the channel too. Overwise, we break the chain of descriptors, ...

Ugh, that's oversimplified and doesn't save much... I rather meant the following prototype: static struct hpt_info *hpt3xx_get_info(struct pci_dev *dev) return info + 1; else return info; or return hwif_dev == host_dev ? info + 1 : info; --

On Wed, Sep 3, 2008 at 4:30 PM, Luis R. Rodriguez Doh this is spurious, I forgot to remove the undef as I am not using it. Going to resent without this. Luis --

You make it sound like it's just some minor technical hurdle that needs to be addressed. But from all analysis of these issues I've seen so far it's extremly hard and all possible solutions have serious issues. So before doing some baby steps there should be at least some general idea how this thing is supposed That's the easy stuff. The hard parts are all the kernel objects that you cannot move. -Andi --

So far, I have tested it on a 2-node IBM x460, 2-node IBM x3950, and a 4-node IBM x3950 M2 and have been able to successfully offline and re-online all memory sections marked as removable multiple times with no apparent problems. By directing the change to -mm our hope is that others will try it The inability to offline all non-primary node memory sections certainly needs to be addressed. The pgdat removal work that Yasunori Goto has started will hopefully continue and help resolve this ...

I am not sure if I understand why you appear to be opposed to enabling the hotremove function before all the issues related to an eventual goal of being able to free all memory on a node are addressed. Even in the absence of solutions for these issues it seems like there could still be other possible benefits such as the ability to selectively expand and shrink available memory for testing or debugging purposes. I believe it would also be helpful to those working on or testing possible ...

That means you can never put any slab data on specific nodes. And all the kernel subsystems on that node will not ever get local memory. How are you going to solve that? And if you disallow kernel allocations in so large memory areas you get many of the highmem issues that plagued 32bit back in the 64bit kernel. There are lots of other issues. It's quite questionable if this Ok for hypervisors you can do it reasonably easy on x86 too, but it's likely that some hypercall interface is ...

so this will break the build on 32-bit, if CONFIG_MEMORY_HOTREMOVE=y? mm/memory_hotplug.c assumes that remove_memory() is provided by the hm, nothing appears to be arch-specific about this trivial wrapper around offline_pages(). Shouldnt this be moved to the CONFIG_MEMORY_HOTREMOVE portion of mm/memory_hotplug.c instead, as a weak function? That way architectures only have to enable ARCH_ENABLE_MEMORY_HOTREMOVE - and architectures with different/special needs can override ...

Resending with linux-kernel@vger.kernel.org and x86@kernel.org copied this time. No changes other than this and modified Subject line. The only response so far on linux-mm has been an Acked-by: from Yasunori Goto <y-goto@jp.fujitsu.com> Add memory hotremove config option to x86_64 Memory hotremove functionality can currently be configured into the ia64, powerpc, and s390 kernels. This patch makes it possible to configure the memory hotremove functionality into the x86_64 kernel as ...

Same problems as previously reported, except now it's gotten worse. Where before the adapter would lockup only when setting encryption keys, now it locks up intermittently even without using encryption using the native linux iwl3945 driver This same kernel now causes ndis drivers to crash under ndiswrapper (which wrked before) with bugs being reported in the "workqueue" functions. The specific area where I tracked down some serious bugginess and sickness was here (I LOVE MY SHINY NEW ...

Both iSCSI and Fibre Channel make use of 24-bit big-endian values in frame headers. This patch defines __be24 and __le24 typedefs for a structure wrapped around a 3-byte array, and macros to convert back and forth to a 32-bit integer. The undefs in iscsi_proto.h are because of the different calling convention for the existing hton24 macro in the iSCSI code. iSCSI will be converted in a subsequent patch. Signed-off-by: Chris Leech <christopher.leech@intel.com> --- ...

The calling convention of hton24 is different now, it takes a single u32 as an argument and evaluates to a __be24 lvalue. Signed-off-by: Chris Leech <christopher.leech@intel.com> --- drivers/scsi/iscsi_tcp.c | 8 ++++---- drivers/scsi/libiscsi.c | 6 +++--- include/scsi/iscsi_proto.h | 46 ++++++++++++++++++-------------------------- 3 files changed, 26 insertions(+), 34 deletions(-) diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c index 2a2f009..c9d6e96 ...

Some DSS results from a 32-way ia64 machine set up to try and analyze Oracle OLTP & DSS loads (128GB RAM, >200 disks). The data collected was the elapsed time for DSS runs w/ 128 MBRs and 128 Readers, running on a kernel generated from Jens Axboe's origin/for-2.6.28 tree. I alternated runs, setting rq_affinity to 0 and 1 for all disks at the beginning of each run. There are a total of 68 data points for each alternative, and the overall results show a decided improvement for this type of load ...

No, that's just wrong pointer arithmetics there: struct hpt_info *info = host->host_priv + (hwif->dev == host->dev[1]); The 'host_priv' is declared as 'void *', hence in case the condition abobe is true, there will be added only 1 to host->host_priv, not sizeof(struct hpt_info) as it should've been... MBR, Sergei --

Hello. Uh, I wonder where did it get those 33 MHz DPLL base -- there's simply no such base. Looks like memory addressed by .host_priv got corrupt... MBR, Sergei --

This patch adds the capability flag to the capability list for dynamic LPAR memory remove to enable this feature. Signed-off-by: Hannes Hering <hering2@de.ibm.com> --- diff -Nurp -X dontdiff linux-2.6.27-rc5/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h --- linux-2.6.27-rc5/drivers/net/ehea/ehea.h 2008-08-29 00:52:02.000000000 +0200 +++ patched_kernel/drivers/net/ehea/ehea.h 2008-09-05 15:33:12.000000000 +0200 @@ -40,13 +40,13 @@ #include <asm/io.h> #define ...

applied to tip/irq/sparseirq, thanks. Ingo --

On Aug 27, 3:06pm, Jeff Dike wrote: } Subject: Re: Is SKAS still required for UML Any thoughts or timetable on SKAS4 going mainline? I suspect the SKAS3 patches are even remotely compatible with current mainline kernels. We've had good success with SKAS4 on 2.6.24.x but thats even getting awful long in the tooth at this point. I've been meaning to try the last copy of the SKAS4 patch against 2.6.26.x but haven't found the time yet to wade through the flock of rejects which I would ...

applied to tip/irq/sparseirq - thanks Dean! Ingo --

need to change irq to int too diff --git a/drivers/pci/htirq.c b/drivers/pci/htirq.c index 7c5aef1..468115d 100644 --- a/drivers/pci/htirq.c +++ b/drivers/pci/htirq.c @@ -109,7 +109,7 @@ int __ht_create_irq(struct pci_dev *dev, int idx, ht_irq_update_t *update) u32 data; int max_irq; int pos; - unsigned int irq; + int irq; unsigned int irq_want; pos = pci_find_ht_capability(dev, HT_CAPTYPE_IRQ); --

Gregory did a similar fix a while ago, but that caused grief of some kind.. Greg, can you recollect why we pulled it? I can't seem to find it. --

sched: Fix __load_balance_iterator() for cfq with only one task. From: Gautham R Shenoy <ego@in.ibm.com> The __load_balance_iterator() returns a NULL when there's only one sched_entity which is a task. It is caused by the following code-path. /* Skip over entities that are not tasks */ do { se = list_entry(next, struct sched_entity, group_node); next = next->next; } while (next != &cfs_rq->tasks && !entity_is_task(se)); if (next == &cfs_rq->tasks) return ...

Reduce the amount of partial register accesses in the NR_CPUS < 256 case, and slightly weaken resource dependencies in the other case. Signed-off-by: Jan Beulich <jbeulich@novell.com> Cc: Nick Piggin <npiggin@suse.de> --- include/asm-x86/spinlock.h | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) --- linux-x86.orig/include/asm-x86/spinlock.h +++ linux-x86/include/asm-x86/spinlock.h @@ -21,8 +21,10 @@ #ifdef CONFIG_X86_32 # define LOCK_PTR_REG "a" +# define ...

In addition to these changes I doubt the 'volatile' on all the ticket lock asm()-s are really necessary. Signed-off-by: Jan Beulich <jbeulich@novell.com> Cc: Nick Piggin <npiggin@suse.de> --- include/asm-x86/spinlock.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- linux-x86.orig/include/asm-x86/spinlock.h +++ linux-x86/include/asm-x86/spinlock.h @@ -101,7 +101,7 @@ static __always_inline int __ticket_spin "1:" "sete %b1\n\t" "movzbl ...

applied to tip/x86/spinlocks - thanks Jan! Ingo --

Make the x86_{phys,virt}_bits common for 32- and 64-bits, and use the former in ioremap's phys_addr_valid() check also on 32bit/PAE. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- arch/x86/kernel/cpu/common.c | 17 +++++++++++++++++ arch/x86/mm/ioremap.c | 15 ++++++--------- include/asm-x86/processor.h | 4 ++-- 3 files changed, 25 insertions(+), 11 deletions(-) --- linux-2.6.27-rc5/arch/x86/kernel/cpu/common.c 2008-08-21 14:37:29.000000000 +0200 +++ ...

%llx and the like cannot be used on u64-derived data types - they must be cast to long long explicitly for arch-es where u64 is a typedef of unsigned long (ia64 is where I observed the problem). Signed-off-by: Jan Beulich <jbeulich@novell.com> --- drivers/pci/probe.c | 16 +++++++++++++--- drivers/pci/setup-bus.c | 6 +++++- 2 files changed, 18 insertions(+), 4 deletions(-) --- linux-2.6.27-rc5/drivers/pci/probe.c 2008-08-21 14:37:32.000000000 +0200 +++ ...

- first of all, add .init.rodata to INIT_DATA - second, add .init.rodata and .init.setup to modpost's ALL_INIT_DATA_SECTIONS - third, generalize the pattern used by modpost's *INIT_SECTIONS and EXIT_SECTIONS, and use them for ALL_{INIT,EXIT}_SECTIONS - fourth, warn about cross references between .cpuinit.* and .meminit.*+ - finally, put all __setup_str* symbols in .init.rodata (and mark them 'const') Signed-off-by: Jan Beulich <jbeulich@novell.com> --- ...

Many of the PDA class SoC are often in the 200-400 MHz class, although faster variants are turning up there's an large contingent of similar Well, it isn't really from me, I've been doing the maintainance and required I've never really liked that PIO tasklet, and was planning on vanquishing it (or at least allowing it to be configured off) in the next release, I I'm not sure if I'll get the time to look at this before the new kernel is released... anyway DMA may not be much of a win for ...

On Fri, 05 Sep 2008 13:45:55 +0200 Why doesn't santa bring me any of the nice toys everyone else seems to The latency improvement is indeed impressive, but I am not convinced it is worth it. An asynchronous API is much more complex and difficult to work with (not to mention reading and trying to make sense of existing code), and SDIO is not even an asynchronous bus to begin with. Also, as the latency is caused by CPU cycles, the problem will be reduced as hardware improved. I do like ...

Yes. For the DMA-capable S3C SPI driver I wrote, I added some thresholds, so for smaller transfers than a certain number of bytes, I skip DMA and just do a polled/interrupt transfer instead. For short transfers at high clock rates it's not even worth getting an interrupt per byte, it's better to just busy wait for each byte, since the interrupt overhead is larger than the time between each byte. A SDIO CMD/response packet is 48 bits, so at 25 MHz that is only about 4 us and I think ...

Well, nobody answered. Anyway, as suspected with TCP connections it seems that current->pid produces 0 very often after the first initial packet (SYN). I take this to mean, that the TCP engine is being executed on some interrupt context? Now I'm wondering how SELINUX manages to get the secmark right, as the code in iptables seems to eventually need the current task context? Something tricky being made using the SECMARK and CONNSECMARK? It seems to trust, that at least the first packet has ...

Hi Erik, I have run those tests on i686, x86_64 & ppc64 running 2.6.26 kernel. And here are my observations: 1) Built and ran perfectly on X86_64: # uname -a Linux 2.6.26-autokern1 #1 SMP PREEMPT Fri Sep 5 09:40:31 UTC 2008 x86_64 GNU/Linux # ./disable-tsc-test rdtsc() == 9766811077875 prctl(PR_GET_TSC, &tsc_val); tsc_val == PR_TSC_ENABLE rdtsc() == 9766811184102 prctl(PR_SET_TSC, PR_TSC_ENABLE) rdtsc() == 9766811200743 prctl(PR_SET_TSC, PR_TSC_SIGSEGV) rdtsc() ...

I tried to build a kernel without it, and it still takes the exact same amount to boot, I've also tried unloading usb drivers and it takes the --

Please don't remove the blank line here. I'll fix this up locally. Other than that Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> --

Thanks, I will follow this procedure as your mentioned. I just want to make it easier for your git-am operation, -:))) -Bryan --

Thanks. Please, when sending updates to this patch series could you send incremental patches as I asked? There is a lot of code here, most of which has already been acked and is not changing so showing only the changes that have been made will greatly simplify the review process. --

From: Cliff Cai <cliff.cai@analog.com> Signed-off-by: Cliff Cai <cliff.cai@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- sound/soc/Kconfig | 2 +- sound/soc/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig index f743530..0adbc92 100644 --- a/sound/soc/Kconfig +++ b/sound/soc/Kconfig @@ -31,7 +31,7 @@ source "sound/soc/sh/Kconfig" source "sound/soc/fsl/Kconfig" source ...

From: Cliff Cai <cliff.cai@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> Signed-off-by: Cliff Cai <cliff.cai@analog.com> --- sound/soc/blackfin/bf5xx-ac97-pcm.c | 428 +++++++++++++++++++++++++++++++++++ sound/soc/blackfin/bf5xx-ac97-pcm.h | 29 +++ 2 files changed, 457 insertions(+), 0 deletions(-) create mode 100644 sound/soc/blackfin/bf5xx-ac97-pcm.c create mode 100644 sound/soc/blackfin/bf5xx-ac97-pcm.h diff --git a/sound/soc/blackfin/bf5xx-ac97-pcm.c ...

From: Cliff Cai <cliff.cai@analog.com> Signed-off-by: Cliff Cai <cliff.cai@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- sound/soc/blackfin/Kconfig | 85 +++++++++++++++++++++++++++++++++++++++++++ sound/soc/blackfin/Makefile | 20 ++++++++++ 2 files changed, 105 insertions(+), 0 deletions(-) create mode 100644 sound/soc/blackfin/Kconfig create mode 100644 sound/soc/blackfin/Makefile diff --git a/sound/soc/blackfin/Kconfig b/sound/soc/blackfin/Kconfig new file mode ...

From: Cliff Cai <cliff.cai@analog.com> SPORT is a serial port which can support serveral serial communication protocols. It can be used as I2C/PCM/AC97. For further information, please look up the HRM. Signed-off-by: Cliff Cai <cliff.cai@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- sound/soc/blackfin/bf5xx-sport.c | 1028 ++++++++++++++++++++++++++++++++++++++ sound/soc/blackfin/bf5xx-sport.h | 192 +++++++ 2 files changed, 1220 insertions(+), 0 deletions(-) create mode ...

From: Cliff Cai <cliff.cai@analog.com> Signed-off-by: Cliff Cai <cliff.cai@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- sound/soc/blackfin/bf5xx-i2s-pcm.c | 288 ++++++++++++++++++++++++++++++++++++ sound/soc/blackfin/bf5xx-i2s-pcm.h | 29 ++++ 2 files changed, 317 insertions(+), 0 deletions(-) create mode 100644 sound/soc/blackfin/bf5xx-i2s-pcm.c create mode 100644 sound/soc/blackfin/bf5xx-i2s-pcm.h diff --git a/sound/soc/blackfin/bf5xx-i2s-pcm.c ...

Explicitly define the struct page fields which buddy uses when it owns pages. Defines a new anonymous struct to allow additional fields to be defined in a later patch. Signed-off-by: Andy Whitcroft <apw@shadowen.org> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Reviewed-by: Rik van Riel <riel@redhat.com> Reviewed-by: Christoph Lameter <cl@linux-foundation.org> --- include/linux/mm_types.h | 3 +++ mm/internal.h | ...

When allocating we need to confirm that the zone we are about to allocate from is acceptable to the CPUSET we are in, and that it does not violate the zone watermarks. Pull these checks out so we can reuse them in a later patch. Signed-off-by: Andy Whitcroft <apw@shadowen.org> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Reviewed-by: Rik van Riel <riel@redhat.com> --- mm/page_alloc.c | 62 ...

Looks good, just a few coding sandards issues that I've fixed up locally. --

Hi all, There will be no linux-next tree until at least September 9 (US Central time) as I will be travelling. Changes since next-20080904: The ttydev tree is back since Alan thinks he has fixed Andrew's problem. The dwmw2 tree lost the build breakage that required a revert. The arm tree gained some trivial conflicts (unreported). The block tree lost a conflict but gained a conflict against the scsi tree. I have also applied the following patches for known problems: ftrace: ...

asm/dma-mapping.h guarantees that gart alloc_coherent doesn't get NULL device argument. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> --- arch/x86/kernel/pci-gart_64.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c index 4d08649..0b99d4a 100644 --- a/arch/x86/kernel/pci-gart_64.c +++ b/arch/x86/kernel/pci-gart_64.c @@ -506,9 +506,6 @@ gart_alloc_coherent(struct device *dev, size_t ...

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> --- arch/x86/kernel/pci-nommu.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c index 526b2db..3495f88 100644 --- a/arch/x86/kernel/pci-nommu.c +++ b/arch/x86/kernel/pci-nommu.c @@ -102,6 +102,9 @@ nommu_alloc_coherent(struct device *hwdev, size_t size, if (dma_mask == DMA_24BIT_MASK) gfp |= GFP_DMA; again: + if (gfp & GFP_DMA) + gfp |= ...

This patchset restores some of the current alloc_coherent behaviors that Joerg's x86 patchset (in tip/x86/iommu) changes. The first patch uses __GFP_DMA for NULL device argument (fallback_dev) with pci-nommu. It's a hack for ISA (and some old code) so we need DMA_ZONE. The second patch uses __GFP_NORETRY in the case of GFP_DMA. The third patch is a minor cleanup. I'll send patchset for the rest of alloc_coherent issues this weekend. --

Andi, I guess you made the dma_mask of the fallback_dev 32 bit a long time ago. Is there any reason it cannot be 24 bit? Joerg -- | AMD Saxony Limited Liability Company & Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System | Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: Center | AMD Saxony LLC (Wilmington, Delaware, US) | General ...

On Fri, 5 Sep 2008 17:58:46 +0900 Oops, I messed up the subjects. They should have been: [PATCH 1/3] x86: fix nommu_alloc_coherent allocation with NULL device argument [PATCH 2/3] x86: use __GFP_NORETRY in the case of GFP_DMA with pci-nommu [PATCH 3/3] x86: gart alloc_coherent doesn't need to check NULL device argument --

I agree with this patch in principle. It fixes the problem. But I think we should evaluate if we can change the dma_mask of the fallback_dev to 24 bit. Please leave these spare lines where they are. They increase the -- | AMD Saxony Limited Liability Company & Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System | Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: ...

applied to tip/x86/unify-cpu-detect - thanks Yinghai. Ingo --

Hi. mm_update_next_owner() may clear mm->owner to NULL if it races with swapoff, page migration, etc. (This behavior was introduced by mm-owner-fix-race-between-swap-and-exit.patch.) But memcg doesn't take account of this situation, and causes: BUG: unable to handle kernel NULL pointer dereference at 0000000000000630 This fixes it. Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> --- diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 2979d22..ec2c16b 100644 --- ...

On Fri, Sep 5, 2008 at 1:40 AM, KAMEZAWA Hiroyuki Because lots of mm operations take place in a context where we don't We can, but that's orthogonal - we still need to be able to get to some thread (or a pointer directly in the mm to the cgroup, but with multiple cgroup subsystems popping up that needed such a pointer, it seems cleaner to have the owner pointer rather than adding multiple separate cgroup subsystem pointers to mm. Paul --

Hi, while copying large remote files for an USB memory stick formatted with ext3 using scp, I noticed a stall in wrie speed. Looking at the system with top I saw: top - 09:25:25 up 55 days, 23:49, 2 users, load average: 11.09, 7.41, 4.43 Tasks: 128 total, 1 running, 127 sleeping, 0 stopped, 0 zombie Cpu0 : 7.6%us, 0.3%sy, 0.0%ni, 0.0%id, 90.4%wa, 0.3%hi, 1.3%si, 0.0%st Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id,100.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, ...

Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git sh/for-2.6.27 Which contains: Adrian Bunk (2): sh64: re-add the __strnlen_user() prototype sh: fix ptrace_64.c:user_disable_single_step() Carmelo Amoroso (1): sh: resume_kernel fix for kernel oops built with CONFIG_BKL_PREEMPT=y. Magnus Damm (6): sh: crash kernel resource fix sh: fix kexec entry point for crash kernels sh: fix platform_resource_setup_memory() section ...

On Fri, 5 Sep 2008 21:26:02 +0400 I went looking, but afaict the whole thing got removed from today's --

Hi Andrew 2.6.27-rc5-mm1.gz seems broken gzip: 2.6.27-rc5-mm1.gz: unexpected end of file The result does not contain drivers/net/wireless/libertas_tf/ gpg sign seems good --

Hello, Again 100% reproducible rmmod ide-cd_mod problem. Kernel is tainted because of earlier sysfs acpi problems similar (probably identical) to those reported by Li Zefan here http://marc.info/?l=linux-kernel&m=121921059026064&w=2 Steps to reproduce: unload ide-cd_mod kobject (dd9e4a7c): tried to init an initialized object, something is seriously wrong. Pid: 4734, comm: modprobe Tainted: G W 2.6.27-rc5-mm1 #1 [<c01ec982>] kobject_init+0xc4/0xc9 [<c02cb84a>] ? ...

Hi, in -next tree, this patch fixes the compilation error instead of my patch. So, there is a conflict. commit 9b90dc7bc3079376567fc501e2e84751fa4040fd Author: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed Aug 27 14:45:37 2008 +1000 rr: build fix for remove CONFIG_KMOD from net Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> thanks, Hiroshi Shimamoto --

Jens, send to Andrew whatever you fixed in git://git.kernel.dk/linux-2.6-block.git for-2.6.28 [ 24.567512] ------------[ cut here ]------------ [ 24.567619] WARNING: at lib/list_debug.c:30 __list_add+0x95/0xa0() [ 24.567722] list_add corruption. prev->next should be next (ffff88017f9b8420), but was ffff88017f9b8588. (prev=ffff88017f9b8858). [ 24.567882] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables xt_tcpudp ...

Oops. How come I didn't find it earlier? hmm... This is current mainline: kobject (ddb049fc): tried to init an initialized object, something is seriously wrong. Pid: 4650, comm: modprobe Not tainted 2.6.27-rc5-00132-gb380b0d #8 [<c01e3196>] kobject_init+0x6a/0x6c [<c01e35cb>] kobject_init_and_add+0x14/0x30 [<c01e32f7>] ? kobject_get+0x12/0x17 [<c01df89c>] blk_register_filter+0x4b/0x5a [<de839310>] ide_cd_probe+0x289/0x5ae [ide_cd_mod] [<c01aad99>] ? sysfs_addrm_start+0x65/0x90 ...

Guess nobody tests with readonly? We had a socket on our board that flipped the write protect signal, and the rest you know :-) -----Original Message----- From: Pierre Ossman [mailto:drzeus-list@drzeus.cx] Sent: Friday, September 05, 2008 1:07 PM To: Andrew Morton Cc: Sasi Nair; linux-kernel@vger.kernel.org Subject: Re: mmc/card/block.c : mmc_blk_open readonly mount bug? On Thu, 4 Sep 2008 16:08:08 -0700 I wonder how that bug has been able to go unnoticed for so long... Acked-by: ...

We are pleased to announce the 2.6.26.3-rt6 tree, which can be downloaded from the location: http://rt.et.redhat.com/download/ Information on the RT patch can be found at: http://rt.wiki.kernel.org/index.php/Main_Page Changes since 2.6.26-rt5 - rebased ftrace to latest (Steven Rostedt) - schedule RT task push/pull improvements (Gregory Haskins) - pm qos requirement updated patch (John Kacur) - PowerPC ftrace mcount undefined symbol fix (Steven Rostedt) to build a ...

Thanks, I'll get these fixed today. -- paul moore linux @ hp --

Even with this patch, net/netlabel/netlabel_mgmt.c has build errors when CONFIG_IPV6=n: linux-next-20080904/net/netlabel/netlabel_domainhash.c:79: warning: unused variable 'tmp6' linux-next-20080904/net/netlabel/netlabel_domainhash.c:78: warning: unused variable 'iter6' linux-next-20080904/net/netlabel/netlabel_domainhash.c:340: warning: unused variable 'tmp6' linux-next-20080904/net/netlabel/netlabel_domainhash.c:301: warning: unused variable ...

If all the cpus in a cpuset are offlined, the tasks in it will be moved to the nearest ancestor with non-empty cpus. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Acked-by: Paul Jackson <pj@sgi.com> --- fixed a typo: s/binded/bound -- Documentation/cpusets.txt | 18 ++++++++++-------- 1 files changed, 10 insertions(+), 8 deletions(-) diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt index 1f5a924..47e568a 100644 --- a/Documentation/cpusets.txt +++ ...

If all the cpus/mems in a cpuset are offlined, the tasks in it will be moved to the nearest ancestor with non-empty cpus/mems. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> --- Documentation/cpusets.txt | 18 ++++++++++-------- 1 files changed, 10 insertions(+), 8 deletions(-) diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt index 1f5a924..871c1dd 100644 --- a/Documentation/cpusets.txt +++ b/Documentation/cpusets.txt @@ -635,14 +635,16 @@ prior 'mems' setting, will not ...

That loop does lock up on people occasionally - last time was in isofs, because it had done an insane set_blocksize() earlier on. Yes, it's always a case of garbage in, garbage out (or nothing out, as the case may be). No, it's not particularly programmer-friendly behaviour. --

hi, Wouldnt it make sense to limit the loop in __getblk_slow()? Like only try five times and drop a warning? Yesterday I changed free_more_memory() to return the number of pages freed by try_to_free_pages() and abort if no pages where freed. But it seems it always frees exactly one page... Greetings, Eric --

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/common.c | 8 +++ arch/x86/kernel/cpu/common_64.c | 111 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 119 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index e0ca51f..9128ba0 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -93,6 +93,7 @@ DEFINE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page) = { .gdt = { ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/common.c | 20 ++++++++++++++++++++ arch/x86/kernel/cpu/common_64.c | 2 ++ 2 files changed, 22 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index b2018f7..ffc2f5e 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -458,6 +458,26 @@ static void __cpuinit get_cpu_cap(struct cpuinfo_x86 *c) c->x86_capability[6] = ...

very nice patchset! I've created a new topic for this: tip/x86/unify-cpu-detect, with these commits: f5017cf: x86: use cpu/common.c on 64 bit 143b604: x86: cpu/common*.c, merge whitespaces 102bbe3: x86: cpu/common*.c, merge identify_cpu() b89d3b3: x86: cpu/common*.c, merge generic_identify() 56f0d03: x86: cpu/common*.c: merge print_cpu_info() 6627d24: x86: cpu/common*.c, merge early_identify_cpu() 5122c89: x86: cpu/common.c: merge get_cpu_cap() 1cd7877: x86: cpu/common*.c, merge ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/common.c | 13 ++++++++++++- arch/x86/kernel/cpu/common_64.c | 9 +++++++++ 2 files changed, 21 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index f919120..b2018f7 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -330,6 +330,9 @@ void __cpuinit detect_ht(struct cpuinfo_x86 *c) if (cpu_has(c, X86_FEATURE_CMP_LEGACY)) ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/common.c | 4 ++++ arch/x86/kernel/cpu/common_64.c | 19 ++++++++++++++++--- 2 files changed, 20 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index ffc2f5e..61a7074 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -490,7 +490,11 @@ static void __cpuinit get_cpu_cap(struct cpuinfo_x86 *c) */ static void __init ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/common.c | 8 ++++++++ arch/x86/kernel/cpu/common_64.c | 17 +++++++++++++++++ 2 files changed, 25 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 2c4bfa2..f919120 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -285,6 +285,10 @@ void __cpuinit display_cacheinfo(struct cpuinfo_x86 *c) printk(KERN_INFO "CPU: L1 I ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/common_64.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/cpu/common_64.c b/arch/x86/kernel/cpu/common_64.c index 6475548..68b06a3 100644 --- a/arch/x86/kernel/cpu/common_64.c +++ b/arch/x86/kernel/cpu/common_64.c @@ -730,8 +730,20 @@ __setup("noclflush", setup_noclflush); void __cpuinit print_cpu_info(struct cpuinfo_x86 *c) { + char *vendor = NULL; + + if ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/common.c | 22 +++++++++++++++++++--- arch/x86/kernel/cpu/common_64.c | 2 +- 2 files changed, 20 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 1f80ce0..6bbdbc2 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1,25 +1,41 @@ #include <linux/init.h> +#include <linux/kernel.h> +#include <linux/sched.h> #include ...

hard to merge by lines... will try do it later Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/common.c | 124 +++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/cpu/common_64.c | 88 +++++++++++++++++++++++++++- 2 files changed, 211 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index dcd3ebd..f44678d 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -901,7 +901,129 ...

I'll take it. -- Dmitry --

Ack. Sorry about that. Wrong ucb thread. ucb1400_core still has build errors in linux-next since it uses ac97_bus_type even when CONFIG_SOUND=n. --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --

What about this? diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index 6e1e8c6..22cf319 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -219,7 +219,6 @@ config TOUCHSCREEN_ATMEL_TSADCC config TOUCHSCREEN_UCB1400 tristate "Philips UCB1400 touchscreen" - select AC97_BUS depends on UCB1400_CORE help This enables support for the Philips UCB1400 touchscreen interface. diff --git a/drivers/mfd/Kconfig ...

diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index 6e1e8c6..22cf319 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -219,7 +219,6 @@ config TOUCHSCREEN_ATMEL_TSADCC config TOUCHSCREEN_UCB1400 tristate "Philips UCB1400 touchscreen" - select AC97_BUS depends on UCB1400_CORE help This enables support for the Philips UCB1400 touchscreen interface. diff --git a/drivers/mfd/Kconfig ...

Both sound (AC97) and UCB1400 should be able to select CONFIG_AC97_BUS independently from each other. And in linux/sound/Makefile one can find this note: # This one must be compilable even if sound is configured out obj-$(CONFIG_AC97_BUS) += ac97_bus.o This was fixed 2 years ago. Who broke it this time? Nicolas --

At Fri, 05 Sep 2008 10:52:25 -0400 (EDT), Could you repost? I can't find it easily now. thanks, Takashi --

The tap functionality of mousedev does not distinguish between a tap (on/off localized in time and space) and a quick move (on/off localized in time only). This patch improves the tap detection by testing also for space locality. Signed-off-by: Henrik Rydberg <rydberg@euromail.se> --- drivers/input/mousedev.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c index 8137e50..27e1d73 100644 --- ...

Oh. It _is_ LIST_POISON1. Sorry for the bit of noise. Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --

On Fri, 05 Sep 2008 01:05:21 +0200 cc's added. --

[...] I'm not sure this is correct. pci_user_write_config_dword() expects a value in host byte order, but this memcpy() makes val always little-endian. Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. --

At the very least put a big comment in here that we're polling the hardware without completion event. yield() is not good either, when used with a RT task (IMHO still the only valid use of yield) it mostly doesn't spend any time away from this task at all. The other option, schedule_hrtimeout() isn't ideal either because on crappy hardware it will fall back to jiffie based timeouts and I _hope_ that most hardware is less shitty than the 13ms reported in the changelog. Can we make this a ...

Will the wording "Returns a valid platform device, or a valid IS_ERR No. The kobject is initialised in platform_device_alloc() -> I just copied the surrounding code style. If you wish, I can put the names for this function back. BTW: would you prefer the followup "fix" patch or just the replacement one? -- With best wishes Dmitry --

also, On Fri, 5 Sep 2008 01:30:16 +0400 When you start implementing callers, please check whether platform_device_register_data() should have been exported to modules. --

Yes, it would be nice if this patchset worked here too. It currently I did some testing with multipath here. I could get it working by shutting down the devices, resizing all the underlying paths using the above methods, restarting the devices, then running pvresize. This method does not help much given that most users cannot realistically shutdown a device. This patch series works fine with standard LVM/dm, i.e., resize using one of the above methods, then run pvresize. I was planning on ...

Maybe we should return early at this point if revalidate_disk() We might return success here even if bdev is NULL. OTOH, as the callers of revalidate_disk() do not check the return value anyway (although at least tapeblock_revalidate_disk() might return a negative value) it's probably also an option to change the return type of revalidate_disk() to void. Andre --=20 The only person who always got his work done by Friday was Robinson Crusoe

Thanks Andrew, applied. -- Jens Axboe --

OK. Jens, Do you want me to send you a new patch? Resend the entire series, or send a patch to the patch? I have appended the new patch. Andrew -- Adjust block device size after an online resize of a disk. From: Andrew Patterson <andrew.patterson@hp.com> The revalidate_disk routine now checks if a disk has been resized by comparing the gendisk capacity to the bdev inode size. If they are different (usually because the disk has been resized underneath the kernel) the bdev inode ...

[Ingo Molnar - Fri, Sep 05, 2008 at 08:38:35PM +0200] | | * Cyrill Gorcunov <gorcunov@gmail.com> wrote: | | > So as you see it's more then enough self-solid :) So I wouldn't break | > it 'cause of printing. If we have enough memory for bit field - we | > could just mark there if pin is connected to irq and print connection | > map after. Don't get me wrong please - I just don't want to overload | > this function with additional call. | | the compiler will inline that single-called ...

[Ingo Molnar - Fri, Sep 05, 2008 at 10:04:47AM +0200] | | * Cyrill Gorcunov <gorcunov@gmail.com> wrote: | | > Use a nested level for 'for' cycle and break long lines. | > For apic_print we should countinue using KERNEL_DEBUG if | > we have started to. | | > @@ -1521,32 +1521,35 @@ static void __init setup_IO_APIC_irqs(vo | > apic_printk(APIC_VERBOSE, KERN_DEBUG "init IO_APIC IRQs\n"); | > | > for (apic = 0; apic < nr_ioapics; apic++) { | > - for (pin = 0; pin < ...

[Ingo Molnar - Fri, Sep 05, 2008 at 10:04:47AM +0200] | | * Cyrill Gorcunov <gorcunov@gmail.com> wrote: | | > Use a nested level for 'for' cycle and break long lines. | > For apic_print we should countinue using KERNEL_DEBUG if | > we have started to. | | > @@ -1521,32 +1521,35 @@ static void __init setup_IO_APIC_irqs(vo | > apic_printk(APIC_VERBOSE, KERN_DEBUG "init IO_APIC IRQs\n"); | > | > for (apic = 0; apic < nr_ioapics; apic++) { | > - for (pin = 0; pin < ...

applied to tip/irq/sparseirq - thanks Cyrill. Ingo --

My favorite is #1. Millisecond is small amount of time but it's also not hard to imagine some future cases where, say, 0.5 sec of Not yet but I think we should move toward per-queue EH which will enable fine-grained exception handling like this. Such approach would also help things like ATAPI CHECK_SENSE behind PMP. I think it's better to define the interface which suits the problem best rather If the timeout is global, it's best to have one knob. If the timeout is per-port, it's best ...

Well may be, but then there is still the performace degrading, so I don't want to have it enabled on our production kernels. I admit I never measured what is the difference between of CONFIG_FRAME_POINTER=y and =n, but the fact the help text says there is a difference already makes me want to disable it (especially, since we have to provide benchmarks before we can sell a system). Cheers, Bernd -- Bernd Schubert Q-Leap Networks GmbH --

The pipeline dependency stalls yes, the icache/decode overhead no. Also CONFIG_FRAME_POINTER currently enables -fno-sibling-calls which generates significantly worse code for a lot of common %rbp is a general purpose register. In fact it's even better than a general purpose register because it has often shorter Even on modern CPUs you can measure it in macro benchmarks, at least that was the state last time that was investigated. On older CPUs without the magic hardware it was even ...

Thanks Andi, found it! If someone else needs it, the correct path is What it the reason this patch isn't mainline? It provides better traces, doesn't slow down the kernel (which is important in our HPC envirement), so what is the disadvantage? Thanks again, Bernd -- Bernd Schubert Q-Leap Networks GmbH --

On Fri, 5 Sep 2008 16:48:52 +0200 to be honest, on 64 bit the overhead is quite small (the extra instructions it adds are optimized for by the modern cpus that you use in the systems you're selling); on 32 bit the overhead is.. well a little bigger but not THAT much. yes it loses a register for the compiler to use, but no it's not a general purpose register, and with the register renaming that today's cpus do, I'd be surprised if you could see anything significant. -- If you want to ...

uh-oh. On Thu, 04 Sep 2008 11:42:36 -0400 The patch was space-stuffed. I fixed that. Please see Documentation/email-clients.txt to fix it. Please send a Signed-off-by: for this change. --

So theoretically, on real hardware, the minimum of 50 reads will take 100us. The 256 PTI cycles will take 214us, so in the absolute worst case, you can have two consecutive successful cycles despite having a 228us SMI (or other event) if it happens just in the middle. Of course, then the actual _error_ on the TSC read will be just half that, but since there are two TSC reads - one at the beginning and one at the end - and if the errors of the two reads go in opposite directions, they ...

With this patch applied, the kernel behaves as expected for my config: it requests a 'modprobe hid_dummy', which prints a nasty message about being unable to find it on the initrd, and then we continue with the boot. Thanks for the quick fix...

The current quirk is incomplete. Some more chipset fiddling has to be done to enable HPET interrupts. I have a patch that would do this. And from my tests it seems to work faultlessly. But the official statement is that HPET is not supported on SB4XX. Thus there are 2 alternatives: (1) Remove the current (incomplete) quirk. (2) Extent the quirk. But whoever forces HPET would use it on his own risk. I decided to do (1) because it's safest. Other ...

Yup, I prefer (2). It might help users. It still needs hpet=force on the kernel command line. So it's a documented "you forced it" feature with no guarantees. I don't expect that the systems will explode, burn out or fall into pieces when hpet is enabled. That would be a reason to go for (1) :) Thanks, tglx --

Your ordering makes sense. Someone just has to go through all the users and fix them up I guess and also document it properly. One thing to consider though: if there are more and more NMI drivers it would make sense to have a new notifier chain just for this (and also finally convert oprofile to use it too). The problem with adding more and more into the die chain is that die is executed on every exception, including quite performance critical ones like page fault or int 3 (performance ...

btw., while we are talking about watchdog design problems, the current way the NMI timer watchdog oprofile fallback uses the die handler and how it all interacts with the ioapic/lapic-timer NMI watchdog is misdesigned as well. (this is used in the relatively rare but still possible case where no primary oprofile handler is found and installed) The i386 and x86_64 architecture code started using die notifiers for the NMI timer watchdog oprofile code two years ago, via commit 2fbe7b25 ...

At Thu, 4 Sep 2008 14:36:48 +0200, According to DMA-API.txt, dma_free_coherent() must be called with IRQ Takashi --

Do you recommend any specific benchmarks for memory-related projects ? Which one did you use for your own implementation ? Thank You --

Thanks for the review and the comments. Do you consider the clustering_info struct to hurt the readability The allocation order value is initially passed to the try_to_free_pages() in __alloc_pages_internal() and its value can be well more than zero. The clustering code adjusts the cluster size to the value of the allocation order (in a non-linear fashion of course). In this sense the cluster size is not determined at compile time, but the parameters affecting it are. Perhaps the term ...

On Thu, 4 Sep 2008 16:08:08 -0700 I wonder how that bug has been able to go unnoticed for so long... Acked-by: Pierre Ossman <drzeus@drzeus.cx> --=20 -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption.

From: Randy Dunlap <randy.dunlap@oracle.com> ixgbe needs to be restricted to the same build config (m/y) as DCA since it calls the dca_*() functions. ixgbe_main.c:(.text+0xd9c09): undefined reference to `dca3_get_tag' ixgbe_main.c:(.text+0xd9cc9): undefined reference to `dca3_get_tag' ixgbe_main.c:(.text+0xda5c1): undefined reference to `dca_add_requester' ixgbe_main.c:(.text+0xda5d6): undefined reference to `dca_remove_requester' text+0xdc162): undefined reference to ...

At Thu, 4 Sep 2008 20:28:13 -0700, Thanks, applied now. --

Thanks Randy for catching that, you're correct. Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com> --

(gdb) x/60i getnstimeofday 0xc0135d63 <getnstimeofday>: push %ebp 0xc0135d64 <getnstimeofday+1>: mov %esp,%ebp 0xc0135d66 <getnstimeofday+3>: push %edi 0xc0135d67 <getnstimeofday+4>: push %esi 0xc0135d68 <getnstimeofday+5>: push %ebx 0xc0135d69 <getnstimeofday+6>: sub $0x8,%esp 0xc0135d6c <getnstimeofday+9>: mov %eax,0xffffffec(%ebp) 0xc0135d6f <getnstimeofday+12>: mov 0xc045a2c0,%eax 0xc0135d74 <getnstimeofday+17>: mov %eax,0xfffffff0(%ebp) 0xc0135d77 ...

It does not help after these 4 patches applied. Gregory Haskins (4): sched: make task_hot() once again use sd->cache_hot_time Revert "sched: zap the migration init / cache-hot balancing code" Revert "[PATCH] sched: remove cache_hot_time" revert "sched: sched_cacheflush is now unused" --

Nothing prevents you from setting the class flags based on platform-specific information if you have a need for that. That being said, in cases where you have that level of information about which devices are present on the I2C bus, you probably want to declare the I2C devices at the platform level, and not rely on probing at all (so .class is 0). -- Jean Delvare --

If you have a need for that, sure. If you don't, that's making the code more complex for no good reason. I expect I2C_CLASS_HWMON to be removed from that driver soon. Now that almost all hwmon drivers have been converted to support instantiated I2C devices, and given that all users of i2c-gpio are embedded architectures with platform code, it should be no longer needed. But again I am leaving it to whoever is actually using this driver to decide what is best for them. -- Jean Delvare --

Good morning Jean, OK but which devices that can be connected to an I2C bus is platform specific, isn't it ? For example, an I2C adapter can be used in a TV and in that case there may be no point to probe for a HW mon chips but this same I2C adapter can be used by other platforms in a different context where there's a HW mon chip. So the flags probably are useful, but they're are hard coded in adapters... Sorry if I'm still missing something. -- Francis --

Thanks for the pointers, Mikael. I appreciate it. Alin --

First as a minor pedantic correction (sorry!): the ro syscall table is not fully free. It means you cannot use 2MB pages anymore to map it, which costs One way to do that today is to feed gcc random data for profile feedback. Game copy protections have been playing similar games for decades. While I'm sure it was endless fun for both sides afaik the crackers tended to ultimatively win. And all of these things also make the kernel more fragile which is not good. Likely a case of "the only ...

i think Linux is fundamentally different here as we have the source and every box where it matters we could have a _per box_ randomized kernel image in essence, with non-essential symbols thrown away, and with a few checks inserted in random locations - inlined and in essence unrecognizable from the general entropy of randomization. Not that a randomizing compiler which inserts true, hard to eliminate entropy would be easy to implement. But once done, the cat and mouse game is over ...

It depends on where the userland runs. e.g. if it's under a hypervisor and in a separate domain it should be reasonably safe. And then I don't think it is much difference between Ingo's kernel checker and a user land checker. Both can be disabled it you know about them. -Andi -- ak@linux.intel.com --

Sure, they can :-) It's just an idea I had on irc but I tend to agree that it wouldn't have much effect in practice... regarding security, it will break some existing rootkits ... until updated ones show up. Cheers, Ben. --

and that'd be because at the same time they patch the syscall table (remember, they already have to go to length to get around the read-only pages), they can't also patch this 'protection'? sounds really plausible, right :). [fixed hpa's address, .org bounces.] --

how's that supposed to work for the binary distros, i.e., the majority of why do you assume that an attacker wants to do that? it's equally possible, and there's even academic research on this in addition to the underground cracking scene, that one simply hides the modifications from the checker. from marking your patched code as unreadable to executing it from a different place than what the checker checks, there're many ways to trick such checkers. as far as reality goes, it's never been ...

it takes less than 10 minutes to build a full kernel on recent hardware. yes, in this area debuggability is in straight conflict. Since we can assume that both attacker and owner has about the same level of access to the system, making the kernel less accessible to an attacker makes it well at least in the case of Linux we have a fairly good tally of what kernel code is supposed to be executable at some given moment after bootup, and can lock that list down permanently until the next ...

Then they will simply proceed like this : - patch /boot/vmlinuz - sync - crash system => user says "oh crap" and presses the reset button. Patched kernel boots. Game over. Patching vmlinuz for known targetted distros is even easier because the attacker just has to embed binary changes for the most common distro kernels. Clearly all this is a waste of developer time, CPU cycles, memory, reliability and debugging time. All that time would be more efficiently spent ...

Nope, no problems. I think I have some pending patches that may have conflicts with the above, but I'll take care of that when I get back to the US (I think Sunday or Monday will be a massive patch review/merge/comment day). Thanks, Jesse --

Gah, not another yield in the network code we have to figure out wtf its meant to do. --

Dear Wolfgang, this patch is already applied (d2029eba in linux-2.6-denx repo) I just sent it upstream. Regards, Ilya. --

Dear Ilya &Yrui, What about this patch? SHould it be applied to our repository? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de The use of Microsoft crippleware systems is a sin that carries with it its own punishment. -- Tom Christiansen in <6bo3fr$pj8$5@csnews.cs.colorado.edu> --

Hi, <linux/ide.h> it is not exported to user-space at all so introducing What it is the point of 'q->rq.count[READ] + q->rq.count[WRITE] <= 1' Since Tejun already raised concerns about multiplexing per-device and per-port settings I'm not repeating them here. Please just No need to use ide_devset_execute() - ide_setting_mtx already provides the needed protection. Thanks, Bart --

Changes: 1) Fixed segfaults in help window. 2) Removed the instructions window, made the instructions appear as a button which displays a popup window. 3) Added hot keys support. As ncurses does not support several colors inside a menu, keys are highlighted using "()". 4) Optimized for 80x24 terminals. 6) Fixed zconf.y to use _menu_init 7) added nconfig to "make help" 8) Misc fixes. Comments are appreciated. Cheers. --- scripts/kconfig/Makefile | 17 +- ...

Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --

Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --

i've applied the fix below to tip/core/locking - but would be nice if the UML folks had a comment as well. Ingo From 8c56250f48347750c82ab18d98d647dcf99ca674 Mon Sep 17 00:00:00 2001 From: Rui Sousa <rui.p.m.sousa@gmail.com> Date: Thu, 4 Sep 2008 19:47:53 +0200 Subject: [PATCH] lockdep, UML: fix compilation when CONFIG_TRACE_IRQFLAGS_SUPPORT is not set With the patch bellow it compiles (make ARCH=um with a x86 host), but I'm really out of my league on this one... Reported-by: ...

fails to build with this config: http://redhat.com/~mingo/misc/config-Fri_Sep__5_18_51_13_CEST_2008.bad arch/x86/xen/built-in.o: In function `xen_play_dead': (.text+0x576a): undefined reference to `play_dead_common' arch/x86/xen/built-in.o: In function `xen_cpu_disable': (.text+0x57b1): undefined reference to `cpu_disable_common' Ingo --

applied to tip/x86/paravirt - thanks. Ingo --

It was a once-off. --

They both use the opposite from what their respective usermodes use for thread local storage, since there may be a slight performance advantage to doing so (at least on 32-bit). 32-bit's use of %gs for usermode TLS is old and arbitrary, probably predating x86-64 (at least its wide availability). The use of %gs for kernel per-cpu data is architectural on 64-bit, because of the "swapgs" instruction; there's no "swapfs" They don't exist in 64-bit. The GDT contains them, but they're not Yes, ...

Thanks again ;) I know these things ;) but what I wanted to know is the "x86 architectural details". In fact, I saw that during the machine init the BIOS select a cpu on the bus to be the BSP (bootstrap proc). The others are then the APs (Appli proc). Then the kernel runs on the BSP. What I wonder is how the kernel gives execution flow to the APs. Thanks. --

Acked-by: Paul Menage <menage@google.com> Thanks. --

Indeed, poor IIfx, mine is a dedicated linux box, meaning that the mac partition is only used to boot linux, still the about 50-60 K/s you get from the HD scare you away. Still I have hopes in the 2.6 kernels Ric --

hm, is the remote read debug output, now that it's not present in CPUs made in the past 5 years or so, really that important? Ingo --

Hi Uwe, Note: patches to i2c bus drivers are better sent to the i2c mailing list (Cc'd.) Looks good, patch applied. Thanks for your contribution. -- Jean Delvare --

That's always a problem with humans in the loop. I very much agree that one line or three is far safer against a hasty line insertion than only two. In my own code I write one if it fits, three if it doesn't. Being easy -- Bill Davidsen <davidsen@tmr.com> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot --

done, thx. Ingo --

Can I blame my keyboard? No, probably not, I sent that with the keyboard working. In any case, now it's attached for real. -Daniel *This .sig left intentionally blank*

That is untruth :)) -- Dmitry --

ok - fixing this makes sense. I have two worries about this patch. Firstly, the quirk is keyed off an ACPI capability which is quite bad if someone boots with ACPI off. (which is still quite possible) The DMAR is PCI enumerated so there's nothing inherently ACPI about this. A DMI quirk (which will work even if ACPI is disabled) looks more robust. Secondly, keying off the PCI ID and assuming a BIOS bug based on the presence of an ACPI table can indeed get incoherent results as you ...

wonder if need to put x86: split e820 reserved entries record to late v4 IO resources: add reserve_region_with_split() x86: split e820 reserved entries record to late, v7 into 2.6.27 for fix hang on David's system. YH --

.. Not to mention that we still have the unsolved regression from when HPET support first went in (2.6.2[01] timeframe), where machines randomly lock up at "Switching to HPET" time during boot. Depending upon kernel .config, phase of the moon, and apparently SMM events. Hopefully this will finally get fixed with this work? Cheers --

Hmm.. I'm not a huge fan of the ASM_NOP mess, but you also disable it for 64-bit x86 too. On 32-bit, at least the generic nops are fairly reasonable, but the default nops for 64-bit really look pretty sad, and the P6 nops really do look better. So I would suggest perhaps moving the static P6 nop selection into the CONFIG_X86_64 thing. The alternative is to just get rid of that static nop selection, and just have two cases: 32-bit and 64-bit, and just pick obviously safe cases ...

I disagree here: If I configure a 686+ kernel, I expect these NOPs to be that way (and to work). If you want to run on something that's not compliant, you just shouldn't configure your kernel that way. Jan --

Okay, we do not generate P6 NOPs statically if CONFIG_X86_GENERIC_CPU is enabled -- unless, of course gcc/binutils generates them, which they now do for certain CPU types. If you are selecting a specific CPU *and* you don't select GENERIC, you should get valid code for the selected CPU only. As far as using them dynamically, there is code in -tip that determines dynamically and explicitly if the long NOPs are available, and only uses them if they are. -hpa --

Well, the paravirt_ops patching uses multibyte nops to pad out the unused space in a patch site, and they're generally on hot paths (otherwise we wouldn't bother with patching). But even then I don't think the particular nop chosen matters all that much, and even if it did using the dumb redundant prefix long nops seems to be as good as or better than the p6 nops. The "call mcount" patching ftrace wants to do Yep. We could run the p6 nops with an exception handler to see if the cpu ...

applied to tip/sched/urgent - thanks! Ingo --

Maybe the statement was a little bit harsh, it's just that you won't need bay in conjunction with libata, because it can't install the notification handler because that was already done by libata. Regards, Holger --

On Fri, 05 Sep 2008 15:09:00 -0500 Oh? There shouldn't be any changes around those chunks. What kind of problems are you seeing? Rgds --=20 -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption.

applied to tip/sched/urgent, thanks! Ingo --

Well, my crappy copied comment has a typo in it. I really meant "boo". I was trying to scare patch reviewers. I'll have a new one out in a bit, akpm found another issue in it. -- Dave --

Sometimes I find the terminology a little confusing. "Client" and "server" are clear enough, as is "device-side" (synonymous with "server"). I guess vhci-hcd runs on the client, right? But "host" is ambiguous; vhci-hcd is a host controller driver on the client and [uoe]hci-hcd is a host controller driver on the server. Thus both sides are hosts. Also, "stub" isn't too clear. Is vhci-hcd a stub driver? Or does the stub driver run strictly on the server? Getting back to your ...

I'm sorry I'm barging into the conversation, but a HC without a root hub is rather shocking. One would think it easier to emulate a root hub with one port in HCD than to teach the whole stack about such thing as a hubless HC. -- Pete --

This version does not work for me, possibly because I use a different hard disk driver (ata_piix instead of sata_sil)? I've seen there are later versions of the patch, but as the comments Added. Cheers, FJP --

[resend, as the first had a problem going out] Hi Nick, Cool stuff...see inline =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= I would prefer to see this done as a polymorhpic atomic_dec_and_lock() call with something like Ingo's "PICK_OP" method (currently used in -rt) rather than expanding the atomic_X namespace. I haven't looked into it to make sure its plausible, but I do not see any reasons from 30k feet why it would not. Its not a huge deal either ...

This one breaks wireless with 32bit userspace/64bit kernel. Bisected back to changeset 087d833e5a9f67ba933cb32eaf5a2279c1a5b47c: mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM -- Alex Williamson HP Open Source & Linux Org. --

Yes, just revert it. Jouni, feel free to send me a new version for 2.6.28. Thanks, John -- John W. Linville linville@tuxdriver.com --

Ok, to be more specific, I was thinking of following. Currently, all the requests for a block device go into request queue in a linked list and then associated elevator selects the best request for dispatch based on various policies as dictated by elevator. Can we maintan an rb-tree per request queue and all the requests being queued on that request queue first will go in this rb-tree. Then based on cgroup grouping and control policy (max bandwidth capping, proportional bandwidth etc), one ...

Where are they written to? "P" in a sysrqd telnet session does not "l" results in the SysRq HELP being written to the kernel log, so I guess that "recently" means "not yet in 2.6.26.3". Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | ...

CONFIG_RCU_CPU_STALL_DETECTOR it is! It is sufficiently lightweight to be included in production systems, and similar mechanisms have proven Agreed, but note well the quote from above: The hierarchical-RCU implementation has been moved to its own "rcutree" set of files. This allows configuring three different implementations of RCU (CLASSIC_RCU, PREEMPT_RCU, and the new TREE_RCU). More importantly, it enables easy application of this patch to a wide variety of Linux ...

Is it likely that anyone will ship kernels with NR_CPUS=8? What are ____cacheline_internodealigned_in_smp will expand this structure to OK, thanks. As it's effectively a bugfix, a full description of the bug would grease some wheels. --

This looks somewhat strange, mostly like 'c' is NULL and it's oopsing in in removeQ (I don't think Randy's analysis is correct in assuming it's 'h' and it's in fifo_full). Given that 'c' cannot be NULL, it's c->prev or c->next that are NULL. -- Jens Axboe --

I'll revert it, and if it's resubmitted, I'll ignore it until after the next merge window - since my tree for the upcoming merge window currently pre-dates the revert, so effectively continues to carry it until it's merged. I'm not sure what went wrong, other than being continuously bugged by Harvey to apply his patch. If his patches are inappropriate, surely that should've been pointed out to Harvey before he got the first of his series merged? Maybe more of his patches need reverting if ...

How useful. If those generic headers are already in Linus' tree, and are required for architectures to convert, why hasn't the patch which exports them to userspace already been submitted? However, another question: why should userspace be using a kernel header file for byteswapping? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: --

yeah - it's still in the integration branch - but it doesnt hurt as it's same-content patch (it got cherry-picked over into an urgent branch). The duplication should go away on the next tip/master integration run (tomorrow-ish) - please let me know if it doesnt. Ingo --

Ah, I stumbled other this because it is still listed in the shortlog: $ git shortlog linux-2.6/master..tip/master | grep oprofile x86: fix oprofile + hibernation badness ... But anyway, I found the other commit as well, thanks. -Robert -- Advanced Micro Devices, Inc. Operating System Research Center email: robert.richter@amd.com --

Yeah, ARCH_SUPPORTS_AOUT was a bit b0rked from the beginning. Hm, that reminds me -- I was supposed to pick up Adrian's patch to remove a bunch of pointless <asm/a.out.h> files... now added to my tree and sent. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation --

From: Adrian Bunk <bunk@kernel.org> This patch also includes the required removal of (unused) inclusion of <asm/a.out.h> <linux/a.out.h>'s in the arch/ code for these architectures. [dwmw2: updated for 2.6.27-rc] Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> --- arch/avr32/include/asm/a.out.h | 20 ----------------- arch/blackfin/include/asm/a.out.h | 19 ---------------- arch/cris/arch-v10/boot/tools/build.c | ...

Ok I should take the time to properly add these to ltp, but for now here is the result of 15-minutes of playing around with shell scripts to do some basic testing. Run usermounts_root.sh as root first, then usermounts_user as a user. Cleanup for the usermounts_root.sh side-effects is not done. Miklos, do you have better-thought-out or more complete testcases? -serge ===================================================================== FILE ...

Hello, Thanks, Alan for your comment about Marvell PATA IDE driver. In this time I'm a litle bit busy and do not have time to backport driver in 2.4 probably after a time I'll try (I'm not a profesional C programer and it is litle hard to me). I correct generic IDE patch and send you in the attached file. I make also patch to update e1000 driver in the 2.4 kernel to e1000-7.6.5 and add support for: 00:19.0 Ethernet controller: Intel Corporation 82801I (ICH9 Family) Gigabit Ethernet ...

Hi Alan, Indeed, your driver is clear enough to serve as a doc. Looking at ata_piix.c in 2.4, I see that the libata core has evolved a lot, but backporting your work should not be hard at all. Among other things, the driver needs to set ap->cbl itself during reset, for instance. However, I wonder if it's really worth doing it if the IDE generic driver already works. The PATA port on such motherboards today is mostly used by CD/DVD, and I think that even if we limit ourselves to 40-pin, ...