hm, i know it's not your fault as you just took this vmware code, but this is really not an acceptable method of detection. The above is totally unsafe to do on native hardware - we dont know whether there's anything on that port. vmware could have used one of the following methods to communicate to the guest kernel: - a CPUID and an MSR range - like a good virtual CPU should. That way even bootloaders could detect the presence of vmware. - or a PCI ID and a PCI driver like KVM ...

Sure. Another possible solution is to print that message at the first call only, it's good for debugging to keep that in dmesg. If it's not possible to do live migration in/out of a running VMware environment, we can also safely do this detection only at the first That sounds good too. And I think the current routines for detecting KVM, Xen and VMWare are all ready. I can do that if there are more positive feedbacks. Thanks. -- Li, Yan "Everything that is really great and ...

Hi, Well, I believe that again it was somehow forgotten or was not applied for other reasons, since polling the following URL several times in last days did not show this patch (url: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/patches.git) Regards, MR --

Thanks. I'll fix it. -- Yasunori Goto --

This patch broke kallsyms on powerpc. Please see http://ozlabs.org/pipermail/linuxppc-dev/2008-September/062549.html --

At Sun, 7 Sep 2008 23:56:27 -0700, Hmm... h8300 local symbol head of '.L'. But powerpc don't have '.L' pattern. I think add condition "str[1] == 'L'". -- Yoshinori Sato <ysato@users.sourceforge.jp> --

Okay, seems like vojtech fixed my notebook with a bit of compressed air... a lot of dust came out, and machine works okay now. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Ulrich -- ping! ---------- Forwarded message ---------- From: Michael Kerrisk <mtk.manpages@googlemail.com> Date: Sep 2, 2008 9:58 AM Subject: Re: Rationale for paccept() sigset argument? To: Ulrich Drepper <drepper@gmail.com> Cc: Michael Kerrisk <mtk.manpages@googlemail.com>, Ulrich Drepper <drepper@redhat.com>, Davide Libenzi <davidel@xmailserver.org>, lkml <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Jakub Jelinek <jakub@redhat.com>, Linus Torvalds ...

On Sun, 7 Sep 2008 13:29:40 -0400 (EDT) Yes, I forgot the per-cpu buffers. When merging you want the first one wrt. timestamp, and when continuing you want the next on that cpu's My first idea was to filter out all newlines from messages, making a message a single line, and then force a newline, but now I realize that would be an exception to the printk convention. Maybe I should just start a new line in the output, when I get a newline :-) Although that probably means my version of ...

On Thu, 04 Sep 2008 22:34:47 -0700 kmalloc becomes more unreliable above 32 kbytes and 100% unreliable above MAX_ORDER. --

Agreed, but that's something to be fixed in a different patch - the existing cgroups code (and cpusets originally) has had this kind of kmalloc call in it. I think it should be reasonably straightforward to replace it with an array of page allocations. Paul --

applied --

I've no experience of what happens if NX is set to a non-NX-supporting CPU, so can't advise on that at all. But I think you're looking at it the wrong way round - or else I am. Here's the declaration and comment on level2_ident_pgt in head_64.S: NEXT_PAGE(level2_ident_pgt) /* Since I easily can, map the first 1G. * Don't set NX because code runs from these pages. */ PMDS(0, __PAGE_KERNEL_LARGE_EXEC, PTRS_PER_PMD) (The "Since I easily can" comment is there because it used to ...

[Empty message]

libata part looks good to me but I think it would be better to separate out DMI changes into a separate patch. Thanks. -- tejun --

I re-tested this new patch series using an iSCSI target via the following steps: 1) Connect to iSCSI storage, creating the /dev/sd* devices. 2) Create a file system on the block device 3) Mount the file system, and leave a shell active on the mount point. 4) resize the iSCSI LUN 5) rescan the iSCSI session 6) resize the file system This procedure worked fine. Cheers, Jeff --

From: Stephen Hemminger <shemminger@vyatta.com> Applied, thanks Stephen. I added more information to the commit message so that Dushan's incredibly contribution to this bug getting fixed are mentioned. I don't see how we would have figured out Bridging as even the cause without his detective work. So it's definitely wrong not to give him at least some mention in the commit message :-/ bridge: don't allow setting hello time to zero Dushan Tcholich reports that on his system ksoftirqd can ...

I suppose its not too surprising, but I noticed that if I suspend-to-disk after undocking I can then suspend-to-ram. -- Steven King -- sfking at fdwdc dot com --

--- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --

You're right, I changed the patch accordingly (I also fixed the read timeout path). From 03b2d04b2e597ec073f2ff61224df1d3dee3b9de Mon Sep 17 00:00:00 2001 From: Matthew Fleming <matthew.fleming@imgtec.com> Date: Mon, 8 Sep 2008 14:10:14 +0100 Subject: [PATCH] MMC: Use timeout values from CSR Currently, the MMC/SD over SPI code has a hard-coded timeout value of 250ms on writes and 100ms on reads. This is correct for SDHC cards and is specified in the spec, but it is not correct for MMC/SD ...

dmidecode just from 3000-N100? Attached a dmidecode from a Lenovo Thinkpad T61. I have a Lenovo 3000-V200 too. You want a dmidecode from it? Regards, Renato

On Mon, 8 Sep 2008 15:27:16 +0200 timers are slacking today, at least for select() and poll(), and are a great deal more so than the defaults in this patchkit. The great advantage of the prctl() approach (which is usable) over new system calls and glibc APIs is that it will get used, because the admin can use it just like he uses the "nice" command, on existing software. -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power ...

...and new applications, yes. I believe applications should explicitely enable slacking timers. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

On Sat, 6 Sep 2008 18:09:55 +0300 That's a strange position in which to add the new field. It will prevent the compiler from using the same word for sh_bang, misc_bang and taso. Why "4"? Why make linux_binprm.recursion_depth a u8? There would be practically (or actually) zero cost to making it 32-bit. Admittedly a depth >256 would be a bit odd, but did we gain anything from this restriction? --

Don't use __init but __devinit to define probe function. A pointer to sa11xx_uda1341_probe is passed to the core via platform_driver_register and so the function must not disappear after the module is loaded. Using __init and having HOTPLUG=y and SND_SA11XX_UDA1341=m the following probably oopses: echo -n sa11xx_uda1341.1 > /sys/bus/platform/driver/sa11xx_uda1341/unbind echo -n sa11xx_uda1341.1 > /sys/bus/platform/driver/sa11xx_uda1341/bind Signed-off-by: Uwe Kleine-König ...

I'm not sure "tuning" it to make those arrays longer than PAGE_SIZE will ever be a good idea. Seems like we should just keep the structures at PAGE_SIZE to me. -- Dave --

I'd suggest the double loop. I think it is much more straightforward I think we have a basically different philosophy on these. I'd say don't define them unless absolutely necessary. The less you spell out explicitly, the more flexibility you have in the future, and the less code you spend doing simple conversions. Anyway, I see why you're doing it this way. -- Dave --

'ctid' in my patchset will be used later (when we will have container infrastructure) to specify container ID. Right now we can drop this 'ctid' --

Hi everyone, I posted this problem last week on this mailing list, I got an answer from Alan Cox requiring more informations. Then when I gave those informations, I didn't get any other answer. So I try another time to get help from some of you. Here is my problem : I have a Linux box with an RDX removable disk in SATA. A software uses regularly this RDX, mounts it, reads and/or writes to it and unmounts it. But after a certain time or a certain number of uses (not clearly identified), the ...

Thank you for the review and comments. You are right in that searching the whole process address space is not a good idea. The idea is to make the scan range flexible, thus normally, assuming that the code has been well-tuned, only a very limited number of VMA's are scanned. In general, i think that the cluster size and the scan range should be tuned depending on the backing storage characteristics and the low-on-memory severity. Like any VM code, this one needs tuning. BTW, the code could ...

I do not think that the virt_to_page() can work well on userland virtual address space. And the linear searching for whole address space of a vma is not good --

Btw Yinghai, do you really have a machine with that many unconnected pins? --

thanks for explanation Yinghai, i was reffering to MP and didn't take a look on ACPI facility (that is why I've asked you). Thanks! --

got 0-16<7> 0-17<7> 0-18<7> 0-19<7> 0-20<7> 0-21<7> 0-22<7> 0-23<7> (apicid-pin) not connected 1-0<7> 1-1<7> 1-2<7> 1-3<7> 1-4<7> 1-5<7> 1-6<7> 1-7<7> 1-8<7> 1-9<7> 1-10<7> 1-11<7> 1-12<7> 1-13<7> 1-14<7> 1-15<7> 1-16<7> 1-17<7> 1-18<7> 1-19<7> 1-20<7> 1-21<7> 1-22<7> 1-23<7> (apicid-pin) not connected can you remove the extra <7>? YH --

Hmm, from this disassembly it seems that somebody has overwritten our page->private pointer to 1000c20d02020000 and then we obviously failed to get bh->b_size. But I don't really see how this can happen. What also puzzles me a bit is that I don't see BUG_ON(!PagePrivate(page)) in the disassembly but it should be there because of page_buffers() implementation... Anyone has an idea? Honza -- Jan Kara <jack@suse.cz> SuSE CR Labs --

On Thu, 04 Sep 2008 13:56:37 -0700 It doesn't call schedule() - it calls yield(). yield() is pretty notoriously badly behaved in the presence of lots of runnable tasks and there's been a general move to eradicate its in-kernel callsites. An alternative would be nice. --

On Thu, 04 Sep 2008 13:56:38 -0700 But this (I think) is assigning a ssize_t-returning function to an int-returning function pointer. --

Hmm, I don't think that it does. There's a queue per drive in the old IDE driver, so there should be a 1:1 relation between queues and gendisk -- Jens Axboe --

I think the problem here is due to the usage of kobject_init_and_add(). When we hit the add the second time, the ->state_initalised in the kojb is still 1. The below should fix it. The ->state_initalised stuff is a disaster imho, it should be shot and killed. diff --git a/block/blk-core.c b/block/blk-core.c index 6cb3c6d..820132b 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -495,6 +495,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, int node_id) ...

The rest of that patch updates the sysfs entries in line with Andi's changes, but I don't think they're in mainline yet. The sysfs namespace clash means that Xen balloon and hotplug memory try to register the same name, which is bad because one of them is going to lose. J --

No, because it caused compile-time warnings. The signatures on sysfs access functions changed, so that patch will break unless the rest of the sysfs changes went in. J --

i cherry-picked the whole thing as that's the tested commit. Is that fine too? Ingo --

Ok, so please add a comment to this so we know in the future why this is there. 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 LLC: Dr. Hans-R. Deppe, ...

btw., the build became very noisy - see the messages below. Ingo ----------> init/initramfs.c:517: warning: 'clean_rootfs' defined but not used In file included from include/linux/dma-mapping.h:53, from include/linux/dmaengine.h:30, from include/linux/skbuff.h:30, from include/linux/netlink.h:156, from include/linux/genetlink.h:5, from include/net/genetlink.h:5, from ...

Why do you need to clear down anonymous mapping ? I think if you don't convert this cleardown in free_hot_cold_page(), you don't need it. -- Thanks, MinChan Kim --

*Much* less likely, actually. Because there should be very little allocation required for reclaim (only dirty pages, and only when backed by filesystems that do silly things like not ensuring their own reserves before allowing the page to be dirtied). Also, your scheme still doesn't avoid allocation for reclaim so I don't see I don't see why it should be unfair to allow a process to allocate 1024 order-0 pages ahead of one order-10 page (actually, yes the order 10 page is I guess ...

Yeah that has slipped through from where originally this patch used to merge two different instances of this code. Good spot. Will sort that -apw --

Sorry, I don't recall anything else I needed to address. Jan --

This is my take at it: Make the x86_{phys,virt}_bits common for 32- and 64-bits, and use the former in ioremap's phys_addr_valid() check also on 32bit/PAE. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- arch/x86/kernel/cpu/common.c | 22 +++++++++++++++++++++- arch/x86/mm/ioremap.c | 13 ++++++------- include/asm-x86/processor.h | 4 ++-- 3 files changed, 29 insertions(+), 10 deletions(-) --- linux-x86.orig/arch/x86/kernel/cpu/common.c +++ ...

these lines should be in early_init_intel/init_intel. also need to be checked if it could be overwriten by others functions later.. BTW, did you address Peter's concern? YH --

Thanks a lot for these numbers Alan, it definitely looks like a clear win (and a pretty big one) for all of the above and the previous mail. It would be interesting to see sys and usr times seperately, as well as trying to compare profiles of two runs. On the testing that I did with a 4-way ppc box, lock contention and bouncing was way down with XFS and btrfs. I didn't test other file systems yet. I saw mean acquisition and hold time reductions in the 20-30% range and waittime reductions of ...

Even with that there are lots of issues, like keeping track of Agreed. -Andi -- ak@linux.intel.com --

First blocking arbitary code is hard. There is some code parts which are not allowed to block arbitarily. Machine check or NMI handlers come to mind, but there are likely more. Then that would be essentially a hypervisor or micro kernel approach. e.g. Xen does that already kind of, but even there it would be quite hard to do fully in a general way. And for hardware hotplug only the fully generally way is actually useful unfortunately. -Andi --

There is nothing architecture specific about remove_memory(). remove_memory() function is common for all architectures which support hotplug memory remove. Instead of duplicating it in every architecture, collapse them into arch neutral function. Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com> arch/ia64/mm/init.c | 17 ----------------- arch/powerpc/mm/mem.c | 17 ----------------- arch/s390/mm/init.c | 11 ----------- mm/memory_hotplug.c | 10 ++++++++++ 4 files ...

Cleaned up patch with out remove_memory(). Depends on make remove_memory() arch neutral patch. Thanks, Badari Add memory hotremove config option to x86 Memory hotremove functionality can currently be configured into the ia64, powerpc, and s390 kernels. This patch makes it possible to configure the memory hotremove functionality into the x86 kernel as well. Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com> Signed-off-by: Gary Hade <garyhade@us.ibm.com> --- arch/x86/Kconfig | ...

On Mon, Sep 8, 2008 at 10:54 AM, Luca Tettamanti <kronos.it@gmail.com> wrote: can you post boot log with working kernel + "debug"? YH --

so some config works, others not? YH --

that could explain sth. big kernel use more, and lilo put ramdisk need to figure out, lilo put ramdisk so low... need to know e820 table layout... YH --

do you mean tip/master? http://people.redhat.com/mingo/tip.git/readme.txt YH --

Hi Chuck, I think fp.flush() in Python is equivalent to fflush() i.e. it only flushes the stdio buffer. It doesn't actually call fsync or fdatasync or anything like that. We can pretty easily change the Python code to use the syscall I've exported them on the server as sync e.g. in exports: /export 192.168.0.0/24(rw,sync) However I don't give any special options when mounting e.e. on the client: mount machine:/export mntpnt Anyway thanks for looking at this and let me ...

A little analysis reveals the bad behavior on the wire. I filtered the network traces for just WRITE requests. There were six in the good trace, and five in the bad. This seems to correspond with the strace logs, which show that you stopped the bad run before it generated more writes. Good: time: offset: len: sync: byte range: 35.402734 0 8000 FILE_SYNC [0, 7999] 100.405170 4096 11904 FILE_SYNC ...

From: Nick Piggin <nickpiggin@yahoo.com.au> This is a great idea, especially since it will make it even more painfully obvious that essentially any function local cpumask_t variable is a bug. Really, it seems sensible to do something like: 1) Make cpumask_t a pointer. 2) Add cpumask_data_t which is what cpumask_t is now. This gets used when for the actual storage, and will only get applied to datastructures that are dynamically allocated. For example, for the cpu_vm_mask in ...

Yes, that's what I have done in the past ... but putting it into the QA I was wondering if we'd need to be able to default a cpumask_t pointer argument to be a const and then use a different method for those cases where it shouldn't be? This would strengthen the compiler type checking of functions calls. For example: proto(cpumask_t mask) would imply that *mask is a const, whereas proto(cpumask_var mask) would indicate it to be non-const? But then we couldn't use "cpumask_t" ...

Cool, I think we should, it's like a ticking bomb waiting to explode on us eventually. IMHO it was a big mistake to allow cpumask_t being passed by value in the first place. Cheers, Jes --

applied to tip/timers/hpet-percpu, thanks Venki! Ingo --

We it be possible to send these fixes back the stable trees 2.6.26.y and 2.6.25.y? David --

On Mon, 8 Sep 2008 19:37:16 +1000 The dmesg with Nick's patch below (now the third WARN_ON is triggered in different module). Regards, Krzysztof Linux version 2.6.27-rc5-mm1 (root@xxx) (gcc version 3.4.6) #2 SMP Mon Sep 8 17:49:16 CEST 2008 PAT WC disabled due to known CPU erratum. BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) ...

It is in latest ACPI test branch queued for 2.6.28. The problem in bug: http://bugzilla.kernel.org/show_bug.cgi?id=9614 is another. But the patchset pointed to in comment #43 should fix several, also your problem. If not, please tell me and open a new bug. Thanks, Thomas --

It was exactly the right one. I'll get a look at adding proper detection for Toshiba HCI systems. Thank you!

I'm sorry, but I don't have any idea so far. Yinghai, does this happen even when pciehp is not configured? Thanks, Kenji Kaneshige --

I suspect this behavior may have already been changed, you may want to try a newer kernel and see.. --

Both 7zip and LZMA-Utils have serious file format problems. The author of LZMA-Utils is working on a new format, which is likely to be widely adopted once it materializes. -hpa --

commit 49048622eae698e5c4ae61f7e71200f265ccc529 Author: Balbir Singh <balbir@linux.vnet.ibm.com> Date: Fri Sep 5 18:12:23 2008 +0200 sched: fix process time monotonicity Spencer reported a problem where utime and stime were going negative despite the fixes in commit b27f03d4bdc145a09fb7b0c0e004b29f1ee555fa. The suspected reason for the problem is that signal_struct maintains it's own utime and stime (of exited tasks), these are not updated using the new task_utime() ...

Jesse, have you queued up this patch to send to Linus for 2.6.27? thanks, greg k-h --

seconded. Mike, since none of this is v2.6.27 material, lets do it right with a v2.6.28 target. You know all the cpumask_t using code sites inside out already, so the know-how is all available already :-) Please make it finegrained series of patches so that we can resolve conflicts with other trees more easily. perhaps propose the new cpumask_t API early (in this thread?), so that people can comment on it before NAKs come flying against a full patchset ;-) Ingo --

Again, yes, as I got farther into that one, it became clear that having static cpumask_t temps over too large a range was ending up very messy. Thanks, Mike --

Sorry that patch seems incredibly messy. Global variables and a tricky ordering and while it's at least commented it's still a mess and maintenance unfriendly. Also I think set_affinity is the only case where a truly arbitary cpu mask can be passed in anyways. And it's passed in from elsewhere. The other cases generally just want to handle a subset of CPUs which are nearby. How about you define a new cpumask like type that consists of a start/stop CPU and a mask for that range only and ...

Umm, right, my cut and paste error... Thanks, --

Indication of the faulty part, so I know whether to contact AMD or Tyan. Without a clear idea of which it could quickly turn into an infinite redirect loop between the two. Regards, Tony V.

I was hoping for some help in narrowing it down, yes. Jeroen's reply was very helpful, and more among the line of what I was expecting. I have contacted all vendors involved now, and it looks like the system RAM is not fully compatible with the mainboard. With regard to the message, I would suggest an alternate wording like such: A hardware component in your system is failing. Please contact your hardware vendor(s). If unsure, contact your CPU vendor first. Regards, Tony V.

Or this: "A hardware component in your system is failing. [insert specific bit if MCE is certain enough about what part] If you can, try to narrow it down by placing it in another mainboard (assuming you have one available), or run [memcheck, another tool]. Then contact the hardware vendor(s) in question, if uncertain, try Jeroen. --

Ok so you wanted linux-kernel to diagnose your hardware for you? For DIMMs you can get that with --dmi if you run the latest mcelog and if it's a memory problem. Unfortunately the BIOS vendors in their wisdom often deliver incorrect DMI tables, so the information is not always very useful. -Andi -- ak@linux.intel.com --

Well, the specific problem is that the BIOS appears to corrupt low memory. It might corrupt other memory anywhere, but that would be pretty pathologically evil. The assumption is that it gets away with it Well, it wouldn't help in this case. It's not random hardware bit-flipping. J --

OK, fine, sorry I didn't follow the thread back. --

applied to tip/x86/memory-corruption-check - thanks Jeremy. Ingo --

we dont really ignore it - we detect that it got corrupted by the bootloader. (it got overwritten by the kernel image - information has been destroyed irrevocably) how we react to that breakage we detect is up to debate: it's fine to try to continue (presumably a huge vmlinux means it has all the drivers already) - and if a system relies on an initrd it wont get fast in bootup anyway. that's why i suggested to print a warning, do a 5 seconds delay after that warning via ...

El lun, 08-09-2008 a las 12:46 -0700, Randy Dunlap escribi=C3=B3: So is it useful to report them or i just do: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" Thanks for the answer, Cheers --=20 The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place.=20 ...

=20 Ok; thank you for your time

[Ingo Molnar - Mon, Sep 08, 2008 at 04:33:35PM +0200] | | * Cyrill Gorcunov <gorcunov@gmail.com> wrote: | | > Convert DO_ACTION macro into more obvious io_apic_modify_irq | > function with callers | > --- | > | > I found it more readable then original was. Especialy we could grep | > the callers in normal way. It's just an attempt - free to drop this | > patch. I hope I don't messed with all these masks :) So the question | > is rather NOT about details but idea in general. | | yeah ...

Doesn't matter. If gcc passes "-mtune=i686" down to gas and thus the end result doesn't match gcc's own documentation (and whole point of -mtune), then it's still a gcc bug, even if it may not be a "cc1" bug. The fact that "cc1" and "gas" are two different phases is pretty much irrelevant. gcc calls them both. But sure, if there are separate bugzillas, post it in both. Linus --

It almost certainly never gets as far as detect_nopl(). -hpa --

yes. X86_P6_NOPS is a totally insignificant optimization and if it makes _any_ CPU not boot (be that virtual or real), then it's frankly not worth it. David, exactly how does the kernel fail to boot with latest -git? (v2.6.27-rc5-313-g64f996f or later) Does detect_nopl() run? It really should, and it should detect the non-working instructions. Ingo --

Under that logic we shouldn't even have CPU configurables, since you want it to "just work" whatever crap you're running on. That is EXACTLY what CONFIG_X86_GENERIC means, and the fact that any particular distribution is broken with respect to not enabling it is a bug in that distribution, and not grounds for breaking the upstream kernel. -hpa --

No, please don't. Instead, David, please enable CONFIG_X86_GENERIC. -hpa --

The help text is indeed out of date. I did a patch yesterday to, among other things, update it; I also want to verify that we are disabling all options that can cause gcc or binutils to generate nopl's; I plan to push it today. -hpa --

Sounds like a plan. I'll have a patch shortly. -hpa --

Btw, I do think that the whole NOPL issue is separate from all the other issues. There can be _other_ cases where it really is worth doing some "generic" optimizations or being more "specific", and my argument really is that NOPL is _not_ one of those cases. So I'm still not sure that X86_GENERIC is necessarily the answer. The answer may be: - never use NOPL statically unless we _know_ it works (eg x86-64) - never allow such a stupid decision by gcc as to use NOPL on ...

I always understood the CPU selection to be "this CPU and ones compatible with it will work, others won't" unless generic was enabled. the fact that only a few CPU's wouldn't work and the rest was optimization is true, but the details of what chips would and wouldn't work were never that clear. The difference between a kernel compiled for generic and once compiled for a specific CPU can be very significant. (I ran into 30% differences back in the 2.4 days between generic and Athlon) This ...

Ingo, With CONFIG_X86_GENERIC=y, the latest v2.6.27 in Linus's tree boots fine. But if you don't select that option (and some distributions don't) it won't boot at all. It just hangs (blank screen) with no error messages and nothing in dmesg. I assume it is hitting one of the ASM_NOP? instructions. David --

That is A TOTAL PIECE OF SH*T, and against gcc's own documentation. "-mtune=x" is very much defined to be a performance _tuning_ option, not an "architectural" option. Quite frankly, this is a gcc bug. Plain and simple. Look at the gcc man-pages. It very much says: -mtune=cpu_type Set only the instruction scheduling parameters for machine type cpu_type. The instruction set is not changed. (in various different formats - it says the same things ...

The issue at hand is that at least with the current toolchain, we need to pass -march=generic in order for these instructions to be generated. We have an option for this, CONFIG_X86_GENERIC, which distributions really *should* be using anyway. And yes, it should be the default. The patch I have makes it "default y" as well as change the help text. Would it make you happier if this option was forced enabled unless CONFIG_EMBEDDED was on? -hpa --

Okay, a few things here... 1. First, I wrote up a patch yesterday to update the CONFIG_X86_GENERIC description and to make it "default y". It is currently on x86/defconfig, but I think it should be promoted to mainline immediately. 2. X86_P6_NOPS is not the only source of static NOPLs. If gcc is set to optimize for specific architectures, then gcc/binutils will generate static NOPLs. The only way we can prevent that is by not using specific -march options, as far as I can ...

Ok, goodie. And we don't pass the -mtune=xyz option when we use gas I have no problem with it, with the fix to actually assemble things. But I also don't think it's a huge deal (ie not 2.6.27 stuff - we don't know if some odd version of as does something odd with -mtune=generic, or whether this can interact oddly with some version of gcc perhaps passing the _correct_ -mtune to the assembler?). Linus --

The option that works best for users is for the kernel to not use NOPLs on 32-bit cpu's. That is what Linus's patch accomplishes. I am not having any issues with gcc or gas generating NOPLs. The kernel should work out of the box for PentiumPro or later cpu's running in 32-bit mode. I think you are trying to over-engineer the issue. Just apply the patch and move on. David --

Previously they could set CPU x and it would still run on other CPUs even if that option was not set. If that's not the case anymore then they will have some unhappy users once they update their kernels. -Andi -- ak@linux.intel.com --

OK, turns out that is already happending, by virtue of: # add at the end to overwrite eventual tuning options from earlier # cpu entries cflags-$(CONFIG_X86_GENERIC) += $(call tune,generic,$(call tune,i686)) -mtune=generic on 32-bit CPUs disable NOPL generation, and any gcc/binutils combo too old to have -mtune=generic won't generate them at all. I think I verified this some time in the past, but I just had to refresh my memory. This was a major reason to put this functionality on ...

Likely broke a lot of distribution setups how? -hpa --

Originally it was an option because the 128 byte cache line it selects caused bloat in several important data structures. That was back then when cache line padded NR_CPUs arrays were still pretty common. I don't know if it's still a problem, but before making it default y it would be good to check the dynamic+static memory cost at least. -Andi --

Er, also written like: +#ifdef CONFIG_SMP Bonk. Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --

Should really be just: +#if defined(CONFIG_SMP) Can you amend? Thanks a lot, Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --

I was concerned that would cause lots of cross-arch churn, but of course the only other relevant architecture is ia64. I'll prep a followup patch. J --

You mean there's code which just assumes that it can keep using a linear-mapped acpi even after __acpi_map_table() should have implicitly __acpi_map_table() is called by acpi_map_table(), which does have a acpi_unmap_table() counterpart. But it only calls iounmap() once we're past the stage of calling early_*(). I could easily make it call __acpi_unmap_table()->early_iounmap(). But if the concern is that the early boot callers of acpi_map_table() "know" that they never need to And the ...

Acked-by: Yinghai Lu <yhlu.kernel@gmail.com> --

The same thing is happening on my MacBookPro 3.2 (with nVidia binary driver sorry). Cheers. -- Guillaume

Attached, thanks.

Can you both please provide the full dmesg output and the out put from lspci -vvv please ? Thanks, tglx --

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/Kconfig.cpu | 10 +- arch/x86/kernel/cpu/Makefile | 3 +- arch/x86/kernel/cpu/amd_64.c | 473 ------------------------------------------ 3 files changed, 2 insertions(+), 484 deletions(-) delete mode 100644 arch/x86/kernel/cpu/amd_64.c diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu index 331922c..dd8a937 100644 --- a/arch/x86/Kconfig.cpu +++ b/arch/x86/Kconfig.cpu @@ -462,17 +462,9 @@ config ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/apic.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/apic.c b/arch/x86/kernel/apic.c index 0556f37..f3f5085 100644 --- a/arch/x86/kernel/apic.c +++ b/arch/x86/kernel/apic.c @@ -1548,7 +1548,7 @@ void __init init_apic_mappings(void) apic_phys = mp_lapic_addr; set_fixmap_nocache(FIX_APIC_BASE, apic_phys); - apic_printk(APIC_VERBOSE, "mapped APIC to %16lx ...

applied to tip/x86/unify-cpu-detect, thanks. Ingo --

1. make 32bit have early_init_amd_mc and amd_detect_cmp 2. seperate init_amd_k5/k6/k7 ... v2: fix compiling for !CONFIG_SMP Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/amd.c | 396 ++++++++++++++++++++++++------------------ arch/x86/kernel/cpu/amd_64.c | 17 +- arch/x86/kernel/cpu/common.c | 2 +- include/asm-x86/processor.h | 2 +- 4 files changed, 236 insertions(+), 181 deletions(-) diff --git a/arch/x86/kernel/cpu/amd.c ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/amd_64.c | 2 -- arch/x86/kernel/process.c | 1 - 2 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/amd_64.c b/arch/x86/kernel/cpu/amd_64.c index 7913e48..466a1ea 100644 --- a/arch/x86/kernel/cpu/amd_64.c +++ b/arch/x86/kernel/cpu/amd_64.c @@ -9,8 +9,6 @@ #include "cpu.h" -int force_mwait __cpuinitdata; - #ifdef CONFIG_NUMA static int __cpuinit nearby_node(int ...

nice! Applied these patches to tip/x86/unify-cpu-detect: ff73152: x86: make 64 bit to use amd.c 2a02505: x86: make amd_64 have 32 bit code 6c62aa4: x86: make amd.c have 64bit support code 8d71a2e: x86: merge header in amd_64.c 2b86473: x86: add srat_detect_node for amd64 c58606a: x86: remove duplicated force_mwait 11fdd25: x86: cpu make amd.c more like amd_64.c v2 thanks Yinghai, Ingo --

I am tired of waiting for rc6, so if there are ground shaking changes over rc6-git9, I will update the patches. ChangeLog, 09/07/2008 Corrected dword, word, and byte dereference in the mdb-logic.c documentation to match the disassembly display. Changed oops_in_progress entry point to a counter variable to preserve state when mdb is called from exceptions where it may have been previously set. Cleaned up several hundred more checkpatch.pl messages. Cleanup error check cases in ...

Thanks, I've applied it to the ext4 patch queue. - Ted --

[ Refrain from using "unlisted-recipients" please! ] The patch is legit. The problem is simply that functions like flush_tlb_current_task and flush_tlb_mm disable preemption and then call flush_tlb_others. This function locks the tlbstate_lock which is currently a rtmutex. An rtmutex can not be called with preemption disabled. The tlbstate_lock is static, small and confined. I'm not sure we can change this code (flushing the TLB) in a way where we can allow preemption. This may ...

Chirag, Kindly understand what xavier is trying to do. He is Trying to disable smp. The RT - Linux Code is dependent on the mutex lock to perform some soft/hard real time processing. This is an problem with the mutex lock. Kindly check with some one before signing off patches. Thanks, Sujit -- --linux(2.4/2.6),bsd(4.5.x+),solaris(2.5+) --

The check to see if dev->dma_mask is NULL in pci-nommu is more appropriate for dma_alloc_coherent(). Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> --- arch/x86/kernel/pci-nommu.c | 3 --- include/asm-x86/dma-mapping.h | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c index 73853d3..0f51883 100644 --- a/arch/x86/kernel/pci-nommu.c +++ b/arch/x86/kernel/pci-nommu.c @@ -80,9 +80,6 @@ ...

-- | 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 LLC: Dr. Hans-R. Deppe, Thomas McCoy --

This patchset (against tip/master) fixes the problem that swiotlb exhausts ZONE_DMA: http://lkml.org/lkml/2008/8/31/16 The root problem is that swiotlb_alloc_coherent always use ZONE_DMA, which is fine for IA64 but not for x86_64. This patchset makes the callers set up the gfp flags so that swiotlb_alloc_coherent can stop playing with the gfp flags. I think that it would be better to remove the allocation code in swiotlb_alloc_coherent theoretically (what swiotlb should do is ...

Cool :-) This is much better than our last two tries to solve this problem. Doing no gfp handling at all in swiotlb_alloc_coherent is a nice and clean solution. 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 ...

i've applied Fujita's patches to tip/x86/iommu: 68e91d6: swiotlb: remove GFP_DMA hack in swiotlb_alloc_coherent 823e7e8: x86: dma_alloc_coherent sets gfp flags properly 8a53ad6: x86: fix nommu_alloc_coherent allocation with NULL device argument de9f521: x86: move pci-nommu's dma_mask check to common code 3a80b6a: ia64: dma_alloc_coherent always use GFP_DMA Tony, do you have any problem with us carrying the ia64 commit above (3a80b6a, also attached below) in tip/x86/iommu tree? It's ...

Non real IOMMU implemenations (which doesn't do virtual mappings, e.g. swiotlb, pci-nommu, etc) need to use proper gfp flags and dma_mask to allocate pages in their own dma_alloc_coherent() (allocated page need to be suitable for device's coherent_dma_mask). This patch makes dma_alloc_coherent do this job so that IOMMUs don't need to take care of it any more. Real IOMMU implemenataions can simply ignore the gfp flags. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> --- ...

We can safely remove the following duplication? = From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Subject: [PATCH] ia64: remove duplicated swiotbl externs Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> --- arch/ia64/hp/common/hwsw_iommu.c | 11 ----------- arch/ia64/hp/common/sba_iommu.c | 2 -- arch/ia64/include/asm/machvec.h | 5 ++--- 3 files changed, 2 insertions(+), 16 deletions(-) diff --git a/arch/ia64/hp/common/hwsw_iommu.c ...

This patchset is minor cleanups for swiotlb. It doesn't confilict with the swiotlb fixes for the x86 tree (that I've just sent): http://lkml.org/lkml/2008/9/8/30 This can be cleanly applied to tip/master and tip/x86/iommu. Ingo, can you apply this to your tree? --

No objections from me. -Tony --

This adds is_swiotlb_buffer() helper function to see whether a buffer belongs to the swiotlb buffer or not. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> --- lib/swiotlb.c | 14 +++++++++----- 1 files changed, 9 insertions(+), 5 deletions(-) diff --git a/lib/swiotlb.c b/lib/swiotlb.c index bf61c73..b5f5d11 100644 --- a/lib/swiotlb.c +++ b/lib/swiotlb.c @@ -283,6 +283,11 @@ address_needs_mapping(struct device *hwdev, dma_addr_t addr) return (addr & ~mask) != 0; } ...

hm, i think extending the already existing flags category sounds like a better solution than the separate virtual CPU flags line in /proc/cpuinfo. We already have self-invented flag entries (such as X86_FEATURE_NOPL), and adding more for virtualization would be quite natural to do, as long as it's reasonably close to the meaning of a 'CPU feature'. Peter, what would be your preference? Ingo --

Hi, Ingo (sorry for former noises, I mistake the address... Report to lkml) I've sent this patchset before, but got no comments from upstream at that time. So I'd like to resend this. The virt flags is used for the important hardware virtualization features, like EPT of incoming Nehalem. Because the feature availability are read from MSRs, and I think virtualization features should not at the same level as "vmx", so I added a new flags catagory here. But I still have concern, for this may ...

They are hardware specific MSRs, and we would use them in virtualization feature detection later. Signed-off-by: Sheng Yang <sheng.yang@intel.com> --- arch/x86/kvm/vmx.h | 15 --------------- include/asm-x86/msr-index.h | 16 ++++++++++++++++ 2 files changed, 16 insertions(+), 15 deletions(-) diff --git a/arch/x86/kvm/vmx.h b/arch/x86/kvm/vmx.h index 425a134..b32d4e5 100644 --- a/arch/x86/kvm/vmx.h +++ b/arch/x86/kvm/vmx.h @@ -331,21 +331,6 @@ enum vmcs_field { #define ...

Just to clarify: I'm suggesting adding these to the existing feature flags array, in a separate binary word. -hpa --

The ioctls for the generic freeze feature are below. o Freeze the filesystem int ioctl(int fd, int FIFREEZE, arg) fd: The file descriptor of the mountpoint FIFREEZE: request code for the freeze arg: Ignored Return value: 0 if the operation succeeds. Otherwise, -1 o Unfreeze the filesystem int ioctl(int fd, int FITHAW, arg) fd: The file descriptor of the mountpoint FITHAW: request code for unfreeze arg: Ignored Return value: 0 if the operation succeeds. ...

Hi, Andrew, Christoph and Oleg I've addressed your comments in these patches and re-based from linux-2.6.26-rc3 to linux-2.6.27-rc5. The points are followings. - Replaced the semaphore (bd_freeze_sem) with the mutex (bd_fsfreeze_mutex). - To avoid the deadlock, fixed thaw_bdev() so that it didn't call del_freeze_timeout() only when it's called by the delayed work task. - Changed the function names and global symbol names like xxx_freeze_yyy() to xxx_fsfreeze_yyy(). - Removed ...

The timeout feature is added to "freeze ioctl" to solve a deadlock when the freezer accesses a frozen filesystem. And new ioctl to reset the timeout period is added to extend the timeout period. For example, the freezer resets the timeout period to 10 seconds every 5 seconds. In this approach, even if the freezer causes a deadlock by accessing the frozen filesystem, it will be solved by the timeout in 10 seconds and the freezer will be able to recognize that at the next reset of timeout ...

Linus, Please pull from the 'merge' branch of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge There is one commit there from Hugh Dickins that fixes a build problem, plus three from the Cell guys fixing a couple of races and a reference count leak in arch/powerpc/platforms/cell/spufs/sched.c. The reference count leak is a regression from 2.6.26, and the races can apparently lead to an unkillable process (looping in the kernel) or to a panic. Thanks, Paul. ...

Subject: [PATCH] system call notification with self_ptrace From: Pierre Morel <pmorel@fr.ibm.com> PTRACE SELF This patch adds a new functionality to ptrace: system call notification to the current process. When a process requests self ptrace, with the new request PTRACE_SELF_ON: 1. the next system call performed by the process will not be executed 2. self ptrace will be disabled for the process 3. a SIGSYS signal will be sent to the process. With an appropriate SIGSYS signal ...

Dave put a recent copy up at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/libpcap.git --

applied to tip/x86/xen - thanks Alex. I've also merged the latest tip/x86/xen code into tip/master and i'm testing the result now. Ingo --

There's no need for these functions to be accessed from outside of xen/smp.c Signed-off-by: Alex Nixon <alex.nixon@citrix.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Ingo Molnar <mingo@elte.hu> --- arch/x86/xen/smp.c | 12 ++++++------ arch/x86/xen/xen-ops.h | 4 ---- 2 files changed, 6 insertions(+), 10 deletions(-) diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index bf51a46..d77da61 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -333,7 +333,7 @@ ...

Acked-by: Christoph Lameter <cl@linux-foundation.org> --

Oh, I see. Thanks Hugh. Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --

Hi Ben, here are the s3cmci SDIO patches that I've done so far. The first patch modifies the s3cmci driver so that it supports non-word-sized transfers which is needed by SDIO. The second patch removes calls the pio_tasklet directly from the interrupt handler instead of scheduling it as a tasklet. This reduces the CPU load for the driver sligthtly. The third patch adds experimental SDIO interrupt support. Since there are issues with spurious interrupts on some S3C processors, I ...

Hmm, i'd be interested to find out how long these are taking... I might try and rig up something to test the time being taken via an SMDK. If the fifo read/writes are taking significant amounts of time, then the pio tasklet will at least improve the interrupt latencies invloved, as iirc we're currently running the main irq handler in IRQ_DISABLED mode to stop any problems with re-enternancy.... I'll check this and see what -- -- Ben Q: What's a light-year? A: One-third less ...

Ok, I just measured this on the 200 MHz S3C24A0, when running the SDIO bus at 10 MHz, the longest time I saw the driver spend in the pio_read function was ~10us. I guess that means that the hardware managed to empty the fifo enough to do yet another spin through the loop. So with a faster SDIO clock the time spent in pio_read ought to go up, and for a long transfer it could grow without bounds. I also tried to run the code with the schedule_tasklet still there, and then I saw ~13us as ...

This cannot be a global variable, what happens when we have two disjoint --

Preferably in the form of in-code comments and code structure, this That would be much appreciated. But I also prefer to get rid of that power savings tweak in cpu_coregroup_map(). But above all, readable code ;-) find_busiest_group() is the stuff of nightmares. --

From: Gautham R Shenoy <ego@in.ibm.com> *** RFC patch of work in progress and not for inclusion. *** Currently the sched_mc/smt_power_savings variable is a boolean, which either enables or disables topology based power savings. This extends the behaviour of the variable from boolean to multivalued, such that based on the value, we decide how aggressively do we want to perform topology based powersavings balance. Variable levels of power saving tunable would benefit end user to match ...

> 1. Detailed documentation Messy code cannot be really made good with documentation. It's not that your patches are that messy, it's more that it makes I think one issue is that there are general too many special cases that completely change the algorithm especially for power saving. Perhaps it would make sense to refactor the code a bit and then use different high level code paths for those? I assume that would make it all simpler and easier to understand. The other alternative would be ...

current power save balance code: 1. Detailed documentation 2. Cleanup the group_min and group_leader stuff in find_busiest_group() Did I get the requirements correct? --Vaidy --

Just in case two groups have identical load, prefer to move load to lower logical cpu number rather than the present logic of moving to higher logical number. find_busiest_group() tries to look for a group_leader that has spare capacity to take more tasks and freeup an appropriate least loaded group. Just in case there is a tie and the load is equal, then the group with higher logical number is favoured. This conflicts with user space irqbalance daemon that will move interrupts to lower ...

When the system utilisation is low and more cpus are idle, then the process waking up from sleep should prefer to wakeup an idle cpu from semi-idle cpu package (multi core package) rather than a completely idle cpu package which would waste power. Use the sched_mc balance logic in find_busiest_group() to nominate a preferred wakeup cpu. This info can be sored in appropriate sched_domain, but updating this info in all copies of sched_domain is not practical. For now lets try with a global ...

Hi Linus, Please pull git://git.kernel.org/pub/scm/linux/kernel/git/hskinnemoen/avr32-2.6.git master to receive the following two fixes. Haavard Skinnemoen (1): avr32: Fix lockup after Java stack underflow in user mode Humphrey Bucknell (1): avr32: pm_standby low-power ram bug fix arch/avr32/kernel/asm-offsets.c | 6 +++ arch/avr32/kernel/entry-avr32b.S | 59 ++++++++++++++++++++++++++++++- arch/avr32/mach-at32ap/pm-at32ap700x.S | 2 +- 3 files ...

But the utsname gets freed after the mnt_ns, so the analysis seems wrong somehow. I trust addr2line or whatever verified that rpc_create+0x332/0x42f is exactly at the call to utsname()? --

On a system with nfs mounts, if a task unshares its mount namespace, a oops can occur when the system is rebooted if the task is the last to unreference the nfs mount. It will try to create a rpc request using utsname() which has been invalidated by free_nsproxy(). The patch fixes the issue by using the global init_utsname() but at the same time, it breaks the capability of identifying rpc clients per uts namespace. Any better suggestions ? BUG: unable to handle kernel NULL pointer ...

--

Hi, Is it possible to include pre-generated docs in the tarballs? I downloaded one and run 'make doc' and get these messages: fatal: Not a git repository which looks like it comes from this line in Documentation/Makefile: VERSION=$(shell git describe) Its not critical, but looks awkward. Thanks Bert --

There is no need to feel "it[']s really annoying", as install-doc from the tarball distribution works out of the box. I used 1.6.0.1 in the demonstration below, but this is nothing new in that version but has been like this for quite some time (it is how sample RPMs binary packages are built, so the procedure ought to work): $ ls -1 /usr/bin/git ;# to show there is no other "git" on this box ls: /usr/bin/git: No such file or directory $ mkdir /var/tmp/16 $ cd /var/tmp/16 ...

1) I already commit generated man pages for each release - on the man branch (there's also html branch with the html-formated man pages). 2) I'm aware of the git error you saw, and it is on my todo list 3) I just checked the git tarballs, and they don't include man pages either. Should I include the manpages in the source tarball, or should I just create another tarball with the manpages? (The git error will get fixed regardless - that's the only invocation of git during the ...

All the logic and locking is in the core code so would show up on all sorts of boxes. You say you are using sata_sil - is this on an Nvidia Can you duplicate this with the drives just on the ata_piix ? Alan --

We (the -stable team) are announcing the release of the 2.6.25.17 kernel. It contains lots of bugfixes, all over the map. Any users of the 2.6.25 kernel series should upgrade to this version. For details on the fixes, see the changelog entries and the diffstat below. I'll also be replying to this message with a copy of the patch between 2.6.25.16 and 2.6.25.17 The updated 2.6.25.y git tree can be found at: ...

The drives are on the ata_piix. I have no clue why the 'install' added the sata_sil driver because I have never used on on this machine! I note thet /etc/modprobe.conf has an alias for it so at one time a Fedora install thought it found one! Cheers, Dick Johnson Penguin : Linux version 2.6.25.17 on an i686 machine (4786.48 BogoMips). My book : http://www.AbominableFirebug.com/ _ **************************************************************** The information transmitted in this ...

--- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --

diff --git a/Makefile b/Makefile index e537896..63c96c6 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 26 -EXTRAVERSION = .3 +EXTRAVERSION = .4 NAME = Rotary Wombat # *DOCUMENTATION* diff --git a/arch/sparc64/mm/init.c b/arch/sparc64/mm/init.c index e289a98..387d3f6 100644 --- a/arch/sparc64/mm/init.c +++ b/arch/sparc64/mm/init.c @@ -842,6 +842,9 @@ static unsigned long nid_range(unsigned long start, unsigned long end, start += ...

Randy, does the patch below fix the problem? It's an interdiff between what I applied and what David sent me as the correct patch. thanks, greg k-h ------------- diff -u b/include/linux/mroute.h b/include/linux/mroute.h --- b/include/linux/mroute.h +++ b/include/linux/mroute.h @@ -2,7 +2,10 @@ #define __LINUX_MROUTE_H #include <linux/sockios.h> +#include <linux/types.h> +#ifdef __KERNEL__ #include <linux/in.h> +#endif /* * Based on the MROUTING 3.5 defines ...

From: Randy Dunlap <randy.dunlap@oracle.com> Sorry for creating such a confusing situation Greg :) --

On Thinkpads with ACPI video support, yes. -- Matthew Garrett | mjg59@srcf.ucam.org --

Nothing is actually planned, I do not care which config option will be used for that, just do not want to get a new claims on that it should be If I will ut (void) casting there, I'm pretty sure I will be blamed That's a fast path, so I optimized a bit, but I agree, iv initializaion could be also moved to the preallocated area. I think connector message can be allocated on stack, since I know the whole callchain in that path. I will updated the patch. -- Evgeniy Polyakov --

Hi Sven. Thanks for the review. Yup, sector_t is diffrent depending on arch and config options (u64 vs unsigned long), so it is not possible to represent it correctly without dereferencing In case of extended functionality there will be no need to change config Debug prints are not supposed to be turned on except on very serious conditions. In this case we do need to have as much info as possible (like No, I do belive that grepping over |struct ablkcipher_request| when something is ...

Some warnings: CC [M] drivers/block/dst/state.o drivers/block/dst/state.c: In function 'dst_recv_bio': drivers/block/dst/state.c:396: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'sector_t' drivers/block/dst/state.c: In function 'dst_process_io_response': drivers/block/dst/state.c:434: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'sector_t' CC [M] drivers/block/dst/export.o drivers/block/dst/export.c: In ...

What is the expectation? If you're expecting all the architectures to migrate over to RTC_CLASS, actually telling linux-arch and saying why its a good idea would have been helpful. All the PDC real time clock calls can do are read and set, nothing else, so it's idealy suited to the GEN_RTC infrastructure ... what's the No, it's a regression. You made it so when you added this # # These legacy RTC drivers just cause too many conflicts with the generic # RTC framework ... let's not even ...

From: David Brownell <david-b@pacbell.net> My update_persistent_clock() on sparc64 is: int update_persistent_clock(struct timespec now) { struct rtc_device *rtc = rtc_class_open("rtc0"); if (rtc) return rtc_set_mmss(rtc, now.tv_sec); return -1; } and that should handle this NTP shouldn't it? --

Easier if those distros just wouldn't select RTC_CLASS then. :) And long term, better to work with RTC_CLASS. Eliminate that crufty asm-parisc/rtc.h file and one more GEN_RTC user; and share more widely-used infrastructure. If I read things right, that would be easy: the PARISC RTC is two firmware calls, ptc_tod_{read,set}(), which would map to RTC class {read,set}_time() methods of about six lines each. The RTC framework can do UIE emulation, if needed. - Dave --

From: James Bottomley <James.Bottomley@HansenPartnership.com> I wrote RTC layer drivers on sparc64 that make the firmware calls in the Niagara system case, exactly like your case. Really, this is the way to do this. Since you're not reading what I implemented, I'll read it for you :-/ See drivers/rtc/rtc-sun4v.c, that's the driver Code in arch/sparc64/kernel/time.c creates and registers the appropriate platform_device object once the correct system type is detected, and then ...

The fact that the override you put in to disable GEN_RTC is causing a On 2.6.25 the parisc users got a working realtime clock. On 2.6.26 they can find themselves without one using the same .config file. This is the regression. The fix is to disable RTC_CLASS until we have it Kconfig is complex enough that we try not to trip users up by hiding things, especially when it's the wrong thing to hide on this platform. If an option specifically doesn't work or causes harm on a platform, ...

As of 2.6.26, most distribution kernels for PARISC are coming with the wrong RTC infrastructure enabled, meaning that userland can no longer get at the RTC, so all our parisc clocks are drifting. The fault is this patch: commit c750090085f260503d8beec1c73c4d2e4fe93628 Author: David Brownell <david-b@pacbell.net> Date: Mon Apr 28 02:11:52 2008 -0700 rtc: avoid legacy drivers with generic framework Which makes drivers/rtc take precedence over the generic rtc. However, for parisc we ...

I'm guessing they're not upstream yet (since I can't find them)? However, if you based them on rtc-ppc.c then yes, I agree, it looks reasonably easy: it's just a matter of converting over the GEN_RTC PDT_TOD helpers. On a related note ... I could do this specifically for parisc, but I could also do a GEN_RTC conversion to PDC_CLASS ... would that be more helpful? James --

I basically agree. There's functional overlap between those machine descriptions and the RTC framework, and it should be removed (by shrinking those descriptions). The shim gets /dev/rtcN support, and thus hwclock; also /sys/class/rtc/* stuff. But no wake alarms... That said, there's a bit of unresolved stuff around NTP hooks in the kernel. Some patches are pending to let thtem work with the RTC framework -- where writing an RTC may need to sleep, for example because the RTC is on an ...

Automounter maps can contain mount options valid for other NFS implementations but not for Linux. The Linux automounter uses the mount command's "-s" command line option ("s" for "sloppy") so that mount requests containing such options are not rejected. Commit f45663ce5fb30f76a3414ab3ac69f4dd320e760a attempted to address a known regression with text-based NFS mount option parsing. Unrecognized mount options would cause mount requests to fail, even if the "-s" option was used on the mount ...

applied to tip/sched/cpu-hotplug - thanks Manfred, nice cleanup. (FYI, i fixed up the 3 problems that checkpatch reported) David, can you see any problems with the Sparc32 bits? Ingo --

Well, the traditional wisdom in kernel land is that you want a spinlock if the contention phases are short. But we grow more an more places where we might do sleep under the lock. One optimization would be to spin, but only if the mutex holder is not sleeping. Or we make the spinning a completely different API, mutex_lock_adaptive() --

We (the -stable team) are announcing the release of the 2.6.26.5 kernel. It fixes the build error introduced in 2.6.26.4 due to me applying a stale patch to the tree. Thanks to David Miller for providing the correct patch and Randy Dunlap for pointing out my error. I'll also be replying to this message with a copy of the patch between 2.6.26.4 and 2.6.26.5 The updated 2.6.26.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.26.y.git and ...

That's just *asking* for flame mail if somebody builds a kernel for a system that's 4 year 9 months old, and he builds a kernel 6 months later, and it fails to boot because the CPU is now 3 months out and we've deprecated it... Quick - what year/month was the CPU you're using now released? No peeking. ;) (For the record, I have no *clue* when Intel actually released the Core2 T7200, which is a whole *nother* can of worms - the chip release date can be quite some time before the system ...

On Mon, 8 Sep 2008 12:30:02 -0700 (PDT) I'd lump all cpus that don't have cpuid in this bucket too (eg half the 486es) simply because not having cpuid is painful in pretty much the again makes sense; question is if it makes sense to take PSE and PAE it does to me; the only question is if we hit a new bucket with the various fancy string instructions that are in upcoming models; doing string/copy operations inlined for those guys will make a fourth bucket. -- If you want to reach me ...

Ok, so after having realized that this seems to be more about a bug with gcc, I'm really not as convinced any more. As far as I can tell, there are three issues: - "-mtune=core/core2/pentium4/.." is buggy in some gas/gcc versions on x86-32, and makes architectural choices. Any actual _released_ versions? Maybe it's just a current SVN issue? Workaround: don't use it. And yes, X86_GENERIC=y will do that, although quite frankly that seems to be dubious in itself. But ...

On Mon, 08 Sep 2008 11:22:24 -0700 the ideal case would be "support them all" the second-most ideal case would be "support all as of <year>" I suppose a third one for advanced users not distros would be "support only <vendor>" since that would be the biggest part of code to drop between models of the same vendor.. not too much to win there. -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit ...

Not really. That would include things like the i386, which is a bunch of really nasty stuff. -hpa --

Not really. Detecting CPUID is pretty trivial, and we just initialize Well, PAE implies PSE. Unfortunately Intel released a series of Pentium-Ms without PAE support. We *should* be able to take PSE for granted, but there is Xen damage. -hpa --

cmov, cmpxchg and xadd are the noticeable things. I think there are realistically three classes: - _really_ old, to the point of being totally useless for SMP. This is really just 386 and clones. We _need_ a working WP for a race-free access_ok(), and we need cmpxchg (and lately xadd). SMP cannot really realistically work reasonably (ys, there were SMP machines. No, they don't matter), and you'd have to be insane to care about this as a vendor even on UP. Probably ...

Linus, Please pull the latest x86-fixes-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus Thanks, -hpa ------------------> H. Peter Anvin (1): x86: enable CONFIG_X86_GENERIC by default arch/x86/Kconfig.cpu | 19 ++++++++++--------- 1 files changed, 10 insertions(+), 9 deletions(-) diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu index 2c518fb..46d0acf 100644 --- a/arch/x86/Kconfig.cpu +++ ...

What you can do it increase the /proc/sys/kernel/sched_shares_ratelimit value and thereby decrease the accuracy of the SMP fairness of the group scheduler. --

Sam: Is there a reason cc-option and friends use -S instead of -c? -hpa --

Linus, Please pull the latest x86-fixes-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus Thanks, -hpa ------------------> H. Peter Anvin (1): x86: prevent binutils from being "smart" and generating NOPLs for us Jeremy Fitzhardinge (1): xen: fix 2.6.27-rc5 xen balloon driver warnings Linus Torvalds (1): x86: disable static NOPLs on 32 bits arch/x86/Kconfig.cpu | 13 ++++++++----- ...

Oh bloody hell... cc-option = $(call try-run,\ $(CC) $(KBUILD_CFLAGS) $(1) -S -xc /dev/null -o "$$TMP",$(1),$(2)) Note the -S. Useless for anything related to the assembler. /me wimpers... -hpa --

That looks OK, but rather than copying it, why not move the definition into pgtable.h? Isn't it identical for all pagetable modes? --

Linus, Please pull the latest sched-fixes-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git sched-fixes-for-linus These are cpusets related cpu hotplug race fixes that have been tested to fix crashes and behavioral regressions that were reported. Thanks, Ingo ------------------> Max Krasnyansky (2): sched, cpuset: rework sched domains and CPU hotplug handling (v4) sched: arch_reinit_sched_domains() must destroy domains to ...

Two SMP fixes for sparc64: 1) Conversion to generic SMP call function helpers didn't update the locking. The sparc64 code was still using it's local "call lock" in it's cpu hotplug code, yet that isn't used for smp_call_function() et al. any longer. Fix to use the locking interface exposed by the generic code. 2) Bug fix from Paul McKenney so that the online cpu map is cleared at the correct moment during cpu hotplug. Otherwise an offline CPU can receive an interrupt ...

Hello Linus, some time ago I sent two patch scripts to LKML that changed the MAINTAINERS file. One fixed the alphabetic ordering and another merged the P and M fields to ease copy'n'paste. See http://thread.gmane.org/gmane.linux.kernel/702194 for the details. I still like both changes, but I think it's not sensible to send you the resulting patches because MAINTAINERS changes frequently. If you like these two changes, too, I would be happy if you run the attached script in your ...

I have 2 IOMEGA BETA90 scsi drives connected to an Adaptec pci 2930c scsi adapter. I use these drives in their raw form vi the SG interface. I cannot boot successfully with these drives connected and no media installed (2.6.24.3). After the machine finally boots up, "lsscsi" does not even show them. I'm booting off Sata drives and the scsi controller is NOT in the initrd. When the media is installed all is good BTW. I tried "options scsi_mod dev_flags=IOMEGA:BETA90:0x1000" in my ...

From: Alain Knaff <alain@knaff.lu> This is an updated version of my bzip2/lzma patch It is based on an idea by Christian Ludwig, includes support for compressing the kernel with bzip2 or lzma rather than gzip. Both compressors give smaller sizes than gzip. Lzma's decompresses faster than bzip2. It also supports ramdisks and initramfs' compressed using these two compressors. The functionality has been successfully used for a couple of years by the udpcast project This version applies ...

Added dummy function for hpet_setup_msi_irq(). Signed-off-by: Steven Noonan <steven@uplinklabs.net> --- arch/x86/kernel/hpet.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index 01005ae..422c577 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -635,6 +635,10 @@ static int hpet_cpuhp_notify(struct notifier_block *n, } #else +static int hpet_setup_msi_irq(unsigned int irq) +{ + return ...

Fixing compiler warning when the kernel isn't compiled with support for RAM block devices enabled. Signed-off-by: Steven Noonan <steven@uplinklabs.net> --- init/initramfs.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/init/initramfs.c b/init/initramfs.c index da8d030..2f056e2 100644 --- a/init/initramfs.c +++ b/init/initramfs.c @@ -512,6 +512,7 @@ skip: initrd_end = 0; } +#ifdef CONFIG_BLK_DEV_RAM #define BUF_SIZE 1024 static void __init ...