Hi Greg, While playing with hotplug memory remove on 2.6.24-mm1, I noticed that /sysfs directory entries are not getting removed. sysdev_unregister() used to call kobject_unregister(). But in 2.6.24-mm1, its only dropping the ref. It should call kobject_del() to remove the object. Correct ? With this change, the directories are getting removed correctly. Comments ? Thanks, Badari sysdev_unregister() should call kobject_del() to remove the object. Signed-off-by: Badari Pulavarty ...

Some led hardware allows drivers to query the led state, and this patch adds a hook to let the led class take advantage of that information when available. Without this functionality, when access to the led hardware is not exclusive (i.e. firmware or hardware might change its state behind the kernel's back), reality goes out of sync with the led class' idea of what the led is doing, which is annoying at best. Behaviour for drivers that do not or cannot read the led status ...

Add a sysfs led class interface to the thinklight (light subdriver). Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Richard Purdie <rpurdie@rpsys.net> --- Documentation/thinkpad-acpi.txt | 25 ++++++++++++++++++++----- drivers/misc/thinkpad_acpi.c | 39 ++++++++++++++++++++++++++++++++++++++- 2 files changed, 58 insertions(+), 6 deletions(-) diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt index 204161e..0301394 100644 --- ...

Commit 14e0cb3c60b89c4a2512852ffc18601c72314a0f broke frv compilation: <-- snip --> ... CC arch/frv/kernel/asm-offsets.s In file included from include/asm/system.h:271, from include/asm/bitops.h:19, from include/linux/bitops.h:17, from include/linux/kernel.h:15, from include/linux/sched.h:52, from arch/frv/kernel/asm-offsets.c:7: include/asm-generic/cmpxchg-local.h: In function ...

yes, it's in my batch of fixes. thanks for the reminder. cheers, kyle --

<big sigh of relief> So I do not have to worry about it? --

3062fc67 introduced far too many build errors for the convenience it allows. It's not even always necessary to rcu deference mm->mem_cgroup in the first place, so we'll use it on a case by case basis. Signed-off-by: David Rientjes <rientjes@google.com> --- include/linux/memcontrol.h | 13 ------------- mm/memcontrol.c | 2 +- mm/rmap.c | 6 ++++-- 3 files changed, 5 insertions(+), 16 deletions(-) diff --git a/include/linux/memcontrol.h ...

Hi Ingo, I'm starting with you because the first file I used to experiment with this idea was arch/x86/ia32/sys_ia32.c. I found it strange that the struct sk_buff definition was found inside the DWARF debugging sections in the generated object, so I verified and found that there is no need for the files that bring struct sk_buff definition into this file and verified also that sk_buff is not brought in indirectly too, thru other headers. I went on and removed many other unneeded ...

But powerpc is subtle and I foresee that we have to kill __devinitconst and friends soonish. The problem is that despite data being const the compiler does not always mark the section const. So we will see a lot of the errors you see for powerpc now that we unconditionally specify a section. Previously this inconsistentcy were hidden by the fact that powerpc tagets seldom were build without CONFIG_HOTPLUG=y. So the patches are correct. Tomorrow I hope to do a patch that kill ...

Hi, I have the same problem with my Thinkpad T60. root@zorro:~# ping arnold PING arnold (192.168.158.6) 56(84) bytes of data. 64 bytes from arnold (192.168.158.6): icmp_seq=1 ttl=64 time=49.7 ms 64 bytes from arnold (192.168.158.6): icmp_seq=2 ttl=64 time=0.438 ms 64 bytes from arnold (192.168.158.6): icmp_seq=3 ttl=64 time=1000 ms 64 bytes from arnold (192.168.158.6): icmp_seq=4 ttl=64 time=0.970 ms 64 bytes from arnold (192.168.158.6): icmp_seq=5 ttl=64 time=885 ms 64 bytes from arnold ...

From: Tony Breeds <tony@bakeyournoodle.com> Commit ad7f71674ad7c3c4467e48f6ab9e85516dae2720 corrected the clock resolution reported by the VDSO clock_getres() but introduced another problem in that older versions of gcc (gcc-4.0 and earlier) fail to compile the new code in arch/powerpc/kernel/asm-offsets.c. This fixes it by introducing a new MONOTONIC_RES_NSEC define in the generic code which is equivalent to KTIME_MONOTONIC_RES but is just an integer constant, not a ktime ...

Commit 6e16d89bcd668a95eb22add24c02d80890232b66 Sanitize the type of struct user.u_ar0 struct user.u_ar0 is defined to contain a pointer offset on all architectures in which it is defined (all architectures which define an a.out format except SPARC.) However, it has a pointer type in the headers, which is pointless -- <asm/user.h> is not exported to userspace, and it just makes the code messy. Redefine the field as "unsigned long" (which is the same size ...

CONFIG_COMPAT_BRK=y means that heap randomization is turned off, so it's *always* a safe choice. I assume the help text is trying to say that if one does not run ancient binaries, then enabling heap randomization is safe. Signed-off-by: Roland Dreier <rolandd@cisco.com> --- diff --git a/init/Kconfig b/init/Kconfig index 95ac265..242ce32 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -565,7 +565,7 @@ config COMPAT_BRK disabled, and can be overriden runtime by setting ...

See? It even has completely useless help text. Does WMI stand for Windows Management Instrumentation? It is some server management feature? What is it good for? Pavel WMI (EXPERIMENTAL) (ACPI_WMI) [N/m/y/?] (NEW) ? This driver adds support for the ACPI-WMI mapper device (PNP0C14) found on some systems. NOTE: You will need another driver or userspace application on top of this to actually use anything defined in the ACPI-WMI mapper. -- (english) ...

I have a very long list of Acer laptops that are supported - which is far too long, and changes on far too much of a regular basis to put in there. Perhaps adding something like "This driver is also a required dependency to build the firmware specific drivers needed for many laptops, including Acer and HP machines"? (There's currently another ACPI-WMI based driver in development related to more HP laptops, and acer-wmi also supports a handful of non-Acer laptops). I don't think ...

In plain English? ACPI-WMI is a nasty hack/ abuse of ACPI by Microsoft to force their driver model into ACPI, and that should be thoroughly discouraged from further use. However, since quite a few laptop vendors rely on it for basic functionality, we have to implement it (or a part of it) as well. Yes, WMI itself is supposed to be an instrumentation/ management thing, as well as, if I understand, part of their driver model, and ACPI-WMI is a part of that - by and of itself though, ...

Following patch introduce HAVE_IDE to support flexible per arch or even per. sub-arch configuration of IDE support. This patch is needed to allow arm to use the generic drivers/Kconfig file. Introducing HAVE_IDE so each arch explicit select HAVE_IDE if supported allowed us to get rid of HAS_IOMEM which is anyway overloaded. And doing it this way is a much better way to document which architectures that supports IDE. Furthermore the decision if IDE is supported or not ...

Hi, With a lot of help from Ingo Molnar and Pekka Enberg over the last couple of weeks, we've been able to produce a new version of kmemcheck! General description: kmemcheck is a patch to the linux kernel that detects use of uninitialized memory. It does this by trapping every read and write to memory that was allocated dynamically (e.g. using kmalloc()). If a memory address is read that has not previously been written to, a message is printed to the kernel log. Changes since v2: - Don't ...

Applies on top of kmemcheck patch. Fixes/silences some reports of use of uninitialized memory. From: Ingo Molnar <mingo@elte.hu> Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com> diff --git a/include/asm-generic/siginfo.h b/include/asm-generic/siginfo.h index 8786e01..b70cd97 100644 --- a/include/asm-generic/siginfo.h +++ b/include/asm-generic/siginfo.h @@ -278,11 +278,19 @@ void do_schedule_next_timer(struct siginfo *info); static inline void copy_siginfo(struct siginfo *to, ...

Ok, then I think we are still talking about different things :-) The tracking that kmemcheck does is actually a byte-for-byte tracking of whether memory has been initialized or not. Think of it as valgrind for the kernel. We do this by "hiding" pages (marking them non-present for for MMU) and taking the page faults, which effectively tells us what memory is being attempted to be read from or written to. (This generally means that the tracking that kmemcheck does is page-granular, but we can ...

I just re-downloaded an re-patched and re-compiled (with gcc 4.2.3), and now the kernel boots. I must have screwed up the previous patching. It now works, with Fujita's patch applied. -- Hilsen Harald --

Ok, I was wrong. The code really *does* compile to that insane a3 14 00 00 00 mov %eax,0x14 by your compiler. That's the asc_dvc_varp->overrun_buf = kzalloc(ASC_OVERRUN_BSIZE, GFP_KERNEL); thing, and gcc seems to have decided that it can statically prove that asc_dvc_varp is NULL. Quite frankly, I don't see that being true. But you have some patches in your tree that I haven't followed, so.. Are you sure the patches applied to the right spot? The patch I saw ...

-add documentation about pr_debug kernel-parameters.txt Signed-off-by: Jason Baron <jbaron@redhat.com> --- Documentation/kernel-parameters.txt | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index cf38689..6d524bb 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1494,6 +1494,11 @@ and is between 256 and 4096 characters. It is defined in ...

-add /proc/sys/debug/pr_debug, to toggle pr_debug() on/off Signed-off-by: Jason Baron <jbaron@redhat.com> --- kernel/sysctl.c | 41 +++++++++++++++++++++++++++++++++++++++++ 1 files changed, 41 insertions(+), 0 deletions(-) diff --git a/kernel/sysctl.c b/kernel/sysctl.c index 7cb1ac3..73508d7 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -155,6 +155,11 @@ static int proc_do_cad_pid(struct ctl_table *table, int write, struct file *filp static int proc_dointvec_taint(struct ...

-make pr_debug() dynamic so it can be switched on/off. The off state is implemented on top of the immediate infrastructure, so as to promote more dynamic printing and debugging. depends on CONFIG_HAVE_IMMEDIATE and CONFIG_PRINTK Signed-off-by: Jason Baron <jbaron@redhat.com> --- include/linux/kernel.h | 10 ++++++++++ init/Kconfig | 5 +++++ kernel/printk.c | 17 +++++++++++++++++ 3 files changed, 32 insertions(+), 0 deletions(-) diff --git ...

What's wrong with klogd -c 8 or equivalent? --

On Thursday 03 January 2008, Robert Hancock wrote: Cc: Robert Hancock <hancockr@shaw.ca> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/ide.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) Index: b/drivers/ide/ide.c =================================================================== --- a/drivers/ide/ide.c +++ b/drivers/ide/ide.c @@ -44,8 +44,6 @@ * inspiration from lots of linux users, esp. hamish@zot.apana.org.au */ ...

include/linux/mmzone.h:640:22: warning: potentially expensive pointer subtraction The code in question was doing a pointer subtraction to find the index of the zone argument in the node_zones array. This essentially boils down to: ((unsigned long)zone - (unsigned long)zone->zone_pgdat->node_zones)/sizeof(struct zone) Which can be expensive if struct zone is not a power of two. Instead, just calculate the offsets rather than the index in the array. Signed-off-by: Harvey Harrison ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Pekka J Enberg <penberg@cs.helsinki.fi> [ Upstream commit: 556a169dab38b5100df6f4a45b655dddd3db94c1 ] If the node we're booting on doesn't have memory, bootstrapping kmalloc() caches resorts to fallback_alloc() which requires ->nodelists set for all nodes. Fix that by calling set_up_list3s() for CACHE_CACHE in kmem_cache_init(). As kmem_getpages() is called with GFP_THISNODE set, ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Stephen Hemminger <shemminger@linux-foundation.org> patch a7bffe722c996679b4fb2103ecaf673ec2b9b4a7 in mainline. If the sky2 deadman timer forces a recovery, the multicast hash list is lost. Move the call to sky2_set_multicast to the end of sky2_up() so all paths that bring device up will restore multicast. Signed-off-by: Stephen Hemminger ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Ayaz Abdulla <aabdulla@nvidia.com> patch 2b91213064bd882c3adf35f028c6d12fab3269ec in mainline. This patch is a critical fix for MCP77 and MCP79 devices. The feature flags were missing the define for correct mac address (DEV_HAS_CORRECT_MACADDR). Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: David S. Miller ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Stefan Bader <stefan.bader@canonical.com> The device setup did miss to initialize the num_interrupt_out field, thus failing to successfully complete the probe function. Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Cc: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/usb/serial/kobil_sct.c | 1 + 1 file changed, 1 ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Damien Stuart <dstuart@dstuart.org> This simply adds the "YC Cable" as a vendor and its pl2303-based USB<->Serial adapter as a product. This particular adapter is sold by Radio Shack. I've done limited testing on a few different systems with no issues. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/usb/serial/pl2303.c | 1 + drivers/usb/serial/pl2303.h | 3 ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Stephen Smalley <sds@tycho.nsa.gov> patch b1aa5301b9f88a4891061650c591fb8fe1c1d1da in mainline. The proc net rewrite had a side effect on selinux, leading it to mislabel the /proc/net inodes, thereby leading to incorrect denials. Fix security_genfs_sid to ignore extra leading / characters in the path supplied by selinux_proc_get_sid since we now get "//net/..." rather than ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Oliver Neukum <oliver@neukum.org> this function will run in the context of the scsi error handler thread. It must use GFP_NOIO instead of GFP_KERNEL to avoid a possible deadlock. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/usb/core/hub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Nate Carlson <natecars@natecarlson.com> I've got a Dell wireless 5520 card with a different USB ID - specifically, 8136 instead of 8137. Attached a small patch to add support, and the output of an 'ati3'. If we could get this in, that'd be sweet. ;) Thanks! nc@knight:~/tmp/linux-2.6.24-rc8/drivers/usb/serial$ lsusb | grep 8136 Bus 001 Device 005: ID 413c:8136 Dell Computer ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Daniel Kozák <kozzi11@gmail.com> Remove entry for Huawei E620 UMTS/HSDPA card (ID: 12d1:1001) in pl2303 driver Option driver is use instead Signed-off-by: Daniel Kozák <kozzi11@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/usb/serial/pl2303.c | 1 - drivers/usb/serial/pl2303.h | 4 ---- 2 files changed, 5 deletions(-) --- ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Michael Buesch <mb@bu3sch.de> patch 8dd0100ce9511e52614ecd0a6587c13ce5769c8b in mainline. This fixes four resource leakages. In any error path we must deallocate the DMA frame slots we previously allocated by request_slot(). This is done by storing the ring pointers before doing any ring allocation and restoring the old pointers in case of an error. Signed-off-by: Michael Buesch ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Michael E Brown <Michael_E_Brown@dell.com> patch 7d640c4a5b36c4733460065db1554da924044511 in mainline. This reverts commit 109f0e93b6b728f03c1eb4af02bc25d71b646c59. The original patch breaks BIOS updates on all Dell machines. The path to the firmware file for the dell_rbu driver changes, which breaks all of the userspace tools which rely on it. Note that this patch re-introduces a ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Alan Cox <alan@lxorguk.ukuu.org.uk> If we get a data URB back from the hardware after we have put the tty to bed we go kaboom. Fortunately all we need to do is process the URB without trying to ram its contents down the throat of an ex-tty. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/usb/serial/keyspan.c | 2 +- 1 ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Jessica L. Blank <j@twu.net> Adds the appropriate vendor and device IDs for the AirCard 881U to sierra.c. (This device is often rebadged by AT&T as the USBConnect 881). Signed-off-by: Jessica L Blank <j@twu.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/usb/serial/sierra.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/usb/serial/sierra.c +++ ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Nick Piggin <npiggin@suse.de> Drivers that register a ->fault handler, but do not range-check the offset argument, must set VM_DONTEXPAND in the vm_flags in order to prevent an expanding mremap from overflowing the resource. I've audited the tree and attempted to fix these problems (usually by adding VM_DONTEXPAND where it is not obvious). Signed-off-by: Nick Piggin ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Nick Piggin <nickpiggin@yahoo.com.au> patch 124d3b7041f9a0ca7c43a6293e1cae4576c32fd5 in mainline. Frederik Himpe reported an unkillable and un-straceable pan process. Zero length iovecs can go into an infinite loop in writev, because the iovec iterator does not always advance over them. The sequence required to trigger this is not trivial. I think it requires that a zero-length ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Stefano Brivio <stefano.brivio@polimi.it> patch 0cd67d48b519c3d8d89d238fab1cf68a5289638a in mainline. Fix the crash reported below, which seems to happen on bcm4306 rev. 2 devices only while using PIO: Oops: 0000 [#1] PREEMPT Modules linked in: b43(F) rfkill(F) led_class(F) input_polldev(F) arc4 b43legacy mac80211 cfg80211 i915 drm snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Peter Stark <Peter.Stark@t-online.de> I work with a group of people on a free home automation tool called FHEM. Some of the users own more than one USB-serial device by ELV. The ftdi_sio driver has most of the ELV devices disabled by default and needs to be re-enabled every time you get a new kernel. Additionally a new device (EM 1010 PC - enegry monitor) is missing in the ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Kevin Lloyd <linux@sierrawireless.com> The following improvements were made: - Added new product support: MC5725, AC 880 U, MP 3G (UMTS & CDMA) Signed-off-by: Kevin Lloyd <linux@sierrawireless.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/usb/serial/sierra.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/drivers/usb/serial/sierra.c +++ ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Stefano Brivio <stefano.brivio@polimi.it> patch 8dd0100ce9511e52614ecd0a6587c13ce5769c8b in mainline. This fixes four resource leakages. In any error path we must deallocate the DMA frame slots we previously allocated by request_slot(). This is done by storing the ring pointers before doing any ring allocation and restoring the old pointers in case of an error. This patch by Michael ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Jan Andersson <jan@gaisler.com> usbtest did not swap the received status information when checking for a non-zero value and failed to discover halted endpoints on big endian systems. Signed-off-by: Jan Andersson <jan@gaisler.com> Acked-by: David Brownell <david-b@pacbell.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/usb/misc/usbtest.c | 1 + 1 file ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Michael Buesch <mb@bu3sch.de> patch 09552ccd8277e6382097e93a40f7311a09449367 in mainline We must drop any packets we are not able to encrypt. We must not send them unencrypted or with an all-zero-key (which basically is the same as unencrypted, from a security point of view). This might only trigger shortly after resume before mac80211 reassociated and reconfigured the keys. It is ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Stephen Hemminger <shemminger@linux-foundation.org> patch 82637e808478087ce861129745fa60cc37e7929d in mainline This patch disables config mode access after clearing PCI settings. Without this change WOL won't work on some BIOS's Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/net/sky2.c | 9 ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Oleg Nesterov <oleg@tv-sign.ru> patch 8a459e44ad837018ea5c34a9efe8eb4ad27ded26 in mainline. Fix ->vm_file accounting, mmap_region() may do do_munmap(). Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: ...

2.6.24-stable review patch. If anyone has any objections, please let us know. ------------------ From: Michael Buesch <mb@bu3sch.de> (not in mainline, as it is not applicable.) We must reject new incompatible firmware early to avoid running into strange transmission failures. The current development tree supports newer firmware revisions. These revisions cause strange failures on the stable 2.6.24 kernel. Add a check to avoid confusing users a lot. Signed-off-by: Michael Buesch ...

Probe port _after_ it is fully initialized. Cc: Anton Salnikov <asalnikov@ru.mvista.com> Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/arm/palm_bk3710.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) Index: b/drivers/ide/arm/palm_bk3710.c =================================================================== --- a/drivers/ide/arm/palm_bk3710.c +++ b/drivers/ide/arm/palm_bk3710.c @@ ...

Even better is to move the update outside the function. What do we think of the following? From d667a08d73cd6659219d21cc57f67882f46e42d1 Mon Sep 17 00:00:00 2001 From: Joel Becker <joel.becker@oracle.com> Date: Thu, 7 Feb 2008 14:25:11 -0800 Subject: [PATCH] ocfs2: Clean up locking protocol negotiation. The comparison functions for protocol negotiation (introduced in commit d24fbcda0c4988322949df3d759f1cfb32b32953) were confusing. Separate out the comparison and value update ...

On Thu, 7 Feb 2008 12:09:44 -0800 It's somewhat obnoxious that what appears to be a straightforward compare-two-things-and-return-result function will actually modify one of the things which it is allegedly comparing. Please integrate checkpatch into your processes - this one had a few little glitches. --

It went through my tree. Paul pulls from Josh Boyer's tree for powerpc-4xx patches, and Josh pulls from mine for xilinx virtex powerpc 405 patches. My screw up, sorry I broke the rules. What is the best way to resolve this? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --

Yup, should... [I don't know how ofter people have 64bit resources on 32 bit this becomes a problem.] --

For MMIO it's becoming more and more common actually in the embedded space. Xilinx uses 405 cores which I think still only have a 32 bits physical bus though, but if they ever extend it or switch to 440 they'll have a 36 bits bus. Ben. --

No, it's correct. If you look deeper, you'll see (in gitk, or using "--pretty=fuller") that it has: Author: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> Commit: Grant Likely <grant.likely@secretlab.ca> which means that the sign-off chain is complete and matches: Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> ie it was written by Stephen, and then committed by Grant, and ...

On Thu, 07 Feb 2008 21:08:50 +0100 Never seen it before in my life. Can't find any references to it in any of the mailing lists. I ended up googling the changelog text for a whopping three hits and it appears that this change went into the powerpc patch system (http://patchwork.ozlabs.org/linuxppc/patch?id=16712) How it got from there into Linux is also a mystery. I see a batch of powerpc updates just went into mainline but I don't know whose tree was pulled - I wasn't copied on any pull ...

They should actually be resource_size_t :-) Ben. --

Hi, first of all, I think that the driver should go through lkml before upstream merge or at least be in -mm for a while (I think this used to be a rule some time ago), correct me if I'm wrong, but none of it happened. Few comments I have: - release f_op retval is silently ignored, I guess you will get your device into undefined state when the first function fails (esp. when you interrupt the sem) - semaphores are deprecated - class_device_create is deprecated - module_init/exit ...

Hmmm, if that's the rule then I apologize. I had thought that arch specific drivers were okay (assuming not part of a common subsystem like USB, Eth, etc). The driver went through a number of review cycles on the linuxppc mailing list and the comments had settled down. I didn't see any problem in merging it as it is a platform specific driver only used by the Xilinx Virtex chips. It is only used by arch/powerpc and only when CONFIG_XILINX_VIRTEX is selected. Linus has already pulled ...

On Thu, 7 Feb 2008 13:35:09 -0800 We're all still trying to figure it out, really. We've gone and made it awfully easy to get code into the kernel nowadays. Perhaps too easy. I'm presently having a little campaign of watching what's going on a bit more closely, and ecouraging people to make it easier for others to see what's going on, should they choose to do so. I'm hoping that by the time we're developing 2.6.26 there will be a unified git tree (aka linux-next) (basically all the git and ...

the sem) Hmm.. hadn't realized that. I'm open to suggestions on how to do this better. The real reason why the synchronization is there is to make sure that only one client is using the device at a time, using the The physical device only generates/accepts complete words, the intention is to account for the possibility that a read does not read complete words, and to fulfill the read whenever possible. It's arguable that read() and write() should not accept or return no idea. even ...

The Virtex5 has a 440. It's going to be released "real soon now" g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --

My apologies, those mailing list postings there haven't hit my inbox yet. -- paul moore linux security @ hp --

aka: nfsv4-MAXNAME-fix.patch From: J. Bruce Fields <bfields@citi.umich.edu> Date: Fri, 28 Sep 2007 16:45:51 -0400 Subject: knfsd: query filesystem for NFSv4 getattr of FATTR4_MAXNAME References: 271803 Patch-mainline: 2.6.24 (likely) mainline: a16e92edcd0a2846455a30823e1bac964e743baa Without this we always return 2^32-1 as the the maximum namelength. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Andreas Gruenbacher <agruen@suse.de> CC: Oliver Pinter ...

aka: nfs-name-len-limit.patch Patch-mainline: 2.6.23 References: 325913 GIT: 54af3bb543c071769141387a42deaaab5074da55 Mon Sep 17 00:00:00 2001 From: Trond Myklebust <Trond.Myklebust@netapp.com> Date: Fri, 28 Sep 2007 12:27:41 -0400 Subject: [PATCH] NFS: Fix an Oops in encode_lookup() mainline: 54af3bb543c071769141387a42deaaab5074da55 It doesn't look as if the NFS file name limit is being initialised correctly in the struct nfs_server. Make sure that we limit whatever is being set ...

aka: nfsacl-retval.patch From: J. Bruce Fields <bfields@citi.umich.edu> Date: Fri, 2 Nov 2007 15:36:08 -0400 Subject: [PATCH] knfsd: fix spurious EINVAL errors on first access of new filesystem References: 340873 mainline: ac8587dcb58e40dd336d99d60f852041e06cc3dd The v2/v3 acl code in nfsd is translating any return from fh_verify() to nfserr_inval. This is particularly unfortunate in the case of an nfserr_dropit return, which is an internal error meant to indicate to callers that this ...

aka: via-velocity-dont-oops-on-mtu-change-1.patch From: Stephen Hemminger <shemminger@linux-foundation.org> Date: Thu, 15 Nov 2007 03:47:27 +0000 (-0800) Subject: [VIA_VELOCITY]: Don't oops on MTU change. Patch-mainline: v2.6.24-rc3 References: 341537 [VIA_VELOCITY]: Don't oops on MTU change. mainline: bd7b3f34198071d8bec05180530c362f1800ba46 Simple mtu change when device is down. Fix http://bugzilla.kernel.org/show_bug.cgi?id=9382. Signed-off-by: Stephen Hemminger ...

It's possible that the caller of sysfs_remove_group messed up and passed in an attribute group that was not really registered to this kobject. But don't panic for such a foolish error, spit out a warning about what happened, and continue on our way safely. Cc: Roland Dreier <rdreier@cisco.com> Cc: Tejun Heo <htejun@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- fs/sysfs/group.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/fs/sysfs/group.c ...

From: Michael E Brown <Michael_E_Brown@dell.com> This reverts commit 109f0e93b6b728f03c1eb4af02bc25d71b646c59. The original patch breaks BIOS updates on all Dell machines. The path to the firmware file for the dell_rbu driver changes, which breaks all of the userspace tools which rely on it. Note that this patch re-introduces a problem with i2c name collision that was previously fixed by this patch. Signed-off-by: Michael E Brown <michael_e_brown@dell.com> Signed-off-by: Greg ...

aka: pci-fix-unterminated-pci_device_id-lists.patch From: Kees Cook <kees@ubuntu.com> Date: Wed, 19 Sep 2007 05:46:32 +0000 (-0700) Subject: pci: fix unterminated pci_device_id lists Patch-mainline: 2.6.23-rc7 References: 340527 Git-commit: h=248bdd5efca5a113cbf443a993c69e53d370236b pci: fix unterminated pci_device_id lists mainline: 248bdd5efca5a113cbf443a993c69e53d370236b Fix a couple drivers that do not correctly terminate their pci_device_id lists. This results in garbage being ...

aka: i386-fixup-TRACE_IRQ-breakage.patch From: Peter Zijlstra <peterz@infradead.org> Date: Wed, 18 Jul 2007 18:59:22 +0000 (+0200) Subject: i386: fixup TRACE_IRQ breakage Patch-mainline: 2.6.23-rc1 References: 326270, CVE-2007-3731 i386: fixup TRACE_IRQ breakage mainline: a10d9a71bafd3a283da240d2868e71346d2aef6f The TRACE_IRQS_ON function in iret_exc: calls a C function without ensuring that the segments are set properly. Move the trace function and the enabling of interrupt into the ...

aka: cciss-panic-in-blk_rq_map_sg.patch From a683d652d334a546be9175b894f42dbd8e399536 Mon Sep 17 00:00:00 2001 From: Lee Schermerhorn <Lee.Schermerhorn@hp.com> Date: Fri, 21 Sep 2007 08:33:55 +0200 Subject: [PATCH] Panic in blk_rq_map_sg() from CCISS driver mainline: a683d652d334a546be9175b894f42dbd8e399536 New scatter/gather list chaining [sg_next()] treats 'page' member of struct scatterlist with low bit set [0x01] as a chain pointer to another struct scatterlist [array]. The CCISS ...

RESEND as you yesterday asked (in plain text), and plus: *add git id for all patches *add my CC *remove shon included patches -------- stats: Andrea Arcangeli (1): Race condition in userspace testcase J. Bruce Fields (2): knfsd: fix spurious EINVAL errors on first access of new filesystem knfsd: query filesystem for NFSv4 getattr of FATTR4_MAXNAME Jesper Juhl (1): cciss: fix memory leak Kees Cook (1): pci: fix unterminated pci_device_id ...

[This patch was originally in the old ff tree and was intended for .24; but somehow got lost in the arch merge. Has also shipped with OpenSUSE 10.3. I think it should go into .25] This replaces the old NF3/NF4 reference BIOS timer override quirk with a device ID list. We need to ignore the timer override on these systems, but not ignore it on NF5 based systems. Previously this was distingushed by checking for HPET, but a lot of BIOS vendors didn't enable HPET in their pre Vista ...

From: Alfred E. Heggestad <aeh@db.org> This driver adds support for USB VoIP phones using the CM109 chipset, such as Komunikate KIP-1000 and Genius G-talk. Keypad is scanned and events are reported to the input subsystem. The buzzer can be activated by sending SND_TONE or SND_BELL to the input device. The phone keymap can be selected in run-time by using the "phone" module parameter. The driver has been tested with linux 2.6.24 on i386, and also tested to build cleanly on AMD64. More testing ...

Cleanup of - whitespace - macros - useless casts - return (sth); -> return sth; - types - superfluous parenthesis and braces - init tmp directly in moxa_get_serial_info - commented defunct code - commented prototypes Signed-off-by: Jiri Slaby <jirislaby@gmail.com> --- drivers/char/moxa.c | 158 ++++++++++++++++++--------------------------------- 1 files changed, 55 insertions(+), 103 deletions(-) diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c index 5a55b8c..d123827 ...

- cleanup types - use tty_prepare_flip_string and io memcpys Signed-off-by: Jiri Slaby <jirislaby@gmail.com> --- drivers/char/moxa.c | 124 ++++++++++++++++++++------------------------------ drivers/char/moxa.h | 2 +- 2 files changed, 51 insertions(+), 75 deletions(-) diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c index bdd5fd9..f45405f 100644 --- a/drivers/char/moxa.c +++ b/drivers/char/moxa.c @@ -224,7 +224,7 @@ static void MoxaPortLineCtrl(struct moxa_port *, int, int); ...

- merge 2 timers into one -- one can handle the emptywait as good as the other - merge 2 separated poll functions into one, this allows handle the actions directly and simplifies the code Signed-off-by: Jiri Slaby <jirislaby@gmail.com> --- drivers/char/moxa.c | 422 +++++++++++++++++---------------------------------- drivers/char/moxa.h | 10 +- 2 files changed, 142 insertions(+), 290 deletions(-) diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c index b61d14a..bdd5fd9 ...

The lock fixes window between board->ready test and its port access. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> --- drivers/char/moxa.c | 12 ++++++++++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c index fd9c946..6e170a4 100644 --- a/drivers/char/moxa.c +++ b/drivers/char/moxa.c @@ -299,6 +299,7 @@ static int moxa_ioctl(struct tty_struct *tty, struct file *file, struct moxa_port *p; unsigned int i, j; ...

and old-stable (eg 2.6.22)? -- Thanks, Oliver --

[probably stable material too] Use global TLB flushes in MTRR code Obviously kernel mappings should be flushed here too. Signed-off-by: Andi Kleen <ak@suse.de> --- arch/x86/kernel/cpu/mtrr/generic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux/arch/x86/kernel/cpu/mtrr/generic.c =================================================================== --- linux.orig/arch/x86/kernel/cpu/mtrr/generic.c +++ linux/arch/x86/kernel/cpu/mtrr/generic.c @@ -356,7 ...

Yes you're right. Thanks makes more sense. The weird style fooled me. It seems to come from the pseudo code in the Intel manual, but I think it would be still cleaner/more idiomatic to use two __flush_tlb_all() and remove the explicit code. The only drawback would be some more cr4 accesses, which does not seem like a big issue. Updated patch follows. -Andi --- Use standard global TLB flushes in MTRR code This is more idiomatic and it does not really make sense for this code ...

Hi, Just saw this from gcc: drivers/char/drm/i915_drv.c: In function ?i915_suspend?: drivers/char/drm/i915_drv.c:173: warning: array subscript is above array bounds CC [M] drivers/char/drm/i915_dma.o drivers/char/drm/i915_drv.c: In function ?i915_resume?: drivers/char/drm/i915_drv.c:220: warning: array subscript is above array bounds It's this code: dev_priv->saveGR[0x18] = i915_read_indexed(VGA_GR_INDEX, VGA_GR_DATA, 0x18); which looks legit, since ...

I think he was saying that the warning was legit. Anyway, my gcc isn't smart enough to emit warnings like this, maybe it's time to ugprade... Jesse --

of course, the reference was to the warning (I do know C and array indexing 101 :-) -- Jens Axboe --

even though it's not mentioned in the feature removal file, Documentation/pm.txt makes it pretty clear that there is some seriously obsolete content WRT legacy PM. is that scheduled for removal any time soon? i still have a patch for that lying around somewhere. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: ...

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

Thanks! --

Hi! The Sequans company who produce WiMAX chips provides the USB driver and kthp addon driver. However the USB device doesn't work correctly. Here is more true hack for Sequans SQN11x0 based modem. P.S. For more details, please, ask Sequans staff (see Signed-off-by lines). Signed-off-by: Andy Shevchenko <andy@smile.org.ua> Signed-off-by: Gosne Stephane <sgosne@sequans.com> --- a/drivers/usb/host/ehci-q.c.orig 2008-02-07 16:53:18.000000000 +0200 +++ ...

Hi, Remove IP6_RT_PRIO_FW and IP6_RT_FLOW_MASK definitions in include/net/ip6_route.h, as they are not used in the kernel. Regards, Rami Rosen Signed-off-by: Rami Rosen <ramirose@gmail.com>

The Documentation/cgroups.txt file contains the info on how to write some controller for cgroups subsystem, but even with this, one need to write quite a lot of code before developing the core (or copy-n-paste it from some other place). I propose to put this minimal controller into Documentation directory to let people copy-n-paste a) from a known place and b) a small piece of code. Besides, many people learn better reading an example rather than/along with a document. Signed-off-by: ...

Actually I thought that was the main point of kernel/cgroup_debug.c? --

We could do in theory do that, but it would make the recovery logic in cgroup.c:attach_task() more complex - it would have to be able to deal with undoing a partial attach. It seems simpler to just split it into two phases, given that most cgroups don't appear to have attachment conditions anyway. Paul --

Turn off quotas before filesystem is remounted read only. Otherwise quota will try to write to read-only filesystem which does no good... We could also just refuse to remount ro when quota is enabled but turning quota off is consistent with what we do on umount. Signed-off-by: Jan Kara <jack@suse.cz> --- Andrew, this should fix the hang reported... Please apply. Thanks. diff --git a/fs/super.c b/fs/super.c index ceaf2e3..945c322 100644 --- a/fs/super.c +++ b/fs/super.c @@ -603,6 +603,7 @@ ...

Provided the amount of time this issue exists, I don't think it's worth to push it to -stable. It's an oooooooold, issue, which happens quite rarely, and no one bothered to report it so far... But it's not my call... ;) But... I'm thinking about this scenario: # mount /data # quotaon /data (some maintenance stuff to be planned) # mount -o remount,ro /data (do backup etc) # mount -r remount,rw /data at this point, it's expected that quota on /data is enabled. After this ...

This was meant to be a preparation before converting palm_bk3710 to use struct ide_port_info. On the second thought this change may be as well integrated into the future patch (which I'll try to cook later today, unless somebody beats me to it ;-). Thanks, Bart --

Hm, how does it help if you don't make it into driver's method? :-O MBR, Sergei --

* Convert palm_bk3710 host driver to use ide_device_add() instead of ide_register_hw() (while at it drop doing "ide_unregister()" loop which tries to unregister _all_ IDE interfaces if useable ide_hwifs[] slot cannot be find). [ identical change as done to bast-ide/ide-cs/delkin_cb host drivers by commit 9e016a719209d95338e314b46c3012cc7feaaeec ] * Rename 'ide_ctlr_info' to 'hw' and 'index' to 'i' while at it. Cc: Anton Salnikov <asalnikov@ru.mvista.com> Signed-off-by: ...

Is there easy way to push that fix to e1000, too? Or print "use e1000e instead" and refuse to load? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

So you don't think it's related to the interrupt coalescing by any chance ? I'd suggest to try and disable the coalescing and see if it makes any difference. We've had lots of issues with coalescing misbehavior. Not this bad (ie 1 second) though. Add this to modprobe.conf and reload e1000 module options e1000 RxIntDelay=0,0 RxAbsIntDelay=0,0 InterruptThrottleRate=0,0 TxIntDelay=0,0 TxAbsIntDelay=0,0 Max --

this sounds like you have some sort of PCI POST-ing problem and those can indeed be worse if you use any form of interrupt coalescing. In any case that is largely irrelevant to the in-kernel drivers, and as I said we definately have no open issues on that right now, and I really do not recollect any as well either (other than the issue of interference when both ends are irq coalescing) Cheers, Auke --

that can't be the problem. irq moderation would only account for 2-3ms variance maximum. Pavel, can you send me the `lspci -vvv` of your machine with the very latest git tree and after it's showing the poor ping performance? Auke --

Oh, I've definitely seen worse than that. Not as bad as a 1second though. Plus you're talking about the case when coalescing logic is working as designed ;-). What if there is some kind of bug where timer did not expire or something. Max --

well, if you do it you should see that L1 ASPM is now disabled (with e1000e) whereas with e1000 it is still enabled. That's the fix that you need... Auke --

# kexec -v Yes and no. I just booted 2.6.24 on a diskless system (Mandriva) I normally use with 2.6.18 kernel, did kexec -e... And it executed the kernel immediately, without any syncing. On Debian, with the same 2.6.24 kernel, it does sync. So what user space part does the syncing (and how to prevent it)? It does seem to help, thanks. Why it has to be the last option specified? Good to have a newer version, I'll try that, too. -- Tomasz ...

According to kernel/kexec.c: * kexec does not sync, or unmount filesystems so if you need * that to happen you need to do that yourself. I saw this was true with 2.6.18 kernel (i.e., it didn't sync), but kexec syncs with recent kernels (I checked 2.6.23.14 and 2.6.24): # kexec -e md: stopping all md devices sd 2:0:0:0: [sdb] Synchronizing SCSI cache With kexec on 2.6.18 it was executing a loaded kernel immediately. Generally, it's a good thing to sync before jumping into a ...

From: Jens Rottmann <JRottmann@LiPPERT-AT.de> Extends the PLL frequency table of the AMD Geode-LX frame buffer driver to make use of the DIV4 bit, thus adding support for dotclocks between 6 and 25 MHz. These are needed for small LCDs (e.g. 320x240). Also inserts some intermediate steps between pre-existing frequencies. Signed-off-by: Jens Rottmann <JRottmann@LiPPERT-AT.de> --- --- linux-2.6.24/drivers/video/geode/lxfb_ops.c +++ lxfb_clocks_added/drivers/video/geode/lxfb_ops.c @@ -34,35 ...

Let SVM detect if the Nested Paging feature is available on the hardware. Disable it to keep this patch series bisectable. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- arch/x86/kvm/svm.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index c0aaa85..b037b27 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -47,6 +47,8 @@ MODULE_LICENSE("GPL"); #define SVM_FEATURE_LBRV (1 << 1) #define ...

i dont know if it worth checking it here, -- woof. --

Hi, here is the improved patchset which adds support for the Nested Paging feature of the AMD Barcelona and Phenom processors to KVM. The patch set was successfully install- and runtime-tested with various guest operating systems (64 bit, 32 bit legacy and 32 bit PAE Linux, Windows 64 bit and 32 bit versions too). To the previous post of these patches they were extended with support for KVM on 32 bit PAE hosts. Live migration is also implemented and tested in various situations (migration ...

thinking about it again you are right, (for some reason i was thinking about old kvm code that was replace already) -- woof. --

The mapping function for the nonpaging case in the softmmu does basically the same as required for Nested Paging. Make this function generic so it can be used for both. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- arch/x86/kvm/mmu.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 3477395..5e76963 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -965,10 +965,9 @@ static void ...

This patch contains the changes to the KVM MMU necessary for support of the Nested Paging feature in AMD Barcelona and Phenom Processors. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- arch/x86/kvm/mmu.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++-- arch/x86/kvm/mmu.h | 6 ++++ 2 files changed, 82 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 5e76963..5304d55 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ ...

So we can replace the above with this: diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig index 519b4ff..8b22281 100644 --- a/drivers/pcmcia/Kconfig +++ b/drivers/pcmcia/Kconfig @@ -38,6 +38,7 @@ config PCMCIA_DEBUG config PCMCIA tristate "16-bit PCMCIA support" select CRC32 + select HAVE_IDE default y ---help--- This option enables support for 16-bit PCMCIA cards. Most older Yes. Sam --

diff -u arch/arm/Kconfig drivers/Kconfig shows the situation. This is why I insist that new entries to arch/arm/Kconfig should be in the same IDE people insisted that we _will_ have that silly conditional for IDE. I personally do not want it and would be happy to see it go - but I don't have the authority to do that. Take this one up with Bart. --

Are we finally going to allow architecture modifications to drivers/Kconfig? The answer to your question is identical to the answer to that question. --

From: Hans J Koch <hjk@linutronix.de> To: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.arm.linux.org.uk Cc: Greg KH <greg@kroah.com> Subject: arch/arm/Kconfig: Make UIO available on ARM architecture Source drivers/uio/Kconfig to make UIO available in menuconfig if ARCH=arm. I already posted this a few months ago, but it got lost somehow. Signed-off-by: Hans J Koch <hjk@linutronix.de> --- arch/arm/Kconfig | 2 ++ 1 file changed, 2 insertions(+) Index: ...

Shouldn't this be: def_bool PCMCIA Also, should this be something ARM specific - if you have PCMCIA you could --

Hello, I have T61 and have no problem with sound. No sound problem could arise from hw mute that is controlled via volume buttons. Volume mute does just mute (*no unmute*!), buttons volume up/down unmutes volume. There is bar "Speaker" in alsa mixer, must not be muted. -- Lukáš Hejtmánek --

Linus, Could you please pull from: git://git.o-hand.com/linux-rpurdie-backlight for-linus for the backlight tree updates for 2.6.25. This includes a new driver and an optimisation for the class. Both changes have been testing in -mm for quite a while. Thanks, Richard drivers/video/backlight/Kconfig | 9 + drivers/video/backlight/Makefile | 1 drivers/video/backlight/backlight.c | 12 +- drivers/video/backlight/omap1_bl.c | 210 ++++++++++++++++++++++++++++++++++++ ...

Even without the hardware acceleration, a user write to set_brightness leaves any active trigger active and isn't really intuitive or right Ouch, I'm looking into this. I wish I'd known about it earlier. I agree function is more important but didn't want to break the existing convention. I guess this limitation comes from the kobjects involved... Richard --

Disable any active triggers when someone writes to the brightness attribute. This fixes also a misbehaviour with hardware accelerated flashing. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Márton Németh <nm127@freemail.hu> Cc: Richard Purdie <rpurdie@rpsys.net> --- drivers/leds/led-class.c | 2 ++ drivers/leds/led-triggers.c | 12 +++++++++--- drivers/leds/leds.h | 2 ++ 3 files changed, 13 insertions(+), 3 deletions(-) The led class is not even close ...

(cc's restored, and expanded a bit) Thanks. I uploaded the oops picture to mm... looks like all Matthew's changes were in 2.6.23. And 2.6.23 worked OK, yes? The only recent changes to drivers/scsi/advansys.c are commit b80ca4f7ee36c26d300c5a8f429e73372d153379 Author: FUJITA Tomonori <tomof@acm.org> Date: Sun Jan 13 15:46:13 2008 +0900 [SCSI] replace sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE This replaces sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE ...

On Thu, 7 Feb 2008 12:14:56 +0100 Can you try this? Thanks, diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c index 374ed02..f5dde12 100644 --- a/drivers/scsi/advansys.c +++ b/drivers/scsi/advansys.c @@ -566,7 +566,7 @@ typedef struct asc_dvc_var { ASC_SCSI_BIT_ID_TYPE unit_not_ready; ASC_SCSI_BIT_ID_TYPE queue_full_or_busy; ASC_SCSI_BIT_ID_TYPE start_motor; - uchar overrun_buf[ASC_OVERRUN_BSIZE] __aligned(8); + uchar *overrun_buf; dma_addr_t overrun_dma; uchar ...

Oh yeah, definitely agree, I wrote that in the intro as well. The That's definitely a possibility, Nick had something like that. I just didn't like having to allocate a cookie object to store the function and That would indeed be nicer and not require any arch changes. I was afraid it would be more costly than massaging the softirqs a bit though, perhaps that is unfounded. -- Jens Axboe --

I'll get to that, working my way through the first batch of testing on a NUMA platform. [[If anybody has ideas on specific testing to do, that would be helpful.]] I do plan on running some AIM7 tests, as those have shown improvement in other types of affinity changes in the kernel, and some of them have "interesting" IO load characteristics. Alan --

FYI: on a kernel with this patch set, running on a 4-way ia64 (non-NUMA) w/ a FC disk, I crafted a test with 135 combinations: o Having the issuing application pegged on each CPU - or - left alone (run on any CPU), yields 5 possibilities o Having the queue affinity on each CPU, or any (-1), yields 5 possibilities o Having the completion affinity on each CPU, or any (-1), yields 5 possibilities and o Having the issuing application pegged on each CPU - or - left alone (run on ay CPU), ...

I was just considering that, since I knew -rt moved the softirqs into threads. I'll look into it, but may not post anything until after my vacation. -- Jens Axboe --

pick up the threaded softirq patches from -rt, those move all softirqs processing into kernel threads. I'd suggest to extend those via wakeup-from-remote functionality - it fits the construct quite naturally. You should also be able to directly observe any performance impact of threaded softirq handlers. (and if you find any, let me know so that we can make it faster :-) Ingo --

if then this should be a general facility to trigger any softirq - not this wastes another irq vector and is very special-purpose. Why not make the smp_call_function() one more scalable instead? on the more conceptual level, shouldnt we just move to threads instead of softirqs? That way you can become affine to any CPU and can do cross-CPU wakeups anytime - which will be nice and fast via the smp_reschedule_interrupt() facility. Ingo --

This only works for the block softirq, due to the hackish method of the arch implementations. Signed-off-by: Jens Axboe <jens.axboe@oracle.com> --- include/linux/smp.h | 5 +++++ kernel/softirq.c | 7 +++++++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/include/linux/smp.h b/include/linux/smp.h index 55232cc..2b546c0 100644 --- a/include/linux/smp.h +++ b/include/linux/smp.h @@ -61,6 +61,7 @@ int smp_call_function_single(int cpuid, void (*func) (void *info), ...

Signed-off-by: Jens Axboe <jens.axboe@oracle.com> --- arch/ia64/kernel/smp.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/arch/ia64/kernel/smp.c b/arch/ia64/kernel/smp.c index 4e446aa..96f8ffa 100644 --- a/arch/ia64/kernel/smp.c +++ b/arch/ia64/kernel/smp.c @@ -80,6 +80,7 @@ static volatile struct call_data_struct *call_data; #define IPI_CALL_FUNC 0 #define IPI_CPU_STOP 1 #define IPI_KDUMP_CPU_STOP 3 +#define IPI_BLOCK_SOFTIRQ 4 /* This ...

Signed-off-by: Jens Axboe <jens.axboe@oracle.com> --- arch/x86/kernel/entry_64.S | 3 +++ arch/x86/kernel/i8259_64.c | 3 +++ arch/x86/kernel/smp_64.c | 15 +++++++++++++++ include/asm-x86/hw_irq_64.h | 2 ++ 4 files changed, 23 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index c7341e8..753834b 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -704,6 +704,9 @@ END(invalidate_interrupt\num) ...

Hi, Here's a variant using kernel threads only, the nasty arch bits are then not needed. Works for me, no performance testing (that's a hint for Alan to try and queue up some testing for this variant as well :-) -- Jens Axboe

I completely agree, the fidgeting with single members quickly loses appeal. Ingo, I'll merge and integrate your fixes before leaving, I'll be here all day tomorrow as well. -- Jens Axboe --

we should more seriously investigate kernel thread scalability for another reason as well: besides -rt, any generic async IO facility we pick up will likely heavily rely on them. Kernel thread scheduling is quite a bit lighter than user task scheduling [no TLB flushes, etc.] - and if it is still not good enough we could probably accelerate them some more. (and everyone will benefit) irq-context softirqs on the other hand are quite rigid and bring in many atomicity assumptions so they are ...

i definitely agree and do that for all code i write. But if someone does item by item initialization for some crazy performance reason (networking folks tend to have such constructs), it should be done i think how i've done it in the patch: by systematically listing _every_ field in the structure, in the same order, and indicating it clearly when it is not initialized and why. and there it already shows that we do not initialize a few other members that could cause problems later ...

Hey, This is with latest Linus's tree. It started IIRC just after the big x86 merge. Machine is amd64, no 32-bit emulation set. .config here: http://plaes.org/files/2008-Q1/dot_config_VDSO64_error [snip] LD vmlinux.o MODPOST vmlinux.o modpost: Found 29 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD ...

hmm, i think, the site is broken (193.219.28.140), and not the card or the driver is wrong. when it does, then other sites are auch reproductable .. /* is use auch madwifi-0.9.3.3, but it think, it is not driver problem */ -- Thanks, Oliver --

1749015234:1749015234(0) win 5840 <mss 1460,sackOK,timestamp 1885141 0,nop,wscale ²2> wscale 2 here (instead of 5 on your non working case) 1:1(0) ack 7 win 1460 <nop,nop,timestamp 1885191 536320613> Typical window scaling problem here... (well, for previous traces, with wscaling of 5, since with wscale 2 it seems to work), you probably have a buggy router or something... http://lwn.net/Articles/92727/ Try : # echo 0 >/proc/sys/net/ipv4/tcp_window_scaling And retry to ...

Here goes, this happens after running: ftp sunsite.icm.edu.pl The ftp session is successful ---------------------------------------------------- tcpdump -i ath0 tcp and port 21 -X -s 300 -vv tcpdump: listening on ath0, link-type EN10MB (Ethernet), capture size 300 bytes 18:09:48.435612 IP (tos 0x0, ttl 64, id 6423, offset 0, flags [DF], proto: TCP (6), length: 60) sabayonx86.local.41649 > sunsite2.icm.edu.pl.ftp: S, cksum 0xe759 (correct), 1749015234:1749015234(0) win 5840 <mss ...

On Thu, 07 Feb 2008 10:04:00 +0100 You have the wrong mailing list: 1. You are using proprietary drivers (ndiswrapper and madwifi both have binary only parts). 2. The network developers read netdev@vger.kernel.org Sounds like you have a TCP corrupting firewall that mangles the window scaling. This is a known issue with buggy middleboxes that can not be fixed in Linux without limiting performance. Complain to the middlebox vendors or IETF. -- Stephen Hemminger ...

BITS_PER_LONG is a signed value (32 or 64) DIV_ROUND_UP(nr, BITS_PER_LONG) performs signed arithmetic if "nr" is signed too. Converting BITS_TO_LONGS(nr) to DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long)) makes sure compiler can perform a right shift, even if "nr" is a signed value, instead of an expensive integer divide. Applying this patch saves 141 bytes on x86 when CONFIG_CC_OPTIMIZE_FOR_SIZE=y and speedup bitmap operations. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>

Just for the sake of cleanness. Signed-off-by: Jan Kiszka <jan.kiszka@web.de> --- lib/Kconfig.kgdb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: b/lib/Kconfig.kgdb =================================================================== --- a/lib/Kconfig.kgdb +++ b/lib/Kconfig.kgdb @@ -16,7 +16,7 @@ config KGDB_ARCH_HAS_SHADOW_INFO depends on KGDB config KGDB_CONSOLE - bool "KGDB: Console messages through gdb" + bool "Console messages through gdb" depends on ...

Cool! Yes, Yinghai Lu's patch indeed is the same as mine and its really surprising that we've used the same variable name too! :) regards, balaji rao --

Hello, The following commit caused my X server to stop working. commit 99fc8d424bc5d803fe92cad56c068fe64e73747a Author: Jesse Barnes <jesse.barnes@intel.com> Date: Wed Jan 30 13:33:18 2008 +0100 x86, 32-bit: trim memory not covered by wb mtrrs This patch fixes the improper handling of addresses > 4G by mtrr_trim_uncached_memory. This, now brings up X on my system. Signed-off-by: Balaji Rao <balajirrao@gmail.com> diff --git a/arch/x86/kernel/cpu/mtrr/main.c ...

indeed ... i think the 64-bit behavior of gcc is inherently dangerous, we had numerous subtle bugs in that area. i think perhaps Sparse should be extended to warn about this. I think any case where on _32-bit_ we have an 'unsigned long' that is shifted to the left by any significant amount is clearly in danger of overflowing. _Especially_ when the lvalue is 64-bit! or in other words, on any such construct: 64-bit lvalue = ... 32-bit value we should enforce _explicit_ (u64) ...

indeed :) Although further reading into the commit clearly tells us that yeah, linux-2.6.git is append-only. Ingo --

should be x86_64: trim memory not covered by wb mtrrs anyway, we can not modify git log in linux-2.6.git. can we? YH --

Sorry about that, I've been sending Ingo a bunch of x86 patches, didn't think to look further than that. Will keep in mind. Harvey --

Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> --- Hello, ups, I made a typo myself, how embarrassing. Sorry for getting this patch twice. Best regards Uwe scripts/checkpatch.pl | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 579f50f..35bb5a1 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -1373,7 +1373,7 @@ sub process { # multi-statement macros should be enclosed in ...

From: Denis Cheng <crquan@gmail.com> it moves 365 bytes from .text to .init.text, and 30 bytes from .text to .exit.text, saves memory. Signed-off-by: Denis Cheng <crquan@gmail.com> Signed-off-by: David Teigland <teigland@redhat.com> --- fs/dlm/config.c | 2 +- fs/dlm/debug_fs.c | 2 +- fs/dlm/lockspace.c | 2 +- fs/dlm/memory.c | 2 +- fs/dlm/netlink.c | 4 ++-- fs/dlm/user.c | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) diff --git ...

Put lkb_astparam in a union with a dlm_user_args pointer to eliminate a lot of type casting. Signed-off-by: David Teigland <teigland@redhat.com> --- fs/dlm/debug_fs.c | 6 ++---- fs/dlm/dlm_internal.h | 5 ++++- fs/dlm/lock.c | 14 ++++++-------- fs/dlm/memory.c | 2 +- fs/dlm/netlink.c | 5 ++--- fs/dlm/user.c | 8 +++----- 6 files changed, 18 insertions(+), 22 deletions(-) diff --git a/fs/dlm/debug_fs.c b/fs/dlm/debug_fs.c index ...

From: Al Viro <viro@zeniv.linux.org.uk> ... those can happen and BUG() from DLM_ASSERT() in allocate_direntry() is not a good way to handle them. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David Teigland <teigland@redhat.com> --- fs/dlm/dir.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/fs/dlm/dir.c b/fs/dlm/dir.c index 831050e..85defeb 100644 --- a/fs/dlm/dir.c +++ b/fs/dlm/dir.c @@ -319,6 +319,9 @@ static int get_entry(struct dlm_ls ...

From: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David Teigland <teigland@redhat.com> --- fs/dlm/lock.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index 6c605fc..0593dd8 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -4271,7 +4271,6 @@ static int receive_rcom_lock_args(struct dlm_ls *ls, struct dlm_lkb *lkb, struct dlm_rsb *r, struct dlm_rcom *rc) { ...

From: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David Teigland <teigland@redhat.com> --- fs/dlm/dir.c | 2 +- fs/dlm/dlm_internal.h | 2 +- fs/dlm/rcom.c | 11 ++++++----- fs/dlm/recover.c | 4 ++-- 4 files changed, 10 insertions(+), 9 deletions(-) diff --git a/fs/dlm/dir.c b/fs/dlm/dir.c index ff97ba9..ce30136 100644 --- a/fs/dlm/dir.c +++ b/fs/dlm/dir.c @@ -235,7 +235,7 @@ int ...

From: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David Teigland <teigland@redhat.com> --- fs/dlm/rcom.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/fs/dlm/rcom.c b/fs/dlm/rcom.c index 3f9b96f..a312f1d 100644 --- a/fs/dlm/rcom.c +++ b/fs/dlm/rcom.c @@ -85,6 +85,7 @@ static void make_config(struct dlm_ls *ls, struct rcom_config *rf) static int check_config(struct dlm_ls *ls, struct dlm_rcom *rc, int ...

From: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David Teigland <teigland@redhat.com> --- fs/dlm/dlm_internal.h | 22 +++++++++++----------- fs/dlm/lock.c | 34 +++++++++++++++++++--------------- fs/dlm/rcom.c | 14 +++++++------- fs/dlm/util.c | 45 ++------------------------------------------- 4 files changed, 39 insertions(+), 76 deletions(-) diff --git a/fs/dlm/dlm_internal.h ...

From: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David Teigland <teigland@redhat.com> --- fs/dlm/dir.c | 23 ++++++++++++++++++++--- 1 files changed, 20 insertions(+), 3 deletions(-) diff --git a/fs/dlm/dir.c b/fs/dlm/dir.c index ce30136..831050e 100644 --- a/fs/dlm/dir.c +++ b/fs/dlm/dir.c @@ -220,6 +220,7 @@ int dlm_recover_directory(struct dlm_ls *ls) last_len = 0; for (;;) { + int left; error = ...

This is a second batch of dlm patches that I think should be ready for 2.6.25. It's largely clean ups and minor fixes from Al Viro, and a couple more added by me after Al pointed them out. Thanks, Dave Al Viro (13): dlm: use proper C for dlm/requestqueue stuff (and fix alignment bug) dlm: dlm_process_incoming_buffer() fixes dlm: do not byteswap rcom_lock dlm: do not byteswap rcom_config dlm: use proper type for ->ls_recover_buf dlm: missing length ...

Just FYI, given some of the weirdness we've seen in 8xx chipsets in the 2D driver, this new suspend/resume code may still need a few tweaks. Please test it out and report any bugs you find asap (preferably w/o X running as that makes things easier to debug). Also, if you find that your outputs don't come back, I've got an experimental patch at https://bugs.freedesktop.org/show_bug.cgi?id=14249 that may work for you (this one in particular is the one I'm worried may break ...

Hi Linus, They've been discussed with RT/scheduler/cpuset folks. Andrew is definitely in the loop. He just replied and asked for some fixes and clarifications. He seems to be ok with merging this in general. The last patch may not be as bad as I originally thought. We'll discuss it some more with Andrew. I'll also check with Rusty who wrote the stopmachine in the first place. It actually seems like an overkill at this point. My impression is that it was supposed to be a safety net if some ...

Speaking of which.. there is the -rt tree. Have those people had a look at the feature, perhaps played with the code? --

ah, I missed that. Yup, the implementation you have there looks OK. --

Peter Z. and Steven R. sent me some comments, I believe I explained and addressed them. Ingo's been quite. Probably too busy. btw It's not an RT feature per se. It certainly helps RT but removing all the latency sources from isolated CPUs. But in general it's just "reducing kernel overhead on some CPUs" kind of feature. Max --

Awesome :) I think it's get more and more useful as people will start trying to figure out what the heck there is supposed to do with the spare CPU cores. I mean pretty soon most machines will have 4 cores and some will have 8. Those are local versions that depend whether a feature is enabled or not. If CONFIG_CPUISOL_WORKQUEUE is disabled we want to cpu_unusable() in the workqueue.c to be a noop, and if it's enabled that macro resolve to cpu_isolated(). Same thing for the stopmachine.c. If ...

The feature as a whole seems useful, and I don't actually oppose the merge based on what I see here. As long as you're really sure that cpusets are inappropriate (and bear in mind that Paul has a track record of being wrong on this :)). But I see a few glitches - There are two separate and identical implementations of cpu_unusable(cpu). Please do it once, in a header, preferably with C function, not macros. - The Kconfig help is a bit scraggly: +config ...

heh - I saw that <grin>. Max - Andrew's about right, as usual. You answered my initial questions on this patch set adequately, but hard real time is not my expertise, so in the final analysis, other than my saying I don't have any more objections, my input doesn't mean much either way. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214 --

[PATCH] x86_64: clean up find_e820_area change size to unsigned long, becase caller and user all used unsigned long. also make bad_addr take align. Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> Index: linux-2.6/arch/x86/kernel/e820_64.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/e820_64.c +++ linux-2.6/arch/x86/kernel/e820_64.c @@ -95,7 +95,7 @@ void __init early_res_to_bootmem(void) } /* Check for already reserved areas ...

yes. need 256g. 128g without patch it still work. because round_up(.., PAGE_SIZE) get sound interesting. but need some variable to prevent using non exist page. YH --

[PATCH] x86_64: fix page table size Command line: apic=debug acpi.debug_level=0x0000000F debug initcall_debug pci=routeirq ramdisk_size=131072 root=/dev/ram0 rw ip=dhcp console=uart8250,io,0x3f8,115200n8 BIOS-provided physical RAM map: BIOS-e820: 0000000000000100 - 000000000009bc00 (usable) BIOS-e820: 000000000009bc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 00000000dffe0000 (usable) BIOS-e820: 00000000dffe0000 - ...

What tree did you use? The patch I submitted had if (direct_gbpages == GBP_ON) { here. And the actual direct gbpages patch does not even have to made it to Linus' tree yet, just all the other gbpages patches But yes if it really was if (direct_gbpages) { here then your change is correct of course. -Andi --

thanks Yinghai, applied! I'm wondering why this bug didnt trigger more widely. It seems to me it needs some serious amount of RAM to trigger this bug - correct? btw., it would be nice to have some "lots of RAM simulation" debugging code which would just _fake_ a really large e820 map and would in the end throw away the 'fake' pages later during bootup. Perhaps tell the early allocator to never allocate into these fake areas [via an struct e820 entry flag], but all our sizing code and ...

This is a 2.4 backport of a linux-2.6 change by Oliver Neukum. (commit 85237f202d46d55c1bffe0c5b1aa3ddc0f1dce4d) CVE-2007-5093 was assigned for this issue. This backport has been compile-tested only. Commit log from 2.6 follows. the pwc driver has a disconnect method that waits for user space to close the device. This opens up an opportunity for a DoS attack, blocking the USB subsystem and making khubd's task busy wait in kernel space. This patch shifts freeing resources to close ...

The kernel implements readlink of /proc/pid/exe by getting the file from the first executable VMA. Then the path to the file is reconstructed and reported as the result. Because of the VMA walk the code is slightly different on nommu systems. This patch avoids separate /proc/pid/exe code on nommu systems. Instead of walking the VMAs to find the first executable file-backed VMA we store a reference to the exec'd file in the mm_struct. That reference would prevent the filesystem holding the ...

I would have, but I didn't see the original offender in my upstream branch, so I just applied it separately - looks to me like fcprint.c hasn't been touched (until your patch) since its introduction: ericvh@ericvh-desktop:~/src/linux/9p$ git log net/9p/fcprint.c commit bd238fb431f31989898423c8b6496bc8c4204a86 Author: Latchesar Ionkov <lucho@ionkov.net> Date: Tue Jul 10 17:57:28 2007 -0500 9p: Reorganization of 9p file system code This patchset moves non-filesystem interfaces of ...

On Wed, 6 Feb 2008 19:39:26 -0600 "Eric Van Hensbergen" <ericvh@gmail.com> wrote: Could you please cc me on pull requests? I need to pay more attention to Really this should have been folded into the patch which it fixes. We get a cleaner history that way, and it protects git-bisectability. Yes, it can mean that people lose credit points. I make that up by adding a little note in the signoffs in the form [foo@bar.com: <whatever [s]he did>] box:/usr/src/git26> git-log | grep ' ...

Duplicating Neil Brown's jbd patch for jbd2. I guess this can go through the ext4 queue rather than straight into -mm. Neil's text: Some devices - notably dm and md - can change their behaviour in response to BIO_RW_BARRIER requests. They might start out accepting such requests but on reconfiguration, they find out that they cannot any more. ext3 (and other filesystems) deal with this by always testing if BIO_RW_BARRIER requests fail with EOPNOTSUPP, and retrying the write requests ...

Yes. Actually, I think there's another bug in there as well - at least I have bugreport where we obviously miss that writing ordered buffer failed (I see completion function of the buffer return with eopnotsupp bit set but barriers aren't disabled). I think someone starts writing out the buffer before we call sync_dirty_buffer(bh) but I'm not completely sure who can do this when we just do set_buffer_dirty(bh)... Anyway before I check that it is indeed happening what I think is happening, your ...

Currently the XFS freezer doesn't solve a deadlock automatically and we rely on administrators for ensuring that the freezer will not access the filesystem. And even if the wrong freezer causes a deadlock, it can be solved by other unfreeze process(unfreeze command). So I don't think the freezer itself needs to solve the deadlock. I think the timeout is effective for a unexpected deadlock and the timeout extending feature is very useful as Dmitri proposed. Cheers, Takashi --

On Thu, 7 Feb 2008, Alejandro Riveira Fern

FWIW this is not reproducible on 2.6.24/x86/CentOS-51. (I tried running it nearly 1500 times in a loop.) Assuming those many tries are sufficient to reproduce this bug, there seems to be something specific to the environment/architecture/configuration that's necessary to trigger it. It might be helpful to provide full details like glibc version, compiler version, .config etc. Parag --

Not reproducible with PREEMPT either. Parag --

Testcase attached. Build with gcc -D_GNU_SOURCE -c hangc-2.c -o hangc-2.o gcc -lpthread -o hangc-2 hangc-2.o Run with hangc-2 4500 4500 -- Frank Mayhar <fmayhar@google.com> Google, Inc.

Several, among which were i686+SMP+GnuC-4.0.3+Glibc-2.3.6. No PREEMPT. Linux 2.6.18, 2.6.21 and 2.6.24-rc4. -- Frank Mayhar <fmayhar@google.com> Google, Inc. --

/dev/cpu/msr is bogus. It should be /dev/cpu/0/msr etc. Sounds like your version of udev might be out of date, or you're using an old kernel which doesn't communicate /dev/cpu/* to udev properly. Revert your hacks and, if you have to create the nodes manually, use the MAKEDEV script included with the msr-tools. -hpa --

From: Randy Dunlap <randy.dunlap@oracle.com> Docbook fatal error, file was moved: docproc: linux-2.6.24-git15/drivers/base/dmapool.c: No such file or directory Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- Documentation/DocBook/kernel-api.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.24-git15.orig/Documentation/DocBook/kernel-api.tmpl +++ linux-2.6.24-git15/Documentation/DocBook/kernel-api.tmpl @@ -165,6 +165,7 @@ X!Ilib/string.c ...

From: Randy Dunlap <randy.dunlap@oracle.com> Add I2C to config since the driver makes several i2c*() calls. Add PCI to config because the config selects I2C_I801, which depends on PCI, but currently config* does not follow dependency chains, so randconfig can enable INPUT_APANEL even when PCI is not enabled, which leads to these warnings: linux-2.6.24-mm1/drivers/i2c/busses/i2c-i801.c:641: error: implicit declaration of function ...

OK. What did you have in mind for the help text. I changed it a small bit. I also added "depends on LEDS_CLASS" since defconfig didn't have that set, but the build failed with wanting symbols that it provides. Updated patch: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From: Randy Dunlap <randy.dunlap@oracle.com> Add I2C to config since the driver makes several i2c*() calls. Add to help text that the Intel I2C ICH (i801) driver is also needed for this kernel. Add LEDS_CLASS to config since ...

include/linux/efi.h does not include asm/efi.h, efi.c and efi_64.c explicitly include both. While not really right, add the include to efi_32.c until the header gets sorted out. arch/x86/kernel/efi_32.c:42:6: warning: symbol 'efi_call_phys_prelog' was not declared. Should it be static? arch/x86/kernel/efi_32.c:84:6: warning: symbol 'efi_call_phys_epilog' was not declared. Should it be static? Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- arch/x86/kernel/efi_32.c | 1 + ...

Nested per_cpu accessors will shadow the internal __ptr variable. Use a temporary first_core variable. arch/x86/kernel/cpu/cpufreq/powernow-k8.c:1239:9: warning: symbol '__ptr' shadows an earlier one arch/x86/kernel/cpu/cpufreq/powernow-k8.c:1239:9: originally declared here Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- arch/x86/kernel/cpu/cpufreq/powernow-k8.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git ...

This is a note to let you know that I've just added the patch titled Subject: USB: ftdi_sio.c add missing '|' to my gregkh-2.6 tree. Its filename is usb-ftdi_sio.c-add-missing.patch This tree can be found at http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/ From 12o3l@tiscali.nl Thu Feb 7 10:05:29 2008 From: Roel Kluin <12o3l@tiscali.nl> Date: Thu, 07 Feb 2008 01:06:07 +0100 Subject: USB: ftdi_sio.c add missing '|' To: Greg KH ...

Greg, I'm pretty sure I know what's happening. For whatever reason we're invoking dev_attr_show() on attribute_group objects. The reason it probably only crashes on sparc64 is because perhaps at that dev_attr->show offset on x86 there are zero bytes there instead of a pointer, so the NULL check here in dev_attr_show() masks the bug. The problem with all of this "container_of() this", "container_of() that" is that we lose real type checking. So unless we add magic cookies to verify or ...

I don't understand that code at all, on 2.6.24, what does reading that file give you? At first glance, I don't see how that file would spit out anything and not give you the same kind of oops. you are in a maze of kobject pointers, all alike... --

Picky, picky, picky :) It's odd that the original one didn't also do that, but I'll fix that up properly, let me try again... thanks, greg k-h --

From: Greg KH <gregkh@suse.de> Only Fusion SAS on this system, therefore scsi. --

So, if you just comment out that whole "if (flags & ADDPART_FLAG_WHOLEDISK)" chunk, does the oops go away? I think that is the real solution here as I don't see what this attribute is supposed to be showing. thanks, greg k-h --

From: Greg KH <gregkh@suse.de> In the old code it would vector through part_sysfs_ops (look at how it works before the changeset), which returns 0 if the attribute lacked a ->show method. --

The patch did change over time, but not that much, minor bugfixes for it. I didn't think to update the original date in the quilt file, sorry. It was in -mm for quite a while, so I thought it got a good enough testing period. I'll try to remember to update the timestamp on patches that get updated, it's a pretty rare thing for my patchflow, shouldn't be hard to remember. thanks, greg k-h --

Great, thanks for testing, I'll send it to him tomorrow. greg k-h --

Ah, ok, that's a bit wierd, thanks for explaining it, I'll go make it work... thanks, greg k-h --

From: Greg KH <gregkh@suse.de> I found the problem, it's the "whole_disk" partition attribute. Look in fs/partitions/check.c:add_partition() where it tests the ADDPART_FLAG_WHOLEDISK flag. I think that code block needs to be updated to match the rest of the changes in the offending changeset we are discussing. --

From: Greg KH <gregkh@suse.de> It doesn't crash, but the file returns -EIO instead of zero when read. --

Ofcourse :) : Accept guest _PAGE_PWT page table entries, otherwise lguest will always fail with a "bad page table entry" message. Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com> --- diff --git a/drivers/lguest/page_tables.c b/drivers/lguest/page_tables.c index 74b4cf2..952160b 100644 --- a/drivers/lguest/page_tables.c +++ b/drivers/lguest/page_tables.c @@ -178,8 +178,8 @@ static void release_pte(pte_t pte) static void check_gpte(struct lg_cpu *cpu, pte_t gpte) { - if ...

On Thu, 07 Feb 2008 17:08:19 -0600 I think it's fine. People can go look at the definition site, read the comment and come away happy. --

Something like: Index: linux-2.6.24-mm1/include/linux/compiler-gcc.h =================================================================== --- linux-2.6.24-mm1.orig/include/linux/compiler-gcc.h +++ linux-2.6.24-mm1/include/linux/compiler-gcc.h @@ -53,3 +53,9 @@ #define noinline __attribute__((noinline)) #define __attribute_const__ __attribute__((__const__)) #define __maybe_unused __attribute__((unused)) + +/* + * When gcc inlines multiple functions into a parent function, + * the ...

Yeah, you're definitely going to want an upper bound on acceptable values and not allow anything negative for the aforementioned reason. David --

On Wed, 2008-02-06 at 13:06 -0800, H. Peter Anvin wrote: [...some comments...] I fixed all of those up. Thanks, Ian. --- x86: add a crc32 checksum to the kernel image. Signed-off-by: Ian Campbell <ijc@hellion.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> --- Documentation/i386/boot.txt | 8 ++++ arch/x86/boot/tools/build.c | 88 ++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 95 ...

Weird, .24 proper doesn't have that patch. What exact fedora kernel was Which is even weirder, because the provided trace indicates schedule_timeout() Call Trace: [schedule_timeout+149/208] schedule_timeout+0x95/0xd0 [<ffffffff8057dde5>] schedule_timeout+0x95/0xd0 [tty_poll+145/160] tty_poll+0x91/0xa0 [<ffffffff80430f11>] tty_poll+0x91/0xa0 [do_sys_poll+617/880] do_sys_poll+0x269/0x370 [<ffffffff802bbe69>] ...

Bugger, I thought I had it nailed with: --- commit 3588a085cd52ef080bf72df772378e1ba6bb292f Author: Peter Zijlstra <a.p.zijlstra@chello.nl> Date: Fri Feb 1 17:45:13 2008 +0100 hrtimer: fix hrtimer_init_sleeper() users this patch: commit 37bb6cb4097e29ffee970065b74499cbf10603a3 Author: Peter Zijlstra <a.p.zijlstra@chello.nl> Date: Fri Jan 25 21:08:32 2008 +0100 hrtimer: unlock hrtimer_wakeup Broke hrtimer_init_sleeper() ...

try a dummy iret, something like: asm volatile ("pushf; push $1f; iret; 1: \n"); to get the CPU out of its 'nested NMI' state. (totally untested) the idea is to push down an iret frame to the kernel stack that will just jump to the next instruction and gets it out of the NMI nesting. Note: interrupts will/must still be disabled, despite the iret. (the ordering of the pushes might be wrong, we might need more than that for a valid iret, etc. etc.) Ingo --

The design was as follows: - Doing anything in the crashing kernel is unreliable. - We do not have the information to do anything useful in the recovery/target kernel. - Having the other cpus stopped is very nice as it reduces the amount of weirdness happening. We do not share the same text or data addresses so stopping the other cpus is not mandatory. On some other architectures there are cpu tables that must live at a fixed address but this is not the case on x86. - Having ...

Ingo noted a few posts down the nmi_exit doesn't actually write to the APIC EOI register, so yeah, I agree, its bogus (and I apologize, I should have checked that more carefully). Nevertheless, this patch consistently allowed a hangning machine to boot through an Nmi lockup. So I'm forced to wonder whats going on then that this patch helps with. perhaps its a just a very fragile timing Definately not the case, I did a clean build from a cvs tree to test this and -- ...

However, these patches break my second testbed (dual -core AMD desktop), with the attached config. It crashes on boot with the following trace: Using local APIC timer interrupts. Detected 12.500 MHz APIC timer. lockdep: fixing up alternatives. Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 4400.18 BogoMIPS (lpj=8800361) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) AMD Athlon(tm) ...

Of course, thanks for report :). The problem is we allow remounting read only which we should refuse when quota is enabled. I'll fix that in a minute. Honza -- Jan Kara <jack@suse.cz> SuSE CR Labs --

Yes, but XFS doesn't give a damn about what we do in VFS with quotas ;) So we are speaking here only about quotas implemented in VFS and these need writing. BTW: When filesystem is remounted read-only, quota information shouldn't change so it doesn't matter whether you turn it off or leave it on. The only difference is that when you later remount rw, you have to turn Oh yes... there are some similarities ;). But quota was first! ;) Honza -- Jan Kara <jack@suse.cz> SUSE Labs, ...

We couldn't leave quota on when filesystem is remounted ro because we need to modify quotafile when quota is being turned off. We could turn off quotas when remounting read-only. As we turn them off during umount, it Actually, I couldn't reproduce the hang on my testing machine so I don't know exactly why it hangs. But my guess is that it's because we try to write to the filesystem... Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR --

That is wrong. The API guarantees only that the kthread is initially created in a non-running state. It cannot guarantee that no other task will wake up the kthread before the caller does. Alan Stern --

Oh, I see. You're right - this race is possible... I'll fix that up --

Maybe Grace can help to setup some cruisecontrol auto test machine with email notification. -Bryan --

OK - now that we have that fixed (Mike/Bryan will do this on the mm tree and at least fix up compile issues as soon as we notice) - how do we want to fix this specific issue? Add the missing entries into include/asm-xxxxx/pgtable.h or wrap the callers in ifdefs? -Robin -Robin --

ive setup one of our internal machines to auto build all the Blackfin defconfigs found in mainline git and the mm tree just need to find a way to publish/notify people upon failure ... -mike --

It dies at suspend, always in same place, but not always. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

.. and I have just noticed that my patch was by mistake missing signoff. Could you please add Signed-off-by: Jiri Kosina <jkosina@suse.cz> That actually makes sense, thanks. I will send you a patch. Thanks, -- Jiri Kosina SUSE Labs --

So what do you think is proper behavior in situation when CONFIG_COMPAT_BRK=N on 64bit kernel, and 32bit-binary is loaded in 32bit emulation? We can either leave the brk as-is, but that is in contradiction to user explictly specifying CONFIG_COMPAT_BRK=N. Is this what you propose? Or we can randomize brk start in such situation, but that is the behavior we currently automatically have due to CONFIG_COMPAT_BRK=N, so no change is needed. Thanks, -- Jiri Kosina SUSE Labs --

This indeed looks wrong. The default should be N and the text should say "On recent distros (post-2000 ones) N is usually a safe choice". Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. --

Chris, Can you please apply the following patch, boot w/o nohpet and provide the dmesg output ? Thanks, tglx diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index 429d084..4e98241 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -375,8 +375,10 @@ int __init hpet_enable(void) { unsigned long id; - if (!is_hpet_capable()) + if (!is_hpet_capable()) { + printk(KERN_INFO "HPET not available\n"); return 0; + } hpet_set_mapping(); ...

Now, it would be interesting to know what the detailed difference is, when the system is booted with and without nohpet. Chris, can you please provide the dmesg output and the output of /proc/timer_list for each bootup ? .config file would be interesting as well. Thanks, tglx --

Thomas - I hope that, from at least my perspective, your question is rhetorical. I am fully willing to publicly admit that I don't have a clue. About much of anything. I will even admit that until prompted by Jiri yesterday I had never even heard of the nohpet directive for the boot line. I am willing to do whatever I can to help isolate and or resolve this issue, but to do so I need one of you experts to firmly grab hold of some portion of my anatomy and guide me in the right ...

Jiri - I have just started the build on the 2.6.24-git16 product and when it is done I will come up with just the nohpet parameter - forgoing the previouosly used taskset command. Do you want me to do this using the git15 kernel I built yesterday, or the new git16 kernel? (I was not sure if you wanted me to introduce the variable of a new kernel into the process while you are trying to diagnose the failure) On the topic of doing a git bisect - I am recovering from heart surgery last ...

Jiri - I have been up and running now for about a half hour – since I did not hear your preference I stayed with git15 instead of jumping up to git16 in an attempt to avoid introducing any unwanted changes. The only non-standard thing I did was to use the nohpet directive at boot time - I did NOT enter the previously used taskset command to alter X's affinity. I have been banging away on my keyboard for about a half hour now with no problems. While this is not conclusive on a ...

Hi Bart, The panic is reproducible with the 2.6.24-git16 kernel, the call trace is similar to the previous one BUG: unable to handle kernel paging request at ffffffffffffffa0 IP: [<ffffffff80415673>] init_irq+0x188/0x444 PGD 203067 PUD 204067 PMD 0 Oops: 0000 [1] SMP CPU 3 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.24-git16 #1 RIP: 0010:[<ffffffff80415673>] [<ffffffff80415673>] init_irq+0x188/0x444 RSP: 0000:ffff81022f093e00 EFLAGS: 00010282 RAX: ffffffffffffff80 RBX: ...

yes, i didn't see any followup on that item. i still have the patch, unless it's already working its way thru the system. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook: ...

That's very useful. I'll try it this weekend. Thanks for your help! Jeff. --

*ping* Linus, Do you want me to redo the pull or is it still acceptable as is? I am hesitant touching the tree after sending a pull request... Thanks, Dmitry -- Dmitry --

On Wed, 06 Feb 2008 16:01:47 -0800 (PST) Great, thanks! SPARC IOMMUs use bitmap for the free area management like POWER IOMMUs so it could use lib/iommu-helper as POWER does. --

Thanks, this patch seems to fix the problem. --Clem --

On Thu, 7 Feb 2008 16:24:15 -0500 Awesome. Thanks, guys. --

does the patch below improve the situation? Ingo --- arch/x86/kernel/reboot.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) Index: linux-x86.q/arch/x86/kernel/reboot.c =================================================================== --- linux-x86.q.orig/arch/x86/kernel/reboot.c +++ linux-x86.q/arch/x86/kernel/reboot.c @@ -396,8 +396,20 @@ void machine_shutdown(void) if (!cpu_isset(reboot_cpu_id, cpu_online_map)) reboot_cpu_id = ...

On Wed, 6 Feb 2008 16:31:11 -0800 OK, I did this (tested on a ed50d6cbc394cd0966469d3e249353c9dd1d38b9-tipped tree) and again, the patch made no difference: the machine still pauses 20-odd seconds before (correctly) powering off. --

On Thu, 7 Feb 2008 01:04:25 +0100 Nope. But I tested it on mainline, and mainline exhibits the never-powers-off symptom, whereas ed50d6cbc394cd0966469d3e249353c9dd1d38b9 demonstrates the powers-off-after-20-seconds symptom. So we _may_ be dealing with two bugs here, and your patch might have fixed the first, but that success is obscured by the second. I guess I need to prepare a tree which has ed50d6cbc394cd0966469d3e249353c9dd1d38b9 at its tip. (Wonders how to do that). btw, ...

any link to the proxy splitter? Googling for "kgdb proxy splitter" did not yield anything obviously on-topic. Ingo --

great stuff! I've picked these cleanups up into x86.git. (will pick up Jason's commits too) Could you try something else too perhaps, which would be way useful for me: to add a sysctl flag (or something like that) to change kgdboc to accept a Ctrl-C and break into kgdb mode? [this means a simple Ctrl-C on a kgdboc line would break into KGDB as well - but that would be an acceptable price.] Right now kgdboc just hangs when gdb attaches - i have to generate a SysRq sequence via a ...

What's the srev a phy ver printed few lines above this, please? --

The problem is exactly that it's filesystem specific, each filesystem creates it's own stuff there. Also we have a rule tp not create new things under /proc. Things should either go into /sys or into /proc/sys. And I think a sysctl is more appropriate for this than something under /sys. Thanks, Miklos --

I like how simple it appears to be :) At first I missed the fact that owning uid is always 0 so I thought the uid processing wasn't quite enough. But since it's always 0, the only question is whether there are any /proc/sys files whose users currently depend on being setgid 0 and setgid non-0 with no capabilities. On my laptop, 'find /proc/sys -type f -perm -020' gives me no results, so that is promising. So this certainly seems like a good first step. In fact, combined with /proc/sys/ ...

But I would assume some things under /proc/sys/net/ipv4 or --

actually, the way i solved it for qemu+KVM+paravirt was to just turn off this rather silly check in the serial driver if inside a paravirt guest. When we are emulated then the serial 'hardware' is totally reliable and we should just trust it. That way i never dropped a single bit of kernel log output again. Ingo --

The right thing to do is to add virtual FIFO exhaustion into the Qemu device model. It really isn't a valid emulation of a UART that it has an infinite FIFO behind it that can flood the interrupt handler for an arbitrary number of fetches. I was going to give a technical description of how to do it here, but then I realized I might as well just write it up as a patch. Stay tuned. -hpa --

Specifically, qemu isn't paravirtualized, it's fully virtualized. The same kernel can run on real hardware just fine. (Sort of the point of the project...) I can yank the warning for the kernels I build (or set PASS_LIMIT to 9999999), but I'd rather not carry any more patches than I can avoid... Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. --

It's ok, exactly the same my patch implements. Sven --

Hm, it seems we can convert it at least partially to C. Rafael --

Okay, this uses the iodelay as the timesource... here is the total silliness (and totally untested, of course.) -hpa

Hm, the struct in wakeup.h doesn't contain it too. Why exactly is it necessary? In fact, I'd prefer to remove .signature from the header and use the end_signature only, so that I can use struct wakeup_header for addressing Do you mean placing the header at the end will fill the area between it and the Well, I think we can do that. Rafael --

Can we please use C style in this file. Like this: { .header : { *(.header) } It is not as short as the above but it pays of to keep an consistent style in the whole file and across different .lds files. And for good measure name it wakeup.lds. Do we never need data from a .h file? If we do name it wakeup.lds.S and kbuild will fix it (assuming we have wakeup.lds PAGE_SIZE * 4? Sam --

Why not just put the structure at 0, and put pointers in the structure to everything else you need? -hpa --

No interrupts. We're in the real mode, so BIOS calls should be accessible. Rafael --

struct wakeup_header. I really need the entry point to be at offset 0, so that I can get pointers to my data. I could not figure out how to do it any other way. And if 0 is taken, I thought I'd put header at the end. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

wakeup.ld: SECTIONS { . = 0x3f00; .header : { *(.header) } Ok, if we can use defines, this is probably great candidate for one of them. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Can you post a delta against my versoin? I do not see any changes from a quick glance. This is probably more acceptable version of beep; but there are probably even better ways to clean it... if (wakeup_header.realmode_flags & 4) { inb(97); outb(0, 0x80); outb(3, 97); outb(0, 0x80); outb(-74, 67); outb(0, 0x80); outb(-119, 66); outb(0, 0x80); ...

It's good practice to have at least paragraph (segment boundary) alignment between different types of data. In the case of the .bss, it also allows cleaning with rep;movsl. It's technically not all that necessary (except for 4-byte alignment for Not really, because it's not at all related to the kernel page size; the reference to pages there is informal. If we go to a larger virtual page size we do NOT want this to change. -hpa --

May I ask how you spot tab vs. 8 space problems? Do you apply the patch and check in an editor? 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 --

If you use the backlight class do we really need to duplicate the lcd_level file under sysfs too? Richard --

Nope, I don't think 2.6.24.x needs this fix. Commit 8efe444038a205e79b, wasn't been in 2.6.24. Only 2.6.25-rc0 affected. If applied to 2.6.24.x, it will break things. Thanks, -- Anton Vorontsov email: cbou@mail.ru backup email: ya-cbou@yandex.ru irc://irc.freenode.net/bd2 --

Agreed :-) One more finding: after turning off CONFIG_SLUB and usng CONFIG_SLAB instead, I cannot reproduce the bug. Also, a quite bit Qt-Embedded 3.x programm survives without any trouble the suspend/resume. So I think that I don't have a general memory corruption problem. This is however just a feeling, not an evidence. --

Just a note: I don't use vanilla v2.6.24, but v2.6.24 plus a bunch of patches on top of it. I minimized them and for v2.6.24, this is the minimal number of patches needed to get the device up & running and also supending & resuming: $ quilt series + rt3000-core.patch + rt3000-defconfig.patch + rt3000-smc91x-mac.patch + mn-keyb.patch + mn-smc91x.patch + mn-suspend-ignore-console.patch = ARM-pxa-fix-PXA27x-resume.patch rt3000-core: this is the RT3000/RT4000 machine specific code, ...

I did not test CONFIG_PARAVIRT at all. I just fixed what its introduction had done to break generic x86-64. Thanks, Roland --

Did you test without CONFIG_PARAVIRT, and CONFIG_PARAVIRT booted both with and without the "noreplace-paravirt" parameter? --

There is another issue I see in the recent pageattr changes, again in the GART driver context. GART drivers use map_page_into_agp() and unmap_page_from_agp() during runtime (and not just during load and unload of the driver module). In the recent pageattr changes, we seem to have dropped the concept of reverting to the large page(for the kernel identity mapping) while changing the attribute back to WB. In this GART driver context, over the time, potentially kernel identity mappings might be ...

My initial test is end-to-end 1000Mbps, but I've got a few different I'm running juno-z with 2, 4, & 8 threads of syn flood to port 80. wireshark measures 2 threads at 350pps, 4 threads at 750pps, and 8 threads at 1200pps. Under no SYN flood, the server handles 750 HTTP requests per second, measured via httping in flood mode. With a default tcp_max_syn_backlog of 1024, I can trivially prevent any inbound client connections with 2 threads of syn flood. Enabling tcp_syncookies brings the ...

Or maybe use percpu storage for that... I am not sure if cookie_hash() is always called with preemption disabled.= (If not, we have to use get_cpu_var()/put_cpu_var()) [NET] IPV4: lower stack usage in cookie_hash() function 400 bytes allocated on stack might be a litle bit too much. Using a=20 per_cpu var is more friendly. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>

I don't see this patch in Linus's tree, I see the patch you are patching, but not this one :) Can you tell me the git id of the patch you wish to go into the stable tree, and send the whole thing to us? thanks, greg k-h --

Sounds good, I've dropped it from my queue, so please resend it when it hits Linus's tree to stable@kernel.org if you want it there. thanks, greg k-h --

tg3 is fine now, thanks everyone. :) --

I cannot see any other way out of this than to loose all the newly added consts. We have to different behavior across platforms to find a suitable solution that is reliable. [Kept rest of mail as I added Jan - hope he have some ideas to throw in]. --

Tested on i386/x86-64. Acked-by: Masami Hiramatsu <mhiramat@redhat.com> -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhiramat@redhat.com --

Here you go, Cheers, Chris Linux version 2.6.24 (chris@twopit.underworld) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP PREEMPT Thu Feb 7 00:01:40 GMT 2008 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001ffeb000 (usable) BIOS-e820: 000000001ffeb000 - 000000001ffef000 (ACPI data) ...

He has hit the BUG() here in megaraid_mbox_dpc(): // Make sure f/w has completed a valid command if (scb->state != SCB_ISSUED) { con_log(CL_ANN, (KERN_CRIT "megaraid critical err: invalid command %d:%d:%p\n", scb->sno, scb->state, scp)); BUG(); continue; // Must never happen! } --

applied. thanks, -Len --

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

I haven't revert the changes. It's only moved the notifier chain calls from the ioctls to open/release in user.c . Thanks, Rafael --

Linus -- as there are no other pending objections to the code so far, and I think we agreed that this has nothing to do neither with wireless tree, nor with networking drivers in general (it is basically a PCMCIA serial driver, and thus there is no relevant maintainer alive), would you please consider merging it for 2.6.25? David, thanks a lot for taking care of another respin. Thanks, -- Jiri Kosina --

>>>>> "Ondrej" == Ondrej Zary <linux@rainbow-software.org> writes: Ondrej> Tested using 3 ISA cards in various combinations of PnP and non-PnP modes. Ondrej> #ifdef CONFIG_EISA Ondrej> ret = eisa_driver_register(&el3_eisa_driver); Ondrej> + if (!ret) Ondrej> + eisa_registeted = 1; Ondrej> #endif ^^^^^^^^^^^^^^^ You probably should at least test-compile this driver with CONFIG_EISA enabled... Regards, M. -- And if you don't know where you're going, ...

Hi, I also don't like that voodoo, but as long as we don't have more information or let alone specs.. well, i really wish i could provide more than the already IMHO obvious sequence.. voodoo-adress and value to make config Also thought about that, but as far as i can see this cannot happen since we only probe for those two devices and deny to continue if anything else /those two were not found in the beginning. Thanks, Frank --

On Thu, 7 Feb 2008 09:20:38 +0100 Can never be too careful though. :) I've applied the patch for now. Feel free to keep digging and finding some = docs for those regs though. Rgds Pierre

The fact that you now have to shadow operations on vm_file by operations on your exe_file, easy to get out of step; and that we'll tend not to notice when it goes wrong, because the common case will have them both in the root mount (that will hide busy errors, won't it? or am I mistaken?). Though I should concede that your latest patch looks like it catches all the places it needs to, and that they don't really stretch beyond mm/mmap.c. If you provided functions to do the ...

Hi Linus, If you listen carefully you can hear dozens of Linux kernel developers collectively holding their breath and thinking "Maybe Linus will finally merge kgdb". Yes, user bug reports are important. Developer efficiency is important too. Regards, Daniel --

Don't hijack threads, it completely messes up everyone's mail box and makes your mail very difficult to find. On Thu, 31 Jan 2008 17:35:51 +1100 That would be the hardware. We don't do any software timeout handling. I can only see one of two options here. Either there is some miscalculation of the timeout, or you have a hardware bug. And to determine that we need to check what is actually going over the wire. As you've checked the data contents, that isn't the problem. So the only remaining ...

On Wed, 6 Feb 2008 14:08:35 -0700 What would you be comparing them against? Perhaps you could pass a struct device * from the platform code, which can be compared against "dev" in struct dma_device? Or you could check dma_device->dev->name perhaps. In any case, I agree we probably don't need the engine_type field. Haavard --

On Mon, 28 Jan 2008 15:07:06 -0400 NAK. This header should not be needed in host drivers. It's a clear sign you're doing something bad. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org --

Yes, please. And any chance we you could resend the current version of the patch to lkml? I've lost a little track of how it looks currently. --

Hi Mark, The probe error handling is not quite correct. When we reach the fragment above ret variable is 0 so if platfrom_device_alloc() fails we will return 0 and the device will be considered bound but in half-dead state. Please make sure that proper error is returned in all cases. Also please do not mix out of line and in-line error unwinding (input_free_device() should be called in the error path and if you are concerned about double-free after input_unregister_device() just set ...

Of course. Naturally it's near impossible to prevent people from tweaking the software. But reasonable restrictions are what regulatory Yes it can. You're confusing the software with different or modified software. Different things. And by the way, if you modify the software to defeat the restrictions you are committing a criminal act, or you would be if you did it in Australia. You'd probably get with What's your point? That it's easy to break the law? Nobody's ...

Hi David, Ok. I am not interested in continuing this discussion so please remove from the cc. Thanks. Pekka --

I'm afraid you are wrong despite your desperate attempts to reinterpret your own comments. The civil law is "balance of probability". Those are the precise words used. As it is a dispute between two civil parties with no assumed right or wrong it is a matter of which interpretation is most likely "proof" doesn't come into it whatever version of proof you want to pick this email. "burden of proof" is a specific term with a specific meaning in law. --

It would not be improper to say that "such and such a lawyer said this and that." I'm not proposing that you breach their copyright in their opinions, but there is such a thing as fair use, and I expect you to use Various reasons. I don't know that you're a liar and I'm too much the gentleman to accuse you of that without being quite sure of my facts. As it happens I assume you're not lying, but I do suspect you of having misrepresented what was said to you. I don't say you've done this ...

[Empty message]

And break the HW :-) Actually, they could be happier, since then you have to buy another... [...] Urgh... I don't think NDAs and Open Source mix well... Are you sure your bosses KNOW Linux and the OS in general? :-) BYtE, Diego. --

We were talking about the USA. I am not aware of any Australian answers to the specific question of software as an appropriate safeguard. The US requires appropriate safeguards but no court has actually established an Diddums, thats what the license says. Requiring ac cinema pays the movie company puts a cinema at a disadvantage in the market from those who don't pay. That is why we have laws to try and ensure that crime is not profitable. Alan --

talk to Greg KH about this. Have NDAs and open source work together is really simple. Have the NDA say that you can use all provided documentation to write an open source driver and publish it under GPL. A lot of companies are okay with this these days. The Linux Foundation should have NDA template texts for this. Regards Marcel --

We most certainly were not. We are talking about Linux, and everybody Probably the same in Australia, for the same reason as in USA. Probably That's what you claim it says, but has any court, anywhere, agreed with you? You claim the authority of others (i.e. numerous lawyers), but I don't believe you have that authority. You're just starting hearsay. You've never said what lawyers and you've never told us what they actually said. I see that you have a clear political agenda, and I ...

Your last sentence, above: That is what EXPORT_SYMBOL_GPL attempts to do. The place to state such a requirement is in the licence, not in the source code. That is what I am talking about. I can't provide you with software under a licence that says, "you are free to use this software in any way you want," and later say, "oh, but in the source code is I don't, but EXPORT_SYMBOL_GPL doesn't do that. It makes an ambit claim, that might coerce an author into making a driver GPL, but might also ...

I've had this argument before. The conclusion is that spiteful people insist on using the legal meaning for words which have explicitly been said using plain English. If you are spiteful, then by all means rant about legal terms, but do so knowing that everybody understand what I mean. Even in civil matters, it is necessary for the appellant to present a case and the respondent may simply pick holes in it. Further, don't forget that copyright violation is a criminal matter in some ...

> Perhaps you might read up on unfair trade practices and contract law. I'm familiar with them to some extent because I have run companies in the past and continue to do so as a sideline to my Red Hat work. I also spend First mistake: The GPL is not a contract it is a license. If the GPL was a contract it could most certainly impose conditions upon original works. Contract law permits to write things like "If you buy the source for this package you agree not to write a competing product ...

If the device is well engineered, there's nothing the sw can do to make it work outside regulatory limits. Sometimes there's simply NOTHING the SW can do to *avoid* it. Think about a CB radio. International standard is 5W (well, somewhere it's 3, IIRC, but that's another story: nobody produces a special model with a final amplifier for only 3W, everyone produces the 5W and turns down power in some other way). But linear amplifiers are commonly sold. And (at least in Italy) it's not illegal ...

Hi Christer, On Tue, 5 Feb 2008 13:46:08 +0200 I have simply stated that (1) the problem boils down to what is derived work and what is no and (2) the developers use the EXPORT_SYMBOL_GPL as a hint of what they think to be derived work (not necessarily tested in court). The _logical conclusion_ of these two simple facts is, of course, to _not use_ functions marked as EXPORT_SYMBOL_GPL unless you're willing to test your belief in court. Now I see you really want to argue about this but ...

That's naive, since requirements differ in different jurisdictions, as In Australia it's illegal to own them (CB licensee; HAMs are allowed to That's part of it's purpose. It permits a manufacturer to make a global device that operates within local restrictions. --

A lot of software is written specifically to run on Linux, but that doesn't mean it's derived from Linux. In the case of user-space code it's widely understood that no licence restrictions are conferred. The argument relating to kernel modules is that a module is somehow different because it runs in kernel mode. I can't see it, and in view No. Holders of Linux copyrights would have to prove that the proprietary code is derived from the kernel. They have the burden of proof, and defence ...

This nicely expresses my position. --

That would be improper as you'd well know if you knew the first thing Why don't you just say "you are a liar" as I assume that is what you want Linux is GPL licencesed code you either follow the licence or don't use I don't actually care. If you want to do binary products then pick a The market will ultimately decide which models of software development are the right ones for which situation. Alan --

I actually care about Linux certainly more than you do. I care about the copyright of my kernel contributions and the contributions of others. Not caring about these things is what is the worst. It means you disrespect all the work that a lot of people and companies have put into Linux. And don't quote we with "I don't care". Alan already complained about your quoting style. Don't put words in my mouth that I never said. The Linux kernel is licensed under GPL. If you don't like, go and ...

Actually that is also questionable. The only reason it is fairly certain in Linux is Linus went to the trouble of stating that interpretation was Wrong again. In civil law in the USA and most of europe the test is "balance of probability". Alan --

In Australia, devices require approval from a regulatory body. Such Yes it is; but what is simple, is to understand that lack of such safeguards, even though they are imperfect, does result in refusal to Also, particularly Australia and New Zealand. I can't imagine France or That is what I was saying: To require that only GPL-licenced USB drivers may be used with Linux puts Linux at a disadvantage in the market. The embedded market is simply huge. Microsoft would _love_ Linux to ...

If you know of something relevant, give pointers. --

Mea culpa. It is indeed a licence, which I did and do know. I really did mean, "The licence (GPL)" --

Am Thu, 07 Feb 2008 23:49:42 +1030 What are you trying to say? You like the license but you're against It is not legally meaningless if copyright holders publicly state how they interpret the license and what they consider a license violation. In the end, a court must decide, but lots of courts will at least look That's your opinion because it's damaging _your_ political goals. Hans --

If that were true, you couldn't legally install more than one program on a computer without permission from all the copyright holders without specific license permission. A "work based on the Program" is the same as a derivative work. A laptop with an assortment of different programs on it is not a work, it is a collection of works. DS --

Again, I missed who wrote the above. I'm reminded of Apple computer, who explaining some engineering decisions in the Apple ][ pointed out that an additional 10c in components adds $10 to the retail price (or something rather like that.) Cheap, cheap, cheap helps market share far more than quality. --

What is the "propability" that drivers using the interfaces now declared as "EXPORT_SYMBOL_GPL" are derived from the Linux kernel source code instead of some definitive documentation? As you all (should) know there is a book called "Linux Device Drivers, 3rd Edition" published by O'Reilly (ISBN 0-596-00590-3)". All the USB kernel interfaces are documented there. One of the authors is Greg Kroah-Hartman which makes this book "definite" source of information on Linux USB driver programming. ...

In which case for each statement please give the case at appeal or higher Export symbol is a guide. There is no reason to think that EXPORT_SYMBOL symbols alone mean your work is somehow not derivative. --

Al, can you try a patch posted to linux-fsdevel and linux-ext4 from Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp> to see if this improves your situation? Dated Mon, 04 Feb 2008 19:15:25 +0900. [PATCH] ext3,4:fdatasync should skip metadata writeout when overwriting It may be that we already have a solution in that patch for database workloads where the pages are already allocated by avoiding the need for ordered mode journal flushing in that case. Cheers, Andreas -- Andreas ...

I think the other data point here would be that final target design needs to be as generic as possible. Generic in the sense that the engine eventually needs to be able to accept NDB and other ethernet based target mode storage configurations to an abstracted device object (struct scsi_device, struct block_device, or struct file) just as it would for an IP Storage based request. We know that NDB and *oE will have their own naming and discovery, and the first set of IO tasks to be completed ...

why should linux as an iSCSI target be limited to passthrough to a SCSI device. the most common use of this sort of thing that I would see is to load up a bunch of 1TB SATA drives in a commodity PC, run software RAID, and then export the resulting volume to other servers via iSCSI. not a 'real' SCSI device in sight. As far as how good a standard iSCSI is, at this point I don't think it really matters. There are too many devices and manufacturers out there that implement iSCSI as ...

Since the focus of this thread shifted somewhat in the last few messages, I'll try to summarize what has been discussed so far: - There was a number of participants who joined this discussion spontaneously. This suggests that there is considerable interest in networked storage and iSCSI. - It has been motivated why iSCSI makes sense as a storage protocol (compared to ATA over Ethernet and Fibre Channel over Ethernet). - The direct I/O performance results for block transfer sizes below 64 KB are ...

unfortunatly it doesn't even compile: distcc[30740] ERROR: compile (null) on localhost failed In file included from include/asm/futex.h:2, from kernel/futex.c:59: include/asm/futex_32.h:72:29: error: macro "__futex_atomic_op1" passed 6 arguments, but takes just 5 In file included from include/asm/futex.h:2, from kernel/futex.c:59: include/asm/futex_32.h: In function 'futex_atomic_op_inuser': include/asm/futex_32.h:71: error: '__futex_atomic_op1' undeclared ...

Zhang and Dan, What's the status on this patch? Will it make 2.6.25? -- Timur Tabi Linux kernel developer at Freescale --

On Thu, 07 Feb 2008 10:20:39 +0900 Yeah, it looks good. Too bad it still does not work :) Oh well, I'll look at that tomorrow. Jet lag is catching up with me, so I should get some rest first... -- All rights reversed. --

No. Why have a separate "port" device for every ethernet port? What keeps you from just creating the different network devices for your device, and pointing the parent to the same 789D.001.XXXXXX-P1 device? Lots of PCI devices hang "class devices" off of them all the time, why would this be any different from that? thanks, greg k-h --

Hi, I was wondering where these changes are right now. I don't see the sysfs interface for rt-group-sched in mainline right now. Thanks, -- regards, Dhaval --

On Thu, 07 Feb 2008 10:54:05 -0500 nothing should use these directly. So static is the right answer ;) --

regression for sale :-) The above patch, after sitting in -mm for approximately 3 months, just went upstream today via commit d9afa43532adf8a31b93c4c7601f and promptly broke tonight's x86.git randconfig qa run via tons of these messages: [ 3.768431] BUG: scheduling while atomic: swapper/1/0x00000002 [ 3.769430] 1 lock held by swapper/1: [ 3.770437] #0: (riscom_lock){--..}, at: [<80389ceb>] rc_release_drivers+0xe/0x33 [ 3.776430] Pid: 1, comm: swapper Not tainted 2.6.24 ...