Signed-off-by: David Woodhouse <dwmw2@infradead.org> --- drivers/usb/serial/Kconfig | 17 + drivers/usb/serial/ti_fw_3410.h | 885 --------------------------------- drivers/usb/serial/ti_fw_5052.h | 885 --------------------------------- drivers/usb/serial/ti_usb_3410_5052.c | 40 +- firmware/Makefile | 3 + firmware/WHENCE | 15 + firmware/ti_3410.fw.ihex | 862 ++++++++++++++++++++++++++++++++ ...

Signed-off-by: David Woodhouse <dwmw2@infradead.org> --- drivers/usb/serial/Kconfig | 17 + drivers/usb/serial/keyspan_pda.S | 1124 -------------------------------- drivers/usb/serial/keyspan_pda.c | 51 +- drivers/usb/serial/keyspan_pda_fw.h | 99 --- drivers/usb/serial/xircom_pgs.S | 1192 ---------------------------------- drivers/usb/serial/xircom_pgs_fw.h | 103 --- firmware/Makefile | 2 + firmware/WHENCE | 14 ...

Hi, This is a series of cleanups to xen-blkfront, xen-netfront and xenbus. They're mostly changes imported from the linux-2.6.18-xen repo because they looked like they would be useful. Thanks, J drivers/block/xen-blkfront.c | 48 ++++++++++++++++++++++++++--- drivers/net/xen-netfront.c | 4 +- drivers/xen/xenbus/xenbus_client.c | 2 - drivers/xen/xenbus/xenbus_xs.c | 10 +++--- 4 files changed, 52 insertions(+), 12 deletions(-) --

From: Christian Limpach <Christian.Limpach@xensource.com> Return 0 instead of -EINVAL if the blkfront device is a cdrom, i.e. had the VDISK_CDROM attribute. This allows udev's cdrom_id to correctly detect the device as a cdrom device. [ Add blkif_ioctl, and CDROMMULTISESSION ] [ linux-2.6.18-xen changeset d2bd9af846b5 ] Signed-off-by: Christian Limpach <Christian.Limpach@xensource.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- drivers/block/xen-blkfront.c ...

From: Ian Campbell <ian.campbell@xensource.com> [ linux-2.6.18-xen changeset 667228bf8fc5 ] Signed-off-by: Ian Campbell <ian.campbell@xensource.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- drivers/block/xen-blkfront.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -324,6 +324,9 @@ /* Make sure buffer addresses ...

Steps to reproduce: modprobe netsc520 NetSc520 flash device: 0x100000 at 0x200000 ------------[ cut here ]------------ WARNING: at arch/x86/mm/ioremap.c:159 __ioremap_caller+0x15e/0x2c0() Modules linked in: netsc520(+) [many] Pid: 13101, comm: modprobe Not tainted 2.6.26-rc4-fat #6 Call Trace: [<ffffffff80238042>] warn_on_slowpath+0x58/0x88 [<ffffffff80238c7e>] ? printk+0x67/0x69 [<ffffffff80222adc>] __ioremap_caller+0x15e/0x2c0 [<ffffffffa1fab033>] ? ...

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> --- drivers/firmware/edd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/firmware/edd.c +++ b/drivers/firmware/edd.c @@ -753,7 +753,7 @@ edd_init(void) if (!edd_num_devices()) { printk(KERN_INFO "EDD information not available.\n"); - return 1; + return -ENODEV; } edd_kset = kset_create_and_add("edd", NULL, firmware_kobj); --

This patch adds an IORESOURCE_IRQ_OPTIONAL flag for use when assigning resources to a device. If the flag is set and we are unable to assign an IRQ to the device, we can leave the IRQ disabled but allow the overall resource allocation to succeed. Some devices request an IRQ, but can run without an IRQ (possibly with degraded performance). This flag lets us run the device without the IRQ instead of just leaving the device disabled. This is a reimplementation of this previous change by ...

No functional change; just rename "data" to something more descriptive. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Index: work10/drivers/pnp/resource.c =================================================================== --- work10.orig/drivers/pnp/resource.c 2008-05-20 13:23:06.000000000 -0600 +++ work10/drivers/pnp/resource.c 2008-05-20 13:24:27.000000000 -0600 @@ -80,40 +80,40 @@ struct pnp_option *pnp_register_dependen int pnp_register_irq_resource(struct pnp_dev *dev, struct ...

ACPI Address Space Descriptors can be up to 64 bits wide. We should keep track of the whole thing when parsing resource options, so this patch changes PNP port and mem option fields from "unsigned short" and "unsigned int" to "resource_size_t". Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> --- drivers/pnp/base.h | 16 ++++++++-------- drivers/pnp/interface.c | 17 +++++++++++------ drivers/pnp/resource.c | 14 ++++++++++---- 3 files changed, 29 insertions(+), 18 ...

pnp_assign_resources() is static and the only caller checks pnp_can_configure() before calling it, so no need to do it again. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Index: work10/drivers/pnp/manager.c =================================================================== --- work10.orig/drivers/pnp/manager.c 2008-05-13 13:29:57.000000000 -0600 +++ work10/drivers/pnp/manager.c 2008-05-13 13:30:21.000000000 -0600 @@ -231,9 +231,6 @@ static int pnp_assign_resources(struct p struct ...

When we fail to assign an I/O or MEM resource, include the min/max in the debug output to help match it with the options. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Index: work10/drivers/pnp/manager.c =================================================================== --- work10.orig/drivers/pnp/manager.c 2008-05-13 12:01:17.000000000 -0600 +++ work10/drivers/pnp/manager.c 2008-05-13 12:50:57.000000000 -0600 @@ -47,7 +47,10 @@ static int pnp_assign_port(struct pnp_de res->start ...

PNP previously defined PNP_PORT_FLAG_16BITADDR and PNP_PORT_FLAG_FIXED in a private header file, but put those flags in struct resource.flags fields. Better to make them IORESOURCE_IO_* flags like the existing IRQ, DMA, and MEM flags. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> --- include/linux/ioport.h | 10 +++++++--- include/linux/pnp.h | 3 --- drivers/pnp/interface.c | 2 +- drivers/pnp/isapnp/core.c | 4 ++-- ...

No functional change; just make a couple declarations consistent with the rest of the file. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Index: work10/drivers/pnp/interface.c =================================================================== --- work10.orig/drivers/pnp/interface.c 2008-05-09 14:42:25.000000000 -0600 +++ work10/drivers/pnp/interface.c 2008-05-09 14:45:57.000000000 -0600 @@ -216,12 +216,12 @@ static ssize_t pnp_show_options(struct d struct device_attribute *attr, ...

This patch series converts the PNP resource option structures to a unified linked list. This preserves resource order, which is important for some devices. There's more detail in the comments for the last patch. Any comments would be welcome. This depends on some patches that are in -mm, but not yet upstream. In mmotm, these would probably go after pnp-dont-sort-by-type-in-sys-resources.patch Bjorn -- --

To date the behavior of a Smack system running with nltype unlabeled has been carefully undefined. The way you're defining it will result in a system in which only processes running with the ambient label will be able to use sockets, unless I'm reading the code incorrectly. This seems like "correct" behavior, but I don't think it is what those who've tried it would expect. Casey Schaufler casey@schaufler-ca.com --

On Sat, 31 May 2008 02:57:51 +0300 no no no no no. And no. GFP_ATOMIC is *unreliable*. Using it in a "security" feature is a bug - if it fails, the feature isn't secure any more. Failing to check the kmalloc() return value might be a bug. If we _need_ GFP_ATOMIC here then taking a mutex in a cannot-sleep context is a bug. The patch adds a kmalloc but doesn't add a kfree. Is it leaky? Finally, why is there a need to take a lock around a single store instruction? --

Hi all, In case of Smack 'unlabeled' netlabel option, Smack passes a _zero_ initialized 'secattr' to label a packet/sock. This causes an [unfound domain label error]/-ENOENT by netlbl_sock_setattr(). Above Netlabel failure leads to Smack socket hooks failure causing an always-on socket() -EPERM error. Such packets should have a netlabel domain agreed with netlabel to represent unlabeled packets. Fortunately Smack net ambient label packets are agreed with netlabel to be treated as ...

Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git upstream-linus to receive the following updates: drivers/ata/ahci.c | 8 +- drivers/ata/ata_piix.c | 7 +- drivers/ata/libata-core.c | 2 +- drivers/ata/libata-pmp.c | 7 +- drivers/ata/libata-scsi.c | 3 +- drivers/ata/sata_fsl.c | 224 ++++++++++++++++++++++++++++++++------------ drivers/ata/sata_mv.c | 83 ++++++++--------- 7 files ...

fs/proc/base.c already has an array with strings in it --

Signed-off-by: Clifford Wolf <clifford@clifford.at> --- fs/proc/array.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 57 insertions(+), 0 deletions(-) diff --git a/fs/proc/array.c b/fs/proc/array.c index 9e3b8c3..3cb2ad3 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -242,6 +242,62 @@ static void collect_sigign_sigcatch(struct task_struct *p, sigset_t *ign, } } +static const char *rlim_names[RLIM_NLIMITS] = { + [RLIMIT_CPU] = ...

I have just compiled a kernel from wireless-testing (32-bit x86), and I get this during shutdown or if I kill NetworkManager (blacklisting rt73usb fixes it): BUG: unable to handle kernel paging request at 0000759d IP: [<f8ac8f77>] :usbcore:usb_kill_urb+0x17/0xd0 *pdpt = 00000000354d2001 *pde = 0000000000000000 Oops: 0000 [#1] SMP Modules linked in: ocfs2_dlmfs ocfs2_dlm ocfs2_nodemanager configfs ipv6 af_packet microcode rfkill_input binfmt_misc snd_pcm_oss snd_mixer_oss snd_seq ...

Yes, that comment is correct. And unfortunate. We need some way to provide Please fix the few typos and add Acked-by: Randy Dunlap <rdunlap@xenotime.net>. Thanks, Paul. --- ~Randy "He closes his eyes and drops the goggles. You can't get hurt by looking at a bitmap. Or can you?" --

Since alloc_bootmem_core does no goal-fallback anymore and just returns NULL if the allocation fails, we might now use it in alloc_bootmem_section without all the fixup code for a misplaced allocation. Also, the limit can be the first PFN of the next section as the semantics is that the limit is _above_ the allocated region, not within. Signed-off-by: Johannes Weiner <hannes@saeurebad.de> CC: Yasunori Goto <y-goto@jp.fujitsu.com> --- mm/bootmem.c | 27 ++++++--------------------- 1 ...

Hi, Sorry, forgot to update ->last_success handling here. Update coming soon. Hannes --

Introduce new helpers that mark a range that resides completely on a node or node-agnostic ranges that might also span node boundaries. The free/reserve API functions will then directly use these helpers. Note that the free/reserve semantics become more strict: while the prior code took basically arbitrary range arguments and marked the PFNs that happen to fall into that range, the new code requires node-specific ranges to be completely on the node. The node-agnostic requests might span node ...

Hi, Another ->last_success error (missed updating it). I already have a fixed up series here, will wait a bit for sending it out to incorporate feedback as well. Hannes --

Rewrite the code in a more concise way using less variables. Signed-off-by: Johannes Weiner <hannes@saeurebad.de> CC: Ingo Molnar <mingo@elte.hu> CC: Yinghai Lu <yhlu.kernel@gmail.com> CC: Andi Kleen <andi@firstfloor.org> --- mm/bootmem.c | 83 +++++++++++++++++++++++++++-------------------------------- 1 file changed, 38 insertions(+), 45 deletions(-) --- a/mm/bootmem.c +++ b/mm/bootmem.c @@ -144,66 +144,59 @@ unsigned long __init init_bootmem(unsign static unsigned long __init ...

Reincarnate get_mapsize as bootmap_bytes and implement bootmem_bootmap_pages on top of it. Adjust users of these helpers and make free_all_bootmem_core use bootmem_bootmap_pages instead of open-coding it. Signed-off-by: Johannes Weiner <hannes@saeurebad.de> --- mm/bootmem.c | 27 +++++++++------------------ 1 file changed, 9 insertions(+), 18 deletions(-) --- a/mm/bootmem.c +++ b/mm/bootmem.c @@ -50,17 +50,11 @@ early_param("bootmem_debug", bootmem_deb __FUNCTION__, ## ...

Signed-off-by: Johannes Weiner <hannes@saeurebad.de> --- mm/bootmem.c | 147 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 146 insertions(+), 1 deletion(-) --- a/mm/bootmem.c +++ b/mm/bootmem.c @@ -47,7 +47,10 @@ static unsigned long __init get_mapsize( return ALIGN(mapsize, sizeof(long)); } -/* return the number of _pages_ that will be allocated for the boot bitmap */ +/** + * bootmem_bootmap_pages - calculate bitmap size in pages + * @pages: number ...

This only reorders functions so that further patches will be easier to read. No code changed. Signed-off-by: Johannes Weiner <hannes@saeurebad.de> --- include/linux/bootmem.h | 79 ++++----- mm/bootmem.c | 413 +++++++++++++++++++++++------------------------- 2 files changed, 246 insertions(+), 246 deletions(-) --- a/mm/bootmem.c +++ b/mm/bootmem.c @@ -38,6 +38,19 @@ unsigned long saved_max_pfn; bootmem_data_t bootmem_node_data[MAX_NUMNODES] __initdata; +/* + * ...

i is used only as a for-loop index no need to declare another. drivers/usb/atm/speedtch.c:832:7: warning: symbol 'i' shadows an earlier one drivers/usb/atm/speedtch.c:766:6: originally declared here Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- drivers/usb/atm/speedtch.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/atm/speedtch.c b/drivers/usb/atm/speedtch.c index 7d27c9c..76fce44 100644 --- a/drivers/usb/atm/speedtch.c +++ ...

--

Hello All, I've come across a little discrepancy between the glibc docs and linux kernel docs when I was trying to figure out what kernel headers I should being using for my cross compiling. The docs seem to say almost exactly the opposite thing. For a quick summary: linux docs(headers_install.txt) seem to indicate, running glibc compiled against new kernel headers, on an older kernel will possibly cause problems. Where as glib docs(FAQ) indicate glibc compiled against new kernel headers, ...

Yes, it was changed. New one allows only acceptable chmod(), and if not acceptable, it returns -EPERM. Old one allows even if it can't store the disk inode. But it may be too strict for users. Umm.. anyway, the following patch (still untested) will relax the check... -- OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> --- fs/fat/file.c | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 ...

Hi Ray, ...I reorganized it a bit. I think you miss here a lot of clues. First I suspected my FRTO changes as well but later discoveries pointed elsewhere... Those fixes are for sender behavior, which is not the problem here. It's just that once you have flow control, the sending TCP obviously gets stuck once all "buffering" capacity downstream is used up, and that's _correct_ sender behavior rather than a bug in itself. Therefore both FRTO and Ingo's theory about Cubic (though his ...

I am seeing the following errors on a Fedora 7 x86_64 linux box, running on a Tyan Tempest i5000XL motherboard, after upgrading from kernel-2.6.25-14.fc9.x86_64 to kernel-2.6.25.3-18.fc9.x86_64... May 25 04:30:56 fourier kernel: EDAC i5000 MC0: NON-FATAL ERRORS Found!!! 1st NON-FATAL Err Reg= 0x10000 May 25 04:30:56 fourier kernel: EDAC MC0: CE row 1, channel 0, label "": (Branch=0 DRAM-Bank=3 RDWR=Read RAS=14339 CAS=672, CE Err=0x10000) These messages occur about once an hour and are always ...

On Fri, 30 May 2008 17:58:24 +0100 I'll stage this after Mel's But I wonder if helpers which manipulate a vma's HPAGE_RESV_MASK Oh. We already kinda have it. Perhaps vma_resv_huge_pages() should have called set_vma_resv_flags(). I guess the assertions would have busted that. Oh well, whatever. --

Use the new encapsulated huge page offset helper. Signed-off-by: Andy Whitcroft <apw@shadowen.org> --- mm/hugetlb.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 1dce03a..901e580 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -733,8 +733,7 @@ static int vma_needs_reservation(struct vm_area_struct *vma, unsigned long addr) struct inode *inode = mapping->host; if (vma->vm_flags & VM_SHARED) { - unsigned long idx = ...

Please pull a last minute fix intended for 2.6.26: git pull git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6.git for-linus BenH found a bug that broke ABI in the POWER6 PCI hotplug code, so we needed to get the fix upstream asap. Thanks, Jesse Benjamin Herrenschmidt (1): PCI: fix rpadlpar pci hotplug driver sysfs usage rpadlpar_sysfs.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --

ok for some it did gather this information, and it is kernel BUG at mm/highmem.c:319! --

coincidence; I just recreated a new version of the report (so several hours later) and they're 1 appart now. --

I've seen it a few more times the last few weeks, I'll dig into how that is happening. Maybe we changed the bug_on text to miss my regexps ;( (it's only about 1000 lines of perl, so what can go wrong in that ;-) --

Hugh --

versions that do identify themselves as "2.6.25-14.fc9.i686.PAE", and these ones didn't, (they're all in the "2.6.25-14.fc9.i686" form) so this is a kernel without PAE. --

It's a BUG_ON(), but sadly the oops gatherer doesn't seem to gather that part. You can see it from the code portion: the "<0f> 0b" gives it away (that's the ud2 opcode). There's two BUG_ON()'s in that function, and I think it's the second one, based on at least the code generation that my particular compiler version gets. IOW, it would be the BUG_ON(list_empty(&page_address_pool)); thing. Why would we run out of the page-address pool? Or perhaps the right question is what ...

Add the missing newline character at the end of the warning string Signed-off-by: Alessandro Guido <alessandro.guido@gmail.com> --- drivers/misc/sony-laptop.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/misc/sony-laptop.c b/drivers/misc/sony-laptop.c index 00e48e2..daf3c9c 100644 --- a/drivers/misc/sony-laptop.c +++ b/drivers/misc/sony-laptop.c @@ -969,7 +969,7 @@ static int sony_nc_resume(struct acpi_device *device) /* set the last requested ...

Hi all, when trying to understand how Bogomips are implemented I have found bug in arch/i386/lib/delay.c file, delay_loop function /* simple loop based delay: */ static void delay_loop(unsigned long loops) { int d0; __asm__ __volatile__( "\tjmp 1f\n" ".align 16\n" "1:\tjmp 2f\n" ".align 16\n" "2:\tdecl %0\n\tjns 2b" :"=&a" (d0) :"0" (loops)); } The function fails for loops > 2^31+1. It because SF is set when dec returns numbers > 2^31 The fix ...

Yes. The short answer is that this is a real bug in the parport code that has existed forever. We just now complain. http://bugzilla.kernel.org/show_bug.cgi?id=9749 It takes something like two accessors of the parallel port to trigger this. Though not in a bad way. In particular each open creates the sysctl for the duration of the open (or something like that) and so if you open (I think it is /dev/parport0) twice you try and create the sysctls twice. I got as far as basic ...

Hi list, I recently upgraded one of my servers from 2.6.24.2 to 2.6.25. This is more or less a basic fileserver that also does some compilations from time to time. cat /proc/cpuinfo from 2.6.24.2: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 1 model name : Intel(R) Pentium(R) 4 CPU 1.70GHz stepping : 2 cpu MHz : 425.000 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp ...

On Fri, 30 May 2008 15:44:55 +0200 ... and it's not the best solution because it's not saving you any energy... (in fact it may cost you some) p4-clockmod should go away. (at least as cpufreq driver) -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org --

Removed. A new patch is at http://groups.google.com/group/pcidriver --

Hello, Dave! I confess to being confused by the smp_read_barrier_depends() in rxrpc_rotate_tx_window(). It looks like it is ordering the prior fetch of tail from call->acks_tail with the subsequent use of tail as an index into the call->acks_window[] array, but then the code does an assignment to call->acks_tail a few lines later. If we hold a lock protecting call->acks_tail, why do we need the smp_read_barrier_depends()? If we don't hold such a lock, why is the assignment to ...

Hello, Mathieu, I am a bit confused by the smp_read_barrier_depends() in kernel/markers.c. My (probably naive) view is that they need to move as shown in the patch below. Help? Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> --- marker.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff -urpNa -X dontdiff linux-2.6.26-rc4/kernel/marker.c linux-2.6.26-rc4-marker-srbd/kernel/marker.c --- linux-2.6.26-rc4/kernel/marker.c 2008-05-30 04:39:01.000000000 ...

Reading AT91_MCI_SR again at the end of transfer can corrupt the error reporting. Some fields in the SR register are read-and-clear. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> --- drivers/mmc/host/at91_mci.c | 12 +++++------- 1 files changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/mmc/host/at91_mci.c b/drivers/mmc/host/at91_mci.c index 92a0200..9948fe1 100644 --- a/drivers/mmc/host/at91_mci.c +++ b/drivers/mmc/host/at91_mci.c @@ -660,10 +660,9 @@ static void ...

From: Eric Benard <ebenard@free.fr> Enable SDIO interrupt handling. Signed-off-by: Eric Benard <ebenard@free.fr> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> --- drivers/mmc/host/at91_mci.c | 26 ++++++++++++++++++++++---- 1 files changed, 22 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/host/at91_mci.c b/drivers/mmc/host/at91_mci.c index b2138f9..92a0200 100644 --- a/drivers/mmc/host/at91_mci.c +++ b/drivers/mmc/host/at91_mci.c @@ -665,7 +665,7 @@ static void ...

From: Marc Pignat <marc.pignat@hevs.ch> Detect command timeout (or mci controller hangs). Signed-off-by: Marc Pignat <marc.pignat@hevs.ch> Signed-off-by: Hans J Koch <hjk@linutronix.de> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> --- drivers/mmc/host/at91_mci.c | 35 +++++++++++++++++++++++++++++++++-- 1 files changed, 33 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/at91_mci.c b/drivers/mmc/host/at91_mci.c index 543b64b..4b4518f 100644 --- ...

Modify bytes_xfered value after a write. That will report, as accurately as possible, the amount of sectors that are effectively written. This update introduces the check of the busy signal given by the card. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> --- drivers/mmc/host/at91_mci.c | 40 ++++++++++++++++++++++++++++++++++------ 1 files changed, 34 insertions(+), 6 deletions(-) diff --git a/drivers/mmc/host/at91_mci.c b/drivers/mmc/host/at91_mci.c index df975e0..b2138f9 ...

Hi, (please CC me in replies) my current kernel just threw an error, see output from ksymoops below. I've been using this version for quite some time now, this is the first time this has happened. There have been no hardware changes lately. The hardware itself is nothing special, it's a somewhat dusty Thinkpad. I hope I have included all relevant information, please contact me if more information is needed. Cheers, Wolf ksymoops 2.4.11 on i686 2.6.25. Options used -V ...

Also add kvm_ prefix. Signed-off-by: Amit Shah <amit.shah@qumranet.com> --- virt/kvm/ioapic.c | 4 ++-- virt/kvm/ioapic.h | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c index 99a1736..4c41a00 100644 --- a/virt/kvm/ioapic.c +++ b/virt/kvm/ioapic.c @@ -284,7 +284,7 @@ void kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int level) } } -static int get_eoi_gsi(struct kvm_ioapic *ioapic, int vector) +int ...

From: Amit Shah <amit.shah@qumranet.com> From: Ben-Ami Yassour <benami@il.ibm.com> This patch adds support for handling PCI devices that are assigned to the guest ("PCI passthrough"). The device to be assigned to the guest is registered in the host kernel and interrupt delivery is handled. It is expected the module for the device in the host is not loaded. Devices that share their interrupt line are not supported at the moment. By itself, this patch will not make devices work within the ...

I guess there are lots of reasons why it may block (get rescheduled) briefly, but why would that matter to you? Are you saying that its whole design has got broken somehow, and now SYNC_FILE_RANGE_WRITE is behaving as if SYNC_FILE_RANGE_WAIT_AFTER had been supplied too? Hugh --

Keeping the fixes rolling: 1) Two DCCP bug fixes from Gerrit and the DCCP crew. 2) Merge in wireless fixes from John Linville and co. 3) LLC double ref bug fix from Arnaldo. 4) Netfilter conntrack expection fix from Alexey Dobriyan. Please pull, thanks a lot! The following changes since commit 289c79a4bd350e8a25065102563ad1a183d1b402: Patrick McHardy (1): vlan: Use bitmask of feature flags instead of seperate feature bits are available in the git repository at: ...

Here is the output from hdparm -I /dev/sdb. The output is the same for both drives. I just want to re-state that it's not just when drives spindown. Happens on hotplug or cold boot also. As for what happens when I try to access the drives when they have spun down: - drives are asleep - i run fdisk -l - drive on port 1 spins up and LED for that port lights up - it waits 60s then the LED *should* turn off, but many times, at this point the port will hang: LED is always on - LED on ...

On Fri, 30 May 2008 15:32:04 +0800 NAK. These are not redundant, they are used to pull documentation out of the tree using kernel-doc or other tools that know how to finish entries out for both inline and non-inlines. Alan --

> These are not redundant Miao wasn't saying the kernel-doc '/**' markers were redundant. He was saying that, in one case, there was a redundant blank line, right in the middle of a kernel-doc comment, that broke that particular kernel-doc formatting. That one-line fix is still worth getting in, though probably not worth a patch all by itself. The NAK by Alan of the rest of this patch still applies. Thanks, Alan, Randy and Miao. -- I won't rest till it's the best ...

extract two functions from update_cpumask() and update_nodemask().They will be used later for updating tasks' cpus_allowed and mems_allowed after CPU/NODE offline/online. Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> Acked-by: Paul Jackson <pj@sgi.com> --- kernel/cpuset.c | 178 +++++++++++++++++++++++++++++++++--------------------- 1 files changed, 109 insertions(+), 69 deletions(-) diff --git a/kernel/cpuset.c b/kernel/cpuset.c index f063368..2d6dff9 100644 --- ...

It took me a minute to parse this comment (pre-coffee morning fog ;). I take it that you're noticing, Alan, that the header comments for the functions update_tasks_cpumask() and update_tasks_nodemask(), and perhaps one other function, are already in kernel-doc format, except for one detail -- they currently open with '/*' instead of '/**', and you're recommending the trivial change '/*' ==> '/**' for these cases. Yes - Miao commented these new functions in kernel-doc format, all but the ...

From: Paul Jackson <pj@sgi.com> Update status and URL for the "Gary's Encyclopedia" entry. Signed-off-by: Paul Jackson <pj@sgi.com> --- Documentation/kernel-docs.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- linux-2.6.orig/Documentation/kernel-docs.txt 2007-12-18 20:38:50.000000000 -0800 +++ linux-2.6/Documentation/kernel-docs.txt 2008-05-29 21:55:28.488134402 -0700 @@ -715,14 +715,14 @@ * Name: "Gary's Encyclopedia - The Linux Kernel" ...

Oops -- Andrew -- send this so called PATCH to /dev/null. I sent the wrong file. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214 --

Here is a single patch against your 2.6.26-git tree. It was suggested by Stephen, as it will help with the linux-next merge issues starting to happen as this api changes in anticipation for 2.6.27. This patch merges a functional version of the dev_set_name() function for other trees to be able to take adnd merge in changes that help with the progression toward getting rid of the bus_id field and the limitation of 20 characters for the name of struct device. Please pull ...

From: Stephen Rothwell <sfr@canb.auug.org.au> Create the dev_set_name function now so that various subsystems can start changing over to it before other changes in 2.6.27 will make it compulsory. Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/base/core.c | 15 +++++++++++++++ include/linux/device.h | 3 +++ 2 files changed, 18 insertions(+), 0 deletions(-) diff --git ...

Convert NFS statistics to cpu alloc. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- fs/nfs/iostat.h | 27 +++++++++++---------------- fs/nfs/super.c | 2 +- 2 files changed, 12 insertions(+), 17 deletions(-) Index: linux-2.6/fs/nfs/iostat.h =================================================================== --- linux-2.6.orig/fs/nfs/iostat.h 2008-05-26 09:35:31.077736336 -0700 +++ linux-2.6/fs/nfs/iostat.h 2008-05-26 10:01:26.178776581 -0700 @@ -119,13 +119,7 @@ struct ...

Convert tcp statistics to cpu alloc. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- net/ipv4/tcp.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) Index: linux-2.6/net/ipv4/tcp.c =================================================================== --- linux-2.6.orig/net/ipv4/tcp.c 2008-04-29 14:55:55.000000000 -0700 +++ linux-2.6/net/ipv4/tcp.c 2008-05-21 21:46:54.000000000 -0700 @@ -2456,7 +2456,7 @@ { int cpu; for_each_possible_cpu(cpu) { - struct ...

Convert handling of the inuse counters to cpu alloc. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- net/core/sock.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) Index: linux-2.6/net/core/sock.c =================================================================== --- linux-2.6.orig/net/core/sock.c 2008-05-14 19:40:34.000000000 -0700 +++ linux-2.6/net/core/sock.c 2008-05-21 22:00:56.000000000 -0700 @@ -1943,8 +1943,7 @@ #ifdef CONFIG_NET_NS void ...

Convert scratch handling in the network stack to cpu alloc. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- net/ipv4/ipcomp.c | 26 +++++++++++++------------- net/ipv6/ipcomp6.c | 26 +++++++++++++------------- 2 files changed, 26 insertions(+), 26 deletions(-) Index: linux-2.6/net/ipv4/ipcomp.c =================================================================== --- linux-2.6.orig/net/ipv4/ipcomp.c 2008-04-29 14:55:55.000000000 -0700 +++ linux-2.6/net/ipv4/ipcomp.c 2008-05-21 ...

There is no user of local_t remaining after the cpu ops patchset. local_t always suffered from the problem that the operations it generated were not able to perform the relocation of a pointer to the target processor and the atomic update at the same time. There was a need to disable preemption and/or interrupts which made it awkward to use. Quirk: - linux/module.h needs to include hardirq.h now since asm-generic/local.h did and some arches now depend on it (sparc64 for ...

IA64 has no efficient atomic operations. But we can get rid of the need to add my_percpu_offset(). The address of a per cpu variable can be used directly on IA64 since its mapped to a per processor area. This also allows us to kill off the __ia64_get_cpu_var macro. Its nothing but per_cpu_var(). Cc: Tony.Luck@intel.com Signed-off-by: Christoph Lameter <clameter@sgi.com> --- arch/ia64/Kconfig | 3 arch/ia64/kernel/perfmon.c | 2 arch/ia64/kernel/setup.c | ...

It is now possible to use percpu operations for pda access since the pda is in the percpu area. Drop the pda operations. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- arch/x86/kernel/apic_64.c | 4 - arch/x86/kernel/cpu/mcheck/mce_amd_64.c | 2 arch/x86/kernel/cpu/mcheck/mce_intel_64.c | 2 arch/x86/kernel/nmi_64.c | 5 + arch/x86/kernel/process_64.c | 16 ++--- arch/x86/kernel/smp.c | 4 - ...

* Declare the pda as a per cpu variable. * Make the x86_64 per cpu area start at zero. * Since %gs is pointing to the pda, it will then also point to the per cpu variables and can be accessed thusly: %gs:[&per_cpu_xxxx - __per_cpu_start] Signed-off-by: Christoph Lameter <clameter@sgi.com> Signed-off-by: Mike Travis <travis@sgi.com> --- arch/x86/Kconfig | 3 +++ arch/x86/kernel/setup.c | 22 ++++++++++++++++++++-- arch/x86/kernel/smpboot.c ...

Convert scheduler handling of cpuusage to cpu alloc. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- arch/x86/kernel/setup.c | 2 +- kernel/sched.c | 10 +++++----- mm/cpu_alloc.c | 25 +++++++++++++++++++------ 3 files changed, 25 insertions(+), 12 deletions(-) Index: linux-2.6/kernel/sched.c =================================================================== --- linux-2.6.orig/kernel/sched.c 2008-05-26 20:38:49.000000000 -0700 +++ ...

Wow. y:/usr/src/25> grep alloc_percpu patches/*.patch y:/usr/src/25> we might just be able to get away with doing this. But it might make life easier to defer the removal of the old stuff for a while. This can be worked out later. --

The use of CPU ops here avoids the offset calculations that we used to have to do with per cpu operations. The result of this patch is that event counters are coded with a single instruction the following way: incq %gs:offset(%rip) Without these patches this was: mov %gs:0x8,%rdx mov %eax,0x38(%rsp) mov xxx(%rip),%eax mov %eax,0x48(%rsp) mov varoffset,%rax incq 0x110(%rax,%rdx,1) Signed-off-by: Christoph Lameter <clameter@sgi.com --- ...

These are critical fast paths. Reduce overhead by using a segment override instead of an address calculation. Signed-off-by: Christoph LAmeter <clameter@sgi.com> --- arch/x86/kernel/nmi_64.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) Index: linux-2.6/arch/x86/kernel/nmi_64.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/nmi_64.c 2008-04-29 14:55:48.000000000 -0700 +++ ...

Remove the fields in kmem_cache_cpu that were used to cache data from kmem_cache when they were in different cachelines. The cacheline that holds the per cpu array pointer now also holds these values. We can cut down the kmem_cache_cpu size to almost half. The get_freepointer() and set_freepointer() functions that used to be only intended for the slow path now are also useful for the hot path since access to the field does not require accessing an additional cacheline anymore. This results in ...

x86 percpu ops now will work on 64 bit too. So add the missing 8 byte cases. Also add a number of atomic ops that will be useful in the future: x86_xchg_percpu() and x86_cmpxchg_percpu(). Add x86_inc_percpu and x86_dec_percpu. Increment by one can generate more efficient instructions and inc/dec will be supported by cpu ops later. Also use per_cpu_var() instead of per_cpu__##xxx. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- include/asm-x86/percpu.h | 83 ...

Right. --

Use cpu alloc for the crypto subsystem. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- crypto/async_tx/async_tx.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) Index: linux-2.6/crypto/async_tx/async_tx.c =================================================================== --- linux-2.6.orig/crypto/async_tx/async_tx.c 2008-04-29 14:55:49.000000000 -0700 +++ linux-2.6/crypto/async_tx/async_tx.c 2008-05-21 22:01:42.000000000 -0700 @@ -221,10 +221,10 @@ ...

Convert DMA engine to use CPU_xx operations. This also removes the use of local_t from the dmaengine. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- drivers/dma/dmaengine.c | 38 ++++++++++++++------------------------ include/linux/dmaengine.h | 16 ++++++---------- 2 files changed, 20 insertions(+), 34 deletions(-) Index: linux-2.6/drivers/dma/dmaengine.c =================================================================== --- ...

Convert neighbor stats to cpu alloc. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- include/net/neighbour.h | 6 +----- net/core/neighbour.c | 11 ++++++----- 2 files changed, 7 insertions(+), 10 deletions(-) Index: linux-2.6/include/net/neighbour.h =================================================================== --- linux-2.6.orig/include/net/neighbour.h 2008-05-21 23:59:14.000000000 -0700 +++ linux-2.6/include/net/neighbour.h 2008-05-22 07:40:37.000000000 -0700 @@ ...

Convert blktrace percpu handling to cpu_alloc. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- block/blktrace.c | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-) Index: linux-2.6/block/blktrace.c =================================================================== --- linux-2.6.orig/block/blktrace.c 2008-05-28 18:45:08.580239875 -0700 +++ linux-2.6/block/blktrace.c 2008-05-29 00:02:19.570236238 -0700 @@ -82,7 +82,7 @@ void __trace_note_message(struct ...

Its __per_cpu_end - __per_cpu_start. --

Hmm, does cpu_free(NULL, 0) do something? Seems like it shouldn't, for OK, we've *never* had a report of the per-cpu alignment message, so I'd be happy to pass that through to cpu_alloc() and have it fail. Also, the if Where did __per_cpu_size come from? I missed it in the earlier patches... Thanks, Rusty. --

Again moved code. Should I really do string separations for code The code has been able to deal with an allocpercpu failure in the past. Why would it have trouble with a cpu_alloc failure here? --

Was developed on 64bit. As ususal 32 bit was an afterthought. --

Hum, maybe, but then we broke modules that might request up to PAGE_SIZE alignement for their percpu section, if I read your 3rd patch correctly. Taking into account the ((unsigned long)area & (PAGE_SIZE-1)) offset in cpu_alloc() should give up to PAGE_SIZE alignment for free. --

I think that strengthening bitmap_find_free_region() would end up urgh. This is a C-convention versus kernel-convention thing. The C convention exists for very good reasons. But it sure does suck. What do others think? --

area[] is not guaranteed to be aligned on anything but 4 bytes. If someone then needs to call cpu_alloc(8, GFP_KERNEL, 8), it might get an non aligned result. Either you should add an __attribute__((__aligned__(PAGE_SIZE))), or take into account the real address of area[] in cpu_alloc() to avoid waste of up to PAGE_SIZE bytes --

strange choice of a default? I guess it makes it clear that there's no Perhaps it should return UNIT_TYPE? (ugh). This is kinda bitmap_find_free_region(), only bitmap_find_free_region() isn't quite strong enough. Generally I think it would have been better if you had added new primitives to the bitmap library (or enhanced existing ones) and used If this assertion triggers for someone, you'll wish like hell that it eek, a major interface function which is ALL IN ...

The per cpu allocator allows dynamic allocation of memory on all processors simultaneously. A bitmap is used to track used areas. The allocator implements tight packing to reduce the cache footprint and increase speed since cacheline contention is typically not a concern for memory mainly used by a single cpu. Small objects will fill up gaps left by larger allocations that required alignments. The size of the cpu_alloc area can be changed via make menuconfig. Signed-off-by: Christoph Lameter ...

It drastically reduces the memory size f.e. 4 byte allocations require SLAB f.e. to allocate a 32 byte chunk. This reduces memory requirements by 32/4 = 8 times. Plus the per cpu counters allocated in order are likely placed in the same cacheline (whereas the slab allocators avoid placing multiple objects in the same cacheline). Reduces cache footprint. --

Use cpu_alloc instead of allocpercpu. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- lib/percpu_counter.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) Index: linux-2.6/lib/percpu_counter.c =================================================================== --- linux-2.6.orig/lib/percpu_counter.c 2008-05-28 17:56:17.000000000 -0700 +++ linux-2.6/lib/percpu_counter.c 2008-05-28 18:30:25.000000000 -0700 @@ -20,7 +20,7 @@ spin_lock(&fbc->lock); ...

No its not! In order to increment a per cpu value you need to calculate the per cpu pointer address in the current per cpu segment. local_t cannot do that in an atomic (wrt interrupt/preempt fashion) fashion. cpu ops can use a segment prefix and thus the insructions can calculate the per cpu adress and perform the atomic inc without disabling preempt or interrupts. local_t is only useful when you disable interrupt or premption otherwise. With cpu_alloc they are the same. They allocate ...

Currently the per cpu subsystem is not able to use the atomic capabilities that are provided by many of the available processors. This patch adds new functionality that allows the optimizing of per cpu variable handling. In particular it provides a simple way to exploit atomic operations in order to avoid having to disable interrupts or performing address calculation to access per cpu data. F.e. Using our current methods we may do unsigned long flags; struct stat_struct ...

Yes, but this is local_t for dynamically allocated per-cpu vars. You've lost potential symmetry and invented a whole new nomenclature :( local_ptr_inc() etc would be far preferable IMHO. Cheers, Rusty. --

Christoph, you just missed it, that's all. Look at cpu_local_read et al in include/asm-i386/local.h (ie. before the x86 mergers chose the lowest common denominator one). Cheers, Rusty. --

cpu alloc v2 had an extendable per cpu space. You have the patches. We could put this on top of this patchset if necessary. But then it not so nice and simple anymore. Maybe we can rstrict the use of cpu alloc instead to users with objects < cache_line_size() or so? --

We can always increase the sizes. --

The per cpu memory use by subsystems is typically quite small. We already have an 8k limitation for percpu space for modules. And that does not seem But then per cpu data is not frequently allocated and freed. Going away from allocpercpu saves a lot of memory. We could make this 128k or so to be safe? --

It could be 4000. The present alloc_percpu() would support that. And struct nfs_iostats is 264 bytes and nfs does an alloc_percpu() of one of those per server and mounting thousands of servers per client is, I believe, a real-world operation. Plus for the entyenth time: saying that this code will probably work acceptably for most people in 2.6.26 is not sufficient! --

Last time I took a look on this stuff, this was a percpu allocation for all connections, not for each TCP session. (It should be static, instead of dynamic ) Really, percpu allocations are currently not frequent at all. vmalloc()/vfreee() are way more frequent and still use a list. --

On Thu, 29 May 2008 23:16:11 -0700 (PDT) Could you add a text to explain "This interface is for wise use of pre-allocated limited area (see Documentation/xxxx). please use this only when you need very fast access to per-cpu object and you can estimate the amount which you finally need. If unsure, please use generic allocator." for the moment ? At first look, I thought of using this in memory-resource-controller but it seems I shouldn't do so because thousands of cgroup can be used in ...

Restricting the use of cpu_alloc based on size of object is no good when you're trying to allocate 45,000 objects. Extending the per CPU space is the only option. -- 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." --

Christoph, please. An allocator which is of fixed size and which is vulnerable to internal fragmentation is a huge problem! The kernel is subject to wildly varying workloads both between different users and in the hands of a single user. If we were to merge all this code and then run into the problems which I fear then we are tremendously screwed. We must examine this exhaustively, in the most paranoid fashion. --

In various places the kernel maintains arrays of pointers indexed by processor numbers. These are used to locate objects that need to be used when executing on a specirfic processor. Both the slab allocator and the page allocator use these arrays and there the arrays are used in performance critical code. The allocpercpu functionality is a simple allocator to provide these arrays. However, there are certain drawbacks in using such arrays: 1. The arrays become huge for large systems and may be ...

The per cpu allocator requires more per cpu space and we are already near the limit on IA64. Increase the maximum size of the IA64 per cpu area from 64K to 128K. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- include/asm-ia64/page.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6/include/asm-ia64/page.h =================================================================== --- linux-2.6.orig/include/asm-ia64/page.h 2008-05-29 12:10:42.216486476 -0700 +++ ...

Is this a USB keyboard? Might be that pressing keys before the kernel does the USB handoff from BIOS/SMI causes the BIOS to do something that screws things up.. --

This is rewritten version of memcg hierarchy handling. ...and I'm sorry tons of typos in v1. Changelog: - fixed typo. - removed meaningless params (borrow) - renamed structure members. not-for-test. just for discussion. (I'll rewrite when our direction is fixed.) Implemented Policy: - parent overcommits all children parent->usage = resource used by itself + resource moved to children. Of course, parent->limit > parent->usage. - when child's limit is set, the ...

On Fri, 30 May 2008 10:43:12 +0900 I like this idea. The alternative could mean having a page live on multiple cgroup LRU lists, not just the zone LRU and the one cgroup LRU, and drastically increasing run time overhead. Swapping memory in and out is horrendously slow anyway, so the idea of having a daemon adjust the limits on the fly should work just fine. -- All rights reversed. --

This patch tries to implements _simple_ 'hierarchy policy' in res_counter. While several policy of hierarchy can be considered, this patch implements simple one - the parent includes, over-commits the child - there are no shared resource - dynamic hierarchy resource usage management in the kernel is not necessary works as following. 1. create a child. set default child limits to be 0. 2. set limit to child. 2-a. before setting limit to child, prepare enough room in ...

Hi, Now in the GFS2 -nmw git tree. Thanks, Steve. --

No. The "only" difference between the working 2.6.23.8 kernel and the non-working one is a switch from gcc 3.4.6 to 4.1.2. I've collected some information about this issue, comparing the 'working' 2.6.23.8 kernel with a newly compiled, patched one. (The unpatched one compiled with 4.1.2 fails to boot.) So if anybody is interested, have a look at http://int-e.home.tlink.de/linux/irq/ But it's probably not worthwhile to spend a lot of time on this. Bertram --

In this case we want a constant pointer to constant chars: drivers/misc/thinkpad_acpi.c:3824:19: error: Just how const do you want this type to be? Like the error says. drivers/misc/thinkpad_acpi.c:3863:19: error: Just how const do you want this type to be? drivers/misc/thinkpad_acpi.c:3864:19: error: Just how const do you want this type to be? drivers/misc/thinkpad_acpi.c:3865:19: error: Just how const do you want this type to be? drivers/misc/thinkpad_acpi.c:3866:19: error: Just how const do ...

http://lwn.net/Articles/283161/ Barriers What minimal semantics to Filesystem developers actually want? What can hardware really provide? What how can layered mutli-disk devices (md, dm, loop) mediate these? What interface semantics can we come up with that are sufficiently general and powerful that everyone will actually implement them correctly? However I won't be coming this year, so I won't be able to participate directly in such a discussion. NeilBrown --

Hi, I haven't seen this on the list yet. CC drivers/input/serio/serio.o CC drivers/input/serio/i8042.o In file included from drivers/input/serio/i8042.h:28, from drivers/input/serio/i8042.c:85: drivers/input/serio/i8042-x86ia64io.h: In function 'i8042_platform_init': drivers/input/serio/i8042-x86ia64io.h:590: error: 'i8042_nopnp' undeclared (first use in this function) drivers/input/serio/i8042-x86ia64io.h:590: error: (Each undeclared identifier is reported ...

Thanks. I applied the second patch in that thread, and it gets past the serio.o module. I realize this is not related to serio anymore, but now it stops here, using the same config as in my previous email. This is just a general build report... I don't expect you to fix it personally. :-) I can't seem to find ieee80211_tx_control anywhere in the tree, except in pio.h. CC drivers/net/wireless/airo.o CC drivers/net/wireless/b43legacy/main.o In file included from ...

I was so excited about finally figuring out how to create and send a patch with git, that I forgot to mention that this was a warning seen in linux-next, next-20080529. It was more an experiment in how to send git patches than to "get my name in the kernel history", with which most experienced developers seem to think us newbies are only concerned. I keep hearing that testing trees and fixing warnings and small bugs is the preferred way to make it into development - so I'm giving it ...

IMHO yes... fsx w/ mmap dies quickly ( < 100 ops) without this, and survives nicely (to millions of ops+) with it in place. -Eric --

^^ is making your pc speaker your default sound device, i guess. Module is 'snd_pcsp'. --=20 Florian Attenberger <valdyn@valdyn.org>

Ok, will go do so. thanks, greg k-h --

Linus, I've now reverted one of the usb patches in this tree and pushed it out, so the new diffstat is as follows: drivers/usb/core/generic.c | 5 - drivers/usb/core/hcd.h | 2 + drivers/usb/core/hub.c | 15 ++- drivers/usb/core/quirks.c | 4 + drivers/usb/core/sysfs.c | 44 +++--- drivers/usb/gadget/fsl_usb2_udc.c | 2 + drivers/usb/host/ehci-au1xxx.c | 1 + drivers/usb/host/ehci-fsl.c | 7 +- ...

Hi Dave, Sure, I somewhat understand your concerns about the timeout change, but we responded to an email form you over a week ago and never received a reply regarding our viewpoint. It was sent to your personal email address as well as to the public linux-usb list. Please refer to the email titled "[PATCH 5/5] EHCI: fix performance regression" dated Wed, May 21, 2008 at 12:02 PM. In that email, we state that it doesn't make sense to reduce the timeout to 3ms and we still don't have a full ...

Minor fix: do not git-blame /dev/null in patches that add new files. -Andrea diff -urpN linux/whomto.orig.pl linux/whomto.pl --- linux/whomto.orig.pl 2008-05-30 09:43:08.000000000 +0200 +++ linux/whomto.pl 2008-05-30 09:49:26.000000000 +0200 @@ -101,6 +101,7 @@ sub parse_patch { for (@p) { if (m/^--- .*?\/([^\s~]*)/) { + next if ($1 eq 'dev/null'); $file = $files{$1} = { chunks => [], }; --

Thanks Andrew ... in that case I'm not going to worry about any "-next" issues for now. --

On Fri, 30 May 2008 09:52:48 -0400 I wouldn't call your home system with 4GB RAM "small". After all, the VM that Linux currently has was developed mostly on machines with less than 1GB of RAM and later encrusted in bandaids to make sure the large systems did not fail too badly. As for small system performance, I believe that my patch series should cause no performance regressions on those systems and has a framework that allows us to improve performance on those systems too. If you ...

Note: On fujitsu server(IA64 8CPU 8GB), this patch series works well 48+ hours too :) --

>>>>> "Rik" == Rik van Riel <riel@redhat.com> writes: Rik> On Thu, 29 May 2008 13:16:24 -0700 Rik> If I send you a V9 up to patch 12, you can apply Lee's patches Rik> straight over my V9 :) I haven't seen any performance numbers talking about how well this stuff works on single or dual CPU machines with smaller amounts of memory, or whether it's worth using on these machines at all? The big machines with lots of memory and lots of CPUs are certainly becoming more prevalent, but for my ...

Ah - ok - I got that reply, and then lost track of it. My bad. This doesn't make sense to me. We don't just decree that we aren't planning on supporting something that's already out there and being used, and then remove it, on the grounds we aren't supporting it. I don't plan for removing it yet, because I haven't seen a good Not yet. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson ...

Ah - that's what I missed. You're right. I withdraw this objection. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214 --

All the code is ifdefed under CONFIG_SMP. So there is no code in the !SMP case, just three masks. When you mentioned it first time I went back and rebuilt the !SMP kernel with and without the patch. Luckily I have a ridiculously fast 8way box here so I went ahead and verified it again. Before: size vmlinux text data bss dec hex filename 3305622 306420 310352 3922393 3bd9d9 vmlinux size kernel/cpu.o size: 'kernel/cpu.o': No such file After: size vmlinux ...

Hello Sam, Possibly mine didn't ... I'm getting some build errors related to static variables being initialized via htonl(), but I did a compile run with this patch. I think I used a clean kernel for testing - but maybe I was in the tree where I tested converting some "unsigned long priv;" to "void*", looking If I do a patch for them, can that be a trivial patch, or should I send each type conversion to the maintainer? Regards, Phil --

Hi, I just downloaded and tried to compile it. But I got the following error message at compile stage. I use Kubuntu-8.04 with linux-2.6.25.4-rt3 without problems. kernel/sched.c: In function 'sched_init': kernel/sched.c:7677: error: implicit declaration of function 'global_rt_runtime' make[2]: *** [kernel/sched.o] Error 1 make[1]: *** [kernel] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.25.4' make: *** [debian/stamp-build-kernel] Error 2 --

Hello, cc'ing linux-ide@vger.kernel.org ATA drives are supposed to wake up from standby on command issue and from sleep on reset. Does the drive spin up while sata_sil is trying to reset the port? Also, please post the result of 'hdparm -I /dev/sdX' where sdX is the offending drive. Thanks. -- tejun --

Hello. Patching these 15 patches fails. I think this is because the 8 patches are missing. Can I see the 8 patches? 2 out of 4 hunks FAILED -- saving rejects to file include/linux/security.h.rej 2 out of 3 hunks FAILED -- saving rejects to file include/linux/security.h.rej 2 out of 4 hunks FAILED -- saving rejects to file include/linux/security.h.rej Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] 5 out of 5 hunks ignored -- saving rejects to ...

Hi, It interfered with my stupid `remove free swap space display' series which is not yet completely in mainline (and no more in -mm). I wanted to wait until it trickled in but I think I will include the remaining patches into the generic show_mem series and send them out soon, obsoleting the old series... Remaining unpatched show_mem()s in mainline are are um, sparc, sh, m32r, alpha, sparc64 and xtensa. Hannes --

Does everything work when you unmerge this one commit? --

The MAY_* namespace is never mentioned, even though that's the one most relevant here :) Miklos --

OK by me. --b. --

From an RCU viewpoint: --

So s/hardware/platform and you are happy? -- Jens Axboe --

Uh.. We strongly want non-static functions to be documented via kernel-doc. For static functions, it's up to the maintainer/developer whether to do that or not. But if the functions already have kernel-doc, there's no strong reason to remove it. And these look good currently, so I see no good reason to change them. --- ~Randy "He closes his eyes and drops the goggles. You can't get hurt by looking at a bitmap. Or can you?" --

Right you are. Offhand, in kernel/cpuset.c, I see: static int cpuset_test_cpumask(struct task_struct *tsk, static void cpuset_change_cpumask(struct task_struct *tsk, static int update_cpumask(struct cpuset *cs, char *buf) static void cpuset_do_move_task(struct task_struct *tsk, static void move_member_tasks_to_cpuset(struct cpuset *from, struct cpuset *to) all having "/**" header comments. I would be glad to Ack a patch from you to fix such comments. Thank-you. -- ...

Well, that's some reason for your decision. At least you aren't just being arbitrary. I agree with Alan, of course. I don't think that you have stated a Good reason for removing the kernel-doc on the static functions, but it is --- ~Randy "He closes his eyes and drops the goggles. You can't get hurt by looking at a bitmap. Or can you?" --

Well, they won't clutter the generated kernel-doc docbook output unless you/we/someone requests that both non-static and static functions be listed a. I looked at those 5 functions. They should be documented, whether it's done with kernel-doc or some other way. I don't see why there would be a problem with using kernel-doc instead of something else. It might need a little tweaking. Basically what is already there says: """ !E<filename> is replaced by the documentation, in ...

Ok ... hmmm ... how to say this... The documentation in Documentation/kernel-doc-nano-HOWTO.txt of kernel-doc is mostly focused on the details of the apparatus that converts the "/**" comments into various documenation formats, and has only somewhat buried and non-inviting documentation for kernel hackers wanting the "Kernel-Doc for Dummies" summary of how and when and where to create such "/**" comments. For example, the distinction you note between: !E<filename> external ...

Ok - thank-you for the explanation. I had this vague recollection that kernel-doc was just for non-static functions, so when I saw Miao put kernel-doc comments on a static routine, I looked around to see if that was normal. I didn't see mention of static functions in kernel-doc-nano-HOWTO.txt, and in a brief survey, didn't happen to see any static functions with kernel-doc comments. However my survey was so brief I even missed five such functions in the file I maintain, kernel/cpuset.c. ...

You are certainly welcome to add kernel/cpuset.c to kernel-api.tmpl or any other --- ~Randy "He closes his eyes and drops the goggles. You can't get hurt by looking at a bitmap. Or can you?" --

Yes please, as soon as the merge window opens. Now if we could just convince you to host a full kernel tree for DRM development, with a separate, symlinked BSD dir at the top level, we'd be all set. :) Jesse --

Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> MBR, Sergei --

I have an old patch that does that, I just looked it up and it was last updated for 2.6.23. It uses fcntl() with F_SETPIPE_SZ for getting and setting the pipe size. Patch updated, the below is the current Linus kernel. diff --git a/fs/fcntl.c b/fs/fcntl.c index bfd7765..aea3f5b 100644 --- a/fs/fcntl.c +++ b/fs/fcntl.c @@ -15,6 +15,7 @@ #include <linux/smp_lock.h> #include <linux/slab.h> #include <linux/module.h> +#include <linux/pipe_fs_i.h> #include <linux/security.h> #include ...

[Ingo Molnar - Fri, May 30, 2008 at 02:54:00PM +0200] | | * Cyrill Gorcunov <gorcunov@gmail.com> wrote: | | > +extern void nmi_watchdog_default(void); | > +#else | > +#define nmi_watchdog_default(void) do {} while (0) | ^------ | | that doesnt work too well in a macro ... :-) | | Ingo | Oh my.... maybe two prerocessor passes would help? ;-) here is an updated version, please reapply, and thanks a lot for catching this Ingo! Sorry for ...

While updating the bnx2 driver on a 2.6.24.7 based rpm and after reading some of your messages... commit df7f1ed6b85b936a4dd341c48e30aa207697997c Author: Michael Chan <mchan@broadcom.com> Date: Tue Jan 29 21:38:06 2008 -0800 [BNX2]: Update firmware. Update firmware to support programmable flow control. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> After this bnx2.c would be updated to have ...

From: Benjamin Herrenschmidt <benh@kernel.crashing.org> I personally don't even like having to choose presentation topics when I go to conferences. What is interesting for me to talk about usually is changing righ up to the day or two before I travel to the event. And I think the same thing applies here. You can pick some topic now, and by the time we actually get to the summit those folks might have hashed everything out already. We should just all show up and discuss in appropriate ...

It depends how we see this. Having a lot of external contributors is very good, as it implies that more and more people are getting used to read and modify the code. What would be interesting would be to check for people who where there on a regular basis then went away, even though I admit is harder to find out. Willy --

A newcomer is motivated to fix a non-trivial bug if his own setup is seriously affected, no convenient workaround is possible, and it is clear that nobody else is gong to fix the bug (e.g. because the code is orphaned). If you have funds, you may have ways to provide better motivators than this. -- Stefan Richter -=====-==--- -=-= ====- http://arcgraph.de/sr/ --

I know some of the names on the list which seem valid, but they are still in the community at large they just aren't sending patches .. I'd imagine not many of these people are gone from Linux, they're still involved in some way. (btw, Greg KH is listed under 2.6.25 .. ) Daniel --

Unless you actually use the feature added in the first patch of the series, that enables you to build firmware images into your single netbootable image, that is ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} --

It's a bit hard, as sometimes, the topics will just show up before hand, or don't necessarily need special invite list when it's purely something Ok, if something comes to mind I will :-) The only thing at this stage would possibly be page table walking (ie, some old work I did on that to generalize the batch interface to all more-than-one-page operations such as fork, and to get rid of the per-cpu structures, and that I never fully finished, along with the mmu notifier stuff and the ...

Its my own convenience I'm serving here. I hardly ever do a local install. And for the old machines a local build just isn't even an option. It's what benh said; I just want a single netbootable image. And cross buildling initrds is just impossible - which makes the whole solution useless. --

At Thu, 29 May 2008 14:57:38 -0700, OTOH, it doesn't give you any error at build time even if you forget to put a firmware image beforehand. The kernel continues to look for a non-existing external firmware file. In the old code, this can't happen. It's just a small drawback, and I still like the idea very well, though. Takashi --

There's an interesting unspoken assumption here that people who stop contributing patches which end up in the Linux kernel mailing "no longer working on the kernel", or "no longer working in Linux", or "left the community", or (even more of a stretch) people that we have somehow driven away or that we have failed because they didnt come back. Original author of LILO, does networking research using the Linux kernel. (Has shown up and presented papers at various Still working at Red ...

Totally agree. If someone finds one bug, sends us a fix and leaves as a happy customer that is a wonderful thing. Here's the (much shorter) list of people that contributed to two consecutive releases and then disappeared. These people made at least two contributions across a 3+ month period. In most cases this moves them out of the "drive-by" category. Probably some of them moved on to do different things (or were promoted to manage people who still work on Linux). -Tony Scanning ...

Us kernel hackers tend to like self-contained netbootable kernels that have everything needed to boot a machine all the way to a shell prompt :-) David's proposal however do provides for storing the firmwares in the kernel image, so I have no objection there. Ben. --

hpa's klibc solution was cross-buildable IIRC. Jeff --

Or append it to the name of the firmware file, in some cases. -- dwmw2 --

Will this patch or the other bay/dock related patches you send in the past days allow me to undock my laptop and still be able to suspend/resume without locking the laptop up? And without having to run any userspace scripts? My dock is not a simple port replicator, it has an USB hub and an ATA bay in it. My tests showed that I need to 'echo 1 > /sys/.../scsi/.../eject' or something like that before I can take the laptop out of the docking station. If I don't do that and try to ...

Other than repeating my (possibly lost) comment that this would be vastly easier to read if the number were aligned and all had the same number of decimal places in a single column, good stuff. For sequential i/o the winners and losers are clear, and you can set cost and performance to pick the winners. Seems obvious that raid-1 is the loser for single threaded load, I suspect that it would be poor against other levels in multithread loads, but not so much for read. -- Bill Davidsen ...

[ Re that one avr32 patch: ] OK, then feel free to strip out the first chunk and just take that. - Dave --

Hi Dave- The last line suggests you are trying this with 4KB kernel stacks. I have patches queued for .27 that provide some stack relief in this code path. If you hit this often, you might want to try with 8KB stacks to see if that helps. In the meantime, the traceback is a little funky, so I can't see directly what the root cause is. Can you provide the full command line of the mount command that caused this? What "brand" of server were you trying to mount? How often can you ...

On Fri, May 30, 2008 at 11:31:48AM -0700, Trond Myklebust wrote: > On Fri, 2008-05-30 at 14:21 -0400, Dave Jones wrote: > > > mount point in the fstab is .. > > > > gelk:/mnt/data /mnt/nfs/gelk nfs nfsvers=3,tcp 0 0 > > > > > What "brand" of server were you trying to mount? > > > > It's just another linux box. A no-name core2 duo, running 2.6.25. > > > > > How often can you reproduce this? > > > > Seems to do it every time I ask it to. > > ...

This is true, partially. I saw these errors for the drivers using linux/of_gpio.h, it includes asm/gpio.h, which includes asm-generic/gpio.h (I submitted of_gpio.h patch before linux/gpio.h work, though git log might say otherwise). And yes, I should fix of_gpio.h too. The thing is, I always thought that it is _good_ practice for the nested headers to declare/define things conditionally by themselves. That way you'll not have to fix all combinations, everything will (should) just work. ...

Hello. Certainly, and you've seen it many times. :) http://bugzilla.kernel.org/show_bug.cgi?id=7491 Its that the module parameters are overriden by PNP and are ignored, so you can't do "dma=none" etc. Your patch is not for that, AFAICS. Or let me know if it is. --

Not according to this: http://www.opengroup.org/onlinepubs/009695399/functions/readdir.html "If a file is removed from or added to the directory after the most recent call to opendir() or rewinddir(), whether a subsequent call to readdir() returns an entry for that file is unspecified." --

...It is quite easy to kill a TCP flow with enough information (seqnos which one could collect e.g., from a tcpdump), just a RST is necessary, so user-space could do that too. -- i. --

On Mon, May 26, 2008 at 6:28 AM, Ilpo Järvinen Okay, but in some sense you've already bisected this somewhat. I'm assuming that your testing uses the latest tip and is refreshed daily. If that's the case, then I would (possibly naively) expect the culprit to show up in a: git log -p v2.6.26-rc1..78b58e549a3098 net/{compat.c,core,ipv4,netfilter,packet,sched,socket.c} There are only a few commits in there that appear to touch network behavior: 79d44516b4b178ffb6e2159c75584cfcfc097914 ...

It certainly has caused me to stop looking for/at them. More a sin of omission than one of commission. --- ~Randy "He closes his eyes and drops the goggles. You can't get hurt by looking at a bitmap. Or can you?" --

Oh I didn't say it breaks, the thing is I get this message once a while without it breaking, while suspend once a while breaks it (but I'm not Yeah, I tried looking at the code but didn't really find anything either. There must be something else... The thing is, nothing makes sense unless there's a bug elsewhere, because it works fine after you resume broken and reload the module. But reloading the module doesn't really do anything to the hardware, it only submits a new urb while resume ...

On Fri, 30 May 2008 14:45:33 +0300 David Woodhouse <dwmw2@infradead.org> wrote: [...] ACK Seems reasonable to me, though I wouldn't claim to be particularly authoritative on such matters these days :) Cheers, Hugh --

Hmm, linux/module.h does this too, perhaps some enthusiast can implement __concat() and use it everywhere. Cheers, Rusty. --

Then you arrived at the party a year too late. The format name/firmware is commonly used all over the kernel. How that maps to a file or directory is indeed a matter for udev, but there is already a heirarchical namespace and pretending otherwise won't help. Alan --

diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c index 3df8a66..4a28d91 100644 --- a/drivers/usb/serial/keyspan.c +++ b/drivers/usb/serial/keyspan.c @@ -105,6 +105,8 @@ #include <linux/tty_flip.h> #include <linux/module.h> #include <linux/spinlock.h> +#include <linux/firmware.h> +#include <linux/ihex.h> #include <asm/uaccess.h> #include <linux/usb.h> #include <linux/usb/serial.h> @@ -1339,13 +1341,13 @@ static void keyspan_close(struct usb_serial_port *port, ...

I think the hamster dropping code is queued for 2.6.27, so at least we're up to mammals. The story here is that in an unfortunate instance of bad planning the MFGPT timers can only be configured once, so a module can't allocate a timer at init and release it when it is done. The original object of this code was to try give the timer back to a module if it happened to go away and come back, but that is clearly a more complex process then just simply storing the module name, and this code fell ...

I was trying to compile a kernel with this support, and noticed this bug, too. The interface was changed in commit fa28e067c3b8af96c79c060e163b1387c172ae75, with the message: > We had planned to use the 'owner' field for allowing re-allocation of > MFGPTs; however, doing it by module owner name isn't flexible enough. > So, drop this for now. If it turns out that we need timers in > modules, we'll need to come up with a scheme that matches the > write-once fields of the MFGPTx_SETUP ...

-- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. --

Reviewed-by: Nadia Derbey <Nadia.Derbey@bull.net> Why are we locking the sem_undo_list: in the lookup, we are traversing Oh, I'm realizing that we should leave the routine with an rcu_read_lock? Regards, Nadia --

OK. Before 2.6.17 it wouldn't have worked much at all on MAP_SHARED modifications. After 2.6.17 things will be better - we update the mtime on the clean->dirty transitions of a page. So the first modification after an mmap will update the time. Subsequent modifications via the mmap will not update the file time. Until something (usually pdflush) writes the page out. Then the next modification via mmap will cause another clean->dirty transition on the page, hence another mtime ...

Yes, yesterday I posted some patches to do exactly that. J --

--- ~Randy "He closes his eyes and drops the goggles. You can't get hurt by looking at a bitmap. Or can you?" --

I'd say the first thing to do is understand the sequence of ptrace calls, wait results seen by the ptracer, and the ptrace_stop() path, in your test case. Compare that on x86 and ia64, where the behavior you see differs. When you pinpoint the difference in that sequence, we will have some sense of what it is that really matters to your test. Thanks, Roland --

How fair does smp fairness look for a !group scenario? I don't expect group schould be able to do much better. -- regards, Dhaval --

In fact stores to non-cacheable locations have to be kept in order, according to the Power architecture. But you're correct in that non-cacheable loads can in principle be reordered w.r.t. each other Indeed. Paul. --

On Fri, 30 May 2008 17:24:27 +1000 Right, I sort of suspected that. Now, I'm pretty sure the architectures that can actually run those drivers (ARM9 and AVR32 AP7) provide stronger guarantees than that, and I suspect the same is true on most other embedded architectures that use __raw_* in their drivers. So I don't think adding barriers is the right thing to do because they won't do anything useful in practice, so it's hard to tell whether they are used "correctly". And it will ...

The byte swapping depends on the device/bus. So what happened to the old idea of putting the accessor function pointers in the device/bus structure? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds --

Hmmm, I think mmiowb() does some sort of status read from the bridge, I am not sure if it's enough to just do a regular readl(). I'm adding Jeremy to the list, he should know for sure. Cheers, Jes --

Only to the same address I'd say. Ben. --

I could be getting bits wrong, but multi-path here is in the NUMA That would kill all levels of performance in all drivers, resulting in attempts to try and modify a fair bit of drivers to get the performance back. In reality this problem really only exists for devices where ordering of consecutive writel's is a big issue. In my experience it really isn't the case very frequently - and the number of mmiowb's that have put in shows that too :-) Cheers, Jes --

We also need to remove the instance of #ifdef CONFIG_something which David sneaked in to <linux/a.out.h>. And make a 'headers_check' test for it :) -- dwmw2 --

Hey, it takes time to locate all the thousands of copyright holders and request their license to be reinstated after the automatic termination in GPLv2! :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} --

It sounds like I got off lightly - I simply contacted them via their support email address (to which I've still received no reply), then followed up a few days later by going to the tech press in an effort to embarrass them into action. An associate also bought a card to determine whether their infringing kernel image is on the driver CD as well as the website, but the CD hasn't been looked at yet. I suppose it doesn't make much difference now, and given they've publicly acknowledged the ...

Well, with that ringing endorsement :) I would like to state that Yoshihiro Ishijima has fixed some bugs in beforeafter and it will now deal with /proc/interrupts output better than before. ftp://ftp.cup.hp.com/dist/networking/tools/ rick jones --

Actually, the cleanup patches which I'm asking Michael to base his patches on were not NAKed. And Michael is not even working against the vfs-cleanups tree, but rather just a couple of these utimes cleanup patches, none of which are controversial like the path_* stuff. But even if he was working against the vfs-cleanups tree it wouldn't matter, since porting Do please tell me how else should I work? I post patches for review, gradually, not as a 100 patch series, when we manage to ...

Oh, come on. Where in my last mail did I say that these fixes shouldn't be applied? I was only objecting to putting a fix and an independent cleanup (which by now I realized was not such a good idea) into a single patch. Miklos --

Ugh... Could we just omit this part (the if !times and write error then check owner)? I know it was my idea, but a) my ideas are often stupid b) one patch should ideally do just one thing After we fixed the original issue, we can still think about this other Sure, but so could a write(2), so that doesn't seem such a big problem. I think we should leave it this way, since changing it would affect not just utimensat() and futimesat() but utime() and utimes() as well, which are well ...

Hi Miklos, Here's a further version of the patch, against 2.6.26rc2, with the 2008-05-19 git changes you sent me applied. This patch is based on the draft patch you sent me. I've tested this version of the patch, and it works as for all cases except the one mentioned below. But note the following points: 1) I didn't make use of the code in notify_change() that checks IS_IMMUTABLE() and IS_APPEND() (i.e., I did not add ATTR_OWNER_CHECK to the mask in the controlling if statement). Doing ...

Miklos, You omitted to answer my question, the last sentence below: On Fri, May 30, 2008 at 8:24 PM, Michael Kerrisk Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html --

Well, I'd fear that hlt instruction in idle loop would be the one interrupted most. But low bits of tsc at timer interrupt would be fine entropy source. ..actually, bogomips varies a bit between boots, maybe we should hash it into the pool? Maybe we could even redo bogomips calculation at runtime and use low bits as random numbers? :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

[Empty message]

It gets uglier. ALSA ISA drivers (for cards that exist both as legacy and as ISAPnP at least) keep a merged legacy/isapnp model; PnP is used mostly for initializing global variables that the same old legacy probe routines then reference. This means that beyond that global resource init step the specific struct device is no longer available. Without restructuring too many things really only fixable through other hacks again such as a global dma_dev[] array or some such. From the ...

Looks good to me. It does sound like a lot of work and possibly more risk than it's worth to fix up some of this stuff. I do still wonder whether any non-x86 architectures need similar fixes in dma_alloc_coherent(), i.e., check for dev==NULL and fall back to a 24-bit DMA mask. Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com> --

On 30-05-08 23:15, Rene Herman wrote: ... this note by the way I believe pnp_dev might as well get rid of its dma_mask as well. As far I've googled up the history of that the reason why dev->dma_mask is a pointer is only that it's been moved into struct device from struct pci_dev where the latter location was kept as the main one so as to not upset then current code. Everyone else seems to have then faithfully cloned pci_dev and stuck it in their private structs as well but for no good ...

From: Matheos Worku <Matheos.Worku@Sun.COM> Ahh I see. Some of the things I talked about in my presentation here in Berlin at LinuxTAG yesterday can help mitigate the effects. Most of it revolves around batching, and allowing the driver to manage the backlog of packets directly when the TX queue fills up. In such a case we could batch the TX queue refill, know how many more TX packets we will queue up to the chip right now, and therefore know that we can safely set periodic MARK bits and ...

--

--

--

--

I guess in my case, next Tuesday was not an issue. :-/ Anyway, the idr.c changes look good to me. Not sure why you are using INIT_RCU_HEAD() given that call_rcu() completely initializes the fields. Using INIT_RCU_HEAD() doesn't cause any problems, but does add needless code. Commentary below, looks good from an RCU viewpoint. OK, we aren't dereferencing. Besides, we should hold the update-side --

--

Triggered second time with 2.6.24-rc4. FWIW, workload was LTP in infinite loop + parallel compiling on 170 configs with make O=../ on ext2 --

This needs to be upgraded to an smp_mb() because we have a write followed In absence of these two changes, either compiler or CPU could reorder the accesses to ioc_gone on the one hand and to ioc_count on the other, which could result in a hang, for example, cfq_exit() might see the reader's old count, but the reader might fail to see the assignment to ioc_gone. Thanx, Paul --

Hello Greg, If Hans did that, I didn't notice it. If you want to take the patches from me you can pull them from my uio branch at git://www.modarm9.com/gitsrc/pub/people/ukleinek/linux-2.6.git uio These have the Signed-off-by: by Hans, too. Best regards Uwe -- Uwe Kleine-König, Software Engineer Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962 --

Hi Satoshi, I'm testing your patch agains latest Linus git and I've got the following bug. It can be easily reproduced creating a cgroup, switching the i/o scheduler from cfq to any other and switch back to cfq again. -Andrea BUG: unable to handle kernel paging request at ffffffeb IP: [<c0212dc6>] cfq_cgroup_sibling_tree_add+0x36/0x90 Oops: 0000 [#1] SMP Modules linked in: i2c_piix4 ne2k_pci 8390 i2c_core Pid: 3543, comm: bash Not tainted (2.6.26-rc4 #1) EIP: 0060:[<c0212dc6>] ...

Hello, So, sans NCQ, the only remaining issue is MSI, right? Peer Chen, please lemme know which controllers are affected by this MSI problem and where The controller is not reporting NCQ capability in its cap register (flags: line contains ncq if the controller is), so NCQ is not enabled. Thanks. -- tejun --

Thanks. I noticed this yesterday and have sent Andrew updated patch to replace the one he just added to mm tree but forget to copy to the list. Here is the updated patch, Mingming --- fs/jbd2/transaction.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 58 insertions(+), 3 deletions(-) Index: linux-2.6.26-rc4/fs/jbd2/transaction.c =================================================================== --- linux-2.6.26-rc4.orig/fs/jbd2/transaction.c 2008-05-29 ...