New hwmon drivers since 2.6.16.42 for the following hardware: - National Semiconductor pc87427 - SMSC lpc47m192 and lpc47m997 - Winbond w83791d Location: ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/ git tree: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git Changes since 2.6.16.42: Adrian Bunk (1): Linux 2.6.16.43-rc1 Alexey Dobriyan (1): [IPV4/IPV6] multicast: Check add_grhead() return value Charles Spirakis ...

Hello, On an embedded system, I use two ramdisks. They are both 16 megabytes in size. I can create them interactively in the normal way with mke2fs. However, when the system is booted using isolinux, the RAM disks become corrupted. Apparently isolinux.cfg's ramdisk_size (not documented, only referenced, BYW) is not in 1k increments. That value seems to affect all ramdisks, not just the `initrd` one. I can prevent corruption by setting the value to 200000 (way too much). However I won't have ...

There's a known issue with sata_nv on nForce4 controllers running in ADMA mode in 2.6.20 (the first released kernel with ADMA support) where commands can time out when switching between NCQ commands and non-NCQ commands. Hopefully this is fixed in 2.6.21-rc. This doesn't seem to be the issue here, since his system isn't using ADMA mode, for reasons unclear to me.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: ...

There is one thing that seems odd, if you do have an nForce4 chipset, the kernel should be running the SATA controller in ADMA mode in 2.6.20, but it doesn't seem like it is from your dmesg output. Can you post the output of "lspci -vvn"? Also what kind of motherboard is that? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ -

The writing on the wall seem to be that the parport stack is orphaned, rather than maintained by four folk ... and having a webpage that says the latest patches are based on a 2.5 kernel. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Index: g26/MAINTAINERS =================================================================== --- g26.orig/MAINTAINERS 2007-02-28 12:46:00.000000000 -0800 +++ g26/MAINTAINERS 2007-02-28 12:47:58.000000000 -0800 @@ -2552,16 +2552,8 @@ ...

On Wed, 28 Feb 2007 15:40:31 -0700 is_zero_ether_addr() is faster/cleaner for this -- Stephen Hemminger <shemminger@linux-foundation.org> -

We had been using the platform_device.id field to identify which ethernet port is used for mv643xx_eth device. This is not correct in general. It will be incorrect, for example, if a hardware platform uses a single port but not the first port. Here, we add an explicit port_number field to struct mv643xx_eth_platform_data. This makes the mv643xx_eth_platform_data structure required, but that isn't an issue since all users currently provide it already. Signed-off-by: Dale Farnsworth ...

Apologies, but this was a bug fix for a more serious issue. The code to report the directory entries by start time was fundamentally broken. In particular the sequence: opendir readdir readdir readdir .... closedir can miss processes that exist for the entire duration of that sequence. Which is non-posix, non-intuitive, and has no reasonable work around. The sorting by pid happened as a side effect of finding a stable token we can come back to so we can at least guarantee normal ...

On Wed, 28 Feb 2007 14:41:57 +0200 Please submit patch to proper place: netdev@vger.kernel.org and Ben Greear <greearb@candelatech.com> -- Stephen Hemminger <shemminger@linux-foundation.org> -

On Wed, 28 Feb 2007 09:34:10 -0800 -

From: Ingo Molnar <mingo@elte.hu> add the create_async_thread() way of creating kernel threads: these threads first execute a kernel function and when they return from it they execute user-space. An architecture must implement this interface before it can turn CONFIG_ASYNC_SUPPORT on. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> --- arch/i386/kernel/entry.S | 25 +++++++++++++++++++++++++ arch/i386/kernel/process.c | 31 ...

From: Ingo Molnar <mingo@elte.hu> wire up the new syslet / async system call syscalls and make it thus available to user-space. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> --- arch/i386/kernel/syscall_table.S | 6 ++++++ include/asm-i386/unistd.h | 8 +++++++- 2 files changed, 13 insertions(+), 1 deletion(-) Index: ...

From: Ingo Molnar <mingo@elte.hu> add the kernel generic bits - these are present even if !CONFIG_ASYNC_SUPPORT. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> --- fs/exec.c | 4 ++++ include/linux/sched.h | 23 ++++++++++++++++++++++- kernel/capability.c | 3 +++ kernel/exit.c | 7 +++++++ kernel/fork.c | 5 +++++ kernel/sched.c | 9 +++++++++ kernel/sys.c | 36 ...

From: Ingo Molnar <mingo@elte.hu> mark clone() and fork() as not available for async execution. Both need an intact user context beneath them to work. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> --- arch/i386/kernel/ioport.c | 6 ++++++ arch/i386/kernel/ldt.c | 3 +++ arch/i386/kernel/process.c | 6 ++++++ arch/i386/kernel/vm86.c | 6 ++++++ 4 files changed, 21 insertions(+) Index: ...

From: Ingo Molnar <mingo@elte.hu> add include/linux/syslet.h which contains the user-space API/ABI declarations. Add the new header to include/linux/Kbuild as well. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> --- include/linux/Kbuild | 1 include/linux/syslet.h | 155 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 156 insertions(+) Index: ...

From: Ingo Molnar <mingo@elte.hu> Add Documentation/syslet-design.txt with a high-level description of the syslet concepts. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> --- Documentation/syslet-design.txt | 137 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 137 insertions(+) Index: linux/Documentation/syslet-design.txt =================================================================== --- /dev/null +++ ...

From: Ingo Molnar <mingo@elte.hu> enable CONFIG_ASYNC_SUPPORT on x86. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> --- arch/i386/Kconfig | 4 ++++ 1 file changed, 4 insertions(+) Index: linux/arch/i386/Kconfig =================================================================== --- linux.orig/arch/i386/Kconfig +++ linux/arch/i386/Kconfig @@ -55,6 +55,10 @@ config ZONE_DMA bool default y +config ...

worker_thread() doesn't need to "Block and flush all signals", this was already done by its caller, kthread(). Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> --- 6.20-rc6-mm3/kernel/workqueue.c~signals 2007-02-20 02:21:11.000000000 +0300 +++ 6.20-rc6-mm3/kernel/workqueue.c 2007-02-28 23:58:11.000000000 +0300 @@ -290,18 +290,11 @@ static int worker_thread(void *__cwq) struct cpu_workqueue_struct *cwq = __cwq; DEFINE_WAIT(wait); struct k_sigaction sa; - sigset_t blocked; if ...

Commit 908b637fe793165b6aecdc875cdca67c4959a1ad removed ETH_DMA_ALIGN but missed a usage of it in a macro, which broke the build. Signed-off-by: Dave Jones <davej@redhat.com> diff --git a/drivers/net/mv643xx_eth.h b/drivers/net/mv643xx_eth.h index 7cb0a41..7d4e90c 100644 --- a/drivers/net/mv643xx_eth.h +++ b/drivers/net/mv643xx_eth.h @@ -9,6 +9,8 @@ #include <linux/mv643xx.h> +#include <asm/dma-mapping.h> + /* Checksum offload for Tx works for most packets, but * fails if ...

Hey. While testing 2.6.21-rc2 with libhugetlbfs, the shm-fork test case causes the kernel to oops. To reproduce: Execute 'make check' in the latest libhugetlbfs source on a 2.6.21-rc2 kernel with 100 huge pages allocated. Using fewer huge pages will likely also trigger the oops. Libhugetlbfs can be downloaded from: http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20070228.tar.gz I have collected the following information: bc56bba8f31bd99f350a5ebfd43d50f411b620c7 is first bad ...

Add a "favourlzo" compression mode to jffs2 which tries to optimise by size but gives lzo an advantage when comparing sizes. This means the faster lzo algorithm can be preferred when there isn't much difference in compressed size (the exact threshold can be changed). Signed-off-by: Richard Purdie <rpurdie@openedhand.com> --- fs/Kconfig | 7 +++++++ fs/jffs2/compr.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++----- fs/jffs2/compr.h | 3 +++ 3 files changed, 56 ...

Further down the patch you'll see: + kset_set_kset_s(&jffs2_subsys, fs_subsys); There was a reason for doing that instead using fs_subsys in the above although I can't remember why offhand. I did try it and it didn't work as expected... Regards, Richard -

Allow selection of the compression mode for jffs2 via a sysfs attribute. This establishes a sysfs presence for jffs2 through which other compression options could easily be exported too. Signed-off-by: Richard Purdie <rpurdie@openedhand.com> --- fs/jffs2/compr.c | 131 +++++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 94 insertions(+), 37 deletions(-) Index: linux/fs/jffs2/compr.c =================================================================== --- ...

Add LZO1X compression/decompression support to the kernel. This is based on the standard userspace lzo library, particularly minilzo with the headers much trimmed down and simplified for kernel use. Its structured so that it should still diff with the userspace version for ease of future updating. Signed-off-by: Richard Purdie <rpurdie@openedhand.com> --- include/linux/lzo.h | 63 + lib/Kconfig | 5 lib/Makefile | 1 lib/lzo/Makefile | 3 ...

The following patch series adds LZO compression support to the kernel and exposes it in a variety of places (jffs2, crypto). This is particularly useful for jffs2 where significant boot time speedups (~10%) and file read speed improvements (~40%) are seen when its used with only a slight drop in file compression ratio. It also adds a favourlzo mode to jffs2 which is similar to the existing size mode but lets lzo compression win if the lzo compressed size is "similar" to but not the best ...

Another option is to use 46..49 for UARTs #0..3, and 192..195 for UARTs #4..7. Or, perhaps better, use 46..49 for #0..3, and 192..199 for #0..7, handling the duplication in the driver; and deprecate the old range. Segher -

I'd "vote" for the 2nd. Jan -- -

From: Christoph Lameter <clameter@engr.sgi.com> V3 doesn't boot successfully on sparc64, sorry I don't have the ability to track this down at the moment since it resets the machine right as the video device is initialized and after diffing V2 to V3 there is way too much stuff changing for me to try and "bisect" between V2 to V3 to find the guilty sub-change. Maybe if you managed your individual changes in GIT or similar this could be debugged very quickly. :-) Meanwhile I noticed that your ...

Fix __init declarations in Compaq SMART2 Controller driver. Resolves MODPOST warnings similar to: WARNING: drivers/block/cpqarray.o - Section mismatch: reference to .init.text:cpqarray_init_one from .data.rel.local between 'cpqarray_pci_driver' (at offset 0x20) and 'smart1_access' Signed-off-by: Prarit Bhargava <prarit@redhat.com> --- linux-2.6.18.ia64.orig/drivers/block/cpqarray.c 2007-02-14 11:36:20.000000000 -0500 +++ linux-2.6.18.ia64/drivers/block/cpqarray.c 2007-02-14 ...

Eh, I'm not crazy about that. That means that I have to complicate my driver because someone else screwed up a long time ago. -- Timur Tabi Linux Kernel Developer @ Freescale -

Please, let's just leave the four we have and let the driver just allocate increasing minor numbers. If anyone has a product with more than 4 UARTs, they will have to figure out what to do with the additional minors. We are making a very complicated problem out of nothing. This hasn't caused any problems in the past, and changing the existing names and minors will cause problems for everyone today. Just leave it alone, fix up the documentation, and have the driver print some warning ...

*sigh* What about major number 205? It also has the screwed-up /dev/ttyCPM entries, but it has more room, and the CPM driver doesn't actually use it. At least, I can't see where it uses it. -- Timur Tabi Linux Kernel Developer @ Freescale -

> Please, let's just leave the four we have Since you say no one has ever used more than 4 UARTs, there are two options: - Cap the driver at 4 UARTs; - Assign an extra range of minors for more ports. Just randomly using some extra minors that aren't assigned to you isn't such a great idea. Segher -

If a process is closing /dev/input/mice and an mouse disconnects simulta- neously, the system is likely to oops. This usually happens when someone hits <Alt><Ctrl>F1 or logs out from X, and flips a KVM while the system is reacting. I reproduced the issue by running this: while true; do cat </dev/null >/dev/input/mice; done This way, it oopses on 2nd or 3rd disconnect reliably. With the patch, I can disconnect the mouse 20 times. Signed-off-by: Pete Zaitcev ...

Is the ( ... & epi->event.events) really necessary ? (It seems already done) I was wrong about the size of epitem : it is now 68 bytes instead of 72. At least we now use/dirty one cache line instead of two per epitem. Do you have another brilliant idea to shrink 4 more bytes ? :) It seems to me 'nwait' is only used at init time (so that ep_ptable_queue_proc() can signal an error occured). Maybe another mechanism could let us delete nwait from epitem ? We could use a field in ...

Never mind, those patches are already in 2.6.21-rc. -

Here is the .config for 2.6.20. The only difference from the 2.6.21-rc2 config are the default selects. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20 # Tue Feb 27 23:44:38 ...

This patch provides a functionality that allows parallel RX processing on multiple RX queues by using dummy netdevices. Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com> --- diff -Nurp -X dontdiff linux-2.6.21-rc1/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h --- linux-2.6.21-rc1/drivers/net/ehea/ehea.h 2007-02-28 18:20:06.000000000 +0100 +++ patched_kernel/drivers/net/ehea/ehea.h 2007-02-28 18:21:23.000000000 +0100 @@ -39,7 +39,7 @@ #include <asm/io.h> ...

Hi, this version has the issues fixed which were mentioned by Patrick McHardy. The patch set includes two patches against linux-2.6.21-rc1: - dynamic add / remove port: Interface has been discussed and approved by John Rose (see: http://www.spinics.net/lists/netdev/msg25327.html) - NAPI multi queue TX/RX path for SMP: Integrated comments from mailing list (R. Dreier) As soon as discussions about "splitting NAPI from netdevice" have settled and this functionality is in ...

On Wed, Feb 28, 2007 at 10:13:24PM +0100, Michael Hanselmann wrote: > On Wed, Feb 28, 2007 at 12:36:25PM -0500, Dave Jones wrote: > > +#ifdef __powerpc__ > > Is __powerpc__ defined when cross compiling? I'd rather use > CONFIG_PMAC_BACKLIGHT instead of it. Sounds ok to me. Dave -- http://www.codemonkey.org.uk -

drivers/video/nvidia/nv_backlight.c: In function 'nvidia_bl_init': drivers/video/nvidia/nv_backlight.c:103: error: implicit declaration of function 'pmac_has_backlight_type' Signed-off-by: Dave Jones <davej@redhat.com> --- linux-2.6.20.noarch/drivers/video/nvidia/nv_backlight.c~ 2007-02-20 22:25:15.000000000 -0500 +++ linux-2.6.20.noarch/drivers/video/nvidia/nv_backlight.c 2007-02-20 22:25:31.000000000 -0500 @@ -12,6 +12,9 @@ #include <linux/backlight.h> #include <linux/fb.h> #include ...

- ecryptfs_write_inode_size_to_metadata() error code was ignored. - i_op->setxattr() must be supported by lower fs because used below. Signed-off-by: Monakhov Dmitriy <dmonakhov@openvz.org> --- fs/ecryptfs/inode.c | 6 +++--- fs/ecryptfs/mmap.c | 3 ++- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c index 27fd14a..9ccefad 100644 --- a/fs/ecryptfs/inode.c +++ b/fs/ecryptfs/inode.c @@ -168,9 +168,9 @@ static int ...

Where are many places where xxxx_journal_stop() return code wasn't checked. Off cause xxxx_journal_stop() failed very rarely (and usually with fatal consequences), but this does'n meen it should not be checked. For example most retry loops looks like follows: ext3_journal_stop(handle); if (err == -ENOSPC && ext3_should_retry_alloc(dir->i_sb, &retries)) goto retry; It is realy insane do "retry" if ext3_journal_stop() has failed, because this may increase damage in case of real ...

>>/ openSUSE 10.3 Alpha and KDE-3.5.6, xorg-x11-7.2. KDE is setup not to/ >>/ require a password to unlock, but it asks for password. When the screen/ >>/ unlocks, kwin is gone with no errors logged in /var/log/kdm or/ >>/ /var/log/messages. No problems with 2.6.20./ >> >>/ Same problem on openSUSE 10.2 x86_64, KDE-3.5.5 and 2.6.21-rc2./ >>/ Regards/ >>/ Sid./ > This is the linux kernel mailing list. Perhaps you should post your problem to > the opensuse mailing list. > > ...

Hm.. my shuttle box has only a 350W power supply, that could indeed be the problem, as I have an Athlon 64 X2 4400+ CPU (dual core), two SATA-II 500GB harddrives and a GeForce 7800GTX. Damn.. I thought I payed attention to the power supply when I bought the components for my computer :( tom -

openSUSE 10.3 Alpha and KDE-3.5.6, xorg-x11-7.2. KDE is setup not to require a password to unlock, but it asks for password. When the screen unlocks, kwin is gone with no errors logged in /var/log/kdm or /var/log/messages. No problems with 2.6.20. Same problem on openSUSE 10.2 x86_64, KDE-3.5.5 and 2.6.21-rc2. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft ...

A change early last year reordered struct page so that ptl overlaps not only private, but also mapping. Since spinlock_t can be much larger, I'm wondering whether there's a reason to not also overlay the space index and lru take - are these used for anything on page table pages? Thanks, Jan -

Likely already too late then -- if critical state is overwritten you crashed before. Also a lot of stack intensive codes relatively large unused holes so it might miss the canary completely Anyways if you want a crash on context switch in the non hole case you can probably get it by just rearranging thread_info a bit. e.g. put preempt_count first. Any corruption of that will lead to schedule complaining. Don't think it is worth it though. I suppose one could have a ...

Panic on oops/bug is sysctl-activated as things now stand, so you're all set. -- wli -

I guess most stack corruptions touch only a small part of the stack. These kinds of corruptions can only be detected from inside the program. Anyway, going beyond the program's stack boundaries would fault the program. Checking the threadinfo constantly it'll be (IMHO) mostly useless... -- - Thiago Galesi -

Some command timed out, apparently. From this one can't easily say why. Please send full dmesg. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ -

Well that's the strange thing.. I've done heavy I/O on this with no trouble. This happened overnight when my system should have been mostly idle Gerhard -- Gerhard Mack gmack@innerfire.net <>< As a computer I find your faith in technology amusing. -

On Wed, 28 Feb 2007 14:47:12 +0100 No special reason, it has simply always been that way. Getty and friends are expected to put the tty back into a sane state. -

From: Joerg Roedel <joerg.roedel@amd.com> This patch extends the alternative instructions framework to support 2 alternative instructions. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> -- Joerg Roedel Operating System Research Center AMD Saxony LLC & Co. KG

From: Joerg Roedel <joerg.roedel@amd.com> This patch adds the X86_FEATURE_SYNC_RDTSC to the i386 architecture. This is very helpfull to simplify the get_cycles_sync() function and remove the #ifdefs from it. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> -- Joerg Roedel Operating System Research Center AMD Saxony LLC & Co. KG

This series of patches extend the alternative instructions framework on i386 and x86_64 architectures to support two alternative instruction replacements. This code is used together with the introduction of the X86_FEATURE_SYNC_RDTSC flag on i386 to simplify and optimize the get_cycles_sync() function. The optimization changes this function to use RDTSCP instead of CPUID;RDTSC if this instruction is available. Don't use CPUID there is really important if the kernel runs as a KVM guest, because ...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I rebuild the kernel, without the git-block patches Patches revert-md-avoid-possible-bug_on-in-md-bitmap-handling-for-git-block.patch git-block.patch git-block-fixup.patch git-block-dupe-definitions.patch git-block-xfs-barriers-broke.patch but i still get: BUG: unable to handle kernel NULL pointer dereference at virtual address 0000000 4 printing eip: c01f369b *pde = 00000000 Oops: 0000 [#1] PREEMPT last sysfs ...

Hello, This patch splits the vlan_group struct into a multi-allocated struct. On x86_64, the size of the original struct is a little more than 32KB, causing a 4-order allocation, which is prune to problems caused by buddy-system external fragmentation conditions. I couldn't just use vmalloc() because vfree() cannot be called in the softirq context of the RCU callback. Signed-off-by: Dan Aloni <da-x@monatomic.org> --- commit 3e6b63d0827461154066ff4c51f295bfd5006bd7 tree ...

I also have an nforce4. Gerhard -- Gerhard Mack gmack@innerfire.net <>< As a computer I find your faith in technology amusing. -

In wireless we'd like to allow renaming of the phy devices we surface in sysfs. The base wireless code, however, can be built modular and thus we need device_rename exported. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> --- Is this acceptable? For testing reasons we want the cfg80211 code buildable as a module. drivers/base/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- wireless-dev.orig/drivers/base/core.c 2007-02-28 12:35:37.123956566 +0100 +++ ...

The test which automatically enables the backup timer on some HP machines doesn't trigger on other hardware which needs the backup timer too. This patch add a way to enable it manually (8250.use_backup_timer=1) to deal with these machines. Signed-off-by: Gerd Hoffmann <kraxel@suse.de> Cc: Alex Williamson <alex.williamson@hp.com> Cc: Kevin Stansell <kstansel@us.ibm.com> --- drivers/serial/8250.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) Index: ...

No. The diffstat looks huge because you moved "hid_blacklist" into a header file, and that is a big enough change that git won't consider the rename to be just a rename any more (you basically moved the old usbdrivers/usb/input/hid-core.c file into *two* files: hid-core.c and usbhid.h). Why do that? It now gets included INTO EVERY DAMN FILE that includes <usbhid.h>, since that one now has that static const struct hid_blacklist definition in it. Yet *nothing* wants it, except ...

So: - clearly other people *do* include it. - if no-one else incldues it WHY HAVE IT SEPARATE! - if you want to have it separate for other reasons, YOU MAKE IT A .c FILE, SINCE IT'S CLEARLY NOT A HEADERFILE! No. You need to realize just WHY it was wrong. Not just an "But OK". Because if you don't see why I'm complaining, I can't pull from you. You can send me patches, but for me to pull a git patch from you, I need to know that you know what you're doing, and I need to be ...

Yes, but was done by two separate commits, diffstat -M for 3d5af52d0997d545995d8747c8057be5dee49b14 shows hid-core.c as a 100% rename, but later commit b41ea57c01a1943ab36af0017cfc1329815af9ce splits You're right that usbhid.h is not a best place for it. The thing is that hid_blacklist[] and related things just badly needs cleanup - it has been for quite a long time placed on a really random place in the middle of a .c file. In addition to that, the corresponding #defines are scatthered ...

BUT IT IS NOT A HEADER FILE! Dammit! If it has real code or data in it, it's a .c file, and you don't #include it, you *compile* it and you *link* it. Linus -

The point was that noone else than hid/hid-core.c would ever be going to include this header with blacklist. The blacklist is growing in time quite rapidly and having it in the middle of the code just didn't look pretty - currently you have to perform some scrolling effort just to skip from usbhid_init_reports() to hid_find_max_report(), which just looks very sad to me. But OK, I will leave it in there. -- Jiri Kosina -

This is updated version of patch aimed to fix direct_io error handling issue i've previously sent 2 wheeks ago. If you don't like anything in this patch plese let me know. Changes: - comments added. I think now it is clearly describe things. - patch prepared against 2.6.20-mm2 How this patch tested: - LTP test, and other readv/writev op tests. - fsstress test. - manual direct_io tests. Log: - Move common segment checks to separate helper function. - Trim off blocks after ...

Initialize affinity only when building SMP kernels. Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> --- --- linux-2.6.21-rc2-dtt/arch/x86_64/kernel/io_apic.c 2007-03-06 15:20:14.000000000 +0900 +++ linux-2.6.21-rc2-kdump/arch/x86_64/kernel/io_apic.c 2007-03-06 15:48:52.000000000 +0900 @@ -832,7 +832,9 @@ static void setup_IO_APIC_irq(int apic, ioapic_write_entry(apic, pin, entry); spin_lock_irqsave(&ioapic_lock, flags); +#ifdef CONFIG_SMP irq_desc[irq].affinity = ...

Initialize affinity only when building SMP kernels. Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> --- --- linux-2.6.21-rc2-dtt/arch/i386/kernel/io_apic.c 2007-03-06 15:20:14.000000000 +0900 +++ linux-2.6.21-rc2-kdump/arch/i386/kernel/io_apic.c 2007-03-06 15:51:45.000000000 +0900 @@ -1354,7 +1354,9 @@ static void __init setup_IO_APIC_irqs(vo } spin_lock_irqsave(&ioapic_lock, flags); __ioapic_write_entry(apic, pin, entry); +#ifdef CONFIG_SMP ...

Ingo's patch correcting a bug in the SMT scheduler (http://lkml.org/lkml/2007/2/26/103) seems to have been missed. It is quite important when using dynticks. -- Damien Wyart -

I got this warning so far :) drivers/video/Kconfig:1622:warning: 'select' used by config symbol 'FB_PS3' refer to undefined symbol 'PS3_PS3AV' Regards, Gabriel -

Here's the commit with the patch from Eric that I pushed out (I had thought I'd already applied it for rc2, but I obviously hadn't. Blush. It's there now in -git, but obviously not in the -rc2 release). It's got the explanation too. Linus --- commit 2ff7354fe888f46f6629b57e463b0a1eb956c02b Author: Eric W. Biederman <ebiederm@xmission.com> Date: Tue Feb 27 00:27:41 2007 -0700 [PATCH] x86_64/i386 irq: Fix !CONFIG_SMP compilation When removing set_native_irq I ...

Initialize affinity only when building SMP kernels. Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> --- --- linux-2.6.21-rc2-dtt/arch/i386/kernel/io_apic.c 2007-03-06 15:20:14.000000000 +0900 +++ linux-2.6.21-rc2-kdump/arch/i386/kernel/io_apic.c 2007-03-06 15:51:45.000000000 +0900 @@ -1354,7 +1354,9 @@ static void __init setup_IO_APIC_irqs(vo } spin_lock_irqsave(&ioapic_lock, flags); __ioapic_write_entry(apic, pin, entry); +#ifdef CONFIG_SMP ...

I'm attaching it below. It hit the git commits mailing list just a few minutes ago. --- ~Randy

Initialize affinity only when building SMP kernels. Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> --- --- linux-2.6.21-rc2-dtt/arch/i386/kernel/io_apic.c 2007-03-06 15:20:14.000000000 +0900 +++ linux-2.6.21-rc2-kdump/arch/i386/kernel/io_apic.c 2007-03-06 15:51:45.000000000 +0900 @@ -1354,7 +1354,9 @@ static void __init setup_IO_APIC_irqs(vo } spin_lock_irqsave(&ioapic_lock, flags); __ioapic_write_entry(apic, pin, entry); +#ifdef CONFIG_SMP ...

Initialize affinity only when building SMP kernels. Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> --- --- linux-2.6.21-rc2-dtt/arch/x86_64/kernel/io_apic.c 2007-03-06 15:20:14.000000000 +0900 +++ linux-2.6.21-rc2-kdump/arch/x86_64/kernel/io_apic.c 2007-03-06 15:48:52.000000000 +0900 @@ -832,7 +832,9 @@ static void setup_IO_APIC_irq(int apic, ioapic_write_entry(apic, pin, entry); spin_lock_irqsave(&ioapic_lock, flags); +#ifdef CONFIG_SMP irq_desc[irq].affinity = ...

Ah, I misread the name. That does look like a bug, antic_expire is in jiffies. -- Jens Axboe -

Hi, I am reading the source code AS scheduler in 2.6.18(as-ioscheduler.c). In function as_close_req, variable delay is in millisecond, while ad->antic_expire is in jiffies. Doesn't the comparison of delay and ad->antic_expire make any problem? The related source code is quoted blow: if (ad->antic_status == ANTIC_OFF || !ad->ioc_finished) delay = 0; else delay = ((jiffies - ad->antic_start) * 1000) / HZ; if (delay == 0) delta = 8192; else if (delay <= 20 && delay <= ...

You got it. Xiaoning -

From: Divy Le Ray <divy@chelsio.com> This patch adds a "-ko" tag to the driver version. Signed-off-by: Divy Le Ray <divy@chelsio.com> --- drivers/net/cxgb3/version.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/cxgb3/version.h b/drivers/net/cxgb3/version.h index 782a6cf..82278f8 100644 --- a/drivers/net/cxgb3/version.h +++ b/drivers/net/cxgb3/version.h @@ -35,7 +35,7 @@ #define DRV_DESC "Chelsio T3 Network Driver" #define DRV_NAME "cxgb3" ...

... and in the meantime netdevices aren't class_device any more :) IOW, your patch isn't going to work any more. Also, I think wireless could Why not just add this to base kobject_rename instead? That way, userspace is notified for all renames in sysfs. The patch then collapses down to the change in net's sysfs code to add the ifindex to the environment, and another change in kobject to invoke a new event when a name changes and show the old name. johannes

This function is not in the 2.6.21-rc2 kernel, so you might want to rework this patch a bit :) Also, it's userspace that causes the rename to happen, so it knows it did it, why should the kernel have to emit a message to tell userspace again what just happened? thanks, greg k-h -

Hi all, Various hotplug packages have had trouble dealing with network interface being renamed. I've decided to tackle this issue from two angles : o export ifindex to those apps, as ifindex is persistent. o expose interface renaming as a hotplug event. Those two changes are complementary, even an application that would track interface by ifindex would sometime needs to know about ifname change. My assumption is that most apps would still use ifname for a long while to be backward ...

And it's enough - sorry. Jarek P. -

I just cut'n'pasted the code a few line above. If the original code is incorrect, it need fixing. And it will need fixing in probably No, envp is local, so who cares. Thanks. Jean -

From: Robert Hancock <hancockr@shaw.ca> Subject: Re: SMP performance degradation with sysbench Date: Tue, 27 Feb 2007 18:20:25 -0600 Yes, it is. Regards, Hiro -

I disagree. You don't worry about the timestamp being updated _during_ a large write() call, even though the file is constantly being modified. You think of write() as something instantaneous, while you think of writing to a shared mapping, then doing msync() as something taking a long time. In actual fact both of these are basically equivalent operations, the differences being, that you can easily modify non-contiguous parts of a file with mmap, while you can't do that with write. The ...

These change still have the undesirable property that although the modified pages may be flushed to stable storage, the metadata on the file will not be updated until the application takes positive action. This is permissible given the current wording in the specifications, but it would be much more desirable if sync(2), fsync(P), or the inode being written out due to normal system activity would also cause the metadata to be updated. Perhaps the setting of the flag could be checked in some ...

No, but you do worry about the timestamps being updated after I don't believe that this is a valid characterization because the changes to the contents of the file, made through the mmap'd region, are immediately visible to any and all other applications accessing the file. Since the contents of the file are changing, then so I think that we are going to have to agree to disagree because I don't agree either with your characterizations of the desirable semantics associated with shared mmap ...

While these entry points do not actually modify the file itself, as was pointed out, they are handy points at which the kernel gains control and could actually notice that the contents of the file are no longer the same as they were, ie. modified. From the operating system viewpoint, this is where the semantics of modification to file contents via mmap differs from the semantics of modification to file contents via write(2). It is desirable for the file times to be updated as quickly ...

Looks interesting. I'll give it a try. Thanks. /Kristian -

Hm, interesting. Looks like a pointer points to nowhere in input_unregister_device(), but I don't know which one. This may be an evdev problem ... Rafael -

Ok no issues. But when we enable freezer-based hotplug, we expect all Ah ok. When is the above patch expected to be merged? -- Regards, vatsa -

After looking at the current workqueue code, the above minor change I suggested is not required. So you should be able to fix your "kthread_stop on a frozen worker thread hangs" problem by just a simple patch like this (against 2.6.20-mm2): --- workqueue.c.org 2007-02-28 18:32:48.000000000 +0530 +++ workqueue.c 2007-02-28 18:44:23.000000000 +0530 @@ -718,6 +718,8 @@ static void cleanup_workqueue_thread(str insert_wq_barrier(cwq, &barr, 1); cwq->should_stop = 1; alive = ...

Okay, if that's better. Pavel, is that acceptable to you? Rafael -

I think Nigel might object but I forgot what specific trouble XFS was causing him. johannes

Well, if we want to have freezable workqueues eventually, and I think we do, they should be taken into consideration in designing this patchset, as well as the suspend code ordering (ie. freeze_processes(SUSPEND) before freeze_processes(CPU_HOTPLUG)). Greetings, Rafael -

OK, thanks. We can (I think) do pretty much the same with some additional complications in worker_thread() (check !cpu_online() after try_to_freeze() and break). Oleg. -

Okay, but I've just finished the patch that removes the freezability of workqueues (appended), so can we please do this in a separate one? Rafael --- Since freezable workqueues are broken in 2.6.21-rc (cf. http://marc.theaimsgroup.com/?l=linux-kernel&m=116855740612755, http://marc.theaimsgroup.com/?l=linux-kernel&m=117261312523921&w=2) it's better to remove them altogether for 2.6.21 and change the only user of them (XFS) accordingly. --- fs/xfs/linux-2.6/xfs_buf.c | 4 ++-- ...

We can just thaw the worker thread selectively before kthread_stopping them. This will let us freeze all worker threads (which we want to for Hmm ..good point. So can we assume that disable/enable_nonboot_cpus() are called with processes frozen already? See above suggestion of thawing worker thread before kthread_stopping it. -- Regards, vatsa -

Sure, we will. :-) Rafael -

I am not sure this is a good change for 2.6.21. I strongly believe it is better to change XFS so that it doesn't use create_freezeable_workqueue() as Rafael suggested. Besides, freezeable workqueues are buggy anyway in 2.6.21-rc, http://marc.theaimsgroup.com/?l=linux-kernel&m=116855740612755 This means that workqueues become non-freezeable after suspend/resume anyway (if I understand disable_nonboot_cpus() correctly). Oleg. -

No problem, but get that acked-by: from XFS people ;-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -

Hmm, nothing obviously wrong with the patch (ACK), but xfs people should ack this one, too: 'is it okay to let xfs run while suspending' -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -

Since freezable workqueues are broken in 2.6.21-rc (cf. http://marc.theaimsgroup.com/?l=linux-kernel&m=116855740612755, http://marc.theaimsgroup.com/?l=linux-kernel&m=117261312523921&w=2) it's better to change the only user of them, which is XFS, to use "normal" nonfreezable workqueues. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> --- fs/xfs/linux-2.6/xfs_buf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: ...

I get to be the guinea pig, right? :P Unfortunately I was sick for the better part of the past few days and can only test all this stuff early next week. johannes

I think you've hit the only thing that could have triggered the issue. ;-) Greetings, Rafael -

We suspected that the XFS' worker threads might commit I/O after freeze_processes() has returned, but that hasn't been supported by evidence, as far as I can recall. Also, making them freezable was controversial ... Greetings, Rafael -

-

This exception appears to be originating somewhere in the EC driver: ACPI Exception (evregion-0420): AE_NOT_FOUND, Returned by Handler for -

The page cannot be transiting since we hold the lru lock? -

If CPM0 is 46, then CPM5 is not 47, but not 49 either. Unless it's not CPM5 but CPM3? Segher -

Then it appears that the only possible solution is to assign numbers 46 - 53 to the CPM/QE and accept that it overlaps with the Altix. Is everyone okay with that? -- Timur Tabi Linux Kernel Developer @ Freescale -

The QE can have up to 8, actually, but I'm willing to limit the driver to 4. -

I don't know the origin of this thread, but none of that looks correct. Today, there can be up to 8 CPM UART devices, 6 on CPM/CPM2 and 8 on the QE. If ttyCPM0 starts at minor 46, they should be at least monotonically incrementing up to ttyCPM7 with minor 53. Thanks. -- Dan -

Minor nit: On the QE, they'll be called ttyQE0 through ttyQE7. I agree that the CPM and the QE should share the same starting minor number, so that ttyCPM0 has the same major/minor number as ttyQE0, since it's not possible to have a CPM and a QE on the same device. However, ttyCPM0 is currently assigned to 46, and device 50 is an Altix serial card. The only way to give the CPM 6 or 8 slots without moving it is to overlap the Altix card. Now I don't know anything about the Altix card, ...

I'd rather we support 8 now. - k -

Then, this is currently broken in all cases and needs to be fixed since the CPM/CPM2 I don't think that would be a problem, and I'd like the CPM/QE to share devices because it makes the software distributions common to all Freescale That would be bad. It has nothing to do with the kernel, but we have finally survived the distribution updates to ttyCPM, and I don't want to go through that again just because of QE. Thanks. -- Dan -

It sounds like the QE driver should be moved to a separate minor range, and given 8 minors. -hpa -

I just had a thought - since udev doesn't care about major/minor number assignments, can we say that the limit is 4 devices if you're not using udev, and 8 otherwise? -- Timur Tabi Linux Kernel Developer @ Freescale -

Honestly, I don't know. I was just correcting the obvious typo (47 instead of 49). I'll try to get an answer from someone, but I'm no CPM expert. -

Its your choice if you want to limit it to 4 or have it moved into a different minor range. I can live with both. Thanks, Torben -

good point. I'll fix that. I'll send a new patch set later today Thanks, Jan-Bernd -

Well, that's a small (but known!) problem with this scheme. If you say that everything below a directory "_crypt_" should be encrypted, and just move files in there, you've got no problems - the encryption settings stay the same. If you move in/out of encrypted storage, there's two options: - if it's a separate filesystem, ie. mounted, you cannot move - you have to copy & delete, which means the data gets correct settings. - if its not the same filesystem, you might get a wrongly ...

hm, it then needs to be fixed first, instead of adding to the mess. Ingo -

OK, I've fixed this by hoisting all the native_* implementations into pgtable.h. In the !PARAVIRT case the normal macros directly use the native_* functions, and in the PARAVIRT case they're used by the native paravirt_ops. This has the nice property of avoiding this specific problem, and also generally removes code duplication. J -

Hm, this is a bit awkward. We need to map the shared info page fairly early - say, around paging_init - but we're still on the bootmem allocator at that point, so get_vm_area isn't usable yet. Using a fixmap keeps things simple. It seems to me that having a single fixmap available is useful for this kind of simple/early mapping, and if someone needs to map something larger, then they can put it off until get_vm_area() is available... J -

You need to show your code, nobody can help you with such a vague description of what is going on. Either you are illegally removing a request, or your removal code is buggy. That is about all that one can conclude from the above. -- Jens Axboe -

Yes indee. That does not need to exist anymore, once the de-coupled loop is gone. Thx, I'll make a new patch later today. - Davide -

Simple. The non-arch specific code does not use 64/64 divides through the "/" operator (otherwise there would already have been udivdi3 linking errors). So what remains to check is arch/arm26. grep -Pr 'int64|\bu64' returns only a few results to check (kernel/ecard.c, nwfpe/), so the answer is most likely no. Jan -- -

AFAICS, "still active" is printed from ata_host_suspend() if a device (disk) on the host to be suspended doesn't have ATA_DFLAG_SUSPENDED flag set. This flag is only set in ata_eh_suspend(), which is only called from ata_eh_recover(), like this: generic_error_handler() ata_bmdma_drive_eh() ata_do_eh() ata_eh_recover() ata_eh_suspend() dev->flags |= ATA_DFLAG_SUSPENDED; but I don't understand why the error handler should be envoked? Should the "disk" be suspended before the host and ...

PLIP/Laplink runs bidirectional on ordinary parallel ports. The bidirectional part of parallel ports in "normal" modes is still used for things like PnP detection of printer and drivers. -

The bidirectional use is/was PL/IP, aka "laplink" connections. Yes, I still have a machine I installed that way, and it will run 2.2.19 -- 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 -

Screenshot of the resulting kernel panic: http://systemlinux.org/~maan/shots/kernel-panic-21-rc2-huangho2.png Andre

Looks good! -- Regards, vatsa -

You're right, but in that comment I wanted to explain why it was done this way rather than what else it could be used for. There may be some uses of it that we can't even anticipate right now. :-) Rafael -

Which is because we don't want the kernel threads to be frozen in unexpected places, so we allow them to block freeze_processes() instead or to set You're welcome. :-) Greetings, Rafael -

Okay, I have added a comment to freezer.h. Please have a look. Rafael --- From: Rafael J. Wysocki <rjw@sisk.pl> Currently try_to_freeze_tasks() has to wait until all of the vforked processes exit and for this reason every user can make it fail. To fix this problem we can introduce the additional process flag PF_FREEZER_SKIP to be used by tasks that do not want to be counted as freezable by the freezer and want to have TIF_FREEZE set nevertheless. Then, this flag can be set by tasks ...

2.6.20-rcX used to copy all files then hang on certain operations that I think used the VFS. 2.6.21-rc1 stalls the NFS transfer itself after several GB. The data was never corrupted. Have you tried copying _ALL_ 190 GB to the server? florin --=20 Bruce Schneier expects the Spanish Inquisition. http://geekz.co.uk/schneierfacts/fact/163

Actually, in many cases this is just what you do want, to avoid filling memory with buffered writes and then flushing them on time or memory runout. -- 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 -

I wouldn't be that sure ... I've had problems in the past with PMU based cpufreq... looks like flushing all caches and hard-resetting the processor on the fly when there can be pending DMAs might be a source of trouble... especially on CPUs that don't have working cache flush HW assist. Ben. -

Acked-by: Hugh Dickins <hugh@veritas.com> Thanks for doing this, and sorry for my delay. -

That may be the case, but in my opinion if this helps it doesn't "solve" the problem, because the real problem is that a process which is not on a HT is being treated as if it were. Note that Intel does make multicore HT processors, and hopefully when this code works as intended it will result in more total throughput. My supposition is that it currently is NOT working as intended, since disabling SMT scheduling is reported to help. A test with MC on and SMT off would be informative for ...

Ok, thanks for the clarification. -Nish -

I don't think it is exactly a matter of processes >= cores, but rather just a general problem at higher concurrency. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com -

I've had them fail within days when using almost identical serial numbers. Nowdays I just mix disk vendors on each array. End of problem. -

The were some rumours earlier, but now I actually stumbled over the release - and recalled this thread. This might be what you are looking for: http://most4linux.sourceforge.net/ Jan -

Try setting the resolution and frame rate, video=XXX:1280x1024@70 or such. Worked for me. I like pci=noacpi, though ;-) -- 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 -

Quad core what platform? How many C-states are supported in this platform? Current ladder is mostly like Policy embedded in ACPI today. But, Adam has been working on different policies that we want to experiment with as we go along. Thanks, Venki -

On Wed, 28 Feb 2007 18:11:11 +0900 If it's an sh-only thing then through your tree is fine, thanks. -

Extended the cc list with a few people that recently worked on the audit code, maybe somebody could answer my question above? -

The patch does not contain any of the metadata I need to apply it No, this is wrong. Leaving the variables uninitialized at least warns you about the bug you have in this function: when there is anything wrong, you just continue writing the record with zero offset and dcookie values in it. Instead, you should get handle the error condition somewhere down the code. It's harmless most of the time, but you really should not be painting Right, I forgot about this. Arnd <>< -

it is not. Today i've implemented 64-bit syslets on x86_64 and 32-bit-on-64-bit compat syslets. Both the 64-bit and the 32-bit syslet (and threadlet) binaries work just fine on a 64-bit kernel, and they share 99% of the infrastructure. There's only a single #ifdef CONFIG_COMPAT in kernel/async.c: #ifdef CONFIG_COMPAT asmlinkage struct syslet_uatom __user * compat_sys_async_exec(struct syslet_uatom __user *uatom, struct async_head_user __user *ahu) { ...

No-o. Kernel is not designed like that. Often, more complex and slightly faster code exists, and we simply use slower variant, because it is fast enough. 10% gain in speed is NOT worth major complexity increase. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -

there are so many variants of what people think 'asynchronous IO' should look like - i'd not like to limit them. I agree that once a particular syslet script becomes really popular, it might (and should) in fact be pushed into a separate system call. But i also agree that a one-shot-syscall sys_async() syscall could be done too - for those uses where only a single system call is needed and where the fetching of a single uatom would be small but nevertheless unnecessary overhead. A ...

no, i made the 64-bit and 32-bit structures layout-compatible. This makes the 32-bit structure as large as the 64-bit ones, but that's not a the thing is, there's almost zero overhead from having those basic things like conditions and the ->next link, and they make it so much more capable. As usual my biggest problem is that you are not trying to use syslets at all - you are only trying to get rid of them ;-) My purpose with syslets is to enable a syslet to do almost anything that ...

Well, I agree, except for one thing: - user space execution is *inherently* more expensive. Why? Stack. Stack. Stack. If you support threadlets with user space code, it means that you need a separate user-space stack for each threadlet. That's a potentially *big* cost to bear, both from a setup standpoint and from simply a memory allocation standpoint. Quite frankly, I think threadlets are a great idea, but I think the lack of user-level footprint is *also* a great idea, and you ...

No, the "result" needs to go somewhere else. The caller may be totally uninterested in keeping the system call number or parameters around until the operation completes, but if you put them in the same structure with the result, you obviously cannot sanely get rid of them. I also don't much like read-write interfaces (which the above would be: the kernel would read most of the structure, and then write one member of the structure). It's entirely possible, for example, that the ...

that's quite close to what Jens' FIO plugin for syslets (engines/syslet-rw.c) does currently: it builds lists of syslets as IO gets submitted, batches them up for some time and then sends them off. It is a natural next step to do this for in-flight syslets as well. Ingo -

I have to agree; state machines are harder to design and read, but multithreaded programs are harder to write and debug _correctly_. Another way of putting it is that the threadlet approach is easier to do, but harder to do _right_. -

we talked about the parameters at length: if they are pointers the layout is significantly more flexible and more capable. It's a pretty similar argument to the return-pointer thing. For example take a look at how the IO syslet atoms in Jens' FIO engine share the same fd. Even if there's 20000 of them. And they are fully cacheable in constructed state. The same goes for the webserving examples i've got in the async-test userspace sample code. I can pick up a cached request and only ...

Ok, makes sense. Something like this then? struct async_syscall { unsigned long nr_sysc; unsigned long params[8]; long *result; }; And what would async_wait() return bak? Pointers to "struct async_syscall" or pointers to "result"? - Davide -

Ok, now that I can run this on more than x86, I gave it a spin on a box with a little more potent storage. This is a core 2 quad, disks are 7200rpm sata (with NCQ) and a 15krpm SCSI disk. IO scheduler is deadline. SATA disk: Engine Depth Batch Bw (KiB/sec) ---------------------------------------------------- libaio 64 8 17,486 syslet 64 8 17,357 libaio 20000 8 17,625 syslet 20000 8 16,526 sync 1 1 7,529 SCSI ...

At this point, given how threadlets can be easily/effectively dispatched from userspace, I'd argue the presence of either single/parallel or syslet submission altogether. Threadlets allows you to code chains *way* more naturally than syslets, and since they basically are like functions calls in the fast path, they can be used even for single/parallel submissions. No compat code required (ok, besides the trivial async_wait). My point is, the syslet infrastructure is expensive for the kernel ...

This doesn't work for apps that use the deprecated /dev/dsp API. Of course, a modern distro should be trying to purge these anyway... Lee -

Can you please get the dmesg output after resume via the network ? tglx -

Just reproduced this in -rc2. Another thing I noticed: with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM. On 2.6.21-rc2, after resume (when the box is accessible from network), pressing Fn/F4 again does not seem to have any effect. -- MST -

(hrmph. having to copy/paste/try again. evolution seems to be broken.. RCPT TO <linux-kernel@vg.kolivas.org> failed: Cannot resolve your domain {mp049} ..caused me to be unable to send despite receipts being disabled) No I'm not, but let's go further in that direction just for the sake of argument. You're then saying that you prefer realtime priorities to not work in the HT setting, given that realtime tasks don't participate in the 'single stream me' program. I'm saying only that we're ...

The link above has it. -- MST -

Hi Eric, Thanks for getting this cruft cleaned up. I have a few comments regarding; handle-irqs-pending-in-irr-during-irq-migration.patch 1) It relies on checking the IRR, this could race with the corresponding vector bit being set by hardware. 2) apic_handle_pending_vector is oddly named since it doesn't actually handle a pending vector but drops it if it has been freed. 3) It looks complex So how about the following scheme. Add a check in do_IRQ whether the irq's domain ...

Ok if that is really what we are going with, the this silly patch isn't simple enough for a backport. There used to other rules to the effect the patch must be merged in mainline, and we only backport to one kernel revision. I think it fails the 100 lines with context test. The meaning of obviously correct is a little bit nebulous. But if something is obvious multiple people can easily understand what is going on. I haven't gotten any feedback that has said yes I see what you are ...

Hmm.. I seem to have failed to send out this reply a few days ago :( There are two questions. 1) What can we do to make the situation better. 2) Is the hole completely plugged. When I wrote the patch I had the local apic priorities backwards in my head. So apic_in_service_vector can return the wrong value if two irqs are in service. Now I don't think we allows ourselves to enable interrupts in an interrupt service routing until after we have acked the local apic so this should be ...

Works great: survived three reboots without lockup or warning messages. And it's a nice simple patch, too... -

Sounds reasonable to me. But maybe in that case we should invert the sense of the flag. UPF_MOVABLE_PORT or UPF_USER_CONFIGURABLE or something. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson -

Hi Andrew, I've bisected myself 2.6.20-mm2 instead. And the winners are: x86_64-mm-adjust-inclusion-of-asm-fixmap_h.patch x86_64-mm-adjust-inclusion-of-asm-vsyscall32_h.patch The former breaks the compilation in a different way. The latter fixes it but causes the breakage I reported originally. Does it really matter anyway? Even in mainline, include/asm-x86_64/io_apic.h uses MAX_IO_APICS, so it should include the header file which defines it, that is <asm/apicdef.h>. It doesn't, that's ...

Oops, sorry about that but no, that will not work. There's piece of paper, called ACPI specification, and we are following it. Bug is not in our implementation. Bug is in the ACPI specs... it does not explicitely allow you to go out and bitbang i2c, and you do it, and you get problems. Now, you may try to change specs to be hwmon-friendly... good luck. But currently hw manufacturers follow ACPI specs, so we have to follow it, too; bad luck for hwmon. BIOS hiding smbus from you is ...

Why? The device really generates many different interrupts, Duplicate all this stuff into /sys in a sane format (*) and wait until userland catches up, then throw away the /proc interfaces. It'll take a while, and until that day you will have to keep *some* interrupt number <-> interrupt bijection. Userland tools that think they know what interrupt number should be what are dead already. (*) i.e., exposing the interrupt tree as a tree, cascaded controllers and all. Segher -

Well irq_request is probably a bit late for associating an irq with a struct device. And I don't see how to get the device name from that Yes. But if you can do a good job of wrapping them so a driver wouldn't need to care at all that could help simplify drivers and remove one more tidbit of complexity from drivers. However for a widespread change. The less you have to think about it the more quickly you can get it completed. So I would rather do several wide spread changes in ...

Yes, and the irqs can be routed at different cpus independently. However not all hardware supports all 4K irqs. 4K is the implementation defined maximu. Although infiniband HCA's are rumored to support a lot of irqs and it isn't uncommon for simpler nics to support 4 or so. Conceptually think of it as having an irq controller embedded in your pci device. The MSI messages are writes to special addresses that are then No. That would be unnecessary coalescing. Even if that was what ...

Isn't scan_align in pixmap for this? Or do we need more. -

22 =C5=9Eub 2007 Per tarihinde, S.=C3=87a=C4=9Flar Onur =C5=9Funlar=C4=B1 y= Sorry for long delay, here are some more test results; * using video=3Dvesafb:noblank _sometimes_ causes hard freezes on resume, a= nd=20 _sometimes_ X can't start properly (it enters a weird "switch vt1 - wait fo= r=20 some seconds - switch vt7" loop and after ~10 minutes X starts magically!)= =20 whenever this happens system starts to become really unresponsive and dmesg= =20 and Xorg's logs shows nothing ...

The basically random order-of-request_irq() prioritization was causing problems (it worked for some but didnt work for others), so i got rid of trying to auto-guess some priority order. Also, now that we've got tools/scripts like set_kthread_prio and rtprio it seemed more consistent to just not attempt to prioritize interrupts and softirqs at all, but to keep them all 'in the middle' of the RT priority range. Ingo -