[PATCH 1/2] Revert IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs
This reverts commit a3cd7d9070be417a21905c997ee32d756d999b38. The original commit breaks iSER reliably, making it complain: iser: iser_reg_page_vec:ib_fmr_pool_map_phys failed: -11 The FMR cleanup thread runs ib_fmr_batch_release() as dirty entries build up. This commit causes clean but used FMR entries also to be purged. During that process, another thread can see that there are no free FMRs and fail, even though there should always have been enough available. Signed-off-by: Pete Wyckoff [EMAIL PROTECTED] --- drivers/infiniband/core/fmr_pool.c | 21 ++--- 1 files changed, 6 insertions(+), 15 deletions(-) diff --git a/drivers/infiniband/core/fmr_pool.c b/drivers/infiniband/core/fmr_pool.c index 7f00347..4044fdf 100644 --- a/drivers/infiniband/core/fmr_pool.c +++ b/drivers/infiniband/core/fmr_pool.c @@ -139,7 +139,7 @@ static inline struct ib_pool_fmr *ib_fmr_cache_lookup(struct ib_fmr_pool *pool, static void ib_fmr_batch_release(struct ib_fmr_pool *pool) { int ret; - struct ib_pool_fmr *fmr, *next; + struct ib_pool_fmr *fmr; LIST_HEAD(unmap_list); LIST_HEAD(fmr_list); @@ -158,20 +158,6 @@ static void ib_fmr_batch_release(struct ib_fmr_pool *pool) #endif } - /* -* The free_list may hold FMRs that have been put there -* because they haven't reached the max_remap count. -* Invalidate their mapping as well. -*/ - list_for_each_entry_safe(fmr, next, pool-free_list, list) { - if (fmr-remap_count == 0) - continue; - hlist_del_init(fmr-cache_node); - fmr-remap_count = 0; - list_add_tail(fmr-fmr-list, fmr_list); - list_move(fmr-list, unmap_list); - } - list_splice(pool-dirty_list, unmap_list); INIT_LIST_HEAD(pool-dirty_list); pool-dirty_len = 0; @@ -384,6 +370,11 @@ void ib_destroy_fmr_pool(struct ib_fmr_pool *pool) i = 0; list_for_each_entry_safe(fmr, tmp, pool-free_list, list) { + if (fmr-remap_count) { + INIT_LIST_HEAD(fmr_list); + list_add_tail(fmr-fmr-list, fmr_list); + ib_unmap_fmr(fmr_list); + } ib_dealloc_fmr(fmr-fmr); list_del(fmr-list); kfree(fmr); -- 1.5.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ib fmr pool: flush used clean entries
Commit a3cd7d9070be417a21905c997ee32d756d999b38 (IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs) caused a regression for iSER and was reverted in e5507736c6449b3253347eed6f8ea77a28cf688e. This change attempts to redo the original patch so that all used FMR entries are flushed when ib_flush_fmr_pool() is called, and other FMR users are not affected. Simply move used entries from the clean list onto the dirty list before letting the cleanup thread do its job. Signed-off-by: Pete Wyckoff [EMAIL PROTECTED] --- drivers/infiniband/core/fmr_pool.c | 17 - 1 files changed, 16 insertions(+), 1 deletions(-) diff --git a/drivers/infiniband/core/fmr_pool.c b/drivers/infiniband/core/fmr_pool.c index 4044fdf..06d502c 100644 --- a/drivers/infiniband/core/fmr_pool.c +++ b/drivers/infiniband/core/fmr_pool.c @@ -398,8 +398,23 @@ EXPORT_SYMBOL(ib_destroy_fmr_pool); */ int ib_flush_fmr_pool(struct ib_fmr_pool *pool) { - int serial = atomic_inc_return(pool-req_ser); + int serial; + struct ib_pool_fmr *fmr, *next; + + /* +* The free_list holds FMRs that may have been used +* but have not been remapped enough times to be dirty. +* Put them on the dirty list now so that the cleanup +* thread will reap them too. +*/ + spin_lock_irq(pool-pool_lock); + list_for_each_entry_safe(fmr, next, pool-free_list, list) { + if (fmr-remap_count 0) + list_move(fmr-list, pool-dirty_list); + } + spin_unlock_irq(pool-pool_lock); + serial = atomic_inc_return(pool-req_ser); wake_up_process(pool-thread); if (wait_event_interruptible(pool-force_wait, -- 1.5.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + rcu-split-listh-and-move-rcu-protected-lists-into-rculisth.patch added to -mm tree
Hi, Josh Triplett wrote: [I did not see this patch go by on any mailing list, so I replied to the -mm mail and CCed LKML.] Well I'm pretty sure to have always CC'ed LKML, see for example: http://lkml.org/lkml/2008/2/19/150 http://lkml.org/lkml/2008/2/19/151 Thanks, Franck -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
(regression) kernel/timeconst.h bugs with HZ=128
I see these warnings on 32 bit ARM systems: CC kernel/time.o kernel/time.c: In function 'msecs_to_jiffies': kernel/time.c:472: warning: integer constant is too large for 'long' type kernel/time.c: In function 'usecs_to_jiffies': kernel/time.c:487: warning: integer constant is too large for 'long' type Line 472: return ((u64)MSEC_TO_HZ_MUL32 * m + MSEC_TO_HZ_ADJ32) line 487: return ((u64)USEC_TO_HZ_MUL32 * u + USEC_TO_HZ_ADJ32) The problem seems to be that these constants from kernel/timeconst.h have too many digits: #define ONLY_THIRTYTWO_BITS 0x01234567 #define MSEC_TO_HZ_ADJ320x3f7ced916 #define USEC_TO_HZ_ADJ320xfffbce4217d Those *_ADJ32 constants should have ULL suffixes, yes? Adding that by hand resolves the problem, but only until the next time that header file gets regenerated. Someone with observable Perl-fu should fix this ... - Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Performance problems with 3ware 9500S-4LP and 2.6.25-rc3
Andre Noll wrote: we are experiencing massive performance problems with two of our Linux servers that contain 3ware controllers on a Tyan mainboard and a couple of 1T disks. During the daily cron job that uses rsync to sync a 500G file system from another machine to the raid on the 3ware controller the load jumps up, and the machine becomes sluggish as hell. For example, an ssh login to that machine takes minutes to complete and ldap becomes unreliable while the rsync job is running. Even Nagios complains about the machine being down while rsync is running. You're putting your box under astronomical load. This is generally regarded as a bad idea, regardless of how well your storage controller is performing. Can you measure the single-threaded throughput (say, coping one huge file, and then syncing) to give us a baseline performance figure? rsync will happily peg your box, your network, and your cat if you let it. -- Chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Mon, Feb 25, 2008 at 09:27:42PM -0800, Yinghai Lu wrote: On Mon, Feb 25, 2008 at 8:05 PM, Ravikiran Thirumalai [EMAIL PROTECTED] wrote: On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: If you can't support that in your hardware you're supposed to clear it. Hmm! How would a hardware vendor do that? That doesn't seem to be clear in the BKDG. (Well, this is the problem with undocumented features :() any good sign for APIC_clustered box? there is apicid between cpus even all cpu are quadcore and fully populated? I would suggest checking the SLIT distances -- On AMD boxes, if you have three different distances between nodes, then that system would be multiboard, and there is no way TSCs can be synced. On Intel boxes, if there are two different distances between nodes, then this would be a multi board/multi chassi box and TSCs won't be synced. This is a more generic solution and should work on Summit/Unisys boxes as well. (I am ignoring Intel CSI for now. It might need the same treatment as AMD) Comments? Kiran -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 Regression Thinkpad acpi
On Mon, Feb 25, 2008 at 08:00:35PM -0300, Henrique de Moraes Holschuh wrote: On Mon, 25 Feb 2008, Lukas Hejtmanek wrote: volume keys work. But anything through acpid does not. Even AC/battery switch is not signalized. So the bug may be somewhere else? Yeah, there is an EC-related regression in 2.6.25-rc3 that bites your thinkpad. I don't have a link to it right now, but if you look for the messages to LKML on the last 48h, you will find it. this one fixes all my troubles with thinkpad hotkeys in rc3. http://lkml.org/lkml/2008/2/25/400 [ 418.816087] thinkpad_acpi: requested hot key mask 0x, but firmware forced it to 0x00ff Don't do this. Just let the driver select the default mask, unless you *really* know better. OK, thanks. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25 patch] drivers/crypto/hifn_795x.c: fix 64bit division
Hi Adrian. On Tue, Feb 26, 2008 at 05:34:21PM +0200, Adrian Bunk ([EMAIL PROTECTED]) wrote: Using ndelay() with a 64bit variable as parameter can result in build errors like the following on some 32bit systems when it results in a 64bit division: -- snip -- ... MODPOST 759 modules ERROR: __divdi3 [drivers/crypto/hifn_795x.ko] undefined! -- snip -- Reported by Martin Michlmayr. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Yep, ndelay() uses division, thanks a lot Adrian for spotting this. Herbert, please apply. ACK. -- Evgeniy Polyakov -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Is there a memory block device?
I know that tmpfs is a memmory filesystem. Is there a possibility to create also a memory block device? Is there a possibility to create for example a 1 GB memory block device (from the RAM)? -- E-Mail sent with anti-spam site TrashMail.net! Free disposable email addresses: http://www.trashmail.net/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86_64: Seperate mmconf for fam10h out from setup_64.c
Seperate mmconf for fam10h out from setup_64.c Signed-off-by: Yinghai Lu [EMAIL PROTECTED] diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 199f8b5..4f2b9ed 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -101,4 +101,6 @@ ifeq ($(CONFIG_X86_64),y) obj-$(CONFIG_GART_IOMMU) += pci-gart_64.o aperture_64.o obj-$(CONFIG_CALGARY_IOMMU)+= pci-calgary_64.o tce_64.o obj-$(CONFIG_SWIOTLB) += pci-swiotlb_64.o + +obj-$(CONFIG_PCI_MMCONFIG) += mmconf-fam10h_64.o endif diff --git a/arch/x86/kernel/mmconf-fam10h_64.c b/arch/x86/kernel/mmconf-fam10h_64.c new file mode 100644 index 000..3789792 --- /dev/null +++ b/arch/x86/kernel/mmconf-fam10h_64.c @@ -0,0 +1,215 @@ +/* + * AMD Family 10h mmconfig enablement + */ + +#include linux/types.h +#include linux/mm.h +#include linux/string.h +#include linux/pci.h +#include asm/pci-direct.h +#include linux/sort.h +#include asm/io.h +#include asm/msr.h +#include asm/acpi.h + +struct pci_hostbridge_probe { + u32 bus; + u32 slot; + u32 vendor; + u32 device; +}; + +static u64 __cpuinitdata fam10h_pci_mmconf_base; +static int __cpuinitdata fam10h_pci_mmconf_base_status; + +static struct pci_hostbridge_probe pci_probes[] __cpuinitdata = { + { 0, 0x18, PCI_VENDOR_ID_AMD, 0x1200 }, + { 0xff, 0, PCI_VENDOR_ID_AMD, 0x1200 }, +}; + +struct range { + u64 start; + u64 end; +}; + +static int __cpuinit cmp_range(const void *x1, const void *x2) +{ + const struct range *r1 = x1; + const struct range *r2 = x2; + int start1, start2; + + start1 = r1-start 32; + start2 = r2-start 32; + + return start1 - start2; +} + +/*[47:0] */ +/* need to avoid (0xfd32) and (0xfe32), ht used space */ +#define FAM10H_PCI_MMCONF_BASE (0xfcULL32) +#define BASE_VALID(b) ((b != (0xfdULL 32)) (b != (0xfeULL 32))) +static void __cpuinit get_fam10h_pci_mmconf_base(void) +{ + int i; + unsigned bus; + unsigned slot; + int found; + + u64 val; + u32 address; + u64 tom2; + u64 base = FAM10H_PCI_MMCONF_BASE; + + int hi_mmio_num; + struct range range[8]; + + /* only try to get setting from BSP */ + /* -1 or 1 */ + if (fam10h_pci_mmconf_base_status) + return; + + if (!early_pci_allowed()) + goto fail; + + found = 0; + for (i = 0; i ARRAY_SIZE(pci_probes); i++) { + u32 id; + u16 device; + u16 vendor; + + bus = pci_probes[i].bus; + slot = pci_probes[i].slot; + id = read_pci_config(bus, slot, 0, PCI_VENDOR_ID); + + vendor = id 0x; + device = (id16) 0x; + if (pci_probes[i].vendor == vendor + pci_probes[i].device == device) { + found = 1; + break; + } + } + + if (!found) + goto fail; + + /* SYS_CFG */ + address = MSR_K8_SYSCFG; + rdmsrl(address, val); + + /* TOP_MEM2 is not enabled? */ + if (!(val (121))) { + tom2 = 0; + } else { + /* TOP_MEM2 */ + address = MSR_K8_TOP_MEM2; + rdmsrl(address, val); + tom2 = val (0xULL32); + } + + if (base = tom2) + base = tom2 + (1ULL32); + + /* +* need to check if the range is in the high mmio range that is +* above 4G +*/ + hi_mmio_num = 0; + for (i = 0; i 8; i++) { + u32 reg; + u64 start; + u64 end; + reg = read_pci_config(bus, slot, 1, 0x80 + (i 3)); + if (!(reg 3)) + continue; + + start = (((u64)reg) 8) (0xffULL 32); /* 39:16 on 31:8*/ + reg = read_pci_config(bus, slot, 1, 0x84 + (i 3)); + end = (((u64)reg) 8) (0xffULL 32); /* 39:16 on 31:8*/ + + if (!end) + continue; + + range[hi_mmio_num].start = start; + range[hi_mmio_num].end = end; + hi_mmio_num++; + } + + if (!hi_mmio_num) + goto out; + + /* sort the range */ + sort(range, hi_mmio_num, sizeof(struct range), cmp_range, NULL); + + if (range[hi_mmio_num - 1].end base) + goto out; + if (range[0].start base) + goto out; + + /* need to find one window */ + base = range[0].start - (1ULL 32); + if ((base tom2) BASE_VALID(base)) + goto out; + base = range[hi_mmio_num - 1].end + (1ULL 32); + if ((base tom2) BASE_VALID(base)) + goto out; + /* need to find window between ranges */ + if (hi_mmio_num 1) + for (i = 0; i hi_mmio_num - 1; i++) { +
Re: extra bytes written to SATA DVD drive on kernel 2.6.23 till 2.6.24.2
It does happen with 2.6.22 too. Do you see any known pattern in these extra bytes ? Best Regards Gerold 2a 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |[EMAIL PROTECTED]| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0002 2a 00 00 00 00 40 00 00 40 00 00 00 00 40 00 00 |[EMAIL PROTECTED]@[EMAIL PROTECTED]| 00020010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0004 2a 00 00 00 00 80 00 00 40 00 00 00 00 80 00 00 |[EMAIL PROTECTED]| 00040010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0006 2a 00 00 00 00 c0 00 00 02 00 00 00 00 c0 00 00 |*...| 00060010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00061010 00 00 00 00 00 00 00 00 2a 00 00 00 00 c2 00 00 |*...| 00061020 40 00 00 00 00 c2 00 00 00 00 00 00 00 00 00 00 |@...| 00061030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00081010 00 00 00 00 00 00 00 00 2a 00 00 00 01 02 00 00 |*...| 00081020 40 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 |@...| 00081030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 000a1010 00 00 00 00 00 00 00 00 2a 00 00 00 01 42 00 00 |*B..| 000a1020 40 00 00 00 01 42 00 00 00 00 00 00 00 00 00 00 |@B..| 000a1030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 000c1010 00 00 00 00 00 00 00 00 2a 00 00 00 01 82 00 00 |*...| 000c1020 40 00 00 00 01 82 00 00 00 00 00 00 00 00 00 00 |@...| 000c1030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * On Tuesday 26 February 2008 00:32:49 Andrew Morton wrote: On Mon, 25 Feb 2008 20:05:22 +0100 Gerold Jury [EMAIL PROTECTED] wrote: Hello, I have two DVD drives, one connected to the SATA port (LG) the other to the IDE port (PHILIPS) of a via chipset. They are driven by VIA SATA support (SATA_VIA) and VIA PATA support (PATA_VIA). When I write an iso image to the drive on the SATA port /dev/sr0 it has some extra bytes on disk which make the disk unreadable. Writing to the IDE drive /dev/sr1 works well. A simple test with a DVD RAM and dd instead of growisofs dd if=/dev/zero of=/dev/srX bs=1024k count=10 and a readback afterwards dd if=/dev/srX of=imageX.bin bs=1024k count=10 gives me an all zero file from the IDE drive but a file full of probably scsi commands for the SATA drive and looks like 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0002 2a 00 00 00 00 40 00 00 40 00 00 00 00 40 00 00 |[EMAIL PROTECTED]@[EMAIL PROTECTED]| 00020010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0004 2a 00 00 00 00 80 00 00 40 00 00 00 00 80 00 00 |[EMAIL PROTECTED]| 00040010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0006 2a 00 00 00 00 c0 00 00 02 00 00 00 00 c0 00 00 |*...| 00060010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00061010 00 00 00 00 00 00 00 00 2a 00 00 00 00 c2 00 00 |*...| 00061020 40 00 00 00 00 c2 00 00 00 00 00 00 00 00 00 00 |@...| 00061030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00081010 00 00 00 00 00 00 00 00 2a 00 00 00 01 02 00 00 |*...| 00081020 40 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 |@...| 00081030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 000a1010 00 00 00 00 00 00 00 00 2a 00 00 00 01 42 00 00 |*B..| 000a1020 40 00 00 00 01 42 00 00 00 00 00 00 00 00 00 00 |@B..| 000a1030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 000c1010 00 00 00 00 00 00 00 00 2a 00 00 00 01 82 00 00 |*...| 000c1020 40 00 00 00 01 82 00 00 00 00 00 00 00 00 00 00 |@...| 000c1030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || I really need some hints to make the SATA drive usable, please. (added linux-ide) Did any earlier kernel work OK? 2.6.22? Thanks. uname -a Linux blaubaer 2.6.24.2 #4 Sun Feb 24 21:50:21 CET 2008 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux lspvi -v 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) Subsystem: ASUSTeK Computer Inc. A7V600/K8V Deluxe/K8V-X/A8V Deluxe motherboard Flags: bus master, medium devsel, latency 64, IRQ 20 I/O ports at e800 [size=8] I/O ports at e400 [size=4] I/O ports at e000 [size=8] I/O ports at d800 [size=4] I/O ports at d400 [size=16] I/O ports at d000 [size=256] Capabilities: [c0] Power Management version 2 Kernel driver in use: sata_via 00:0f.1 IDE interface: VIA
Re: broken suspend in .2.6.25-rc3 on T61p (was Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p)
On Tue, 26 Feb 2008 19:16:11 +0100 Pavel Machek [EMAIL PROTECTED] wrote: On Tue 2008-02-26 13:10:01, Dave Jones wrote: On Tue, Feb 26, 2008 at 06:59:54PM +0100, Pavel Machek wrote: if by 'custom' you mean the solution everyone agreed to work toward at the power management summit several years ago (hal/pm-utils) then, yes. I must have been on different summit... I believe it is bad to tie s2ram to hal, because it makes testing on minimal system hard. Anyway, what is the default way to trigger s2ram for Andrew? Perhaps Fedora already has his machine whitelisted... There is no s2ram. pm-suspend uses the white/black-lists in pm-utils. Remember that? The cross-distro package everyone agreed was a good idea so that every distro didn't have their own magic utility ? Well, we have cross-distro package, it is at suspend.sf.net , and it can bring up video - which is kind of important. (It is single binary, so it can be pagelocked -- which is important for s2disk). Plus it does not depend on HAL. Meanwhile, my computer continues to not work. First thing we need to do is to work out why it won't stay suspended? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Odd performance observation for RAID0
Hi folks: I posted this in linux-raid, though I thought it might interest the kernel folks due to the subsystems in question. No responses there. Executive summary version: building a RAID0 across 2 large hardware RAIDed disks results in buffered I/O performance that is similar to a single one of these controllers. Additional tests, breaking the raid apart into 2 separate drives, yields the expected I/O performance when using buffered IO, and 2 simultaneous IO operations, one to each disk. Direct IO doesn't show this performance anomaly and is fast in either case. Observed with kernel 2.6.23.14. A curious thing happens with 2.6.24.2, in that now direct IO performance is as bad as buffered IO performance. The problem as stated, leads me to think that I might be running into a point of serialization of the buffer cache. Details: I built a RAID0 stripe across two large hardware RAID cards (identical cards/driver). What I am finding is that direct IO is about the performance I expect (2x the single RAID card) while buffered IO is about the same as the performance of a single RAID card. This is true across chunk sizes of 64 through 4096k, with an xfs file system. This is a 2.6.23.14 kernel. I tried 2.6.24.2, and there the direct IO on two RAID cards was the same speed as the direct and buffered IO on one RAID card, even though the RAID0 striped across 2 RAID cards. There appears to be some issue with this combination of RAID0, buffer cache, and the driver. Breaking the raid in 2, and performing the same tests on each RAID card results in the expected performance during buffered io and direct IO. Tests were simple reads and writes: dd if=/dev/zero of=/big/local.file bs=8388608 count=1 and dd if=/big/local.file of=/dev/null bs=8388608 added oflag=direct and iflag=direct for the direct io versions. I tried changing the default IO scheduler (cfq to deadline) though this particular workload shouldn't make much of a difference (all reads or all writes). I tried altering queue depth, and a number of other parameters. All told, they had limited impact. The end user of this system indicated that they will be using fadvise mechanisms to handle cache hinting, and they will be doing large block sequential streaming, so direct IO like performance should be fine. That said, I am concerned that the buffered IO case appears serialized. Of course we are not re-using the buffer for these tests, so this could have an impact. Along those lines, I tried adjusting the dirty parameters to see what I could do /proc/sys/vm/dirty_expire_centisecs /proc/sys/vm/dirty_writeback_centisecs /proc/sys/vm/dirty_ratio /proc/sys/vm/dirty_background_ratio I tried various changes that I thought might work (increasing the dirty_ratio while decreasing the dirty_expire_centisecs). I did get some impact, though it was mostly in the direction of lower performance. The questions I have are, could the raid0 device be effectively serializing access to the buffer cache? The hardware RAID devices I am using are quite fast, so this might represent a different area of testing than raid0 normally gets. Other possibilities I have thought of include oddities in xfs (I tried ext3 as well, though I ran into an 8TB limit) and how it interacts with the buffer cache. Driver oddities (seen on several versions of this driver). To try to eliminate these other effects, I broke the unit up into 2 separate devices (1 per RAID card), and built two file systems. Simultaneous IO to each file system gave expected performance. My take on that is that the driver (handling both RAIDs) has no trouble interacting with the OS and the buffer cache under heavy IO situations. I used xfs on each file system, so it further suggests that xfs is not likely the problem. With all this said, does anyone have any suggestions on this? Or even where to look in the raid0.c code (or elsewhere) to see what is going on? Thanks! Joe -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: epoll and shared fd's
On Tue, 26 Feb 2008, Michael Kerrisk wrote: Following up after quite some time: Davide Libenzi wrote: On Sat, 26 Jan 2008, Michael Kerrisk wrote: On Jan 25, 2008 12:57 AM, Davide Libenzi [EMAIL PROTECTED] wrote: On Thu, 24 Jan 2008, Pierre Habouzit wrote: On Fri, Jan 18, 2008 at 09:10:18PM +, Davide Libenzi wrote: On Fri, 18 Jan 2008, Pierre Habouzit wrote: Hi, I just came across a strange behavior of epoll that seems to contradict the documentation. Here is what happens: * I have two processes P1 and P2, P1 accept()s connections, and send the resulting file descriptors to P2 through a unix socket. * P2 registers the received socket in his epollfd. [time passes] * P2 is done with the socket and closes it * P2 gets events for the socket again ! Though the documentation says that if a process closes a file descriptor, it gets unregistered. And yes I'm sure that P2 doens't dup() the file descriptor. Though (because of a bug) it was still open in P1[0], hence the referenced socket still live at the kernel level. Of course the userland workaround is to force the EPOLL_CTL_DEL before the close, which I now do, but costs me a syscall where I wanted to spare one :| For epoll, a close is when the kernel file* is released (that is, when all its instances are gone). We could put a special handling in filp_close(), but I don't think is a good idea, and we're better live with the current behaviour. Okay, maybe updating the linux manpages to be more clear about that is the way to go then. Thanks Sure. I'll send Michael Kerrisk and updated statement for the A6 answer in the epoll man page. Thanks Davide -- yes please send me a patch. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Something like the one below ... - Davide --- epoll.4 2008-01-26 12:58:21.0 -0800 +++ epoll.4.new 2008-01-26 13:06:36.0 -0800 @@ -285,7 +285,19 @@ sets automatically? .TP .B A6 -Yes. +A file descriptor is the userspace counterpart of an internal kernel handle. +Every time a process calls functions liks +.BR dup (2), +.BR dup2 (2) +or +.BR fork (2), +a new file descriptor referring to the same internal kernel handle is +created. The internal kernel handle remains alive until all the userspace +file descriptors have been closed. +The +.BR epoll (4) +interface automatically removes the internal kernel handle from the set, +once all the file descriptor instances have been closed. .TP .B Q7 If more than one event occurs between Davide, Two points. a) I did a s/internal kernel handle/open file description/ since that is the POSIX term for the internal handle. b) It seems to me that you text doesn't quite make the point explicit enough. I've tried to rewrite it; could you please check: A6 Yes, but be aware of the following point. A file descriptor is a reference to an open file descrip- tion (see open(2)). Whenever a descriptor is duplicated via dup(2), dup2(2), fcntl(2) F_DUPFD, or fork(2), a new file descriptor referring to the same open file description is created. An open file description continues to exist until all file descriptors referring to it have been closed. The epoll interface automatically removes a file descriptor from an epoll set only after all the file descriptors referring to the underlying open file handle have been closed. This means that even after a file descriptor that is part of an epoll set has been closed, events may be reported for that file descriptor if other file descriptors referring to the same underlying file description remain open. Does that seem okay? I plan to include the text in man-pages-2.79. I agree with Bodo, it is kinda confusing. The name open file description, even though POSIX, looks very similar to file descriptor. I honestly don't know how more easily such concept could be expressed. IMHO at least internal kernel handle does not play look-alike games with file descriptor. Was there some reason why removing a file descriptor couldn't have been made to do the expected thing (i.e., remove notifications for that file descriptor, regardless of whether the underlying file description remains open)? That'd mean placing an eventpoll custom hook into sys_close(). Looks very bad to me, and probably will look even worse to other kernel folks. Is not much a performance issue (a check to
Re: Is there a memory block device?
On Tue, 26 Feb 2008 19:53:36 +0100, rzryyvzy said: I know that tmpfs is a memmory filesystem. Is there a possibility to create also a memory block device? Is there a possibility to create for example a 1 GB memory block device (from the RAM)? A better question would be: What problem are you trying to solve by ysing a memory block device? There may well be other approaches that would work better, but it's hard to say. Are you trying to avoid the buffer cache pool? Ensure pages are in physical memory? Or some other problem? pgpgoVkj7j7vL.pgp Description: PGP signature
Re: + rcu-split-listh-and-move-rcu-protected-lists-into-rculisth.patch added to -mm tree
Franck Bui-Huu wrote: Josh Triplett wrote: [I did not see this patch go by on any mailing list, so I replied to the -mm mail and CCed LKML.] Well I'm pretty sure to have always CC'ed LKML, see for example: http://lkml.org/lkml/2008/2/19/150 http://lkml.org/lkml/2008/2/19/151 I must have missed it when I dug through the archive. Thanks. - Josh Triplett -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi, I've bisected anyway and although the results are not absolutely conclusive, as I neared the end of the process, I was amongst a bunch of mac80211 patches. This set me on a path that resulted in me discovering that with the rt61pci driver, I can freeze my wireless network connection almost at will if I set mac82011's ieee80211_default_rc_algo parameter to 'pid'. if the parametre is set to 'simple', the network seems to be reliable. I've just let the ping application run on and ping another box on my network almost 1500 times whilst repeatedly transferring a kernel source tarball by ftp from another box and the network connection was mantained That's with the parameter set to 'simple', if \I set it to 'pid' the connection rarely survives more than 40 pings even without the ftp activity. If I replace my wireless card with one that uses the rtl8180 driver, the network connection seems to be reliable regardless of how I set the parameter, although I admit that i have not tested this extensively yet. I'll do that now and report later. I've rerun my tests with the rtl8180 driver and found the network to be reliable with the mac82011 module's ieee80211_default_rc_algo parameter set to either 'simple' or 'pid'. I'm about to send 4 patches to this (linux-wireless) list with patches for rt2x00, most of them you already tested individually, but several people reported success after those patches. Hopefully it will be working for you as well. :) Sorry, but that's not the case. I find the same results as without the patches. With the parameter set to 'pid', the network connection fails very quickly, but with it set to 'simple' I can ping and ftp files to and from my laptop as much as I like and the connection stays up. In fact, if anything the patches seem to have made the network even more fragile, in that it fails almost instantly once I start some network activity ( 10 pings). I'm sure this is not the hardware - it works perfectly with Windows XP, with 2.6.23.14 plus the out-of-tree rt61 driver from serialmonkey, with the in-tree driver from 2.6.24.x and with 2.6.25-rc3 with the mac82011's ieee80211_default_rc_algo parameter set to 'simple'. Like I say above, sorry! Chris Ivo -- Beauty is in the eye of the beerholder. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Tue, Feb 26, 2008 at 10:42 AM, Ravikiran Thirumalai [EMAIL PROTECTED] wrote: On Mon, Feb 25, 2008 at 09:27:42PM -0800, Yinghai Lu wrote: On Mon, Feb 25, 2008 at 8:05 PM, Ravikiran Thirumalai [EMAIL PROTECTED] wrote: On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: If you can't support that in your hardware you're supposed to clear it. Hmm! How would a hardware vendor do that? That doesn't seem to be clear in the BKDG. (Well, this is the problem with undocumented features :() any good sign for APIC_clustered box? there is apicid between cpus even all cpu are quadcore and fully populated? I would suggest checking the SLIT distances -- On AMD boxes, if you have three different distances between nodes, then that system would be multiboard, and there is no way TSCs can be synced. On Intel boxes, if there are two different distances between nodes, then this would be a multi board/multi chassi box and TSCs won't be synced. This is a more generic solution and should work on Summit/Unisys boxes as well. (I am ignoring Intel CSI for now. It might need the same treatment as AMD) 1. if acpi=off ? 2. some system will be treated wrong. my four sockets system ACPI: SLIT: nodes = 4 10 13 13 16 13 10 16 13 13 16 10 13 16 13 13 10 my eight sockets system ACPI: SLIT: nodes = 8 10 12 12 14 14 14 14 16 12 10 14 12 14 14 12 14 12 14 10 14 12 12 14 14 14 12 14 10 12 12 14 14 14 14 12 12 10 14 12 14 14 14 12 12 14 10 14 12 14 12 14 14 12 14 10 12 16 14 14 14 14 12 12 10 YH -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: epoll and shared fd's
On Tue, Feb 26, 2008 at 8:04 PM, Davide Libenzi [EMAIL PROTECTED] wrote: On Tue, 26 Feb 2008, Michael Kerrisk wrote: Following up after quite some time: Davide Libenzi wrote: On Sat, 26 Jan 2008, Michael Kerrisk wrote: On Jan 25, 2008 12:57 AM, Davide Libenzi [EMAIL PROTECTED] wrote: On Thu, 24 Jan 2008, Pierre Habouzit wrote: On Fri, Jan 18, 2008 at 09:10:18PM +, Davide Libenzi wrote: On Fri, 18 Jan 2008, Pierre Habouzit wrote: Hi, I just came across a strange behavior of epoll that seems to contradict the documentation. Here is what happens: * I have two processes P1 and P2, P1 accept()s connections, and send the resulting file descriptors to P2 through a unix socket. * P2 registers the received socket in his epollfd. [time passes] * P2 is done with the socket and closes it * P2 gets events for the socket again ! Though the documentation says that if a process closes a file descriptor, it gets unregistered. And yes I'm sure that P2 doens't dup() the file descriptor. Though (because of a bug) it was still open in P1[0], hence the referenced socket still live at the kernel level. Of course the userland workaround is to force the EPOLL_CTL_DEL before the close, which I now do, but costs me a syscall where I wanted to spare one :| For epoll, a close is when the kernel file* is released (that is, when all its instances are gone). We could put a special handling in filp_close(), but I don't think is a good idea, and we're better live with the current behaviour. Okay, maybe updating the linux manpages to be more clear about that is the way to go then. Thanks Sure. I'll send Michael Kerrisk and updated statement for the A6 answer in the epoll man page. Thanks Davide -- yes please send me a patch. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Something like the one below ... - Davide --- epoll.4 2008-01-26 12:58:21.0 -0800 +++ epoll.4.new 2008-01-26 13:06:36.0 -0800 @@ -285,7 +285,19 @@ sets automatically? .TP .B A6 -Yes. +A file descriptor is the userspace counterpart of an internal kernel handle. +Every time a process calls functions liks +.BR dup (2), +.BR dup2 (2) +or +.BR fork (2), +a new file descriptor referring to the same internal kernel handle is +created. The internal kernel handle remains alive until all the userspace +file descriptors have been closed. +The +.BR epoll (4) +interface automatically removes the internal kernel handle from the set, +once all the file descriptor instances have been closed. .TP .B Q7 If more than one event occurs between Davide, Two points. a) I did a s/internal kernel handle/open file description/ since that is the POSIX term for the internal handle. b) It seems to me that you text doesn't quite make the point explicit enough. I've tried to rewrite it; could you please check: A6 Yes, but be aware of the following point. A file descriptor is a reference to an open file descrip- tion (see open(2)). Whenever a descriptor is duplicated via dup(2), dup2(2), fcntl(2) F_DUPFD, or fork(2), a new file descriptor referring to the same open file description is created. An open file description continues to exist until all file descriptors referring to it have been closed. The epoll interface automatically removes a file descriptor from an epoll set only after all the file descriptors referring to the underlying open file handle have been closed. This means that even after a file descriptor that is part of an epoll set has been closed, events may be reported for that file descriptor if other file descriptors referring to the same underlying file description remain open. Does that seem okay? I plan to include the text in man-pages-2.79. I agree with Bodo, it is kinda confusing. The name open file description, even though POSIX, looks very similar to file descriptor. I honestly don't know how more easily such concept could be expressed. IMHO at least internal kernel handle does not play look-alike games with file descriptor. Okay -- I'll look at it some more. I am however loathe to drop the term open file description, because POSIX uses, as well as a number of other Linux man pages by now. Was there some reason why removing a file
Re: epoll design problems with common fork/exec patterns
On Tue, 26 Feb 2008, Michael Kerrisk wrote: Davide Libenzi wrote: On Sun, 28 Oct 2007, David Schwartz wrote: Eric Dumazet wrote: Events are not necessarly reported by descriptors. epoll uses an opaque field provided by the user. It's up to the user to properly chose a tag that will makes sense if the user app is playing dup()/close() games for example. Great. So the only issue then is that the documentation is confusing. It frequently uses the term fd where it means file. For example, it says: Q1 What happens if you add the same fd to an epoll_set twice? A1 You will probably get EEXIST. However, it is possible that two threads may add the same fd twice. This is a harmless condition. This gives no reason to think there's anything wrong with adding the same file twice so long as you do so through different descriptors. (One can imagine an application that does this to segregate read and write operations to avoid a race where the descriptor is closed from under a writer due to handling a fatal read error.) Obviously, that won't work. I agree, that is confusing. However, you can safely add two different file descriptors pointing to the same file*, with different event masks, and that will work as expected. So can I summarize what I understand: a) Adding the same file descriptor twice to an epoll set will cause an error (EEXIST). Yes. b) In a separate message to linux-man, Chris Heath says that two threads *can't* add the same fd twice to an epoll set, despite what the existing man page text says. I haven't tested that, but it sounds to me as though it is likely to be true. Can you comment please Davide? Yes, you can't add the same fd twice. Think about a DB where file*,fd is the key. c) It is possible to add duplicated file descriptors referring to the same underlying open file description (file *). As you note, this can be a useful filtering technique, if the two file descriptors specify different masks. Assuming that is all correct, for man-pages-2.79, I've reworked the text for Q1/A1 as follows: Q1 What happens if you add the same file descriptor to an epoll set twice? A1 You will probably get EEXIST. However, it is pos- sible to add a duplicate (dup(2), dup2(2), fcntl(2) F_DUPFD, fork(2)) descriptor to the same epoll set. This can be a useful technique for filtering events, if the duplicate file descrip- tors are registered with different events masks. Seem okay Davide? Looks sane to me. - Davide -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Revert IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs
Pete, the subject says PATCH 1/2 but I didn't see any follow-up message for PATCH 2/2. Just wondering :) Benny On Feb. 26, 2008, 10:27 -0800, Pete Wyckoff [EMAIL PROTECTED] wrote: This reverts commit a3cd7d9070be417a21905c997ee32d756d999b38. The original commit breaks iSER reliably, making it complain: iser: iser_reg_page_vec:ib_fmr_pool_map_phys failed: -11 The FMR cleanup thread runs ib_fmr_batch_release() as dirty entries build up. This commit causes clean but used FMR entries also to be purged. During that process, another thread can see that there are no free FMRs and fail, even though there should always have been enough available. Signed-off-by: Pete Wyckoff [EMAIL PROTECTED] --- drivers/infiniband/core/fmr_pool.c | 21 ++--- 1 files changed, 6 insertions(+), 15 deletions(-) diff --git a/drivers/infiniband/core/fmr_pool.c b/drivers/infiniband/core/fmr_pool.c index 7f00347..4044fdf 100644 --- a/drivers/infiniband/core/fmr_pool.c +++ b/drivers/infiniband/core/fmr_pool.c @@ -139,7 +139,7 @@ static inline struct ib_pool_fmr *ib_fmr_cache_lookup(struct ib_fmr_pool *pool, static void ib_fmr_batch_release(struct ib_fmr_pool *pool) { int ret; - struct ib_pool_fmr *fmr, *next; + struct ib_pool_fmr *fmr; LIST_HEAD(unmap_list); LIST_HEAD(fmr_list); @@ -158,20 +158,6 @@ static void ib_fmr_batch_release(struct ib_fmr_pool *pool) #endif } - /* - * The free_list may hold FMRs that have been put there - * because they haven't reached the max_remap count. - * Invalidate their mapping as well. - */ - list_for_each_entry_safe(fmr, next, pool-free_list, list) { - if (fmr-remap_count == 0) - continue; - hlist_del_init(fmr-cache_node); - fmr-remap_count = 0; - list_add_tail(fmr-fmr-list, fmr_list); - list_move(fmr-list, unmap_list); - } - list_splice(pool-dirty_list, unmap_list); INIT_LIST_HEAD(pool-dirty_list); pool-dirty_len = 0; @@ -384,6 +370,11 @@ void ib_destroy_fmr_pool(struct ib_fmr_pool *pool) i = 0; list_for_each_entry_safe(fmr, tmp, pool-free_list, list) { + if (fmr-remap_count) { + INIT_LIST_HEAD(fmr_list); + list_add_tail(fmr-fmr-list, fmr_list); + ib_unmap_fmr(fmr_list); + } ib_dealloc_fmr(fmr-fmr); list_del(fmr-list); kfree(fmr); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arcmsr areca-1660 - strange behaviour under heavy load
Hi Andrew, no, right now I have the machine in the weird state, swap is empty (3GB), and so is bigger part of RAM (~100MB free), and the gcc crashes even when trying to compile c program with empty main function. so it doesn't seem to be problem with memory exhaustion. Hopefully the areca guys will be able to find out what is going on. But anyways, if You'll have any other idea what should I check/try, please let me know, as I have to admit that I'd really like to hunt it down myself (and yes, there is some vanity on my side here :)) thanks a lot once more cheers nik On Tue, 26 Feb 2008, Andrew Morton wrote: On Tue, 26 Feb 2008 10:35:31 +0100 (CET) Nikola Ciprich [EMAIL PROTECTED] wrote: Hi On Sun, 24 Feb 2008, Andrew Morton wrote: Hi Andrew, thanks a lot for reply, I'm attaching requested information. please let me know if You need more information/testing, whatever. I'll be glad to help. BR nik Areca support doesn't seem to be very interested in the problem :-( (cc's added) Please get the machine into this state of memory exhaustion then take copies of the output of the following, and send them via reply-to-all to this email: - cat /proc/meminfo - cat /proc/slabinfo - dmesg -c /dev/null ; echo m /proc/sysrq-trigger ; dmesg -c Thanks. Alas, that all looks OK to me. You never get any out-of-memory messages, and no oom-killing messages? Possibly what is happening here is that in this low-memory condition, some of the driver's internal memory-allocation attempts are failing, and the driver isn't correctly handling this. This is a rare situation which may well not have been hit in anyone else's testing. I expect that the Areca engineers will be able to reproduce this with a suitably small mem= kernel boot option. If not, they could perhaps investigate the kernel's fault-injection framework, which permits simulation of page allocation failures. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: epoll and shared fd's
On Tue, 26 Feb 2008, Michael Kerrisk wrote: Okay -- I'll look at it some more. I am however loathe to drop the term open file description, because POSIX uses, as well as a number of other Linux man pages by now. Heh, POSIX. Now doesn't take a genius to see that file description and file descriptor looks amazingly similar, does it? :) That'd mean placing an eventpoll custom hook into sys_close(). Looks very bad to me, and probably will look even worse to other kernel folks. Is not much a performance issue (a check to see if a file* is an eventpoll file is as easy as comparing the f_op pointer), but a design/style issue. Oh -- I wasn't suggesting we could make the change now -- it would break the ABI and all that. I was just wondering why the decision wasn't made to do it the other way to begin with. The existing semantics are somewhat couterintuitive, and potentially interact libraries that do private manipulations with file descriptors. For the same reason that a custom hook in sys_close wouldn't have passed the radar ;) As far as problems with libraries doing tricks with fds, that's an issue that goes beyond epoll. - Davide -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops when using git gc --auto
Nick Piggin [EMAIL PROTECTED] writes: On Wednesday 27 February 2008 00:22, Otavio Salvador wrote: Hello, Today I got this oops, someone has an idea of what's going wrong? Unable to handle kernel paging request at 0200 RIP: [802735c3] find_get_pages+0x3c/0x69 At this point, the most likely candidate is a memory corruption error, probably hardware. Can you run memtest86 for a few hours to get a bit more confidence in the hw (preferably overnight)? I did recently see another quite similar corruption in the pagecache radix-tree, though. Coincidence maybe? I let it running at lunch time and all went OK. I've also let burnP6 running later and nothing happened. Looks like hw is OK. I've just got another oops, with same kernel. Unable to handle kernel paging request at 83006d922370 RIP: [8027a79b] shrink_page_list+0x16f/0x570 PGD 0 Oops: [1] SMP CPU 2 Modules linked in: sha256_generic aes_generic aes_x86_64 cbc blkcipher nvidia(P) rfcomm l2cap bluetooth ac battery ipv6 nfs lockd nfs_acl sunrpc bridge ext2 mbcache dm_crypt tun kvm_intel kvm loop snd_hda_intel snd_usb_audio snd_pcm snd_timer snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd i2c_i801 soundcore snd_page_alloc intel_agp serio_raw button pcspkr e1000e i2c_core psmouse evdev xfs dm_mirror dm_snapshot dm_mod raid0 md_mod sg sr_mod cdrom sd_mod usbhid hid pata_marvell usb_storage floppy ahci ata_generic libata scsi_mod uhci_hcd ehci_hcd thermal processor fan Pid: 213, comm: kswapd0 Tainted: P2.6.24-1-amd64 #1 RIP: 0010:[8027a79b] [8027a79b] shrink_page_list+0x16f/0x570 RSP: 0018:81007ac8bbe0 EFLAGS: 00010286 RAX: 00010009 RBX: 810001e888a8 RCX: 810001e888d0 RDX: 83006d922350 RSI: 0001 RDI: 810001e888a8 RBP: 81007d1b9258 R08: 81007d776407 R09: R10: 0009 R11: 0002 R12: 0001 R13: 81007ac8be70 R14: 81007ac8bda0 R15: 81007ac8be01 FS: () GS:81007d776340() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 83006d922370 CR3: 6d4ac000 CR4: 26e0 DR0: DR1: DR2: DR3: DR6: 4ff0 DR7: 0400 Process kswapd0 (pid: 213, threadinfo 81007ac8a000, task 81007cc03800) Stack: 0006 0002 0002 0001 810001dc79e0 810001dc7a18 810001dc7fc8 810001dc8000 0001 0001 Call Trace: [80279da1] isolate_lru_pages+0x5d/0x1d9 [80279da1] isolate_lru_pages+0x5d/0x1d9 [8027acb9] shrink_inactive_list+0x11d/0x381 [8027b002] shrink_zone+0xe5/0x108 [8027b500] kswapd+0x2fc/0x49b [80413b5b] thread_return+0x3d/0xab [80247ff2] autoremove_wake_function+0x0/0x2e [8027b204] kswapd+0x0/0x49b [80247ed3] kthread+0x47/0x74 [8020cc48] child_rip+0xa/0x12 [80247e8c] kthread+0x0/0x74 [8020cc3e] child_rip+0x0/0x12 Code: 48 83 7a 20 00 0f 85 47 03 00 00 48 8d 42 30 48 39 42 30 0f RIP [8027a79b] shrink_page_list+0x16f/0x570 RSP 81007ac8bbe0 CR2: 83006d922370 ---[ end trace b01014a6540e7663 ]--- -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] Re: device mapper not reporting no-barrier-support?
On Tue, Feb 26 2008 Jens Axboe wrote: On Tue, Feb 26 2008, Alasdair G Kergon wrote: On Mon, Feb 25, 2008 at 03:20:50PM -0800, Andrew Morton wrote: On Mon, 25 Feb 2008 14:26:15 +0100 Anders Henke [EMAIL PROTECTED] wrote: I'm currently stuck between Kernel LVM and DRBD, as I'm using Kernel 2.6.24.2 with DRBD 8.2.5 on top of an LVM2 device (LV). -LVM2/device mapper doesn't support write barriers That's right. -DRBD uses blkdev_issue_flush() to flush its metadata to disk. Which won't work if device-mapper is underneath. On a no-barrier-device, DRBD should receive EOPNOTSUPP, but it really does receive an EIO. Promptly, DRBD gives the error message drbd0: local disk flush failed with status -5. I've posted a lengty summary of my findings to http://lists.linbit.com/pipermail/drbd-user/2008-February/008665.html ... that DRBD does catch the EOPNOTSUPP for blkdev_issue_flush and BIO_RW_BARRIER, but the lvm implementation of blkdev_issue_flush in 2.6.24.2 aparently does return EIO for blkdev_issue_flush. I'd say it's a DM bug. The dm code is unchanged, but look at the limited endio handling in ll_rw_blk.c: static void bio_end_empty_barrier(struct bio *bio, int err) { if (err) clear_bit(BIO_UPTODATE, bio-bi_flags); complete(bio-bi_private); } int blkdev_issue_flush(struct block_device *bdev, sector_t *error_sector) { ... wait_for_completion(wait); if (error_sector) *error_sector = bio-bi_sector; ret = 0; if (!bio_flagged(bio, BIO_UPTODATE)) ret = -EIO; You are right, the return value got broken there. Does this make it return -EOPNOTSUPP properly for you? No, it doesn't. I've applied your patch manually, as 2.6.24.2. doesn't have a blk-barrier.c: ---cut --- linux-2.6.24.2/block/ll_rw_blk.c.prepatch 2008-02-11 06:51:11.0 +0100 +++ linux-2.6.24.2/block/ll_rw_blk.c2008-02-26 20:02:28.514641620 +0100 @@ -2667,8 +2667,11 @@ static void bio_end_empty_barrier(struct bio *bio, int err) { - if (err) + if (err) { + if (err == -EOPNOTSUPP) + set_bit(BIO_EOPNOTSUPP, bio-bi_flags); clear_bit(BIO_UPTODATE, bio-bi_flags); + } complete(bio-bi_private); } ---cut ... and the resulting kernel shows exactly the same behaviour than before: [ 752.301388] drbd0: Writing meta data super block now. [ 752.349713] drbd0: local disk flush failed with status -5 [ 752.416256] drbd0: local disk flush failed with status -5 [ 753.419254] drbd0: local disk flush failed with status -5 [ 753.925726] drbd0: local disk flush failed with status -5 [ 754.551176] drbd0: local disk flush failed with status -5 [ 754.806052] drbd0: local disk flush failed with status -5 [ 755.327988] drbd0: local disk flush failed with status -5 [ 755.781863] drbd0: local disk flush failed with status -5 [ 756.266694] drbd0: local disk flush failed with status -5 Anders diff --git a/block/blk-barrier.c b/block/blk-barrier.c index 6901eed..55c5f1f 100644 --- a/block/blk-barrier.c +++ b/block/blk-barrier.c @@ -259,8 +259,11 @@ int blk_do_ordered(struct request_queue *q, struct request **rqp) static void bio_end_empty_barrier(struct bio *bio, int err) { - if (err) + if (err) { + if (err == -EOPNOTSUPP) + set_bit(BIO_EOPNOTSUPP, bio-bi_flags); clear_bit(BIO_UPTODATE, bio-bi_flags); + } complete(bio-bi_private); } @@ -309,7 +312,9 @@ int blkdev_issue_flush(struct block_device *bdev, sector_t *error_sector) *error_sector = bio-bi_sector; ret = 0; - if (!bio_flagged(bio, BIO_UPTODATE)) + if (bio_flagged(bio, BIO_EOPNOTSUPP)) + ret = -EOPNOTSUPP; + else if (!bio_flagged(bio, BIO_UPTODATE)) ret = -EIO; bio_put(bio); -- Jens Axboe -- 11 Internet AG Use the --force, Luke Brauerstrasse 48 v://49.721.91374.50 D-76135 Karlsruhef://49.721.91374.225 Amtsgericht Montabaur HRB 6484 Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Achim Weiss Aufsichtsratsvorsitzender: Michael Scheeren -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth: delete timer in l2cap_conn_del()
Hi Quel, Delete a possibly armed timer before kfree'ing the connection object. Solves: http://lkml.org/lkml/2008/2/15/514 Reported-by:Quel Qun [EMAIL PROTECTED] Signed-off-by: Thomas Gleixner [EMAIL PROTECTED] --- net/bluetooth/l2cap.c |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6/net/bluetooth/l2cap.c === --- linux-2.6.orig/net/bluetooth/l2cap.c +++ linux-2.6/net/bluetooth/l2cap.c @@ -417,6 +417,8 @@ static void l2cap_conn_del(struct hci_co l2cap_sock_kill(sk); } + del_timer_sync(conn-info_timer); + hcon-l2cap_data = NULL; kfree(conn); } can you confirm that this actually fixes the issue. Thomas, if confirmed, this is Acked-by me. Regards Marcel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Revert IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs
On Tue, Feb 26, 2008 at 11:23:01AM -0800, Benny Halevy wrote: Pete, the subject says PATCH 1/2 but I didn't see any follow-up message for PATCH 2/2. Just wondering :) I think the problem's on your end ... I got it and so did marc: http://marc.info/?l=linux-scsim=120405067313933w=2 -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kconfig configuration restore bug [Was: x86: vSMP selection in config]
Hi Roman. We discovered a situation where we could set a choice value in menuconfig but later when we either was running menuconfig or oldconfig the value were changed. I have created a minimal config that exhibit the error. It was created in a pure mechanical trial-and-error fashion. First the minimal Kconfig file: # x86 configuration choice prompt Subarchitecture Type config X86_PC bool PC-compatible config X86_VOYAGER bool Voyager (NCR) config X86_VSMP bool Support for ScaleMP vSMP depends on PCI endchoice config PCI bool PCI support if !X86_VISWS depends on !X86_VOYAGER default y config USB_ARCH_HAS_HCD bool default PCI config USB bool Support for Host-side USB depends on USB_ARCH_HAS_HCD config USB_PHIDGET bool USB Phidgets drivers depends on USB config USB_PHIDGETMOTORCONTROL bool USB PhidgetMotorControl support depends on USB_PHIDGET Next the saved .config that is used: # # Automatically generated make config: don't edit # Linux kernel version: KERNELVERSION # Tue Feb 26 20:27:09 2008 # # CONFIG_X86_PC is not set # CONFIG_X86_VOYAGER is not set CONFIG_X86_VSMP=y CONFIG_PCI=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB=y # CONFIG_USB_PHIDGET is not set When we enter menuconfig or are running oldconfig then we can see that CONFIG_X86_PC is set to 'y' and CONFIG_X86_VSMP is set to 'n'. If I in menuconfig select VSMP this setting is saved but then oldconfig kicks in and we loose the setting again. If I delete any of the config variables in the sample above then we no longer change the values and we keep the VSMP equals 'y'. Can you please take a look at this. Thanks, Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] Re: device mapper not reporting no-barrier-support?
On Tue, Feb 26 2008, Anders Henke wrote: On Tue, Feb 26 2008 Jens Axboe wrote: On Tue, Feb 26 2008, Alasdair G Kergon wrote: On Mon, Feb 25, 2008 at 03:20:50PM -0800, Andrew Morton wrote: On Mon, 25 Feb 2008 14:26:15 +0100 Anders Henke [EMAIL PROTECTED] wrote: I'm currently stuck between Kernel LVM and DRBD, as I'm using Kernel 2.6.24.2 with DRBD 8.2.5 on top of an LVM2 device (LV). -LVM2/device mapper doesn't support write barriers That's right. -DRBD uses blkdev_issue_flush() to flush its metadata to disk. Which won't work if device-mapper is underneath. On a no-barrier-device, DRBD should receive EOPNOTSUPP, but it really does receive an EIO. Promptly, DRBD gives the error message drbd0: local disk flush failed with status -5. I've posted a lengty summary of my findings to http://lists.linbit.com/pipermail/drbd-user/2008-February/008665.html ... that DRBD does catch the EOPNOTSUPP for blkdev_issue_flush and BIO_RW_BARRIER, but the lvm implementation of blkdev_issue_flush in 2.6.24.2 aparently does return EIO for blkdev_issue_flush. I'd say it's a DM bug. The dm code is unchanged, but look at the limited endio handling in ll_rw_blk.c: static void bio_end_empty_barrier(struct bio *bio, int err) { if (err) clear_bit(BIO_UPTODATE, bio-bi_flags); complete(bio-bi_private); } int blkdev_issue_flush(struct block_device *bdev, sector_t *error_sector) { ... wait_for_completion(wait); if (error_sector) *error_sector = bio-bi_sector; ret = 0; if (!bio_flagged(bio, BIO_UPTODATE)) ret = -EIO; You are right, the return value got broken there. Does this make it return -EOPNOTSUPP properly for you? No, it doesn't. I've applied your patch manually, as 2.6.24.2. doesn't have a blk-barrier.c: ---cut --- linux-2.6.24.2/block/ll_rw_blk.c.prepatch 2008-02-11 06:51:11.0 +0100 +++ linux-2.6.24.2/block/ll_rw_blk.c2008-02-26 20:02:28.514641620 +0100 @@ -2667,8 +2667,11 @@ static void bio_end_empty_barrier(struct bio *bio, int err) { - if (err) + if (err) { + if (err == -EOPNOTSUPP) + set_bit(BIO_EOPNOTSUPP, bio-bi_flags); clear_bit(BIO_UPTODATE, bio-bi_flags); + } complete(bio-bi_private); } ---cut ... and the resulting kernel shows exactly the same behaviour than before: Not surprising, as you missed half of the patch: @@ -309,7 +312,9 @@ int blkdev_issue_flush(struct block_device *bdev, sector_t *error_sector) *error_sector = bio-bi_sector; ret = 0; - if (!bio_flagged(bio, BIO_UPTODATE)) + if (bio_flagged(bio, BIO_EOPNOTSUPP)) + ret = -EOPNOTSUPP; + else if (!bio_flagged(bio, BIO_UPTODATE)) ret = -EIO; bio_put(bio); -- Jens Axboe -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bluez-devel] forcing SCO connection patch
Hi Loius, --- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-25 17:17:11.0 +0900 +++ linux-2.6.23/net/bluetooth/hci_event.c 2008-02-25 17:30:23.0 +0900 @@ -1313,8 +1313,17 @@ hci_dev_lock(hdev); conn = hci_conn_hash_lookup_ba(hdev, ev-link_type, ev-bdaddr); - if (!conn) - goto unlock; + if (!conn) { + if (ev-link_type != ACL_LINK) { + __u8 link_type = (ev-link_type == ESCO_LINK) ? SCO_LINK : ESCO_LINK; + + conn = hci_conn_hash_lookup_ba(hdev, link_type, ev-bdaddr); + if (conn) + conn-type = ev-link_type; + } + if (!conn) + goto unlock; + } NAK. There is no need to check for ACL_LINK. The sync_complete will only be called for SCO or eSCO connections. I see. I removed this check line in the patch. Thanks. Louis JANG Signed-off-by: Louis JANG [EMAIL PROTECTED] --- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-26 12:46:36.0 +0900 +++ linux-2.6.23/net/bluetooth/hci_event.c 2008-02-26 12:47:23.0 +0900 @@ -1313,8 +1313,15 @@ hci_dev_lock(hdev); conn = hci_conn_hash_lookup_ba(hdev, ev-link_type, ev-bdaddr); - if (!conn) - goto unlock; + if (!conn) { + __u8 link_type = (ev-link_type == ESCO_LINK) ? SCO_LINK : ESCO_LINK; + + conn = hci_conn_hash_lookup_ba(hdev, link_type, ev-bdaddr); + if (conn) + conn-type = ev-link_type; + else + goto unlock; + } if (!ev-status) { conn-handle = __le16_to_cpu(ev-handle); do something like this: if (!conn) { conn = if (!conn) goto unlock; conn-type = ev-link_type; } And include a description when submitting a patch. Regards Marcel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/37] Permit filesystem local caching
On Tuesday 26 February 2008 06:33, David Howells wrote: Suppose one were to take a mundane approach to the persistent cache problem instead of layering filesystems. What you would do then is change NFS's -write_page and variants to fiddle the persistent cache It is a requirement laid down by the Linux NFS fs maintainers that the writes to the cache be asynchronous, even if the writes to NFS aren't. As it happens, I will be hanging out for the next few days with said NFS maintainers, it would help to be as informed as possible about your patch set. Note further that NFS's write_page() != writing to the cache. Writing to the cache is typically done by NFS's readpages(). Yes, of course. But also by -write_page no? Which I could eventually find out by reading all the patches but asking you is so much more fun :-) And a waste of my time. I've provided documentation in the main FS-Cache patch, both as text files and in comments in header files that answer your questions. Please read them first. 37 Patches, none of which has Documentation in the subject line, and you did not provide a diffstat in patch 0 for the patch set as a whole. If I had known it was there of course I would have read it. It is great to see this level of documentation. But I do not think it is fair to blame your (one) reader for missing it. See the smiley above? The _real_ reason I am asking you is that I do not think anybody understands your patch set, in spite of your considerable efforts to address that. Discussion in public, right or wrong, is the only way to fix that. It is counterproductive to drive readers away from the discussion for fear that they may miss some point obvious to the original author, or perhaps already discussed earlier on lkml, and get flamed for it. Obviously, the patch set is not going to be perfect when it goes in and it would be a silly abuse of the open source process to require that, but the parts where it touches the rest of the system have to be really well understood, and it is clear from the level of participation in the thread that they are not. One bit that already came out of this, which you have alluded to several times yourself but somehow seem to keep glossing over, is that you need a -direct_bio file operations method. So does loopback mount. It might be worth putting some effort into seeing how -direct_IO can be refactored to make that happen. You can get it in separately on the basis of helping loopback, and it will make your patches nicer. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch v2] cris: proper defconfig setup
On Tue, Feb 26, 2008 at 07:04:02PM +0100, Jesper Nilsson wrote: On Tue, Feb 26, 2008 at 07:47:03PM +0200, Adrian Bunk wrote: This patch moves the cris defconfigs to arch/cris/configs/ where they belong. As a side effect they can now be used directly through e.g. make ARCH=cris artpec_3_defconfig The default defconfig is set through KBUILD_DEFCONFIG. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Patch updated after I discovered an additional defconfig in arch/cris/arch-v10/defconfig That could probably have been nuked, it's ancient. I'll put this in my queue. Thanks! If you blindly apply this patch then make sure you do not end up with zero size files. They are disliked by the kerne and make distclean will delete them - and git becomes unhappy. Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] using smp_processor_id() in preemptible as suspending
On Tue, Feb 26, 2008 at 08:33:54AM -0800, Andrew Morton wrote: On Tue, 26 Feb 2008 16:24:11 +0800 Dave Young [EMAIL PROTECTED] wrote: I don't know whom I should mail to, could you cc the proper guy? Thanks. Hello, Dave, Would you be willing to try out the following (untested, might not even compile) patch show at the very end of this message? This assumes that you were running with CONFIG_PREEMPT_RCU, which seems most likely based on looking at your oops. Thanx, Paul [ 118.331674] acpi LNXSYSTM:00: suspend [ 118.331674] Disabling non-boot CPUs ... [ 118.331674] CPU0 attaching NULL sched-domain. [ 118.331674] CPU1 attaching NULL sched-domain. [ 118.438750] CPU 1 is now offline [ 118.438750] lockdep: fixing up alternatives. [ 118.438750] SMP alternatives: switching to UP code [ 118.438750] BUG: using smp_processor_id() in preemptible [] code: s2ram/2818 [ 118.438750] caller is rcu_offline_cpu+0x15a/0x1c0 [ 118.438750] Pid: 2818, comm: s2ram Not tainted 2.6.25-rc3-test #2 [ 118.438750] [c0129738] ? printk+0x18/0x20 [ 118.438750] [c025c551] debug_smp_processor_id+0xb1/0xc0 [ 118.438750] [c0161f8a] rcu_offline_cpu+0x15a/0x1c0 [ 118.438750] [c03d408f] rcu_cpu_notify+0x3f/0x60 [ 118.438750] [c0141b0d] notifier_call_chain+0x3d/0x80 [ 118.438750] [c0141db9] __raw_notifier_call_chain+0x19/0x20 [ 118.438750] [c0141dda] raw_notifier_call_chain+0x1a/0x20 [ 118.438750] [c015262b] _cpu_down+0x13b/0x230 [ 118.438750] [c01527c9] disable_nonboot_cpus+0x49/0xd0 [ 118.438750] [c0157492] suspend_devices_and_enter+0x72/0x130 [ 118.438750] [c0129738] ? printk+0x18/0x20 [ 118.438750] [c0157623] enter_state+0xb3/0xe0 [ 118.438750] [c015777d] state_store+0x7d/0xc0 [ 118.438750] [c0157700] ? state_store+0x0/0xc0 [ 118.438750] [c0249e4e] kobj_attr_store+0x2e/0x40 [ 118.438750] [c01ca957] flush_write_buffer+0x47/0x70 [ 118.438750] [c01ca9c9] sysfs_write_file+0x49/0x70 [ 118.438750] [c0188d41] vfs_write+0x91/0x140 [ 118.438750] [c0188e9d] sys_write+0x3d/0x70 [ 118.438750] [c0104fca] syscall_call+0x7/0xb [ 118.438750] === [ 118.438750] CPU0 attaching NULL sched-domain. [ 118.440335] CPU1 is down Paul Ingo I guess My .config Doesn't tell us whether you'r eusing CONFIG_CLASSIC_RCU or CONFIG_PREEMPT_RCU. I assume CONFIG_CLASSIC_RCU, if you ran `make oldconfig'. Which kernel are you running here? Signed-off-by: Paul E. McKenney [EMAIL PROTECTED] --- rcupreempt.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -urpNa -X dontdiff linux-2.6.25-rc2/kernel/rcupreempt.c linux-2.6.25-rc2-rcuoffline/kernel/rcupreempt.c --- linux-2.6.25-rc2/kernel/rcupreempt.c2008-02-24 10:30:44.0 -0800 +++ linux-2.6.25-rc2-rcuoffline/kernel/rcupreempt.c 2008-02-26 11:39:33.0 -0800 @@ -702,8 +702,8 @@ void rcu_offline_cpu(int cpu) * fix. */ - rdp = RCU_DATA_ME(); spin_lock_irqsave(rdp-lock, flags); + rdp = RCU_DATA_ME(); *rdp-nexttail = list; if (list) rdp-nexttail = tail; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH] ipg: add jumbo frame support kconfig option
From: Pekka Enberg [EMAIL PROTECTED] Convert the internal JUMBO_FRAME #ifdef to CONFIG_IP1000_JUMBO_FRAME proper and fix compilation errors. Cc: Francois Romieu [EMAIL PROTECTED] Cc: Sorbica Shieh [EMAIL PROTECTED] Cc: Jesse Huang [EMAIL PROTECTED] Signed-off-by: Pekka Enberg [EMAIL PROTECTED] --- drivers/net/Kconfig |8 drivers/net/ipg.c | 21 ++--- drivers/net/ipg.h | 11 ++- 3 files changed, 24 insertions(+), 16 deletions(-) Index: linux-2.6/drivers/net/Kconfig === --- linux-2.6.orig/drivers/net/Kconfig +++ linux-2.6/drivers/net/Kconfig @@ -2029,6 +2029,14 @@ config IP1000 To compile this driver as a module, choose M here: the module will be called ipg. This is recommended. +config IP1000_JUMBO_FRAME + bool Support for jumbo frames (EXPERIMENTAL) + depends on IP1000 EXPERIMENTAL + help + This option enables jumbo frame support for the IP1000 driver. + + If in doubt, say N. + config IGB tristate Intel(R) 82575 PCI-Express Gigabit Ethernet support depends on PCI Index: linux-2.6/drivers/net/ipg.c === --- linux-2.6.orig/drivers/net/ipg.c +++ linux-2.6/drivers/net/ipg.c @@ -42,7 +42,6 @@ #define ipg_r16(reg) ioread16(ioaddr + (reg)) #define ipg_r8(reg)ioread8(ioaddr + (reg)) -#define JUMBO_FRAME_4k_ONLY enum { netdev_io_size = 128 }; @@ -1079,7 +1078,7 @@ static int ipg_nic_rxrestore(struct net_ return 0; } -#ifdef JUMBO_FRAME +#ifdef CONFIG_IP1000_JUMBO_FRAME /* use jumboindex and jumbosize to control jumbo frame status * initial status is jumboindex=-1 and jumbosize=0 @@ -1274,7 +1273,7 @@ static void ipg_nic_rx_with_end(struct n framelen = le64_to_cpu(rxfd-rfs) IPG_RFS_RXFRAMELEN; - endframeLen = framelen - jumbo-current_size; + endframelen = framelen - jumbo-current_size; /* if (framelen IPG_RXFRAG_SIZE) framelen=IPG_RXFRAG_SIZE; @@ -1282,8 +1281,8 @@ static void ipg_nic_rx_with_end(struct n if (framelen IPG_RXSUPPORT_SIZE) dev_kfree_skb_irq(jumbo-skb); else { - memcpy(skb_put(jumbo-skb, endframeLen), - skb-data, endframeLen); + memcpy(skb_put(jumbo-skb, endframelen), + skb-data, endframelen); jumbo-skb-protocol = eth_type_trans(jumbo-skb, dev); @@ -1355,16 +1354,16 @@ static int ipg_nic_rx(struct net_device switch (ipg_nic_rx_check_frame_type(dev)) { case FRAME_WITH_START_WITH_END: - ipg_nic_rx_with_start_and_end(dev, tp, rxfd, entry); + ipg_nic_rx_with_start_and_end(dev, sp, rxfd, entry); break; case FRAME_WITH_START: - ipg_nic_rx_with_start(dev, tp, rxfd, entry); + ipg_nic_rx_with_start(dev, sp, rxfd, entry); break; case FRAME_WITH_END: - ipg_nic_rx_with_end(dev, tp, rxfd, entry); + ipg_nic_rx_with_end(dev, sp, rxfd, entry); break; case FRAME_NO_START_NO_END: - ipg_nic_rx_no_start_no_end(dev, tp, rxfd, entry); + ipg_nic_rx_no_start_no_end(dev, sp, rxfd, entry); break; } } @@ -1595,7 +1594,7 @@ static irqreturn_t ipg_interrupt_handler IPG_DEBUG_MSG(_interrupt_handler\n); -#ifdef JUMBO_FRAME +#ifdef CONFIG_IP1000_JUMBO_FRAME ipg_nic_rxrestore(dev); #endif spin_lock(sp-lock); @@ -1807,7 +1806,7 @@ static int ipg_nic_open(struct net_devic if (ipg_config_autoneg(dev) 0) printk(KERN_INFO %s: Auto-negotiation error.\n, dev-name); -#ifdef JUMBO_FRAME +#ifdef CONFIG_IP1000_JUMBO_FRAME /* initialize JUMBO Frame control variable */ sp-jumbo.found_start = 0; sp-jumbo.current_size = 0; Index: linux-2.6/drivers/net/ipg.h === --- linux-2.6.orig/drivers/net/ipg.h +++ linux-2.6/drivers/net/ipg.h @@ -536,7 +536,7 @@ enum ipg_regs { */ #defineIPG_FRAMESBETWEENTXDMACOMPLETES 0x1 -#ifdef JUMBO_FRAME +#ifdef CONFIG_IP1000_JUMBO_FRAME # ifdef JUMBO_FRAME_SIZE_2K # define JUMBO_FRAME_SIZE 2048 @@ -575,6 +575,7 @@ enum ipg_regs { # define __IPG_RXFRAG_SIZE 4088 # else # define JUMBO_FRAME_SIZE 4096 +# define
Re: [PATCH 1/2] Revert IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs
Diabolical ;-) Thanks for the pointer! Benny On Feb. 26, 2008, 11:39 -0800, Matthew Wilcox [EMAIL PROTECTED] wrote: On Tue, Feb 26, 2008 at 11:23:01AM -0800, Benny Halevy wrote: Pete, the subject says PATCH 1/2 but I didn't see any follow-up message for PATCH 2/2. Just wondering :) I think the problem's on your end ... I got it and so did marc: http://marc.info/?l=linux-scsim=120405067313933w=2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH] ipg: add jumbo frame support kconfig option
[ Sorry for the duplicate. I typoed Francois' email address. ] From: Pekka Enberg [EMAIL PROTECTED] Convert the internal JUMBO_FRAME #ifdef to CONFIG_IP1000_JUMBO_FRAME proper and fix compilation errors. Cc: Francois Romieu [EMAIL PROTECTED] Cc: Sorbica Shieh [EMAIL PROTECTED] Cc: Jesse Huang [EMAIL PROTECTED] Signed-off-by: Pekka Enberg [EMAIL PROTECTED] --- drivers/net/Kconfig |8 drivers/net/ipg.c | 21 ++--- drivers/net/ipg.h | 11 ++- 3 files changed, 24 insertions(+), 16 deletions(-) Index: linux-2.6/drivers/net/Kconfig === --- linux-2.6.orig/drivers/net/Kconfig +++ linux-2.6/drivers/net/Kconfig @@ -2029,6 +2029,14 @@ config IP1000 To compile this driver as a module, choose M here: the module will be called ipg. This is recommended. +config IP1000_JUMBO_FRAME + bool Support for jumbo frames (EXPERIMENTAL) + depends on IP1000 EXPERIMENTAL + help + This option enables jumbo frame support for the IP1000 driver. + + If in doubt, say N. + config IGB tristate Intel(R) 82575 PCI-Express Gigabit Ethernet support depends on PCI Index: linux-2.6/drivers/net/ipg.c === --- linux-2.6.orig/drivers/net/ipg.c +++ linux-2.6/drivers/net/ipg.c @@ -42,7 +42,6 @@ #define ipg_r16(reg) ioread16(ioaddr + (reg)) #define ipg_r8(reg)ioread8(ioaddr + (reg)) -#define JUMBO_FRAME_4k_ONLY enum { netdev_io_size = 128 }; @@ -1079,7 +1078,7 @@ static int ipg_nic_rxrestore(struct net_ return 0; } -#ifdef JUMBO_FRAME +#ifdef CONFIG_IP1000_JUMBO_FRAME /* use jumboindex and jumbosize to control jumbo frame status * initial status is jumboindex=-1 and jumbosize=0 @@ -1274,7 +1273,7 @@ static void ipg_nic_rx_with_end(struct n framelen = le64_to_cpu(rxfd-rfs) IPG_RFS_RXFRAMELEN; - endframeLen = framelen - jumbo-current_size; + endframelen = framelen - jumbo-current_size; /* if (framelen IPG_RXFRAG_SIZE) framelen=IPG_RXFRAG_SIZE; @@ -1282,8 +1281,8 @@ static void ipg_nic_rx_with_end(struct n if (framelen IPG_RXSUPPORT_SIZE) dev_kfree_skb_irq(jumbo-skb); else { - memcpy(skb_put(jumbo-skb, endframeLen), - skb-data, endframeLen); + memcpy(skb_put(jumbo-skb, endframelen), + skb-data, endframelen); jumbo-skb-protocol = eth_type_trans(jumbo-skb, dev); @@ -1355,16 +1354,16 @@ static int ipg_nic_rx(struct net_device switch (ipg_nic_rx_check_frame_type(dev)) { case FRAME_WITH_START_WITH_END: - ipg_nic_rx_with_start_and_end(dev, tp, rxfd, entry); + ipg_nic_rx_with_start_and_end(dev, sp, rxfd, entry); break; case FRAME_WITH_START: - ipg_nic_rx_with_start(dev, tp, rxfd, entry); + ipg_nic_rx_with_start(dev, sp, rxfd, entry); break; case FRAME_WITH_END: - ipg_nic_rx_with_end(dev, tp, rxfd, entry); + ipg_nic_rx_with_end(dev, sp, rxfd, entry); break; case FRAME_NO_START_NO_END: - ipg_nic_rx_no_start_no_end(dev, tp, rxfd, entry); + ipg_nic_rx_no_start_no_end(dev, sp, rxfd, entry); break; } } @@ -1595,7 +1594,7 @@ static irqreturn_t ipg_interrupt_handler IPG_DEBUG_MSG(_interrupt_handler\n); -#ifdef JUMBO_FRAME +#ifdef CONFIG_IP1000_JUMBO_FRAME ipg_nic_rxrestore(dev); #endif spin_lock(sp-lock); @@ -1807,7 +1806,7 @@ static int ipg_nic_open(struct net_devic if (ipg_config_autoneg(dev) 0) printk(KERN_INFO %s: Auto-negotiation error.\n, dev-name); -#ifdef JUMBO_FRAME +#ifdef CONFIG_IP1000_JUMBO_FRAME /* initialize JUMBO Frame control variable */ sp-jumbo.found_start = 0; sp-jumbo.current_size = 0; Index: linux-2.6/drivers/net/ipg.h === --- linux-2.6.orig/drivers/net/ipg.h +++ linux-2.6/drivers/net/ipg.h @@ -536,7 +536,7 @@ enum ipg_regs { */ #defineIPG_FRAMESBETWEENTXDMACOMPLETES 0x1 -#ifdef JUMBO_FRAME +#ifdef CONFIG_IP1000_JUMBO_FRAME # ifdef JUMBO_FRAME_SIZE_2K # define JUMBO_FRAME_SIZE 2048 @@ -575,6 +575,7 @@ enum ipg_regs { # define __IPG_RXFRAG_SIZE 4088 # else #
Re: [2.6 patch v2] cris: proper defconfig setup
On Tue, Feb 26, 2008 at 08:44:53PM +0100, Sam Ravnborg wrote: On Tue, Feb 26, 2008 at 07:04:02PM +0100, Jesper Nilsson wrote: On Tue, Feb 26, 2008 at 07:47:03PM +0200, Adrian Bunk wrote: This patch moves the cris defconfigs to arch/cris/configs/ where they belong. As a side effect they can now be used directly through e.g. make ARCH=cris artpec_3_defconfig The default defconfig is set through KBUILD_DEFCONFIG. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Patch updated after I discovered an additional defconfig in arch/cris/arch-v10/defconfig That could probably have been nuked, it's ancient. I'll put this in my queue. Thanks! If you blindly apply this patch then make sure you do not end up with zero size files. They are disliked by the kerne and make distclean will delete them - and git becomes unhappy. At least GNU patch will correctly remove the files with my patch. Please name the tools that are that broken that they wouldn't apply this patch correctly and don't claim my patch was broken (or shut up). Sam cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mips: use KBUILD_DEFCONFIG
With KBUILD_DEFCONFIG we don't have to ship a second copy of ip22_defconfig Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- arch/mips/Makefile |2 arch/mips/defconfig | 1158 2 files changed, 2 insertions(+), 1158 deletions(-) 57da2fa4b7e8c035c8317e8796ca6d2ea17c1d1f diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 001c017..93ef27b 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -12,6 +12,8 @@ # for archclean cleaning up for this architecture. # +KBUILD_DEFCONFIG := ip22_defconfig + cflags-y := # diff --git a/arch/mips/defconfig b/arch/mips/defconfig deleted file mode 100644 index 4f5e56c..000 --- a/arch/mips/defconfig +++ /dev/null @@ -1,1158 +0,0 @@ -# -# Automatically generated make config: don't edit -# Linux kernel version: 2.6.23-rc2 -# Tue Aug 7 12:39:49 2007 -# -CONFIG_MIPS=y - -# -# Machine selection -# -CONFIG_ZONE_DMA=y -# CONFIG_MACH_ALCHEMY is not set -# CONFIG_BASLER_EXCITE is not set -# CONFIG_MIPS_COBALT is not set -# CONFIG_MACH_DECSTATION is not set -# CONFIG_MACH_JAZZ is not set -# CONFIG_LEMOTE_FULONG is not set -# CONFIG_MIPS_ATLAS is not set -# CONFIG_MIPS_MALTA is not set -# CONFIG_MIPS_SEAD is not set -# CONFIG_MIPS_SIM is not set -# CONFIG_MARKEINS is not set -# CONFIG_MACH_VR41XX is not set -# CONFIG_PNX8550_JBS is not set -# CONFIG_PNX8550_STB810 is not set -# CONFIG_PMC_MSP is not set -# CONFIG_PMC_YOSEMITE is not set -CONFIG_SGI_IP22=y -# CONFIG_SGI_IP27 is not set -# CONFIG_SGI_IP32 is not set -# CONFIG_SIBYTE_CRHINE is not set -# CONFIG_SIBYTE_CARMEL is not set -# CONFIG_SIBYTE_CRHONE is not set -# CONFIG_SIBYTE_RHONE is not set -# CONFIG_SIBYTE_SWARM is not set -# CONFIG_SIBYTE_LITTLESUR is not set -# CONFIG_SIBYTE_SENTOSA is not set -# CONFIG_SIBYTE_BIGSUR is not set -# CONFIG_SNI_RM is not set -# CONFIG_TOSHIBA_JMR3927 is not set -# CONFIG_TOSHIBA_RBTX4927 is not set -# CONFIG_TOSHIBA_RBTX4938 is not set -# CONFIG_WR_PPMC is not set -CONFIG_RWSEM_GENERIC_SPINLOCK=y -# CONFIG_ARCH_HAS_ILOG2_U32 is not set -# CONFIG_ARCH_HAS_ILOG2_U64 is not set -CONFIG_GENERIC_FIND_NEXT_BIT=y -CONFIG_GENERIC_HWEIGHT=y -CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_GENERIC_TIME=y -CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y -# CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ is not set -CONFIG_ARC=y -CONFIG_DMA_NONCOHERENT=y -CONFIG_DMA_NEED_PCI_MAP_STATE=y -CONFIG_EARLY_PRINTK=y -CONFIG_SYS_HAS_EARLY_PRINTK=y -# CONFIG_NO_IOPORT is not set -CONFIG_GENERIC_ISA_DMA_SUPPORT_BROKEN=y -CONFIG_CPU_BIG_ENDIAN=y -# CONFIG_CPU_LITTLE_ENDIAN is not set -CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y -CONFIG_IRQ_CPU=y -CONFIG_SWAP_IO_SPACE=y -CONFIG_ARC32=y -CONFIG_BOOT_ELF32=y -CONFIG_MIPS_L1_CACHE_SHIFT=5 -CONFIG_ARC_CONSOLE=y -CONFIG_ARC_PROMLIB=y - -# -# CPU selection -# -# CONFIG_CPU_LOONGSON2 is not set -# CONFIG_CPU_MIPS32_R1 is not set -# CONFIG_CPU_MIPS32_R2 is not set -# CONFIG_CPU_MIPS64_R1 is not set -# CONFIG_CPU_MIPS64_R2 is not set -# CONFIG_CPU_R3000 is not set -# CONFIG_CPU_TX39XX is not set -# CONFIG_CPU_VR41XX is not set -# CONFIG_CPU_R4300 is not set -# CONFIG_CPU_R4X00 is not set -# CONFIG_CPU_TX49XX is not set -CONFIG_CPU_R5000=y -# CONFIG_CPU_R5432 is not set -# CONFIG_CPU_R6000 is not set -# CONFIG_CPU_NEVADA is not set -# CONFIG_CPU_R8000 is not set -# CONFIG_CPU_R1 is not set -# CONFIG_CPU_RM7000 is not set -# CONFIG_CPU_RM9000 is not set -# CONFIG_CPU_SB1 is not set -CONFIG_SYS_HAS_CPU_R4X00=y -CONFIG_SYS_HAS_CPU_R5000=y -CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y -CONFIG_SYS_SUPPORTS_64BIT_KERNEL=y -CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y -CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y - -# -# Kernel type -# -CONFIG_32BIT=y -# CONFIG_64BIT is not set -CONFIG_PAGE_SIZE_4KB=y -# CONFIG_PAGE_SIZE_8KB is not set -# CONFIG_PAGE_SIZE_16KB is not set -# CONFIG_PAGE_SIZE_64KB is not set -CONFIG_BOARD_SCACHE=y -CONFIG_IP22_CPU_SCACHE=y -CONFIG_MIPS_MT_DISABLED=y -# CONFIG_MIPS_MT_SMP is not set -# CONFIG_MIPS_MT_SMTC is not set -CONFIG_CPU_HAS_LLSC=y -CONFIG_CPU_HAS_SYNC=y -CONFIG_GENERIC_HARDIRQS=y -CONFIG_GENERIC_IRQ_PROBE=y -CONFIG_ARCH_FLATMEM_ENABLE=y -CONFIG_SELECT_MEMORY_MODEL=y -CONFIG_FLATMEM_MANUAL=y -# CONFIG_DISCONTIGMEM_MANUAL is not set -# CONFIG_SPARSEMEM_MANUAL is not set -CONFIG_FLATMEM=y -CONFIG_FLAT_NODE_MEM_MAP=y -# CONFIG_SPARSEMEM_STATIC is not set -CONFIG_SPLIT_PTLOCK_CPUS=4 -# CONFIG_RESOURCES_64BIT is not set -CONFIG_ZONE_DMA_FLAG=1 -CONFIG_BOUNCE=y -CONFIG_VIRT_TO_BUS=y -# CONFIG_HZ_48 is not set -# CONFIG_HZ_100 is not set -# CONFIG_HZ_128 is not set -# CONFIG_HZ_250 is not set -# CONFIG_HZ_256 is not set -CONFIG_HZ_1000=y -# CONFIG_HZ_1024 is not set -CONFIG_SYS_SUPPORTS_ARBIT_HZ=y -CONFIG_HZ=1000 -# CONFIG_PREEMPT_NONE is not set -CONFIG_PREEMPT_VOLUNTARY=y -# CONFIG_PREEMPT is not set -# CONFIG_KEXEC is not set -CONFIG_SECCOMP=y -CONFIG_LOCKDEP_SUPPORT=y -CONFIG_STACKTRACE_SUPPORT=y -CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config - -# -# General setup -# -CONFIG_EXPERIMENTAL=y -CONFIG_BROKEN_ON_SMP=y
[2.6 patch] m68k: use KBUILD_DEFCONFIG
The default defconfig should be one from arch/m68k/configs/ arch/m68k/defconfig was not exactly identical to amiga_defconfig but also considering how long they have been without any update that doesn't seem to have been on purpose. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- arch/m68k/Makefile |2 arch/m68k/defconfig | 657 2 files changed, 2 insertions(+), 657 deletions(-) f52a66f85069cc79c30b0c9520713bbba6cfc20d diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile index 2cba605..b15173f 100644 --- a/arch/m68k/Makefile +++ b/arch/m68k/Makefile @@ -13,6 +13,8 @@ # Copyright (C) 1994 by Hamish Macdonald # +KBUILD_DEFCONFIG := amiga_defconfig + # override top level makefile AS += -m68020 LDFLAGS := -m m68kelf diff --git a/arch/m68k/defconfig b/arch/m68k/defconfig deleted file mode 100644 index 7d935e4..000 --- a/arch/m68k/defconfig +++ /dev/null @@ -1,657 +0,0 @@ -# -# Automatically generated make config: don't edit -# Linux kernel version: 2.6.12-rc6-m68k -# Tue Jun 7 20:34:17 2005 -# -CONFIG_M68K=y -CONFIG_MMU=y -CONFIG_UID16=y -CONFIG_RWSEM_GENERIC_SPINLOCK=y -CONFIG_GENERIC_CALIBRATE_DELAY=y - -# -# Code maturity level options -# -CONFIG_EXPERIMENTAL=y -CONFIG_CLEAN_COMPILE=y -CONFIG_BROKEN_ON_SMP=y -CONFIG_INIT_ENV_ARG_LIMIT=32 - -# -# General setup -# -CONFIG_LOCALVERSION= -CONFIG_SWAP=y -CONFIG_SYSVIPC=y -# CONFIG_POSIX_MQUEUE is not set -# CONFIG_BSD_PROCESS_ACCT is not set -CONFIG_SYSCTL=y -# CONFIG_AUDIT is not set -# CONFIG_HOTPLUG is not set -CONFIG_KOBJECT_UEVENT=y -# CONFIG_IKCONFIG is not set -# CONFIG_EMBEDDED is not set -CONFIG_KALLSYMS=y -# CONFIG_KALLSYMS_EXTRA_PASS is not set -CONFIG_PRINTK=y -CONFIG_BUG=y -CONFIG_BASE_FULL=y -CONFIG_FUTEX=y -CONFIG_EPOLL=y -CONFIG_SHMEM=y -CONFIG_CC_ALIGN_FUNCTIONS=0 -CONFIG_CC_ALIGN_LABELS=0 -CONFIG_CC_ALIGN_LOOPS=0 -CONFIG_CC_ALIGN_JUMPS=0 -# CONFIG_TINY_SHMEM is not set -CONFIG_BASE_SMALL=0 - -# -# Loadable module support -# -# CONFIG_MODULES is not set - -# -# Platform dependent setup -# -# CONFIG_SUN3 is not set -CONFIG_AMIGA=y -# CONFIG_ATARI is not set -# CONFIG_MAC is not set -# CONFIG_APOLLO is not set -# CONFIG_VME is not set -# CONFIG_HP300 is not set -# CONFIG_SUN3X is not set -# CONFIG_Q40 is not set - -# -# Processor type -# -CONFIG_M68020=y -CONFIG_M68030=y -CONFIG_M68040=y -# CONFIG_M68060 is not set -CONFIG_MMU_MOTOROLA=y -# CONFIG_M68KFPU_EMU is not set -# CONFIG_ADVANCED is not set - -# -# General setup -# -CONFIG_BINFMT_ELF=y -CONFIG_BINFMT_AOUT=y -# CONFIG_BINFMT_MISC is not set -CONFIG_ZORRO=y -# CONFIG_AMIGA_PCMCIA is not set -# CONFIG_HEARTBEAT is not set -CONFIG_PROC_HARDWARE=y -# CONFIG_ZORRO_NAMES is not set - -# -# Device Drivers -# - -# -# Generic Driver Options -# -CONFIG_STANDALONE=y -CONFIG_PREVENT_FIRMWARE_BUILD=y -# CONFIG_FW_LOADER is not set - -# -# Memory Technology Devices (MTD) -# -# CONFIG_MTD is not set - -# -# Parallel port support -# -# CONFIG_PARPORT is not set - -# -# Plug and Play support -# - -# -# Block devices -# -CONFIG_AMIGA_FLOPPY=y -# CONFIG_AMIGA_Z2RAM is not set -# CONFIG_BLK_DEV_COW_COMMON is not set -# CONFIG_BLK_DEV_LOOP is not set -# CONFIG_BLK_DEV_NBD is not set -CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_COUNT=16 -CONFIG_BLK_DEV_RAM_SIZE=4096 -CONFIG_BLK_DEV_INITRD=y -CONFIG_INITRAMFS_SOURCE= -CONFIG_CDROM_PKTCDVD=y -CONFIG_CDROM_PKTCDVD_BUFFERS=8 -# CONFIG_CDROM_PKTCDVD_WCACHE is not set - -# -# IO Schedulers -# -CONFIG_IOSCHED_NOOP=y -CONFIG_IOSCHED_AS=y -CONFIG_IOSCHED_DEADLINE=y -CONFIG_IOSCHED_CFQ=y -# CONFIG_ATA_OVER_ETH is not set - -# -# ATA/ATAPI/MFM/RLL support -# -# CONFIG_IDE is not set - -# -# SCSI device support -# -CONFIG_SCSI=y -CONFIG_SCSI_PROC_FS=y - -# -# SCSI support type (disk, tape, CD-ROM) -# -CONFIG_BLK_DEV_SD=y -CONFIG_CHR_DEV_ST=y -# CONFIG_CHR_DEV_OSST is not set -CONFIG_BLK_DEV_SR=y -# CONFIG_BLK_DEV_SR_VENDOR is not set -# CONFIG_CHR_DEV_SG is not set - -# -# Some SCSI devices (e.g. CD jukebox) support multiple LUNs -# -# CONFIG_SCSI_MULTI_LUN is not set -CONFIG_SCSI_CONSTANTS=y -# CONFIG_SCSI_LOGGING is not set - -# -# SCSI Transport Attributes -# -# CONFIG_SCSI_SPI_ATTRS is not set -# CONFIG_SCSI_FC_ATTRS is not set -# CONFIG_SCSI_ISCSI_ATTRS is not set - -# -# SCSI low-level drivers -# -# CONFIG_SCSI_SATA is not set -# CONFIG_SCSI_DEBUG is not set -CONFIG_A3000_SCSI=y -CONFIG_A2091_SCSI=y -CONFIG_GVP11_SCSI=y -# CONFIG_CYBERSTORM_SCSI is not set -# CONFIG_CYBERSTORMII_SCSI is not set -# CONFIG_BLZ2060_SCSI is not set -# CONFIG_BLZ1230_SCSI is not set -# CONFIG_FASTLANE_SCSI is not set -# CONFIG_OKTAGON_SCSI is not set - -# -# Multi-device support (RAID and LVM) -# -# CONFIG_MD is not set - -# -# Fusion MPT device support -# - -# -# IEEE 1394 (FireWire) support -# - -# -# I2O device support -# - -# -# Networking support -# -CONFIG_NET=y - -# -# Networking options -# -CONFIG_PACKET=y -# CONFIG_PACKET_MMAP is not set -CONFIG_UNIX=y -# CONFIG_NET_KEY is not set -CONFIG_INET=y -#
[2.6 patch] m32r: use KBUILD_DEFCONFIG
With using KBUILD_DEFCONFIG we don't have to ship a second copy of m32700ut.smp_defconfig Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- arch/m32r/Makefile |2 arch/m32r/defconfig | 863 2 files changed, 2 insertions(+), 863 deletions(-) c1797789816e8d79133d63da3578705f47cedbd3 diff --git a/arch/m32r/Makefile b/arch/m32r/Makefile index 4072a07..469766b 100644 --- a/arch/m32r/Makefile +++ b/arch/m32r/Makefile @@ -5,6 +5,8 @@ # architecture-specific flags and dependencies. # +KBUILD_DEFCONFIG := m32700ut.smp_defconfig + LDFLAGS:= OBJCOPYFLAGS := -O binary -R .note -R .comment -S LDFLAGS_vmlinux:= diff --git a/arch/m32r/defconfig b/arch/m32r/defconfig deleted file mode 100644 index af3b981..000 --- a/arch/m32r/defconfig +++ /dev/null @@ -1,863 +0,0 @@ -# -# Automatically generated make config: don't edit -# Linux kernel version: 2.6.23-rc1 -# Wed Aug 1 17:22:35 2007 -# -CONFIG_M32R=y -CONFIG_GENERIC_ISA_DMA=y -CONFIG_ZONE_DMA=y -CONFIG_GENERIC_HARDIRQS=y -CONFIG_GENERIC_IRQ_PROBE=y -CONFIG_NO_IOPORT=y -CONFIG_NO_DMA=y -CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config - -# -# Code maturity level options -# -CONFIG_EXPERIMENTAL=y -CONFIG_LOCK_KERNEL=y -CONFIG_INIT_ENV_ARG_LIMIT=32 - -# -# General setup -# -CONFIG_LOCALVERSION= -CONFIG_LOCALVERSION_AUTO=y -CONFIG_SWAP=y -CONFIG_SYSVIPC=y -CONFIG_SYSVIPC_SYSCTL=y -# CONFIG_POSIX_MQUEUE is not set -CONFIG_BSD_PROCESS_ACCT=y -# CONFIG_BSD_PROCESS_ACCT_V3 is not set -# CONFIG_TASKSTATS is not set -# CONFIG_USER_NS is not set -# CONFIG_AUDIT is not set -CONFIG_IKCONFIG=y -CONFIG_IKCONFIG_PROC=y -CONFIG_LOG_BUF_SHIFT=15 -# CONFIG_CPUSETS is not set -CONFIG_SYSFS_DEPRECATED=y -# CONFIG_RELAY is not set -# CONFIG_BLK_DEV_INITRD is not set -# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set -CONFIG_SYSCTL=y -CONFIG_EMBEDDED=y -CONFIG_SYSCTL_SYSCALL=y -# CONFIG_KALLSYMS is not set -CONFIG_HOTPLUG=y -CONFIG_PRINTK=y -CONFIG_BUG=y -CONFIG_ELF_CORE=y -CONFIG_BASE_FULL=y -# CONFIG_FUTEX is not set -CONFIG_ANON_INODES=y -# CONFIG_EPOLL is not set -CONFIG_SIGNALFD=y -CONFIG_TIMERFD=y -CONFIG_EVENTFD=y -CONFIG_SHMEM=y -CONFIG_VM_EVENT_COUNTERS=y -CONFIG_SLAB=y -# CONFIG_SLUB is not set -# CONFIG_SLOB is not set -# CONFIG_TINY_SHMEM is not set -CONFIG_BASE_SMALL=0 -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -# CONFIG_MODULE_FORCE_UNLOAD is not set -# CONFIG_MODVERSIONS is not set -# CONFIG_MODULE_SRCVERSION_ALL is not set -CONFIG_KMOD=y -CONFIG_STOP_MACHINE=y -CONFIG_BLOCK=y -# CONFIG_LBD is not set -# CONFIG_BLK_DEV_IO_TRACE is not set -# CONFIG_LSF is not set -# CONFIG_BLK_DEV_BSG is not set - -# -# IO Schedulers -# -CONFIG_IOSCHED_NOOP=y -# CONFIG_IOSCHED_AS is not set -CONFIG_IOSCHED_DEADLINE=y -CONFIG_IOSCHED_CFQ=y -# CONFIG_DEFAULT_AS is not set -# CONFIG_DEFAULT_DEADLINE is not set -CONFIG_DEFAULT_CFQ=y -# CONFIG_DEFAULT_NOOP is not set -CONFIG_DEFAULT_IOSCHED=cfq - -# -# Processor type and features -# -# CONFIG_PLAT_MAPPI is not set -# CONFIG_PLAT_USRV is not set -CONFIG_PLAT_M32700UT=y -# CONFIG_PLAT_OPSPUT is not set -# CONFIG_PLAT_OAKS32R is not set -# CONFIG_PLAT_MAPPI2 is not set -# CONFIG_PLAT_MAPPI3 is not set -# CONFIG_PLAT_M32104UT is not set -CONFIG_CHIP_M32700=y -# CONFIG_CHIP_M32102 is not set -# CONFIG_CHIP_M32104 is not set -# CONFIG_CHIP_VDEC2 is not set -# CONFIG_CHIP_OPSP is not set -CONFIG_MMU=y -CONFIG_TLB_ENTRIES=32 -CONFIG_ISA_M32R2=y -CONFIG_ISA_DSP_LEVEL2=y -CONFIG_ISA_DUAL_ISSUE=y -CONFIG_BUS_CLOCK=5000 -CONFIG_TIMER_DIVIDE=128 -# CONFIG_CPU_LITTLE_ENDIAN is not set -CONFIG_MEMORY_START=0x0800 -CONFIG_MEMORY_SIZE=0x0100 -CONFIG_NOHIGHMEM=y -CONFIG_ARCH_DISCONTIGMEM_ENABLE=y -CONFIG_SELECT_MEMORY_MODEL=y -# CONFIG_FLATMEM_MANUAL is not set -CONFIG_DISCONTIGMEM_MANUAL=y -# CONFIG_SPARSEMEM_MANUAL is not set -CONFIG_DISCONTIGMEM=y -CONFIG_FLAT_NODE_MEM_MAP=y -CONFIG_NEED_MULTIPLE_NODES=y -# CONFIG_SPARSEMEM_STATIC is not set -CONFIG_SPLIT_PTLOCK_CPUS=4 -# CONFIG_RESOURCES_64BIT is not set -CONFIG_ZONE_DMA_FLAG=1 -CONFIG_BOUNCE=y -CONFIG_VIRT_TO_BUS=y -CONFIG_IRAM_START=0x00f0 -CONFIG_IRAM_SIZE=0x0008 -CONFIG_RWSEM_GENERIC_SPINLOCK=y -# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set -# CONFIG_ARCH_HAS_ILOG2_U32 is not set -# CONFIG_ARCH_HAS_ILOG2_U64 is not set -CONFIG_GENERIC_FIND_NEXT_BIT=y -CONFIG_GENERIC_HWEIGHT=y -CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y -CONFIG_PREEMPT=y -CONFIG_SMP=y -# CONFIG_CHIP_M32700_TS1 is not set -CONFIG_NR_CPUS=2 -CONFIG_NODES_SHIFT=1 - -# -# Bus options (PCI, PCMCIA, EISA, MCA, ISA) -# -# CONFIG_ARCH_SUPPORTS_MSI is not set -# CONFIG_ISA is not set - -# -# PCCARD (PCMCIA/CardBus) support -# -# CONFIG_PCCARD is not set - -# -# Executable file formats -# -CONFIG_BINFMT_ELF=y -# CONFIG_BINFMT_MISC is not set - -# -# Networking -# -CONFIG_NET=y - -# -# Networking options -# -CONFIG_PACKET=y -# CONFIG_PACKET_MMAP is not set -CONFIG_UNIX=y -CONFIG_XFRM=y -# CONFIG_XFRM_USER is not set
Re: [2.6 patch v2] cris: proper defconfig setup
Please name the tools that are that broken that they wouldn't apply this patch correctly and don't claim my patch was broken (or shut up). It is only one or two weeks ago we ended up with a zero size file in the kernel tree - and I do not know why. I just wanted to make sure we did not see this happen again. Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] mmiotrace full patch, preview 1
On Mon, 25 Feb 2008 14:49:22 -0800 Andrew Morton [EMAIL PROTECTED] wrote: Please feed the diff through scritps/checkpatch.pl and consider addressing the things which it finds. I checked that, but I didn't think any of them were worth fixing. And since this is a work in progress and a in a state which I do not want committed yet, I did not sign this patch. mmio-mod.c is still a mess. WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt #1097: FILE: arch/x86/mm/mmio-mod.c:437: +void iounmap_trace(volatile void __iomem *addr) I believe the 'volatile' belongs here, it is also in the declaration of iounmap() in arch/x86/mm/ioremap.c. WARNING: externs should be avoided in .c files #1766: FILE: arch/x86/mm/testmmiotrace.c:7: +extern void __iomem *ioremap_nocache_trace(unsigned long offset, WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt #1768: FILE: arch/x86/mm/testmmiotrace.c:9: +extern void iounmap_trace(volatile void __iomem *addr); WARNING: externs should be avoided in .c files #1768: FILE: arch/x86/mm/testmmiotrace.c:9: +extern void iounmap_trace(volatile void __iomem *addr); These are all in testmmiotrace.c which calls the traced ioremap functions directly. These direct calls will go away and it will call the normal ioremap functions. WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt #1790: FILE: arch/x86/mm/testmmiotrace.c:31: + volatile unsigned int v; Since testmmiotrace does not use v for anything other than return value of ioread8/16/32(), I wanted to prevent the compiler from optimizing it away. Now thinking it again, ioread*() must guarantee that the read is always executed. I'll remove v altogether. Patch for the other issues you mentioned is brewing. Thanks. -- Pekka Paalanen http://www.iki.fi/pq/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
On Tue, Feb 26, 2008 at 07:11:39PM +, Chris Clayton wrote: Sorry, but that's not the case. I find the same results as without the patches. With the parameter set to 'pid', the network connection fails very quickly, but with it set to 'simple' I can ping and ftp files to and from my laptop as much as I like and the connection stays up. In fact, if anything the patches seem to have made the network even more fragile, in that it fails almost instantly once I start some network activity ( 10 pings). I'm sure this is not the hardware - it works perfectly with Windows XP, with 2.6.23.14 plus the out-of-tree rt61 driver from serialmonkey, with the in-tree driver from 2.6.24.x and with 2.6.25-rc3 with the mac82011's ieee80211_default_rc_algo parameter set to 'simple'. At last! Vindication for insisting that we keep 'simple' around! Bwahahaha! :-) So, am I to understand that 'pid' works find for you with rtl8180? If so, then I wonder if Stefano and Ivo can help us figure-out what kind of problem is sensitive to both driver _and_ rate control algorithm? Thanks, John -- John W. Linville [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is there a memory block device?
On Tue, 26 Feb 2008, rzryyvzy wrote: I know that tmpfs is a memmory filesystem. Is there a possibility to create also a memory block device? Is there a possibility to create for example a 1 GB memory block device (from the RAM)? There are the /dev/ram* devices, created through kernel config CONFIG_BLK_DEV_RAM (RAM disk support), kernel module rd.ko But I'm not sure how to configure their size besides setting the kernel config option, it's a long time ago that I used them last. c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: vSMP selection in config
On Sun, Feb 24, 2008 at 10:43:49PM -0800, Yinghai Lu wrote: find out vSMP setting is going away in config after make oldconfig vSMP need to PARAVIRT and PCI. so move PARAVIRT out of if PARAVIRT_GUEST, and make vSMP select PCI instead of depends on PCI after patch vSMP could stick there. I'm certain that we have hit a Kconfig bug / limitation here and the patch below is just a workaround for that issue. I tracked it down to a minimal case and hope Roman can provide either an explanation or a fix. IMO VSMP can wait until this is resolved properly and we should not apply this patch. Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [xfs-masters] Re: filesystem corruption on xfs after 2.6.25-rc1 (bisected, powerpc related?)
Gaudenz Steinlin wrote: On Tue, Feb 26, 2008 at 01:13:56AM +0100, Rafael J. Wysocki wrote: On Tuesday, 26 of February 2008, Christoph Hellwig wrote: On Tue, Feb 26, 2008 at 12:52:56AM +0100, Rafael J. Wysocki wrote: I'm not suggesting a partial revert; I just wonder which part of the change is causing the problem, as part of the debugging process. I debuged this a bit further by testing the 4 changed functions individually. The problem only occurs with the new version of xfs_lowbit64. FWIW, Dave I did some testing/debugging on 32-bit powerpc, and it is indeed only xfs_lowbit64 which is doing the wrong thing on that arch, because generic find_next_bit is doing the wrong thing on big-endian 32-bit systems, for sizes 32 bits, near as I can tell. Rather than reverting it all, I think just changing xfs_lowbit64 back to: int xfs_lowbit64( __uint64_t v) { __uint32_t w = (__uint32_t)v; int n = 0; if (w) {/* lower bits */ n = ffs(w); } else {/* upper bits */ w = (__uint32_t)(v 32); if (w (n = ffs(w))) n += 32; } return n - 1; } for now should fix it (this is essentially just ffs64()) -Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch v2] cris: proper defconfig setup
On Tue, Feb 26, 2008 at 08:58:02PM +0100, Sam Ravnborg wrote: Please name the tools that are that broken that they wouldn't apply this patch correctly and don't claim my patch was broken (or shut up). It is only one or two weeks ago we ended up with a zero size file in the kernel tree - and I do not know why. I just wanted to make sure we did not see this happen again. Then research first what went wrong in this case. But it is not funny when you wrongly accuse me publically of sending patches that would remove files in an incorrect way. Sam cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1 xen pvops regression
Mark McLoughlin wrote: @@ -371,6 +372,9 @@ void __init dmi_scan_machine(void) } } else { + if (e820_all_mapped(0xF, 0xF+0x1, E820_RAM)) + goto out; One issue with using the e820 map for this is that a Xen Dom0 will also have this region marked as RAM in the e820 map, but will set up a fixmap for it, allowing dmi_scan_machine() to map the region. Would it be easier to just fake up a mapping so that window points to the real dmi area, and mark E820 accordingly? J -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Intel 945GM: 2.6.25-rc3 report (with a possible regression)
Hi, this mail is to give feedback about the 2.6.25-rc3 kernel, on an Ubuntu 7.10 system, running on a Toshiba Satellite U305. Video is a Intel 845GM, and I run 915resolution at start to make X happy with the correct widescreen resolution. A lot of data is collected here (if more is needed, tell me): http://www.dea.icai.upcomillas.es/romano/linux/info/ 1) The minor regression is that I cannot have any more a correct console. I tried a lot of combinations, but without a framebuffer, console is garbled by ubuntu splash and/or X. With the .config copied in the site above, I do not have console (a random pattern appears as I switch consoles). With intelfb framebuffer, sometime it works, sometime it doesn't work, and everytime break resume from STR. (I mean, the laptop seems to resume, but the screen is blank). I have a doubt about this: is it possible that some state is maintained across reboots? Because sometime two reboots in a row led to different results; for example, after following https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/147606 I had a nice console, but after the failed resume and a sysrq-b reboot, no console again. 2) LCD/CRT switch. It's the first time I tried it, so no idea if it ever worked. Without a CRT connected, nothing happens pressing the key combination (fn-F5), correctly. When I connected a overhead proyector (CRT), pressed fn-F5, and the LCD went off and the CRT on (ok); after that the LCD never came on again. pressing again fn-f5 two times lead to a all-off, a third time made the CRT switch on, and again. The laptop is working but the LCD stay black till the next reboot. (It is very similar to what seems to happen after resume). 3) on the nice side of things, it seems that now echo mem /sys/power/state works (at least in X, I do not have a console to test it...). Thank you very much, Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] [PATCH 2/2] ib fmr pool: flush used clean entries
This looks like a really nice approach to me. Olaf? - R. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/