Hi, a topic that just came up in kernel summit is a script to remove unneeded kernel configs automatically to reduce the compile time. Incidentally, I already wrote such a script during the last SUSE hack week a couple of weeks ago, so I'd like to share here, hopefully to give an idea for further improvements. The script checks the currently loaded modules and trims other CONFIG_XXX=m simply, and tries make oldconfig, and writes out the resultant .config in the current directory after some ...

Use new MODULE_DEVICE_TABLE(dmi, ...) facility. There's no need for every driver to screw it up for themselves, when the alias can be generated automatically. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> diff --git a/drivers/video/backlight/mbp_nvidia_bl.c b/drivers/video/backlight/mbp_nvidia_bl.c index 385cba4..06964af 100644 --- a/drivers/video/backlight/mbp_nvidia_bl.c +++ b/drivers/video/backlight/mbp_nvidia_bl.c @@ -111,6 +111,4 @@ module_exit(mbp_exit); ...

This makes modpost handle MODULE_DEVICE_TABLE(dmi, xxxx). I had to change the string pointers in the match table to char arrays, and picked a size of 79 bytes almost at random -- do we need to make it bigger than that? I was a bit concerned about the 'bloat' this introduces into the match tables, but they should all be __initdata so it shouldn't matter too much. (Actually, modpost does go through the relocations and look at most of them; it wouldn't be impossible to make it handle string ...

usage: in .h to have #define KERN_PCI "<pci>" in .c to have DEFINE_LOGLEVEL_SETUP(pci, KERN_PCI, "pci:"); then could use printk(KERN_DEBUG KERN_PCI fmt, ...); and command line loglevel=pci:8 you can add different printk to different files of one subsys if you like not just one susbsys one tag, and don't need to update kernel.h to add more tags YH --

so could make subsys easy to add loglevel and xxx_printk v2: make it more genric, so subsys user only need to two line macro v3: add back nameStr, so could find out iommu: and iommu_gart: and etc v4: use printk intead of pci_printk usage: in .h to have #define KERN_PCI "<pci>" in .c to have DEFINE_LOGLEVEL_SETUP(pci, KERN_PCI, "pci:"); then could use printk(KERN_DEBUG KERN_PCI fmt, ...); and command line loglevel=pci:8 you can add different printk to different files of one ...

v2: use printk(KERN_DEBUG KERN_PCI ... Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- drivers/pci/probe.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) Index: linux-2.6/drivers/pci/probe.c =================================================================== --- linux-2.6.orig/drivers/pci/probe.c +++ linux-2.6/drivers/pci/probe.c @@ -304,7 +304,7 @@ static int __pci_read_base(struct pci_de } else { res->start = l64; res->end = l64 + ...

Hello, My operating system Debian GNU/Linux "lenny"=20 I am compile new kernel version "2.6.26.5" warning PHYSMAP compat code.. what is PHYSMAP compat code? -> CC [M] drivers/mtd/maps/physmap.o drivers/mtd/maps/physmap.c:252:2: warning: #warning using PHYSMAP compat code and warning message: 1. CC [M] drivers/net/skfp/ess.o drivers/net/skfp/ess.c: In function =E2=80=98ess_send_response=E2=80=99: drivers/net/skfp/ess.c:513: warning: cast from pointer to integer of different ...

Greg, please proactively push this patch of your's upstream as it will kill off a regression list entry: http://marc.info/?l=linux-kernel&m=121976424221858&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11439 Subject : [2.6.27-rc4-git4] compilation warnings Submitter : Rufus & Azrael <rufus-azrael@numericable.fr> Date : 2008-08-26 9:37 (18 days old) References : http://marc.info/?l=linux-kernel&m=121974353815440&w=4 Handled-By : Greg KH <gregkh@suse.de> Patch : ...

Warning message list kernel (2.6.26.5) cpu: Intel Celeron D 1. CC [M] drivers/pcmcia/i82365.o drivers/pcmcia/i82365.c: In function =E2=80=98init_i82365=E2=80=99: drivers/pcmcia/i82365.c:1296: warning: ignoring return value of =E2=80=98request_irq=E2=80=99, declared with attribute warn_unused_result 2. CC drivers/pci/search.o drivers/pci/search.c:145: warning: =E2=80=98pci_find_slot=E2=80=99 is depre= cated (declared at drivers/pci/search.c:134) drivers/pci/search.c:145: warning: ...

I was reviewing the patch below, and I'm a little confused about the added up() call. This semaphore is used to signal an interrupt arriving, where the code below is waiting for the interrupt. The added up() effectively signals that the interrupt arrived even tho it hasn't.. Which means the next down() call won't sleep at all it just falls through .. I don't think that is what's desired, but I though I would ask.. The other question is that it's called conditional on a potentially random ...

Hi, Booting 2.6.27-rc6, or the current Linus' git on large x86_64 NUMA wedges intermittently. This happens on machines with more than 4 NUMA nodes. The same kernel boots on similar hardware with fewer NUMA nodes (or boards). 2.6.27-rc3 seemed to boot well on similar configurations, so looks like a regression crept in between 2.6.27-rc3 and rc6. I am trying a few things -- commandline options to eliminate popular suspects (such as unsynced tsc clocksources) as well as git bisect, but wanted ...

A segmentation fault can occur in kimage_add_entry in kexec.c when loading a kernel image into memory. The fault occurs because a page is requested by calling kimage_alloc_page with gfp_mask GFP_KERNEL and the function may actually return a page with gfp_mask GFP_HIGHUSER. The high mem page is returned because it was swapped with the kernel page due to the kernel page being a page that will shortly be copied to. This patch ensures that kimage_alloc_page returns a page that was created ...

Dear Email Account Owner, This message is from UPGRADING messaging center to all WEBMAIL emailaccount owners. We are currently upgrading our data base and e-mail account center. We are deleting all unused email account to create space for new accounts.To prevent your account from being deactivated you will have to update it. CONFIRM YOUR EMAIL ACCOUNT Email Username : ............... Email Password : .............. Date of Birth : .................. Country or Territory : ...

use DEFINE_LOGLEVEL_SETUP to set loglevel for acpi v2: use <acpi, "acpi:"> instead Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- drivers/acpi/osl.c | 2 ++ include/linux/acpi.h | 1 + 2 files changed, 3 insertions(+) Index: linux-2.6/drivers/acpi/osl.c =================================================================== --- linux-2.6.orig/drivers/acpi/osl.c +++ linux-2.6/drivers/acpi/osl.c @@ -75,6 +75,8 @@ EXPORT_SYMBOL(acpi_in_debugger); extern char line_buf[80]; ...

usage: in .c to have DEFINE_LOGLEVEL_SETUP(pci, "pci:"); in .h to have DECLARE_LOGLEVE(pci); then could use pci_printk(KERN_LOG_DEBUG, fmt, ...); and command line loglevel=pci:7 you can add different printk to different files of one subsys if you like not just one susbsys one tag, and don't need to update kernel.h to add more tags YH --

so could make subsys easy to add loglevel and xxx_printk v2: make it more genric, so subsys user only need to two line macro v3: add back nameStr, so could find out iommu: and iommu_gart: and etc usage: in .c to have DEFINE_LOGLEVEL_SETUP(pci, "pci:"); in .h to have DECLARE_LOGLEVE(pci); then could use pci_printk(KERN_LOG_DEBUG, fmt, ...); and command line loglevel=pci:7 you can add different printk to different files of one subsys if you like Signed-off-by: Yinghai Lu ...

The difference is that things that read the kernel log in userspace will be able to make partial sense of the latter, but not the former. It will thus make the transition smoother. -hpa --

maybe #define KERN_LOG_EMERG 0,KERN_EMERG #define KERN_LOG_ALERT 1,KERN_ALERT ... ? or better - create printk2(level, fmt) which prints "<", level, ">", fmt and wrap it with pci_printk / acpi_printk? Marcin --

according to the code flow, these two is the same... will double check it. YH --

hi, I agree :) __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it --

Make the user pass a "vpcworkarounds" boot option... --

I think you still want the nopl enabled for 64-bits. This is how I detect virtual pc. I based it on a google search. Microsoft itself provides no info: #include <stdio.h> #include <signal.h> #include <stdlib.h> void except(int e) { printf("Not in Virtual PC\n"); exit(1); } int main() { signal(SIGILL, except); asm("\n" "mov $0x01, %eax\n" /* function number */ ".byte 0x0f, 0x3f, 0x07, 0x0b\n" /* call VPC */ ); printf("Inside Virtual PC\n"); return ...

Actually, you can pass noreplace-paravirt, but that is non-obvious to the regular user. --

Well, isn't that "interesting". 0F 3F is in the range expected (although not documented) to be used for 3-byte opcode prefixes in the future. It's also the Centaur ALTINST instruction (which I believe have to be enabled via an MSR, so in that way it's not a bad choice.) It's definitely less broken than the official way to detect VMWare, but still pretty daft. (CPUID, MSR or PCI IDs make a lot more sense.) The "official" way to detect Virtual PC is apparently to look for "Microsoft ...

Why can't the file system registration code set filp->f_op->aio_read to generic_file_aio_read? --

Hi, Cc: Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp>; akpm@linux-foundation.org; linux-kernel@vger.kernel.org; Maybe it is clear with an example: +/* + * file_pos_read/write is atomic by using sequence lock on 32bit arch. + */ +static inline loff_t file_pos_read(struct file *file) +{ +#if BITS_PER_LONG == 32 && defined(CONFIG_SMP) + loff_t pos; + unsigned int seq; + + do { + seq = read_seqbegin(&file->f_pos_seqlock); + pos = file->f_pos; + } while ...

Jacek> I was thinking the same few years ago, but on two Asus boards Jacek> two had problems. K8V-X SE is the board I have now, it's very Jacek> bad choice for Linux, it crashes very often when starting X Jacek> (with DRI) - it's related to buggy BIOS and AGP. Sure, I can understand your frustration here. I'd be pissed too. :] I spent a bunch of time looking at motherboards and finally settled on the one I got because of good reports. Don't get a recent board, get something that's been ...

Of course it makes a difference. The reason why two states are provided is to allow userspace to distinguish whether it can unblock the device or not. It's clear that b43's rfkill code is astonishingly broken (and that's not a criticism of anyone involved - the documentation's confusing and there weren't any good examples of how it should be implemented). The real question is how the LED state is supposed to be being toggled, and what that's got to do with rfkill. I /think/ that the ...

Oh, hey, I suck. This one might stand a better chance of not falling over. diff --git a/drivers/net/wireless/b43/rfkill.c b/drivers/net/wireless/b43/rfkill.c index fec5645..991e318 100644 --- a/drivers/net/wireless/b43/rfkill.c +++ b/drivers/net/wireless/b43/rfkill.c @@ -49,21 +49,18 @@ static void b43_rfkill_update_state(struct b43_wldev *dev) struct b43_rfkill *rfk = &(dev->wl->rfkill); if (!dev->radio_hw_enable) { - rfk->rfkill->state = ...

It locks up tight with a kernel panic when booting. I have a screen picture that I will send separately to Matthew. Larry --

When I disable the b43 device in my laptop via acer-wmi (which in turn, calls into the laptops firmware), b43 physically cannot re-enable it (a not uncommon case on a lot of laptops). In which case, as far as b43 is concerned, the wireless radio is then in RFKILL_STATE_HARD_BLOCKED, since b43 is unable to re-enable the radio on the hardware. So yes, it is quite possible for b43 to be in RFKILL_STATE_HARD_BLOCKED. -Carlos -- E-Mail: carlos@strangeworlds.co.uk Web: ...

Hmm... if this lack of LED control when HARD_BLOCKED is a problem in rfkill, I will track it down and fix it. The rest of the stuff (b43's usage of rfkill), is a problem for the people who know the b43 driver to fix, I don't dare touch it and break it further. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --

Just this should be enough to fix the regression for 2.6.27 (and should be trivial to port to b43legacy) in the immediate term (I was planning to send something similar). The rest of the patch is out-of-scope for 2.6.27, but is definitely along he right lines, IMHO (and it would be good if we can get a working version of it in to 2.6.28). I may try and look at it later, as I do have my b43 hardware handy. -Carlos -- E-Mail: carlos@strangeworlds.co.uk Web: strangeworlds.co.uk GPG Key ...

Sure it is. It's the common case, if there's a button. But I don't know how to tell the rfkill subsystem about the states and I do not _want_ to. See, that crap code _always_ blew up for every single patch we did. I'm tired of this and I am not interested in that anymore. Please revert that patch and if that makes it work I'm fine with it. I'm still waiting for the sane rfkill API where we have three functions rfkill-allocate rfkill-hw-state-changed rfkill-free That's all I need. All ...

Hi, i was thinking about introducing a file_pos_update() not implemented using file_pos_read()/file_pos_write() and taking the seq_lock or disabling preemption only one time __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it --

Could you recommend motherboard which works perfecly stable with Linux? Last time I bought Asus K8V-X SE which was huge mistake - it has serious problems with AGP in Linux. Now I think about Intel chipset - P35 or P45. I want Asus, Gigabyte or MSI board with heat pipe. But I found another issue with audio and network drivers for Asus boards, so maybe I will skip Asus this time? Which motherboard works stable for you? --

The conventional way of ensuring that a piece of hardware will work well with Linux is to hire a few kernel developers, and ship a hundred samples to other kernel developers around the world, with complete hardware specs. This technique is slow and expensive, and still not foolproof. Alternatively, you could ask for motherboard recommendations on an enthusiast forum, which this mailing list is not. This technique is fast and cheap, but still not foolproof. -- Chris --

On Tue, 16 Sep 2008 14:27:13 +0100 Acked-by: Alan Cox <alan@redhat.com> --

The key word is "ideally". We'd like it to work that way, but it doesn't. Patches to fix this are welcome. -- Chris --

Hi Frederic, thank you very much! this is very useful for me. :-) Best regards, Yang --

And perhaps you should have a look at the sched_switch tracer which will log for you the different context switches. Regards, Frederic. --

Hi! That doesn't make much sense as the same thread can run on a different CPU after each scheduling decision. And - as it is in userspace - scheduling can happen before any assembler op. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services --

On Tue, 16 Sep 2008 16:11:10 +0200 the getcpu() system call will do what you want. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

<linux/fcntl.h> conflicts with glibc's <fcntl.h>. It breaks building kdelibs, kdepim and pinot. It's regression itroduced by commit 4006553. Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name> Cc: Ulrich Drepper <drepper@redhat.com> Cc: Davide Libenzi <davidel@xmailserver.org> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> --- include/linux/inotify.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git ...

Even if userspace applications shouldn't use it directly this doesn't sound right: We shouldn't force all libc implementations to copy the contents into a private header. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 And? None of these programs should use <linux/inotify.h>. There has for the longest time been a <sys/inotify.h> header which doesn't need any kernel headers. In fact, <linux/inotify.h> should not be exported. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 ...

Ok. Let's unexport <linux/inotify.h>. diff --git a/include/linux/Kbuild b/include/linux/Kbuild index b68ec09..dbb8107 100644 --- a/include/linux/Kbuild +++ b/include/linux/Kbuild @@ -240,7 +240,6 @@ unifdef-y +=3D igmp.h unifdef-y +=3D inet_diag.h unifdef-y +=3D in.h unifdef-y +=3D in6.h -unifdef-y +=3D inotify.h unifdef-y +=3D input.h unifdef-y +=3D ip.h unifdef-y +=3D ipc.h diff --git a/include/linux/inotify.h b/include/linux/inotify.h index bd57857..0188b6a 100644 --- ...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It would unnecessarily require programs to be changed. I've explained that programs cannot efficiently use accept() and poll() when multiple threads are involved. This means in these situations you'll find a This is because none of the other interfaces had (so far) be revised. You use your own opinion as the deciding factor? The behavior differs The signal set wasn't actually my idea. See: I have explained the need already. you ...

Is not more efficient here a compare xchg operation? Regards Michael __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it --

Hi. Currently reading or writing file->f_pos is not atomic on 32bit environment, so two or more simultaneous access can corrupt file->f_pos value. There are some past discussions about this issue, but this is not fixed yet. http://marc.info/?l=linux-kernel&m=120764199819899&w=2 http://marc.info/?l=linux-kernel&m=114490379102476&w=2 Protecting file->f_pos with a lock adds some overhead but I think we should fix this. I used seqlock to serialize the access to file->f_pos. This approach is ...

The WM8400 is a highly integrated audio CODEC and power management unit optimised for use in mobile multimedia applications. This patch adds core support for the WM8400 to the MFD subsystem. Both I2C and SPI access are supported by the hardware but currently only I2C access is implemented. The code is structured to allow SPI support to be slotted in later. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> --- Changes since last time: - Don't depend on MFD_CORE, we don't use ...

These patches against the regulator development tree add basic support for the WM8400, an audio CODEC and PMU targeted at multimedia systems, covering basic PMIC functionality only. Since the functionality of the device covers multiple subsystems with arbitration required a core driver is provided in drivers/mfd. I think I've covered all the issues raised last time, erring on the side of split headers rather than unifying them, details in the individual patches. The following changes since ...

BUG_ON it was a way to say: "hey you've used the do_sync_read/write as read/write operation but you don't specified an aio_read/write", but your solutions it's good too. --

On Tue, Sep 16, 2008 at 2:59 PM, Marco Stornelli Instead of doing a BUG_ON() why can't we simply fall back to the generic_aio functions since most of the fs tend to do so as below. Signed-off-by: Manish Katiyar <mkatiyar@gmail.com> --- fs/read_write.c | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/read_write.c b/fs/read_write.c index 9ba495d..5439bc4 100644 --- a/fs/read_write.c +++ b/fs/read_write.c @@ -225,7 +225,11 @@ ssize_t ...

Hi Chris, thanks for answering my question. I repeated the test, giving the 'netcat' server a much higher priority than the load generators, and indeed, the stalling disappeared. ************************************************ The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in ...

You utterly fail to mention hrtimers even though you do touch those as well, what's more - there are hrtimers that need to be run on the cpu Why bother with the CONFIG_ variable - its so little code and it adds to We don't indent preprocessor directives like that, also we don't use idem --

Here, I've chosen cpu0 just to demonstrate migration of timers. I'm working on the algorithm to choose the best cpu or the best set of cpus to migrate the timers to. This is just the first iteration on which i intend to build upon. What could be a possible way is that, a package can be chosen as the destination for the migrated timers and any one or many cpus in that package can be the target(s). So, this will prevent Thanks for the hint. I'll do that next time. --

Hi, An idle cpu on which device drivers have initialized timers, has to be frequently woken up to service the timers. So, consolidation of timers onto a fewer number of cpus is important. Migration of timers from idle cpus onto lesser idle cpus is necessary. Currently, timers are migrated during the cpu offline operation. However cpu-hotplug for the sake of idle system power management is too heavy. So, this patch implements a lightweight timer migration framework. Also, in a multi-core, ...

This seems like an exceedingly dumb idea - cpu 0 might be a long long way from x and by pushing all timers to cpu0 you might actually overload cpu 0. Initially you talked about packages an moving timers to busy cpus - If there's anything worth reading in there it should have been mentioned in this email and preferably in some comment in the code and Kconfig help as well. --

v2: using boot_printk v3: using acpi_printk Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- drivers/acpi/numa.c | 8 ++++++++ 1 file changed, 8 insertions(+) Index: linux-2.6/drivers/acpi/numa.c =================================================================== --- linux-2.6.orig/drivers/acpi/numa.c +++ linux-2.6/drivers/acpi/numa.c @@ -150,6 +150,14 @@ static __init int slit_valid(struct acpi { int i, j; int d = slit->locality_count; + acpi_printk(KERN_LOG_DEBUG, ...

[Yinghai Lu - Tue, Sep 16, 2008 at 01:52:54AM -0700] | v2: using boot_printk | v3: using acpi_printk | | Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> | | --- | drivers/acpi/numa.c | 8 ++++++++ | 1 file changed, 8 insertions(+) | | Index: linux-2.6/drivers/acpi/numa.c | =================================================================== | --- linux-2.6.orig/drivers/acpi/numa.c | +++ linux-2.6/drivers/acpi/numa.c | @@ -150,6 +150,14 @@ static __init int slit_valid(struct acpi | ...

so could make subsys easy to add loglevel and xxx_printk v2: make it more genric, so subsys user only need to two line macro Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/vmlinux_32.lds.S | 1 + arch/x86/kernel/vmlinux_64.lds.S | 2 ++ include/asm-generic/vmlinux.lds.h | 8 ++++++++ include/linux/init.h | 36 ++++++++++++++++++++++++++++++++++++ include/linux/kernel.h | 9 +++++++++ init/main.c | 28 ...

use DEFINE_LOGLEVEL_SETUP to set loglevel for pci v2: two lines only Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- drivers/pci/pci.c | 2 ++ include/linux/pci.h | 2 ++ 2 files changed, 4 insertions(+) Index: linux-2.6/drivers/pci/pci.c =================================================================== --- linux-2.6.orig/drivers/pci/pci.c +++ linux-2.6/drivers/pci/pci.c @@ -1953,6 +1953,8 @@ static int __devinit pci_setup(char *str } early_param("pci", pci_setup); ...

By the way, we need to introduce two kinds of "max_aggr" fields to struct net_lro_mgr. The reason is that when LRO is used in the mode in which SKBs are linked, the above limitation does not exist. One will be used for drivers which use lro_receive_skb() (which does not have a limit) and one for drivers which use lro_receive_frags(). This will require changing all the drivers that use LRO. --

So you must set max_aggr to I would be interested to see that, anyway. Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. --

At Tue, 16 Sep 2008 17:34:15 +1000, Thanks for a quick action! This can help to reduce bisection time when a regression is known to be on a certain subsystem tree. Takashi --

Hi all, News: I have added a file (Next/SHA1s) that contains the SHA1 of the head of each merged tree. Hopefully people will find it useful. Changes since next-20080913: New trees: scsi-post-merge and bdev (these are both rebased onto the end of linux-next as they depend on some constituent trees). The pxa tree gained a conflict against Linus' tree. The x86 tree lost two conflicts. The tip-core tree lost a build fix patch. The kvm tree gained a conflict against the x86 ...

Not sure which tree that build problem came from, it isn't from the block git tree. -- Jens Axboe --

Hi, I've 'ported' 2.6.19 cris architecture cris v10 USB host driver from 2.6.19 to 2.6.26. Could someone take a look at the diff attached. I'm experiencing some difficulties with interrupt driven traffic, while USB to serial converter and USB mass storage seem to work. Thank you, Hinko --

Nope, it wont (nor would the old), but having irqs disabled for that long would be something worth fixing. --

L1 instruction memory and MMR memory on blackfin can not be accessed by common functions probe_kernel_read() and probe_kernel_write(). Blackfin asks for 2/4 byte align access to MMR memory and DMA access to L1 instruction memory. These functions need to be reimplemented in architecture specific kgdb.c. Update documentation and prototypes as well. Signed-off-by: Sonic Zhang <sonic.adi@gmail.com> --- include/linux/kgdb.h | 42 ++++++++++++++++++++++++++++++++++++++++-- kernel/kgdb.c | ...

That was weired, the dvd played probably 25% then all of a sudden freeze(only mplayer everything was fine); then a reboot, then the dvd played all the way through without any issues. I did a few days prior clean the lens on the disk drive, so maybe this had something todo with(can't see how), Maybe the lens is so clean, it can pickup on scratches on the disk, Anyways better to post when something like this occurs than not at all. regards; -- Justin P. Mattock --

use DEFINE_LOGLEVEL_SETUP to set loglevel for pci Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- drivers/pci/pci.c | 7 +++++++ include/linux/pci.h | 6 ++++++ 2 files changed, 13 insertions(+) Index: linux-2.6/drivers/pci/pci.c =================================================================== --- linux-2.6.orig/drivers/pci/pci.c +++ linux-2.6/drivers/pci/pci.c @@ -1953,6 +1953,13 @@ static int __devinit pci_setup(char *str } early_param("pci", pci_setup); +static ...

From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> The following patch changes to use __copy_from_user_inatomic(), but the passing parameters incorrect. x86: some lock annotations for user copy paths, v3 - add annotation back to clear_user() - change probe_kernel_address() to _inatomic*() method Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> --- include/linux/uaccess.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git ...

On Mon, Sep 15, 2008 at 6:04 PM, Hiroshi Shimamoto Thank you! This issue was causing a kernel panic on my machine when netfilter was enabled. - Steven --

This is yet another test patch. It kicks ass, eh? Not-signed-off-by: Jeff Garzik <jgarzik@redhat.com> diff --git a/Makefile b/Makefile index 4ff83ea..7d06a3e 100644 --- a/Makefile +++ b/Makefile @@ -2,7 +2,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 27 EXTRAVERSION = -rc6 -NAME = Rotary Wombat +NAME = Patch Wombat Numero Dos # *DOCUMENTATION* # To see a list of typical targets execute "make help" --

This is a test, please ignore. Not-signed-off-by: Jeff Garzik <jgarzik@blahblah.com> --- diff --git a/Makefile b/Makefile index 4ff83ea..7d06a3e 100644 --- a/Makefile +++ b/Makefile @@ -2,7 +2,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 27 EXTRAVERSION = -rc6 -NAME = Rotary Wombat +NAME = Patch Wombat Numero Uno # *DOCUMENTATION* # To see a list of typical targets execute "make help" --

Hello Ted, Thanks for noting that the problem does happen in the real world, though rarely or users do not narrow it down. Yes, it makes sense for all regressions to be fixed before releasing 2.6.27. I have put your suggestion about the Rescue CD & patch to kernel to the Ubuntu forums & bug. The latter would solve it only for one distribution, it is a start. Good point about the Rescue CD, I will get one from other distributions next time, if needed. There is no way of skipping ...

I disagree, something like a TCM can very well be present in any architecture, after all it's some kind of fast memory mapped to an address, nothing special from a software point of view. I will ask on I think I will write a module that implements a software FIFO. One function to allocate a FIFO n words deep, a "push" and a "pop" and similar. The calling module will have to setup the FIFO and use it probably in ISRs or similar (the policy will totally remain in the caller module). Any ...

Generally the genalloc pool will be set up exactly once, at boot, by the platform code. Then yes indeed the pool can be exported for driver use. --Ben. --

This isn't the right list to be discussing this on, try looking for linux-arm-kernel instead. It will get your question to the attention -- Ben (ben@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' --

since pr->id is unsigned, shouldn't something like the patch below be applied? Signed-off-by: Roel Kluin <roel.kluin@gmail.com> --- diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c index e36422a..75c0f76 100644 --- a/drivers/acpi/processor_core.c +++ b/drivers/acpi/processor_core.c @@ -667,7 +667,7 @@ static int __cpuinit acpi_processor_start(struct acpi_device *device) return 0; } - BUG_ON((pr->id >= nr_cpu_ids) || (pr->id < 0)); + BUG_ON((pr->id >= ...

On Mon, 15 Sep 2008 20:50:54 -0400 Acked-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Yoichi --

On Mon, Sep 15, 2008 at 08:50:54PM -0400, roel kluin wrote: Thanks, applied. Ralf --

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bug fix patch at: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-September/010767.html Thanks, Matt Ranostay -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjPxgAACgkQ7s2wy7nhBHULRQCeM0uqdR/rIPRHl+YhMKuZqIg7 NxEAoKQDzb2zw05UyY+i48Y2G65KZkoA =CQnT -----END PGP SIGNATURE----- --

From: Marco Stornelli <marco.stornelli@gmail.com> Now is it ok? Sorry but it's the first time I submit a patch for the kernel. Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com> --- --- linux-2.6.26.3/arch/avr32/kernel/setup.c.orig 2008-09-15 11:30:00.000000000 +0200 +++ linux-2.6.26.3/arch/avr32/kernel/setup.c 2008-09-16 09:06:31.000000000 +0200 @@ -283,6 +283,25 @@ static int __init early_parse_fbmem(char } early_param("fbmem", early_parse_fbmem); +/* + * Pick out the memory ...

doesn't sound like an easily extensible interface, better would be extending printk with a KERN_subsys tag like proposed. Perhaps Jason has better ideas - iirc he worked on something similar. --

That would be my thinking too. -hpa --

pci_printk(v, KERN_ACPI KERN_DEBUG "...\n"); ^^^^ ^^^^^^^^^ Not only do you have duplication, here, but inconsistency... -hpa --

how about pci_printk(v, KERN_DEBUG "...\n"); will put <pci> <7> ...\n in dmesg bug, and let vprintk get rid of <pci> like <7> is that what you want? YH --

you still can use pci_printk(v, KERN_PCI KERN_DEBUG "...\n"); if vprintk is expanded to handle KERN_PCI and other tags... or even you could use pci_printk(v, KERN_ACPI KERN_DEBUG "...\n"); YH --

it seem using pci_printk or acpi_printk.. could be more flexible. otherwise will need to keep update linux/kernel.h to add so call subsys tags... use only need to have DEFINE_LOGLEVEL_SETUP(xxx) in c and have DECLARE_LOGLEVEL(xxx) in .h then just use xxx_printk YH --

and in real subsys could have as many the xxx_printk that user want... YH --

Hi Anton, Yes, I've been following that thread back then and my hack is based on your patch. So yes, it seems to be the same problem and it lies in the way -rt handles the fasteoi flow. But looking at the comments from the XICS code, it seems that its wired for level only interrupts. Therefore without any more specs, it's still not clear to me that there's not a bug with the way the xics handles eHEA interrupts. Are the eHEA interrupts really level interrupts? If so why do they ...

Hi again. Problem is - fib_validate_source() explicitly doesn't allow any local address to be specified as source address. I figured out I'm not the first in need for different behavior. One of the solutions I've found is forward_shared patch [http://www.ssi.bg/~ja/forward_shared-2.6.25-2.diff] which exists for centuries. Actually, it is not working for me but it is addressing the same thing - forwarding packets with local addresses. I've solved my problem (Cisco's GRE keepalive and Linux) ...

Normally, compilebench has read phases that time how quickly the FS can read the files after a bunch of operations. The runs above didn't include the read phase, but in order to be fair to all the filesystems, compilebench figures out the native readdir order of the FS so it can create files in the optimal order for each fs. It does this by creating all the files in its datasets and using readdir to find out what order the FS returns. The files are all deleted and the real runs start. It ...

Thanks, it makes sense. It seems like diff can't handle such scenarios at all. I suppose Linux should supply its own diff tool (which uses regular diff, but implements proper file matching). Maybe git-diff alone could be included in the tarballs, I'll look into it. Cheers, --

The thing is that it looks like there are 2 headers that contain the size. 'hdr' taken by get_totalsize() is not the same as 'hdr' from which total_size is calculated here. :^) A quick search didn't reveal any docs describing the AMD microcode -- Best regards, Dmitry Adamushko --

The delay will be probably due to how slow the system can be when it runs out of memory, not from the lockdep report. Cheers, Dave. -- Dave Chinner david@fromorbit.com --

Hi Dave Yes, you already explained a similar message to me, but it was a bug, not false positive. http://lkml.org/lkml/2008/7/3/29 http://lkml.org/lkml/2008/7/3/315 I will try to bisect. It is not a OOM case. --

Dude, you don't need to cast to void*. -- Dave --

One of the big things I'm looking for in these file patches is to make sure that we can expand some day to lots of mounts and lots of filesystem namespaces. This tells me that we probably need a per-process vfsroot (which is also a shared object). We probably need to make a note in the task structure as well as here. -- Dave --

Acked-by: Serge Hallyn <serue@us.ibm.com> Thanks, Oren, I actually think this is quite nice and readable. Though three questions below. First one is, since you've mentioned having multiple threads doing checkpoint, won't you need some locking? What is the point of the 'type'? By that I mean: is it meant to catch bugs in the implementation, or bad What exactly will objref_index be used for? I don't see any real --

yes. The hash table is maintained in the kernel during checkpoint/restart, adding shared objects to the hash table when they are first seen. An object can be a 'struct file', 'struct mm_struct', etc. When an object is added, it's reference count is incremented to ensure that the pointer is still valid for as long as it's in the hash table. Similarly, when we remove an object from the hash, we need to decrement the reference count. This is done in cr_obj_ref_grab(), ...

I don't doubt it. But holding the members of a whole community as captives over several years is a even much more severe issue. Alone for reading the thousands of mails, how can I build the f*, there is no compensation and that alone is a reason to have serious doubts about such kind of support or keep that out of linuxtv too. To accuse Steve now, his major captive, of something, Manu is far away to even come close to be allowed to do such, if you look at it in whole, is a further ...

Such a fix is even suitable for -stable. If something is considered suitable for -stable, but not for -rc with one month to go before the release of the kernel, then there's something wrong in the process. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --

Well, remember that patches that get published for -stable do have to go through an extra review process. It's not true that any "obviously correct" bug fix gets automatically published in -stable. Sometimes bug fixes do get rejected for -stable because they are too risky, or require more time for testing in the -rc series before they are deemed suitable for -stable. Looking at 2.6.26, there is currently about 195 patches queued up, which is certainly not all of the bugs fixed during the ...

On Mon, Sep 15, 2008 at 02:11:59PM -0700, David Miller wrote: [snip] Hi Dave, can you confirm that the commit message requirement stands even if the SHA1 ID references Linus' tree? I personally think that is reasonable, I just want to confirm that is the requirement. -- Simon Horman VA Linux Systems Japan K.K., Sydney, Australia Satellite Office H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en --

On Tue, 16 Sep 2008 09:54:08 -0400 also note that Linus said "regression or on the kerneloops list"; if it has any kind of backtrace, it'll be there if it's a common problem that hits many users. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

Thomas' patch [1] will fixes a bug of a kind that will likely never make it to your list. And the same also e.g. goes for bugs where your machine is completely dead (no SysRq possible) with nothing in the logs. The kerneloops lists are quite valuable, but they can never cover all classes of fatal bugs. cu Adrian [1] http://article.gmane.org/gmane.linux.network/105810 -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been ...

The kerneloops list is helpful, and improving it is great, but it will You miss my point: We agree that the kerneloops list is not perfect. And usually the bugs with a trace that go into the list are the ones that are easier to debug and fix, while the others might be much harder to debug. If one takes Linus' "simple rule of thumb" literally then a hard to debug bug without any messages anywhere mustn't be fixed outside of a merge window. This literal reading is what doesn't make ...

On Tue, 16 Sep 2008 17:34:10 +0300 not sure; just we need to catch doing pci_disable_device on a non-enabled device as a WARN_ON. and the patch looks quite wrong, the real answer should be to do the that's being worked on, by storing the crash data in some non-volatile if you want perfection, you're not going to get it. "Perfect is the enemy of good" If you want to help make things better (as opposed to perfect), you're very welcome to help out, be it with suggestions on how to ...

Michael Tokarev wrote: [usb-storage hangs on asus M2NPV-VM (nVidia GeForce 6150/nForce 430) After seeing similar situation on another motherboard, I become curious. Here's the result: M3A78-EM motherboard (also from Asus), AMD780G/SB700 etc. Updating to one of the latest bios makes the system unbootable. Kernel hangs on boot right after displaying SLUB: Genslabs=12, HWalign=64, Order=0-1, MinObjects=4, CPUs=2, Nodes=1 Reverting to the older BIOS or disabling PARAVIRT_GUEST in ...

Sure, I can definitely send the patch. I haven't sent a patch before, and I am not fully aware of the process to follow. It might take a little bit if time, but I will try to send it very soon. --

in order not to waste your time, here is how to proceed : go to the directory where both your new kernel and old kernel are. Here is how you do then : $ diff -urN linux-2.4.36-bad linux-2.4.36-goot > my-patch.diff (ensure that you don't have lots of old or temporary files in it). You might have to run a "make distclean" in each dir first. Then integrate the result as inline text into your mail, and as an added bonus, other people will be able to comment on your ...

OK, that will help me review the current code and compare it with 2.6. If you could send me your patch, it will even save me more time. Based on your report, it's very likely that it will get merged. Thanks, Willy --

No, I don't think so. But you should check Redhat and SuSE kernels, they were heavily patched to support an early version of the 2.6 O(1) scheduler, NPTL threads and things like this. As a result, there were a large number of changes in this area and your patches might come from there. Also check for Andrea Arcangelli's patches (2.4-aa), they were approximately the ones that constituted the SuSE kernels by that time. I'm pretty sure that you'll find what you're looking for from No, but that ...

Hi Alan, At the driver level there are lots of varients but I was under the impression that at the user level, the interface is common for async serial ports. Latency can be an issue, but can it be read/changed via the user <-> kernel interface in a way that is not common to all async serial ports? If not, it is transparent at the programming interface for user level code so the USB serial ports are no different at this level to classic PC AT serial ports and as such I see no reason ...

I assume that c142bda458a gave a good results as well... One additional sanity check could be to rebase security 6f0f0fd4963 on top of the c142bda458a and then see if bisection among those security commits on top yields to the the same result... Though I doubt it can change much because there was not that much relevant non-security things in the merge in question. -- i. --

this has already been fixed in -rc6. please refer to http://bugzilla.kernel.org/show_bug.cgi?id=11471#c22 so I think this should be removed from the list. thanks, rui --

i dont know ... lets try that simplification as a delta patch, ok? Please check the before/after size of 'vmlinux' in a 'make defconfig' [with SMP disabled after make defconfig] UP build. If there's visible size difference then Roland's point holds. Ingo --

If it wasn't for the _irq vs _irqsave, I would apply it. But I agree, your current approach is fine. -- Jens Axboe --

Thank you for your feedback Marcin, it was really helpful. The log message above is a good start. There's also the "print-fatal-signals" kernel parameter which prints out much more than just the basic info: ======================= sleep/3277: potentially unexpected fatal signal 11. code at 001b7571: 89 d3 3d 01 f0 ff ff 73 01 c3 53 e8 00 00 00 00 Pid: 3277, comm: sleep Not tainted (2.6.26-2.i2nsmp #7) EIP: 0073:[<001b7571>] EFLAGS: 00000246 CPU: 0 EIP is at 0x1b7571 EAX: fffffdfc EBX: ...

I said that vmalloc is worth. --

This patch does not only add runtime overhead, but also make code much more complex, so the code is harder to read and harder to maintain, and object size is increased, which means increased memory footprint. And is there any reason not using plain vmalloc? Don't bloat the kernel without good reasons IMO... --

On Tue, 16 Sep 2008 19:58:24 +0200 What do you mean? For example, some aacraid cards have 31bit dma mask. What guarantees that IOMMUs's dma_alloc_coherent don't return a I think that the patch is a pretty straightforward, it just the same thing that IOMMUs with > 32bits virtual address space do. We can do better with the simple patch. But I'm ok with dropping the patch for GART since we can live without the patch, as you said. --

Ah you care about masks < 32bit? Those always are handled elsewhere in the block layer (using the bounce_pfn mechanism) or in various other ways in other subsystems. e.g. on networking the rule is that you just don't announce direct SG when you have less than 32bit mask. And the others like sound generally don't use map_sg()/map_single(), but instead pre allocate something with dma_alloc_coherent() or similar. Also what would you do if it this check fails? There is no suitable fallback ...

dma_alloc_coherent() is not used for block IO data. And dma_alloc_coherent() b44 (and related designs like the bcm wireless chipset) It's not worth to handle this strange case. The drivers do anyways. These are very cheap devices which are only rarely used in systems with >2GB and for those cases the existing bouncing setup works fine. -Andi -- ak@linux.intel.com --

I am not aware of any failures which are fixed by these patches. But in theory there could be failures. Joerg -- | AMD Saxony Limited Liability Company & Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System | Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: Center | AMD Saxony LLC (Wilmington, Delaware, US) | General Manager of AMD Saxony ...

Does the patch below fix it ? Thanks, tglx ---- diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c index 1876b52..eb8736f 100644 --- a/kernel/time/clockevents.c +++ b/kernel/time/clockevents.c @@ -69,6 +69,9 @@ void clockevents_set_mode(struct clock_event_device *dev, dev->set_mode(mode, dev); dev->mode = mode; } + + if (mode == CLOCK_EVT_MODE_SHUTDOWN) + dev->next_event.tv64 = KTIME_MAX; } /** diff --git a/kernel/time/tick-broadcast.c ...

In addition to the deadlocks, we still have the watchdog warning: [ 0.460034] Testing NMI watchdog ... [ 0.532557] WARNING: CPU#0: NMI appears to be stuck (0->0)! [ 0.533301] Please report this to bugzilla.kernel.org, [ 0.536635] and attach the output of the 'dmesg' command. Perhaps an HPET problem: [ 0.993800] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 31 [ 0.999969] hpet0: 3 32-bit timers, 25000000 Hz [ 1.004396] ACPI: RTC can wake from S4 [ 1.006637] Clockevents: ...

[Cyrill Gorcunov - Tue, Sep 16, 2008 at 09:56:29PM +0400] ... | | And get apic=debug a try too please. I remember there | was a problem with SB600 on ACPI side (but they should | be already fixed) | | - Cyrill - Sorry Thomas, I meant to send the message to Joshua - Cyrill - --

Current git tree works for receiving IR signals via lirc_serial (tested by Janne) and via lirc_mceusb2 (tested by me). Something is still slightly haywire with lirc_i2c though. It registers fine, but IR signals simply aren't making it to lircd. Probably unrelated to the dynamic device num changes, looking into it. -- Jarod Wilson jarod@redhat.com --

.. No, the failures happen randomly at customer sites, and only since they "upgraded" to SLES10 with libata. I think the PSUs are probably just fine. Time to hack the drivers to give proper status on the timeouts, too; otherwise we won't ever have any clue as to what is really happening. Cheers --

On Mon, Sep 15, 2008 at 1:43 PM, Tejun Heo <tj@kernel.org> wrote: The "raw" values are "vendor defined". Often the 6 bytes of raw data are split up into 1 or 2 byte wide fields. Any volunteers to submit a patch to smartmontools to dump "raw values" as hexidecimal by default? 441778176 == 0x1a550000 Need to see if the vendor will provide documentation to decode these values. AFAICT, it's not safe to directly compare raw values between vendors since the raw values don't mean exactly ...

OK, your call, you know the code better than I do. But the locking could at least be pushed into ehea_update_firmware_handles() and ehea_update_bcmc_registrations() instead of being at each call site. Thanks, --

thanks, applied --

On Fri, 12 Sep 2008 09:12:48 -0700 I'm now writing *lazy* lru handing via per-cpu struct like pagevec. It seems works well (but not so fast as expected on 2cpu box....) I need more tests but it's not so bad to share the logic at this stage. I added 3 patches on to this set. (my old set need bug fix.) == [1] patches/page_count.patch ....get_page()/put_page() via page_cgroup. [2] patches/lazy_lru_free.patch ....free page_cgroup from LRU in lazy way. [3] patches/lazy_lru_add.patch ....add ...

While page_cgroup() has reference to the page, it doesn't increment page->count. Now, the page and its page_cgroup has one-to-one relationship and there is no dynamic allocation. But the behavior of global LRU and memory resource controller is not synchronized. What this means is - LRU handling cost is not high. (because there is no synchronization) - We have to be afraid of "reuse" of the page. Synchronizing global LRU and memcg's LRU means to make the cost of LRU handling twice. ...

Delaying add_to_lru() and do it by batch. For delaying, PCG_LRU flag is added. If PCG_LRU is set, page is on LRU and unchage() have to call remove from lru. If not, the page is not added to LRU. For avoid race, all flags are modified under lock_page_cgroup(). Lazy-add logic reuses Lazy-free's one. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> --- include/linux/page_cgroup.h | 4 + mm/memcontrol.c | 91 ++++++++++++++++++++++++++++++++++++++------ ...

It looks like this isn't Xen-specific at all. See http://www.kerneloops.org/searchweek.php?search=native_safe_halt J --

On Mon, 15 Sep 2008 16:00:58 -0700 The linux-next tree fails in the same way. Here is the dmesg output from the broadcom driver: Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v1.8.0 (Aug 14, 2008) vendor=8086 device=2690 bnx2 0000:05:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f8000000, IRQ 16, node addr 00:19:b9:ee:6c:4a vendor=8086 device=3510 vendor=8086 device=3500 vendor=8086 ...

Here is an updated patch without the defconfig changes == cut here == e1000: remove Kconfig option for packet split and e1000 related code From: Jesse Brandeburg <jesse.brandeburg@intel.com> Since the e1000/e1000e split, no hardware supported by e1000 supports packet split, just remove the Kconfig option and associated code from the driver. reposted without the defconfig changes, should apply to net-next Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> --- ...

Nice! Acked-by: Steven Rostedt <rostedt@goodmis.org> -- Steve --

-- Steve --

From 743cab2763d3e8d9f4d3b82a02fcdc5ad8a13c04 Mon Sep 17 00:00:00 2001 From: Pekka Paalanen <pq@iki.fi> Date: Sun, 14 Sep 2008 16:53:05 +0300 Subject: [PATCH] ftrace: move mmiotrace functions out of trace.c. Moves the mmiotrace specific functions from trace.c to trace_mmiotrace.c. Functions trace_wake_up(), tracing_get_trace_entry(), and tracing_generic_entry_update() are therefore made available outside trace.c. Signed-off-by: Pekka Paalanen <pq@iki.fi> --- kernel/trace/trace.c ...

As I said to you, I met the same bug of this early quit of the pipe. But I should give here more details. This bug occurs with -tip (a version pulled 2 days ago so trace.c didn't change). I never saw it with other tracers than mmiotrace. I had no problem with sched_switch or function tracer. It happened when I was writing the tracer marker. So I'm not sure if the origin is here. If I'm not wrong it happened whithout adding mark messages too. Can you tell me if your pipe quits when you add ...

On Tue, 16 Sep 2008 16:11:20 -0400 (EDT) Good question. It seems to be used a lot. :-) commit 6e21828743247270d09a86756a0c11702500dbfb Author: Richard Knutsson <ricknu-0@student.ltu.se> Date: Sat Sep 30 23:27:11 2006 -0700 [PATCH] Generic boolean This patch defines: * a generic boolean-type, named 'bool' * aliases to 0 and 1, named 'false' and 'true' Removing colliding definitions of 'bool', 'false' and 'true'. Signed-off-by: Richard Knutsson ...

From da74191de5e5a3c0adee0604757d19b2faf8ec79 Mon Sep 17 00:00:00 2001 From: Pekka Paalanen <pq@iki.fi> Date: Sat, 23 Aug 2008 14:32:22 +0300 Subject: [PATCH] x86 mmiotrace: fix a rare memory leak. Signed-off-by: Pekka Paalanen <pq@iki.fi> --- arch/x86/mm/mmio-mod.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/x86/mm/mmio-mod.c b/arch/x86/mm/mmio-mod.c index 635b50e..754bd1e 100644 --- a/arch/x86/mm/mmio-mod.c +++ b/arch/x86/mm/mmio-mod.c @@ -307,8 ...

Good point! Indeed, if you had a 1024-CPU box acting as (say) a router/hub using the Linux-kernel protocol stacks with no user-mode processing, then you could indeed have the system mostly busy with no user-space code running, and thus no quiescent states. However, last I checked, almost all 1024-CPU boxes run HPC workloads mostly in user mode, so this scenario would not occur. However, again, if it does come up, I would add an additional level of state machine to the ...

Hi Paul, I'm still comparing my implementation with your code: - f is called once for each cpu in the system, correct? - if at least one cpu is in nohz mode, this loop will be needed for every grace period. That means an O(NR_CPUS) loop with disabled local interrupts :-( Is that correct? Unfortunately, my solution is even worse: My rcu_irq_exit() acquires a global spinlock when called on a nohz cpus. A few cpus in cpu_idle, nohz, executing 50k network interrupts/sec would ...

Right. Specifically, read bandwidth is on the same order of magnitude. However the read latency of NAND is a couple orders of magnitude higher (100ns vs 20,000ns) so it depends on what you are doing. --

Iain: I'm assuming you'll do this in advance of any patch from me? I was simply going to add printk to the various shutdown paths and see if we could get some finer grained debug output since the generic transport debug output was too verbose. Let me know and I'll help if I can, --

(dropping the e1000 guys, it seems unnecessary to keep spamming them with this issue when it's unlikely to be anything to do with them. I've left their list on for now so they know. I'd suggest dropping it from any replies.) FYI I've repro'd with=20 commit a551b98d5f6fce5897d497abd8bfb262efb33d2a Merge: d1c6d2e... 50bed2e... Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Thu Sep 11 11:50:15 2008 -0700 =20 Merge branch ...

Thanks. It's running 2.6.25.7 although I can massage a more recent patch if needed. (I'm a bit less keen to run a variety of random kernels on that machine). Ian. -- Ian Campbell Current Noise: The Ocean - Protoerozoic - Rhyacian - Untimely Meditations We may not return the affection of those who like us, but we always respect their good judgement. --

When you speak of a 'regular interrupt' I assume you are referring to simply the irq number, with the knowledge of what vector and CPU(s) it is mapped to being hidden? sgi-gru driver The GRU is not an actual external device that is connected to an IOAPIC. The gru is a hardware mechanism that is embedded in the node controller (UV hub) that directly connects to the cpu socket. Any cpu (with permission) can do direct loads and stores to the gru. Some of these stores will result in an ...

On Tue, Sep 16, 2008 at 4:02 AM, Uwe Kleine-König It looks fine for me, thanks a lot. --

Sorry for the massively late response. Don't know how I missed this thread earlier, but I can answer that from my standpoint. At Sony we have a "no modules if possible" policy to reduce kernel footprint. The size difference for a kernel compiled with modules vs one with external modules is about 10% IRRC. -- Tim ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America ============================= --

The reason is not as complicated as I thought. It is because x86 strace don't test TCB_WAITEXECVE. please take a look at defs.h (strace-4.5.16), the flag is defined as follows: #ifdef LINUX # if defined(ALPHA) || defined(SPARC) || defined(SPARC64) || defined(POWERPC) || defined(IA64) || defined(HPPA) || defined(SH) || defined(SH64) || defined(S390) || defined(S390X) || defined(ARM) # define TCB_WAITEXECVE 02000 /* ignore SIGTRAP after exceve */ # endif I'm not an strace expert, so I ...