No, not an oversight. The point is, don't mask/unmask between ack/eoi while handling the interrupt. For many irq controllers, the eoi must be done from the same cpu, hence the mask and eoi before actually handling the interrupt in the general case. Its a feature of xics that we don't have to play that game, but can do the "PowerPC External Interrupt Architecture" is defined in appendix A of "Power.org™ Standard for Power Architecture™ Platform Requirements (Workstation, Server)", ...

--Boundary-01=_HFB3I9mohiun9Ep Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, On Friday 26 September 2008, you wrote in "Re: [Bug #11382] e1000e: 2.6.27-= rc1=20 I attached the current ubuntu 2.6.27 .config for 64bit x86. As another datapoint, my system wasnt effected although having loaded e1000= e=20 both with the ubuntu (without PAT) and the vanilla kernel (PAT enabled). I did not run the -32bit version on ...

This patch is a slightly cleaned up version of one which has been in use at for some time now at Google. It uses an HPET based time source to resynchronize the TSC on systems where it would otherwise be unsynchronized - eg early AMD Opteron based systems where the TSC rate drifts when going in and out of the C1E halt state. While the approach is quite crude it has been effective for systems where user space code relies on the TSC advancing at a constant rate and being reasonably well ...

Noticed this break with virtualization enabled on the latest mmotm. CC net/wireless/util.o CC [M] net/sunrpc/auth_gss/gss_krb5_unseal.o CC [M] drivers/usb/storage/freecom.o CC [M] net/sunrpc/auth_gss/gss_krb5_seqnum.o CC [M] drivers/usb/storage/dpcm.o CC net/wireless/reg.o CC [M] net/sunrpc/auth_gss/gss_krb5_wrap.o CC [M] drivers/usb/storage/isd200.o CC [M] net/sunrpc/auth_gss/gss_krb5_crypto.o CC net/wireless/nl80211.o CC [M] ...

Hello, System : debian/testing, tested kernels 2.6.26, 2.6.26.3, 2.6.26.5. Hardware : core2duo, 4 GB, raid1 software, CFQ scheduler. I have written a program that work on cartographic data. This program is started as a daemon and does some fork() (and pthread_create()). I have seen that it requires 6 GB to work, each process takes 1,5 GB. The same program works fine under FreeBSD or Solaris (on of course the same hardware). When it starts, I can see disk activity (swap), and after 2 ...

And of course, having tried Ingo Molnar's linux-tip (whereas before I was using 2.6.27) I have now found a modern kernel that doesn't exhibit the problem... --

Note: This patch is a proof of concept, and breaks a lot of functionality of ftrace. This patch simply makes ftrace work with the developmental ring buffer. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- kernel/trace/trace.c | 776 ++++++++------------------------------ kernel/trace/trace.h | 22 - kernel/trace/trace_functions.c | 2 kernel/trace/trace_irqsoff.c | 6 kernel/trace/trace_mmiotrace.c | 10 ...

[ NOTE function comments have not been updated. Comments within the code has.] This version I change the event header to what Peter Zijlstra requested. The buffer alignment is now 4 from 8. The minimum event is 8 bytes. The event header is now: struct event_header { u32 type:2, len:3, time_delta:27; u32 array[]; }; The length of the record is determined as: if (data size > 28 bytes) lenght = event->array[0] + sizeof(event_header); else length = event->len << 4 + ...

Here is the sketch, only for RFC. It is tested to work, but there could be silly thinkos anyway. I'll review the changes once again later... Anyhow... David, is this approach looks ok? Or I'm hopeless..? ;-) -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --

Today the API is still based on a fact that QE gpio controllers are registered. If they aren't, the API won't work (gracefully though). There is one caveat though: if anybody occupied the node->data before us, or overwrote it, then bad things will happen. Luckily this is all in the platform code that we fully control, so this should never happen. I could implement more checks (for example we could create a list of successfully registered QE controllers, and compare the node->data in the ...

OK, I'll test with some gcc versions. It's necessary to check outputs of the latest gcc, I think. thanks, Hiroshi Shimamoto --

Does this gcc failure mean unnecessary storing into stack? thanks, Hiroshi Shimamoto --

From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Use __{put|get}_user_cerr for cumulative error handling in x86 signal code. This makes stack usage and code size small. The line err |= __put_user(x, ptr); is comiled to like this; a0: 89 fa mov %edi,%edx a2: 8b 41 20 mov 0x20(%ecx),%eax a5: 89 46 08 mov %eax,0x8(%esi) a8: 89 55 b0 mov %edx,-0x50(%ebp) and the line __put_user_cerr(x, ptr, &err); is comiled to ...

From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Introduce __{put|get}_user_asm_eop which receives eop for error opecode. Define __{put|get}_user_asm as __{put|get}_user_asm_eop with "mov". Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> --- include/asm-x86/uaccess.h | 27 +++++++++++++++++++++------ 1 files changed, 21 insertions(+), 6 deletions(-) diff --git a/include/asm-x86/uaccess.h b/include/asm-x86/uaccess.h index c098dfe..84b0600 100644 --- ...

Wow, now it strikes me that i was running around blind all the time. SECMARK is a target not a match. I always thought i would implementing much the same thing. I guess there would be in fact currently not way to set a MARK or CONNMAK based on a SECMARK. Most of the *MARK targets have a --restore-mark option to restore a mark into the packet mark. But since the SECMARK is not numeric/bitmask there is nothing to restore. They however can do the same in regard do CONNSECMARK and ...

With SELinux the packet's CIPSO label (called the packet's peer label) is different from the SECMARK label. Assuming you take a similar approach in Smack, you should be able to implement SECMARK without Yes, in the absence of the sending socket to obtain the packet's peer label you need to examine the packet itself and any labeling Well, if you are accepting or dropping packets you are applying some form of access control. I thought that was the point of your patch? Hmmm, the ...

Hi all, i made some SMACK related patches. I hope this list is the right place to post them. The intention behind this patch is that i needed a way to (firewall) match for packets originating from specific processes. The existing owner match did not work well enough, especially since the cmd-owner part is removed. Then i thought about a way to tag processes and somehow match this tag in the firewall. I recalled that SELinux can do this (SECMARK) but SELinux would have been way to ...

Sorry if i pollute the wrong list with my stuff. But SMACK does not seem to have it's own list and now lives in the kernel. Though this is userspace related... The smack howto mentions a not yet implemented smack option for start-stop-daemon. We mainly use startproc. So i made a patch which adds this functionality to startproc. It adds the option [-S LABEL] to startproc, which brings the called process up with /proc/self/attr/current = LABEL. I figured setting the security context ...

From: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- Documentation/kmsg/s390/xpram | 61 ++++++++++++++++++++++++++++++++++++++++++ drivers/s390/block/xpram.c | 41 +++++++++++++--------------- 2 files changed, 80 insertions(+), 22 deletions(-) Index: kmsg-2.6/Documentation/kmsg/s390/xpram =================================================================== --- /dev/null +++ kmsg-2.6/Documentation/kmsg/s390/xpram @@ -0,0 ...

From: Martin Schwidefsky <schwidefsky@de.ibm.com> From: Michael Holzheu <holzheu@de.ibm.com> Introduce a new family of printk macros which prefixes each kmsg message with a component name and allows to tag the message with a 24 bit hash of the message text. The kmsg component name is defined per source file with the KMSG_COMPONENT macro. In order to use the kmsg_xxx macros KMSG_COMPONENT has to be defined. If the message hash will be printed to the console / syslog at all depends on ...

Greetings, after a short chat with Greg on the kernel summit here is now the hopefully final version of the kernel message catalog patches. As version x+2 this uses automatically generated message hashes. The new thing is that there are no more special kmsg_dev_xxx macros, this version uses the standard dev_xxx macros. If a KMSG_COMPONENT is defined then dev_xxx will include the message hash after the driver name in the format: <driver-name>.<message hash>: <device name>: <message> The ...

From: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/char/vmcp.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) Index: kmsg-2.6/drivers/s390/char/vmcp.c =================================================================== --- kmsg-2.6.orig/drivers/s390/char/vmcp.c +++ kmsg-2.6/drivers/s390/char/vmcp.c @@ -11,12 +11,15 ...

Overwrite things on page at a time. Don't you already do that? (I didn't check that closely, I just assumed you would do the _much_ simpler "move the head to the next page" thing rather than trying to mix head and tail Use the page start date for the first event in a page. But within pages, make everything depend on previous event. Linus --

Your timestamp handling seems odd. You do it per-event, but I think it should happen for all events, ie just do *ts += event->time_delta; _outside_ the case statement, and then in RB_TYPE_TIME_EXTENT you'd do either - relative: *ts += event->data << TS_SHIFT; - absolute timestamp events: *ts = (event->data << TS_SHIFT) + event->time_delta; but the bigger issue is that I think the timestamp should be relative to the _previous_ event, not relative to the page start. ...

This is probably very buggy. I ran it as a back end for ftrace but only tested the irqsoff and ftrace tracers. The selftests are busted with it. But this is an attempt to get a unified buffering system that was talked about at the LPC meeting. Now that it boots and runs (albeit, a bit buggy), I decided to post it. This is some idea that I had to handle this. I tried to make it as simple as possible. I'm not going to explain all the stuff I'm doing here, since this code is under a lot of ...

Yeah, I decided to do the blast the page instead of just blast the entry. Hmm, I'm confused. I do this already. I put the page start time on each page already. The events on the page are based on the page start time itself. The iterator, or writer, keeps track of the last event. When it reaches a new page, it reads the new time stamp of the page and starts incrementing against that. -- Steve --

Note: This patch is a proof of concept, and breaks a lot of functionality of ftrace. This patch simply makes ftrace work with the developmental ring buffer. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- kernel/trace/trace.c | 776 ++++++++------------------------------ kernel/trace/trace.h | 22 - kernel/trace/trace_functions.c | 2 kernel/trace/trace_irqsoff.c | 6 kernel/trace/trace_mmiotrace.c | 10 ...

This patch implements q->lld_busy_fn() for scsi mid layer to export its busy state. Please note that it checks the cached information (sdev->lld_busy) for efficiency, instead of checking the actual state of sdev/starget/shost everytime. So the care must be taken not to leave sdev->lld_busy = 1 for the following cases: - when there is no request in the sdev queue - when scsi can't dispatch I/Os anymore and needs to kill I/Os Otherwise, request stacking drivers may not submit any ...

Hello, Vanilla kernel 2.6.26.5 hangs on boot right after displaying isapnp: Scanning For PnP cards ... isapnp: No Plug & Play device found I have to power off my laptop to get out of this state. I never had this problem with previous kernels. Redhat Bugzilla has other people with this problem. I had it too so I compiled a vanilla kernel to make sure it wasn't vendor specific. https://bugzilla.redhat.com/show_bug.cgi?id=462156 If I append clocksource=hpet then the kernel will boot - but ...

From: Nick Piggin <npiggin@suse.de> Convert AFS to the new write address space operations. This cannot assume that writes will fully complete, so this conversion goes the easy way and always brings the page uptodate before the write. Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: David Howells <dhowells@redhat.com> --- fs/afs/file.c | 4 +- fs/afs/internal.h | 8 ++- fs/afs/write.c | 131 +++++++++++++++++------------------------------------ 3 files changed, ...

Inserting read-only ext3 SD card into a machine and trying to mount ext3 volume on it is very unnice :-(. Is there easy way to "fix" -oro so that it does not write to the media? (Machine died after I played with that SD card a bit more, but I can't easily reproduce that...) Pavel Sep 25 11:51:38 amd kernel: mmcblk0: mmc0:0002 SD1GB 975872KiB (ro) Sep 25 11:51:38 amd kernel: mmcblk0: p1 Sep 25 11:51:47 amd kernel: JBD: Clearing recovery information on journal Sep 25 11:51:47 ...

[Tej - Fri, Sep 26, 2008 at 12:04:30AM +0530] ... | > | > If assume that git bisect is right - it's hardly possible | | i have bisected it twice n jason mentioned that it looks like some | kind of nmi race condition. | | but i will bisect it again in rc7 and let you know. | | > that proc_nmi_enabled() related changes introduced this | > error (ie this commit) - kgdb seems to be not | > touching /proc/sys/kernel/nmi while doing self-tests. | > | > - Cyrill - | > | There was a ...

[Cyrill Gorcunov - Thu, Sep 25, 2008 at 06:56:35PM +0400] | [Tej - Thu, Sep 25, 2008 at 08:05:23PM +0530] | | On 9/11/08, Jason Wessel <jason.wessel@windriver.com> wrote: | | > Tej wrote: | | >> observed a panic on 2.6.27-rc6 caused by enabling | | >> "CONFIG_KGDB_TESTS_ON_BOOT" option | | >> | | >> panic logged using serial console and .config are attached. | | >> | | >> Linux version 2.6.27-rc6 (root@luser-desktop) (gcc version 4.2.3 | | > (Ubuntu 4.2.3-8 | | > [clip] | | >> kgdb: ...

[Tej - Thu, Sep 25, 2008 at 08:05:23PM +0530] | On 9/11/08, Jason Wessel <jason.wessel@windriver.com> wrote: | > Tej wrote: | >> observed a panic on 2.6.27-rc6 caused by enabling | >> "CONFIG_KGDB_TESTS_ON_BOOT" option | >> | >> panic logged using serial console and .config are attached. | >> | >> Linux version 2.6.27-rc6 (root@luser-desktop) (gcc version 4.2.3 | > (Ubuntu 4.2.3-8 | > [clip] | >> kgdb: Registered I/O driver kgdbts. | >> kgdbts:RUN plant and detach test | >> kgdbts:RUN sw ...

Applied to: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next-creds-subsys -- James Morris <jmorris@namei.org> --

My fault linux-2.6.27-rc7 fixes this. I should have tested this. Thanks to all who responded with fixes. John -----Original Message----- From: John Gumb Sent: 24 September 2008 12:26 To: linux-kernel@vger.kernel.org Cc: 'netdev@vger.kernel.org' Subject: D945GCLF intel atom board & r8169 ethernet broken in linux-2.6.27-rc5?? Hi I have an Intel Atom D945GCLF based system. It has a realtek RTL8101E PCI network interface. With linux-2.6.27-rc4 - everything seems fine. I think ...

Page migration is currently very slow because its overhead is quadratic with the number of pages. This is caused by each single page migration doing a linear lookup in the page array in new_page_node(). Since pages are stored in the array order in the pagelist and do_move_pages process this list in order, new_page_node() can cache the last "pm" pointer to the page array. This way, the next iteration will find the next page in usually 1 while loop (or 0 if called multiple times on the same page, ...

Hi Gregory, We see the following BUG followed by a hang on the latest kernel 2.6.26.5-rt9 on a Power6 blade (PPC64) It is easily recreated by running the async_handler or sbrk_mutex (realtime tests from ltp) tests. login: cpu 0x2: Vector: 700 (Program Check) at [c0000000e8e875d0] pc: c00000000005110c: .pick_next_pushable_task+0x54/0x9c lr: c000000000059f50: .push_rt_task+0x44/0x2b4 sp: c0000000e8e87850 msr: 8000000000021032 current = 0xc0000000ea5bb2e0 paca = ...

From: Avi Kivity <avi@qumranet.com> Now that two-dimensional paging is becoming common, account for tdp page faults. Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/mmu.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index a1ca4ff..a24da8f 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -1283,6 +1283,7 @@ static int direct_map_entry(struct kvm_shadow_walk *_walk, mmu_set_spte(vcpu, sptep, ...

From: Avi Kivity <avi@qumranet.com> This is esoteric and only needed to break COW on MAP_SHARED mappings. Since KVM no longer does these sorts of mappings, breaking COW on them is no longer necessary. Signed-off-by: Avi Kivity <avi@qumranet.com> --- virt/kvm/kvm_main.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 0309571..de3b029 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -734,7 +734,7 @@ ...

From: Joerg Roedel <joerg.roedel@amd.com> Currently KVM implements MC0-MC4_MISC read support. When booting Linux this results in KVM warnings in the kernel log when the guest tries to read MC5_MISC. Fix this warnings with this patch. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/x86.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 675d010..e3b8966 ...

From: Avi Kivity <avi@qumranet.com> It is not specific to the paging mode, so can be made global (and reusable). Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/mmu.c | 2 ++ arch/x86/kvm/paging_tmpl.h | 3 --- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 171bcea..51d4cd7 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -135,6 +135,8 @@ module_param(dbg, bool, 0644); #define ...

From: Avi Kivity <avi@qumranet.com> Spurious acks can be generated, for example if the PIC is being reset. Handle those acks gracefully rather than flooding the log with warnings. Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/i8254.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c index 7d04dd3..c842060 100644 --- a/arch/x86/kvm/i8254.c +++ b/arch/x86/kvm/i8254.c @@ -228,7 +228,7 @@ void ...

From: Avi Kivity <avi@qumranet.com> Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/paging_tmpl.h | 158 ++++++++++++++++++++++++-------------------- 1 files changed, 86 insertions(+), 72 deletions(-) diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h index ebb26a0..b7064e1 100644 --- a/arch/x86/kvm/paging_tmpl.h +++ b/arch/x86/kvm/paging_tmpl.h @@ -25,6 +25,7 @@ #if PTTYPE == 64 #define pt_element_t u64 #define guest_walker ...

From: Avi Kivity <avi@qumranet.com> We currently walk the shadow page tables in two places: direct map (for real mode and two dimensional paging) and paging mode shadow. Since we anticipate requiring a third walk (for invlpg), it makes sense to have a generic facility for shadow walk. This patch adds such a shadow walker, walks the page tables and calls a method for every spte encountered. The method can examine the spte, modify it, or even instantiate it. The walk can be aborted by ...

From: Amit Shah <amit.shah@qumranet.com> ... instead of using the pic and ioapic variants Signed-off-by: Amit Shah <amit.shah@qumranet.com> Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/i8254.c | 6 ++---- arch/x86/kvm/x86.c | 8 +------- 2 files changed, 3 insertions(+), 11 deletions(-) diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c index c842060..fdaa0f0 100644 --- a/arch/x86/kvm/i8254.c +++ b/arch/x86/kvm/i8254.c @@ -596,10 +596,8 @@ void ...

From: roel kluin <roel.kluin@gmail.com> Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/x86_emulate.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c index d5da7f1..5d6c144 100644 --- a/arch/x86/kvm/x86_emulate.c +++ b/arch/x86/kvm/x86_emulate.c @@ -269,7 +269,7 @@ static u16 group_table[] = { ByteOp | DstMem | SrcNone | ModRM, ByteOp | DstMem ...

From: Xiantao Zhang <xiantao.zhang@intel.com> kvm/ia64 uses the virtio drivers to optimize its I/O subsytem. Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com> Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/ia64/kvm/Kconfig | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/ia64/kvm/Kconfig b/arch/ia64/kvm/Kconfig index 7914e48..8e99fed 100644 --- a/arch/ia64/kvm/Kconfig +++ b/arch/ia64/kvm/Kconfig @@ -46,4 +46,6 @@ config KVM_INTEL config ...

From: Avi Kivity <avi@qumranet.com> There is no reason to share internal memory slots with fork()ed instances. Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/x86.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index bfc7c33..675d010 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -4296,7 +4296,7 @@ int kvm_arch_set_memory_region(struct kvm *kvm, userspace_addr = do_mmap(NULL, 0, ...

From: Amit Shah <amit.shah@qumranet.com> Fix typo in as-yet unused macro definition. Signed-off-by: Amit Shah <amit.shah@qumranet.com> Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/svm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 179c2e0..be86c09 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -44,7 +44,7 @@ MODULE_LICENSE("GPL"); #define SVM_FEATURE_NPT (1 << 0) #define ...

From: Avi Kivity <avi@qumranet.com> This is more emulation friendly, if not 100% correct. Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/vmx.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 6aa305a..71e57ae 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -1991,7 +1991,7 @@ static void seg_setup(int seg) vmcs_write16(sf->selector, 0); vmcs_writel(sf->base, 0); ...

From: Mohammed Gamal <m.gamal005@gmail.com> The emulator only supported one instance of mov r, imm instruction (opcode 0xb8), this adds the rest of these instructions. Signed-off-by: Mohammed Gamal <m.gamal005@gmail.com> Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/x86_emulate.c | 15 +++++++++++---- 1 files changed, 11 insertions(+), 4 deletions(-) diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c index ae30435..66e0bd6 100644 --- ...

From: Mohammed Gamal <m.gamal005@gmail.com> This patch adds functions to check whether guest state is VMX compliant. Signed-off-by: Mohammed Gamal <m.gamal005@gmail.com> Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/vmx.c | 180 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 180 insertions(+), 0 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 81db7d4..e889b76 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ ...

From: Avi Kivity <avi@qumranet.com> Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/x86_emulate.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c index 5d6c144..ae30435 100644 --- a/arch/x86/kvm/x86_emulate.c +++ b/arch/x86/kvm/x86_emulate.c @@ -270,7 +270,7 @@ static u16 group_table[] = { 0, 0, 0, 0, [Group3*8] = DstMem | SrcImm | ModRM, 0, - DstMem | SrcNone | ModRM, ByteOp | DstMem | ...

From: Avi Kivity <avi@qumranet.com> Real mode cs is a data segment, not a code segment. Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/vmx.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 9840f37..6aa305a 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -2239,6 +2239,7 @@ static int vmx_vcpu_reset(struct kvm_vcpu *vcpu) fx_init(&vmx->vcpu); + seg_setup(VCPU_SREG_CS); /* * ...

From: Avi Kivity <avi@qumranet.com> Signed-off-by: Avi Kivity <avi@qumranet.com> --- include/asm-x86/kvm_host.h | 13 ++----------- 1 files changed, 2 insertions(+), 11 deletions(-) diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h index 1161af1..982b6b2 100644 --- a/include/asm-x86/kvm_host.h +++ b/include/asm-x86/kvm_host.h @@ -734,15 +734,6 @@ enum { TASK_SWITCH_GATE = 3, }; - -#ifdef CONFIG_64BIT -# define KVM_EX_ENTRY ".quad" -# define KVM_EX_PUSH ...

From: Avi Kivity <avi@qumranet.com> Real mode segments to not reference the GDT or LDT; they simply compute base = selector * 16. Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/x86.c | 22 ++++++++++++++++++++++ 1 files changed, 22 insertions(+), 0 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 22edd95..bfc7c33 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3588,11 +3588,33 @@ static int load_segment_descriptor_to_kvm_desct(struct ...

From: Avi Kivity <avi@qumranet.com> Signed-off-by: Avi Kivity <avi@qumranet.com> --- arch/x86/kvm/mmu.c | 93 ++++++++++++++++++++++++++++++--------------------- 1 files changed, 55 insertions(+), 38 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 8b95cf7..a1ca4ff 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -1260,49 +1260,66 @@ static void nonpaging_new_cr3(struct kvm_vcpu *vcpu) { } -static int __direct_map(struct kvm_vcpu *vcpu, gpa_t v, ...

Changelog ----------------- v2 -> v3 - separated /proc/[pid]/core_dump_filter bits into shared and private mapping pages. - updated document v1 -> v2 - updated document ============================================ Subject: [PATCH v3] coredump_filter: add hugepage core dumping Now, hugepage's vma has VM_RESERVED flag in order not to being swapped. But VM_RESERVED vma isn't core dumped because this flag is often used for some kernel vmas (e.g. vmalloc, sound ...

On Thu, 25 Sep 2008 13:28:56 +0100 NACK. mmiotrace's log output is stricly specified, the standard/default printing functions may NOT be used. The output is supposed to be machine readable in addition to human readable. The ftrace infrastructure assumes there is only one active tracer at a time, therefore destroying unhandled entries is not a problem. -- Pekka Paalanen http://www.iki.fi/pq/ --

On Thu, 25 Sep 2008 16:44:08 +0200 We can (must) return to this if/when multiple tracers are allowed to be active simultaneously. But in the current situation, I do not see a way to trace more than one thing, but I haven't really looked into the other tracers. OTOH, mmiotrace log format has a pid field, which is pretty much unused currently. It could be used to record the current process, if one exists. That can be added, should the need arise, but so far the field has been reserved for ...

applied to tip/tracing/mmiotrace, thanks Frédéric! Ingo --

applied to tip/tracing/fastboot, thanks Frédéric! Ingo --

On Thu, 25 Sep 2008 17:33:02 +0200 My understanding is that the pipe will be broken only, if the trace framework believes tracing is disabled. Recall the discussion about tracer_enabled = 0. Which is a bug, and I hoped Steven would have commented on how to fix that properly. Or was it fixed already, and this is a different issue? I didn't notice. -- Pekka Paalanen http://www.iki.fi/pq/ --

Hi! I tried to figure out the origin of the bug reported by Pekka Paalanen about the broken pipe: http://kerneltrap.org/mailarchive/linux-kernel/2008/9/15/3305224 When I add a trace_mark with the boot tracer, I had this same problem but this time it was easy to reproduce. When it calls a tracer's print_line callback, the print_trace_line function in trace.c returns whithout verifying if it could handle the entry properly. And actually the seq could be empty. For example the boot_tracer ...

It is on -tip if you want :) So, unless someone is opposed to. I will send a patch which define three possible values for the print_line callback. I will define these values on trace.h Why not: #define TRACE_TYPE_PARTIAL_LINE 0 #define TRACE_TYPE_HANDLED 1 #define TRACE_TYPE_UNHANDLED 2 => will relay on default functions Hmm I'm questionning about the relevance of this kind of patch since the tracing API is in refactoring... --

Actually there was two bugs which broke the pipe: _ As you say the old one when none tracer put tracer_enabled = 0 _ And the new one I described here. I think the first is fixed since none tracer has been replaced by "nop tracer" (a recently implemented) which doesn't touch tracer_enabled at all. --

Subject: [PATCH] iucv: Fix mismerge again. From: Heiko Carstens <heiko.carstens@de.ibm.com> fb65a7c091529bfffb1262515252c0d0f6241c5c ("iucv: Fix bad merging.") fixed a merge error, but in a wrong way. We now end up with the bug below. This patch corrects the mismerge like it was intended. BUG: scheduling while atomic: swapper/1/0x00000000 Modules linked in: CPU: 1 Not tainted 2.6.27-rc7-00094-gc0f4d6d #9 Process swapper (pid: 1, task: 000000003fe7d988, ksp: ...

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- arch/x86/kernel/pci-gart_64.c | 17 +++++++++-------- include/asm-x86/gart.h | 2 ++ 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c index b85a2f9..aa569db 100644 --- a/arch/x86/kernel/pci-gart_64.c +++ b/arch/x86/kernel/pci-gart_64.c @@ -27,8 +27,8 @@ #include <linux/scatterlist.h> #include <linux/iommu-helper.h> #include ...

hm, that looks broken. Ingo --

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- arch/x86/kernel/pci-gart_64.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c index aa569db..aecea06 100644 --- a/arch/x86/kernel/pci-gart_64.c +++ b/arch/x86/kernel/pci-gart_64.c @@ -80,7 +80,7 @@ AGPEXTERN int agp_memory_reserved; AGPEXTERN __u32 *agp_gatt_table; static unsigned long next_bit; /* protected by iommu_bitmap_lock ...

ehci_watchdog will wake up CPU very frequently so that CPU stays at C3 very short, average residence time is about 50 ms on Aspire One, but we expect it should be about 1 second or more, so this kind of periodic timer is very bad for power saving. We can't remove this timer because of some bad USB controller chipset, but at least we should reduce its side effect to as possible as low. This patch can make CPU stay at C3 longer, average residence time is about twice as long as original. ...

Hi Bart, here's another null ptr fix in the debugging code. I'll be auditing all the debug fragments in case I've missed some. --- From: Borislav Petkov <petkovbb@gmail.com> Date: Thu, 25 Sep 2008 09:36:26 +0200 Subject: [PATCH] ide-cd: fix another NULL ptr in debug statement There should be no functionality change resulting from this patch. Signed-off-by: Borislav Petkov <petkovbb@gmail.com> --- drivers/ide/ide-cd.c | 11 +++++++---- 1 files changed, 7 insertions(+), 4 ...

Sorry for the dumb question but where is acpi_get_table_with_size defined? Its not in linus's git. /me goes and gets linux-next... --mgross --

since this depends on other x2apic/sparseirq changes in -tip i've applied it to tip/irq/sparseirq. Jesse, any objections? Ingo --

Nope, but it would be good to get Dave or Mark's ack (Dave owns this code now). Jesse --

Yes. X assumed that any ACPI key press was a request to switch the video output. Upgrade X. -- Matthew Garrett | mjg59@srcf.ucam.org --

Since CONFIG_ACPI_VIDEO wasn't required before 2.6.26.x to change the LCD brightness, I'd rather the kernel go back to whatever it was doing for 2.6.25.x. Upgrading X past what's currently packaged by the distribution just to get a new kernel working is somewhat of a pain. What change linked the brightness keys to CONFIG_ACPI_VIDEO? -- DN Daniel --

Hi all, I just upgraded from 2.6.25.17 to 2.6.26.5 on my Thinkpad Z61t, and found the brightness keys will cause the X server to die. When using the brightness up/down keys, the screen will go blank -- Control+Alt+F# will still switch to a different virtual console, but switching back will not restore the video state. After killing the window manager, I was able to bring up X again without a problem -- but using the brightness keys still causes it to go blank again within X, while the ...

need more work.. YH --

Thanks James. I am trying unix mail command. It seems to be working fine. I will resubmit once I make sure everything is ok. Again, sorry about the trouble. Jing -----Original Message----- From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com] Sent: Thursday, September 25, 2008 8:35 AM To: Jing Huang Cc: Jeremy Higdon; Greg KH; linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Ramkumar Vadivelu; Vinodh Ravindran; Srikanth Rayas (CW) Subject: RE: [PATCH 1/6] bfa: ...

Yes ... attachments can be tolerated for people who are forced to use outlook. We had a similar issue with Adaptec engineers. There are rumours that outlook can be persuaded not to mangle text, but everyone who claims to be able to do it has been unable to reproduce under laboratory conditions. James --

Why do we want to print the irq as hex? Do we do that anywhere else? I think we should pick one format and stick with it, and I think decimal is the logical choice because it's the most common. --

looks there is some merge problem. Index: linux-2.6/arch/x86/kernel/hpet.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/hpet.c +++ linux-2.6/arch/x86/kernel/hpet.c @@ -467,6 +467,9 @@ static int hpet_setup_irq(struct hpet_de irq_set_affinity(dev->irq, cpumask_of_cpu(dev->cpu)); enable_irq(dev->irq); + printk(KERN_DEBUG "hpet: %s is using irq %#x aka %d for MSI\n", + dev->name, dev->irq, ...

will check it. YH --

when sparseirq is enabled, irq for msi will be bus_nr/dev/func + 12bits. so show it as hex is more straight. but we can not use hex in /proc/interrupts --ABI want decimal. just try to print out...in log, so user could get some idea that who is using it... YH --

While page-cache's charge/uncharge is done under page_lock(), swap-cache isn't. (anonymous page is charged when it's newly allocated.) This patch moves do_swap_page()'s charge() call under lock. This helps us to avoid to charge already mapped one, unnecessary calls. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> mm/memory.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) Index: ...

Make root cgroup of memory resource controller to have no limit. By this, users cannot set limit to root group. This is for making root cgroup as a kind of trash-can. For accounting pages which has no owner, which are created by force_empty, we need some cgroup with no_limit. A patch for rewriting force_empty will will follow this one. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Documentation/controllers/memory.txt | 4 ++++ mm/memcontrol.c ...

There is a small race in do_swap_page(). When the page swapped-in is charged, the mapcount can be greater than 0. But, at the same time some process (shares it ) call unmap and make mapcount 1->0 and the page is uncharged. For fixing this, I added a new interface. - precharge account to res_counter by PAGE_SIZE and try to free pages if necessary. - commit register page_cgroup and add to LRU if necessary. - cancel uncharge PAGE_SIZE because of do_swap_page failure. This ...

Hi, I updated the stack and reflected comments. Against the latest mmotm. (rc7-mm1) Major changes from previous one is - page_cgroup allocation/lookup manner is changed. all FLATMEM/DISCONTIGMEM/SPARSEMEM and MEMORY_HOTPLUG is supported. - force_empty is totally rewritten. and a problem that "force_empty takes long time" in previous version is fixed (I think...) - reordered patches. - first half are easy ones. - second half are big ones. I'm still testing with full ...

Current force_empty of memory resource controller just removes page_cgroup. This maans the page is never accounted at all and create an in-use page which has no page_cgroup. This patch tries to move account to "root" cgroup. By this patch, force_empty doesn't leak an account but move account to "root" cgroup. Maybe someone can think of other enhancements as moving account to its parent. (But moving to the parent means we have to handle "limit" of pages. Need more complicated work to do ...

Allocate all page_cgroup at boot and remove page_cgroup poitner from struct page. This patch adds an interface as struct page_cgroup *lookup_page_cgroup(struct page*) All FLATMEM/DISCONTIGMEM/SPARSEMEM and MEMORY_HOTPLUG is supported. Remove page_cgroup pointer reduces the amount of memory by - 4 bytes per PAGE_SIZE. - 8 bytes per PAGE_SIZE if memory controller is disabled. (even if configured.) meta data usage of this is no problem in FLATMEM/DISCONTIGMEM. On SPARSEMEM, this makes ...

This patch provides a function to move account information of a page between mem_cgroups. This moving of page_cgroup is done under - lru_lock of source/destination mem_cgroup is held. - lock_page_cgroup() is held. Then, a routine which touches pc->mem_cgroup without lock_page_cgroup() should confirm pc->mem_cgroup is still valid or not. Typlical code can be following. (while page is not under lock_page()) mem = pc->mem_cgroup; mz = ...

Hi, sched: Maintain only task entities in cfs_rq->tasks list. cfs_rq->tasks list is used by the load balancer to iterate over all the tasks. Currently it holds all the entities (both task and group entities) because of which there is a need to check for group entities explicitly during load balancing. This patch changes the cfs_rq->tasks list to hold only task entities. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> CC: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> CC: Peter ...

applied to tip/sched/devel, thanks! Ingo --

From: Jing Huang <huangj@brocade.com> This patch contains common header files for linux driver and hardware/firmeare interface. It is created using 2.6.27-rc7 kernel. Signed-off-by: Jing Huang <huangj@brocade.com> --- drivers/scsi/bfa/include/aen/bfa_aen.h | 73 + drivers/scsi/bfa/include/aen/bfa_aen_adapter.h | 31 drivers/scsi/bfa/include/aen/bfa_aen_audit.h | 31 drivers/scsi/bfa/include/aen/bfa_aen_ioc.h | 35 ...

From: Jing Huang <huangj@brocade.com> This patch contains code that interfaces to Brocade Fibre channel HBA firmware/hardware. It is created using 2.6.27-rc7 kernel. Signed-off-by: Jing Huang <huangj@brocade.com> --- drivers/scsi/bfa/bfa_callback_priv.h | 55 + drivers/scsi/bfa/bfa_cb_ioim_macros.h | 215 ++++ drivers/scsi/bfa/bfa_core.c | 421 ++++++++ drivers/scsi/bfa/bfa_csdebug.c | 60 + drivers/scsi/bfa/bfa_fcpim.c | 158 +++ ...

This is completely the wrong thing to do. The driver needs to bind to the Fibre Channel transport class which provides all of these features in a large measure through infrastructure shareable with the other FC drivers. Any other pieces that are brocade specific rather than FC general can go in host attributes in the same way as the rest of the FC drivers do it. James --

From: Jing Huang <huangj@brocade.com> This patch contains Makefile and Kconfig file for scsi and bfa. It is created using 2.6.27-rc7 kernel. Signed-off-by: Jing Huang <huangj@brocade.com> --- drivers/scsi/Kconfig | 6 ++++++ drivers/scsi/Makefile | 1 + drivers/scsi/bfa/Kconfig | 6 ++++++ drivers/scsi/bfa/Makefile | 25 +++++++++++++++++++++++++ 4 files changed, 38 insertions(+) diff -urpN orig/drivers/scsi/bfa/Kconfig patch/drivers/scsi/bfa/Kconfig --- ...

Your patch is line-wrapped and can't be applied :( Also, did I miss a [0/6] patch that describes this driver and what it is all about? Care to try again? thanks, greg k-h --

From: Jing Huang <huangj@brocade.com> This patch contains code that interfaces to upper layer linux kernel, such as PCI, SCSI mid-layer and sysfs etc. It is created using 2.6.27-rc7 kernel. Signed-off-by: Jing Huang <huangj@brocade.com> --- drivers/scsi/bfa/bfad.c | 1339 ++++++++++++++++++ drivers/scsi/bfa/bfad_attr.c | 660 +++++++++ drivers/scsi/bfa/bfad_attr.h | 75 + drivers/scsi/bfa/bfad_drv.h | 340 ++++ drivers/scsi/bfa/bfad_fwimg.c | 86 + ...

Something like unsigned long now = jiffies; ret = wait_event_interruptible_timeout(..., timeout); if (ret < 0) { next_timeout = now + timeout - jiffies; if (next_timeout < 0) next_timeout = 0; } We can even add another wait_ helper which treats "timeout" as lvalue I'm afraid it would be a pain to modify this API. But please do not hesitate to make the patch if you think the current API can be improved. At worst, the patch will be nacked ;) Oleg. --

The PCI bridge on the Holly board is current incorrectly represented in the device tree. The current device tree node for the PCI bridge sits under the tsi-bridge node. That's not obviously wrong, but the PCI bridge translated some PCI spaces into CPU address ranges which were not translated by the tsi-bridge node. We used to get away with this problem because the PCI bridge discovery code was also buggy, assuming incorrectly that PCI host bridge nodes were always directly under the root bus ...

Er... on second thought, this actually fixes a regression on Holly. So I'll amend my offer to put it in my 'next' branch to be contingent on you not wanting to get it into 2.6.27 this late. josh --

Please pull from 'davem-next' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git davem-next to receive the following updates: arch/arm/mach-kirkwood/db88f6281-bp-setup.c | 2 +- arch/arm/mach-kirkwood/rd88f6192-nas-setup.c | 2 +- arch/arm/mach-kirkwood/rd88f6281-setup.c | 2 +- arch/arm/mach-loki/lb88rc8480-setup.c | 2 +- arch/arm/mach-mv78xx0/common.c | 6 +- arch/arm/mach-mv78xx0/db78x00-bp-setup.c | 8 +- ...

From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Introduce new macro is_ia32 for unification of setup_rt_frame(). No affect in binary, compiler will optimize. Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> --- arch/x86/kernel/signal_32.c | 13 +++++++++---- arch/x86/kernel/signal_64.c | 13 +++++++++---- 2 files changed, 18 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c index b1bc90f..cf62f70 100644 --- ...

From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Make 32-bit setup_rt_frame() look like 64-bit version for unification. Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> --- arch/x86/kernel/signal_32.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c index cf62f70..4337cd5 100644 --- a/arch/x86/kernel/signal_32.c +++ b/arch/x86/kernel/signal_32.c @@ -492,6 +492,8 @@ static int ...

applied your patches to tip/x86/signal: 4694d23: x86: signal_32.c: introduce macro ia32_setup_frame and ia32_setup_rt_frame 455edbc: x86: signal: introduce helper macro is_ia32 b94fd69: x86: signal_64.c: introduce helper function signr_convert() 8d8c13b: x86: signal_32.c: introduce signr_convert() thanks! FYI, your other 13 x86 signal code unification commits and other x86-signals enhancements passed testing just fine so far. Ingo --

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c index dd097b8..9943b4c 100644 --- a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c +++ b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c @@ -779,6 +779,9 @@ static int __init acpi_cpufreq_init(void) { int ret; + if ...

rationale: improve debuggability of memory setup problems. Ingo --

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- mm/page_alloc.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index e293c58..db30af6 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3425,8 +3425,8 @@ static void __paginginit free_area_init_core(struct pglist_data *pgdat, PAGE_ALIGN(size * sizeof(struct page)) >> PAGE_SHIFT; if (realsize >= memmap_pages) { realsize -= ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/irq_32.c | 2 +- arch/x86/kernel/irq_64.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/irq_32.c b/arch/x86/kernel/irq_32.c index b2e1082..001772f 100644 --- a/arch/x86/kernel/irq_32.c +++ b/arch/x86/kernel/irq_32.c @@ -307,7 +307,7 @@ int show_interrupts(struct seq_file *p, void *v) action = desc->action; if (!action && !any_count) goto skip; - seq_printf(p, ...

I posted a similar patch already: http://lkml.org/lkml/2008/8/22/178 Maybe mine was too complicated because it touched more files at once. Regardless, we need to remove the #ifdef DEBUG because it's no longer necessary. --

when SPARSE_IRQ is not used, should still use irq_desc->lock Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- kernel/irq/handle.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c index 7f625fb..fb6bdb6 100644 --- a/kernel/irq/handle.c +++ b/kernel/irq/handle.c @@ -253,7 +253,7 @@ struct irq_desc irq_desc[NR_IRQS] __cacheline_aligned_in_smp = { .chip = &no_irq_chip, .handle_irq = handle_bad_irq, .depth = ...

32bit don't need that anymore Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- include/linux/acpi.h | 8 -------- 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 4d5ec43..8eefaa9 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -95,18 +95,10 @@ int acpi_parse_mcfg (struct acpi_table_header *header); void acpi_table_print_madt_entry (struct acpi_subtable_header *madt); /* the following four ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- drivers/pci/quirks.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 1f26712..addf2db 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1689,8 +1689,7 @@ static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f, struct pci_f if ((f->vendor == dev->vendor || f->vendor == (u16) PCI_ANY_ID) && (f->device == dev->device || ...

1. In this patch, we want to do one thing: add more Huawei product IDs into the USB driver. Then it can support more Huawei data card devices. So I make them in one patch. 2. To change usb_stor_huawei_e220_init function as follows, that's because in the USB standard, while sending SET_FETURE_D to the device, it requires the corresponding data to be zero, and its sending length also must be zero. In our old solution, it can be compatible with our WCDMA data card devices, but can not ...

From: Chuck Ebbert <cebbert@redhat.com> pci: document the pcie_aspm kernel parameter Index: linux-2.6.26.noarch/Documentation/kernel-parameters.txt =================================================================== --- linux-2.6.26.noarch.orig/Documentation/kernel-parameters.txt +++ linux-2.6.26.noarch/Documentation/kernel-parameters.txt @@ -1636,6 +1636,12 @@ and is between 256 and 4096 characters. reserved for the CardBus bridge's memory window. The default value is 64 ...

Can you explain a bit more concretely the problem this solves, and your testing? Ultimately we'll want to merge this code with the atl1 code, so we need to be confident that we can and should make the same change there. --

On Thu, 25 Sep 2008 18:34:29 -0400 Yes, LLTX can (and should) be removed from the atl1 code. I had an exchange with Herbert Xu and David Miller on LKML a few weeks ago, and they gave me a few tips on how to do it, but I haven't yet had the time. What takes an experienced netdev warrior about a half hour to implement unfortunately takes me days of after-dayjob time as I track through all the calls that that are affected and test the modified driver. Now back to atl2... I'd like to hear ...

Can you also add this one? It doesn't panic the kernel when a frame from firmware is invalid. http://marc.info/?l=linux-wireless&m=122219037706528&w=2 Thanks, -yi --

On Thu, Sep 25, 2008 at 2:41 PM, John W. Linville I'm just exporting the major bugs from our internal database to buzilla, 5000 is new so we are hitting the problems during testing before users report them. Now I don't know if it was good idea to push the driver upstream same time as it hits the market. Tomas --

Is there an open bug report for that anywhere? Is this something that real users (no offense to Johannes) are likely to hit? John -- John W. Linville Linux should be at the core linville@tuxdriver.com of your literate lifestyle. --

You're right -- pushing it sooner rather than sitting on it internally probably would have helped to give it more visibility sooner. John -- John W. Linville Linux should be at the core linville@tuxdriver.com of your literate lifestyle. --

David, please revert 2eefbd63d0c85daa1317636474c226e236beba81 by request of author, maintainer, and maintainer's maintainer :) Jeff --

I don't disagree with the CRAP name... fwiw. I think that we have enough quality problems without adding crap. -- ~Randy --

then it would be better if Greg/someone cleaned up the current tree's problems instead of introducing more CRAP under a different name. Oh well, his mind is already made up and I know how difficult it is to --- ~Randy --

Uhm.. not quite. As the one that proposed the flag in the first place, perhaps it helps to cover the rationale (although Greg seems to have mostly covered that already). EXPERIMENTAL today is pretty damn meaningless. What it tends to mean in practice is that somethings needs some more testing, someone wants to be able to pull out the EXPERIMENTAL card when someone enables their option and their kernel blows up, the option/feature hasn't been around in the kernel for that long, or someone has ...

You don't tell me why you want to do something as absurd and incoherent as wanting users to load the modules easily and automatically, then printing a warning about it even when user may not have loaded it on his/her own, then taint the kernel when there is no need to - I have repeatedly said it is very easy to see from the module list for people to decide - not rocket science, definitely not for developers. The whole TAINT drama is unnecessary. Why would people run with even 24 more lines ...

I'm sorry we disagree here. Also note that this goes against what a number of us decided at the kernel summit, we want this code into the So you now agree with the idea, just the implementation of the area A name doesn't really matter here, the modinfo tag is just as Um, no, I'm not going to force all userspace users to upgrade their version of module-init-tools, JUST to prevent them from automatically So you have to load the modules by "hand"? Ick, no, that too is ...

Heh, ok, so the basic premise of getting code that is not currently in mergable shape into the tree earlier to get wider usage and testing is something that you agree with? If so, we can arm-wrestle over what to call it, one name is as good as another, as long as we don't overload a currently used name like EXPERIMENTAL, which Paul has so well explained is a mess right now. And I don't have the inclination to clean up that mess right now, I'm more worried about bigger messes like these 15 ...

The whole concept is a bike shed - disproportionate importance to labeling same things with different name. So it should come as no surprise that we are discussing the need for Again - sure move the staging directory to the mainline tree, group all those drivers under CONFIG_HALFBAKED and default the whole category to N. Name those driver modules with a _stg prefix and be done with it. No need for the insanely useless module loading crap because - 1) You will happily load from that directory ...

How? TAINT_EXPERIMENTAL (I'll stick to that, thanks :) and CONFIG_EXPERIMENTAL are no different - neither to users nor to developers. Here is why - Both try to do the same thing - let people use the drivers on their own risk (as if the stable ones are developer's risk - but let's keep it aside for the moment) and give developers a chance to keep the code in sync with mainline and improve it per user problem reports or generally make it better. You might try to differentiate between them on ...

Re-read my explanation, please. Technically, it doesn't *matter* in that nothing will break, but so what? It's nicer if the DMA driver is already available when the client drivers load, so that they can use the DMA facilities right away. -- Timur Tabi Linux kernel developer at Freescale --

If there's a dependency there, how will it work when this is built as a module? -Scott --

There are no dependencies. fsldma registers with the DMA engine, which is always built in-kernel. The DMA engine is what handles linking DMA clients to DMA drivers. The DMA clients get a callback whenever a DMA driver registers with the DMA engine. If the DMA driver is already registered when the client registers, then the client will get a callback immediately after it registers. I chose subsys_initcall() to increase the probability that fsldma is already present when DMA clients are ...

If there's no dependency, why does it matter whether fsldma is already present? -Scott --

Yeah, I have more reports from people, that with recent kernels, the ieee1394-* links showed up and replaced the scsi-* links, which they say never happended before. We ship these rules for a long time now, so I just guessed, they never really worked before, but as all depends on timing, it's probably not predictable what happens. Regardless of the needed fix for scsi sysfs, we should provide both links, I guess. Thanks, Kay --

On Thu, Sep 25, 2008 at 23:13:19 +0200, Stefan Richter wrote: Not really. My initial problem was that a volume sometimes came up very late, so that the lvm2 initscript didn't activate that volume group. So I wanted to wait for this specific disk during boot. Meanwhile, I created an udev rule that uses the vendor and device name, which also has the advantage of being the same when the disk is connected via Firewire and USB (or, should be the same at least, I didn't test ...

Then this is a regression of the fastboot patch or whatever. They currently work. I never heard of them not working. Even if there were already problems now, then the necessary course of action would be to fix them instead of dropping them. Or fix the fine SCSI stack already to properly export target identifiers and LU identifiers. (Not going to happen because the SCSI folks just The scsi-* link may not be unique because it may be based on unsuitable I will look into it. -- ...

Hmmm - the filesystem mounted without errors, but init was not Same again, it's unable to run the init process. Of course, kernel_execve() throws away any error that might have occurred, so without hacking the init code we can't find out Ok, is the 2.6.27 kernel based on the same config as the 2.6.26 Does it boot if you take away the "ro" option? Cheers, -- Dave Chinner david@fromorbit.com --

http://undomiel.ics.muni.cz/tmp/IMG_2962.JPG this one is if I pass init=/bin/bash indeed. this is a grub record: title Linux 2.6.26.3 root (hd0,0) kernel /boot/vmlinuz-2.6.26.3 root=/dev/sda1 ro console=tty0 title Linux 2.6.27-rc7 root (hd0,0) kernel /boot/vmlinuz-2.6.27-rc7 root=/dev/sda1 ro -- Lukáš Hejtmánek --

I'm *REALLY* skeptical to burying this in screen_info like this, it would probably be better to put it in Kconfig, or it is unlikely to get updated properly. -hpa --

hm, 0x5a is a simple pop %rdx. A #GP there means the stack segment is bust? so it's preceded by a popfq and on the next instruction we #GP. but the stack and flags state looks good: [ 4.523641] RSP: 0018:ffff880007867d70 EFLAGS: 00000286 weird. Ingo --

I'm sorry for the false alarm. I discovered that it did not happen on a clean kernel. My kernel was using this patch. diff --git a/arch/x86/kernel/cpu/common_64.c b/arch/x86/kernel/cpu/common_64.c index a11f5d4..abf5bc8 100644 --- a/arch/x86/kernel/cpu/common_64.c +++ b/arch/x86/kernel/cpu/common_64.c @@ -261,6 +261,8 @@ void __init early_cpu_init(void) cpu_devs[cvdev->vendor] = cvdev->cpu_dev; early_cpu_support_print(); ...

No, I was wrong! It *does* happen for vanilla as well, but it doesn't happen reliably. [ 4.043370] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) [ 4.048765] general protection fault: fff2 [1] SMP [ 4.048765] CPU 0 [ 4.048765] Modules linked in: [ 4.048765] Pid: 1, comm: swapper Tainted: G W 2.6.27-rc7 #8 [ 4.048765] RIP: 0010:[<ffffffff81019d27>] [<ffffffff81019d27>] native_smp_send_stop+0x29/0x2d [ 4.048765] RSP: ...

I suspect it's a problem in Qemu's IOAPIC model, but it's hard to know for sure. -hpa --

LOL :) Applied the commit below to tip/x86/debug, thanks Bill! Ingo --------------------> From f6476774f1fe32593d3d71903b1e98514efbf685 Mon Sep 17 00:00:00 2001 From: Bill Nottingham <notting@redhat.com> Date: Wed, 24 Sep 2008 14:35:17 -0400 Subject: [PATCH] x86_64: be less annoying on boot Remove mostly useless message on every boot. Signed-off-by: Bill Nottingham <notting@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> --- arch/x86/kernel/head64.c | 2 -- 1 files ...

On 24-09-2008 19:28, Corey Minyard wrote: ... Aren't other functions like sk_next() or sk_unhashed() used on the read side and need _rcu versions? Jarek P. --

You do indeed need to match the update-side and read-side primitives: Update-side Read-side synchronize_rcu() rcu_read_lock() call_rcu() rcu_read_unlock() call_rcu_bh() rcu_read_lock_bh() rcu_read_unlock_bh() synchronize_sched() preempt_disable() preempt_enable() [and anything else that disables either preemption or irqs] synchronize_srcu() srcu_read_lock() srcu_read_unlock() Mixing RCU or RCU-SCHED with RCU-BH will ...

On Thu, 25 Sep 2008 08:29:36 -0700 Also, for consistency with other parts of networking code, don't introduce the synchronize_sched() or synchronize_srcu() pattern to network protocols unless there is a no other way to achieve the desired result. --

> - http://sourceforge.net/projects/bluetooth-alsa Allegedly deprecated in favour of a userspace ALSA plugin: http://www.mail-archive.com/debian-devel@lists.debian.org/msg253253.html > - http://www.unav-micro.com/Drivers.aspx -> AR81Family-linux-v1.0.1.0.tar.gz > (e.g. asus-p5q-pro m/b has such ethernet port, pciid=1969:1026) Isn't this the atl1e gigabit ethernet driver? Isn't this being merged into 2.6.27? - ...

could you look at these: - http://www.tahoe.pl/eng/patch.php - ftp://distfiles.pld-linux.org/distfiles/by-md5/8/e/8e4764f6c438427b00fb9aa93abb3cd7/to... thanks, pawel. --

here's a quick list: - http://www.lirc.org - http://sourceforge.net/projects/bluetooth-alsa - http://rt2x00.serialmonkey.com - http://www.unav-micro.com/Drivers.aspx -> AR81Family-linux-v1.0.1.0.tar.gz (e.g. asus-p5q-pro m/b has such ethernet port, pciid=1969:1026) - http://aufs.sourceforge.net - http://linux-uvc.berlios.de - http://www.misdn.org - toshiba bluetooth module [http://0bits.com/toshbt/toshbt-1.0.tar.gz] - zaptel telephony driver [http://www.asterisk.org] with firmware ...

^^^^ People are taking steps to adapt this to be included in kernel. See http://lwn.net/Articles/297770/ . I could have sworn I saw someone posting an input layer patch for lirc the other day too... Aha - Isn't this one already in the wireless tree? I believe it was merged in 2.6.24 - http://kernelnewbies.org/Linux_2_6_24#head-62e9ebf067c978bbf70898986c0aa3904d1a3543 I've read rumblings about one of the stacking FSes being merged but thus USB video has already been merged into ...

Sorry, do you mean we also need a warning for this in VMware? -- Li, Yan --

I checked your patch 1c6e5503 that moved dmi_scan_machine() earlier, but it's still behind mtrr_trim_uncached_memory(), so we still can't use DMI to check for VMware there. -- Li, Yan --

applied your fixes to tip/x86/iommu: 1615965: x86 gart: remove unnecessary initialization 1d99088: x86: restore old GART alloc_coherent behavior ecef533: revert "x86: make GART to respect device's dma_mask about virtual mappings" 9f6ac57: x86: export pci-nommu's alloc_coherent thanks Fujita! Ingo --

On Wed, 24 Sep 2008 19:13:09 +0900 (JST) I posted new ones. - http://lkml.org/lkml/2008/9/25/33 (changes in page_cgroup) http://lkml.org/lkml/2008/9/25/56 (I'm not sure this gets Ack or Nack. but direction will not change.) Then, please tell me if you have new troubles with new ones. Or if you have requests. Major changes are - page_cgroup.h is added. - lookup_page_cgroup(struct page*), lock_page_cgroup() etc.. is exported. - All page_cgroup are allocated at boot. - you can use ...

UIO drivers certainly aren't first class citizens like kernel mode UIO is an interface type, not a bus type. UIO isn't a subsystem as such, it's a user interface. If the interface is consistent (even if the backing device is different) I don't see the problem with consistent naming. Anyway, I don't really see the point arguing here - the interface is what it is, it does everything it needs to to allow you to identify the device nodes. The kernel boys have spent a lot of effort over ...

This thread is still going? Amazing. Anyways, your protocol driver argument doesn't make any sense. Take the case of uio_pdrv or the genirq variant. This is the name it hands off to the core, while the devices that register underneath it all have their own names set. Go grep for all instances of uio_pdrv platform data in the architecture code. I'm getting the impression you haven't actually even bothered to look at the name entries. Breaking the uio%d stuff is unacceptable, and if you need ...

So IMO there is some major badness here in the form of copying all of those functions out of fs/namei.c. I think we need to discuss case-by-case whether using the functions is appropriate (and hence they should be made non-static in fs/namei.c), or whether the intended likewise... (except in the case of fifo/sock, devcgroup should not be consulted as I'm not sure it'll handle that properly - have you tested -serge --

Hi, I just found a method how I can enable WOL again: echo enabled > /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/power/wakeup This device is the NIC device, of cause. I already had another case (EHCI) where I needed to do this to be able to wake the computer up with the USB keyboard. It seems like 2.6.27 behaves different here compared to 2.6.26, and things that worked with 2.6.26 need manual fixing to work again. Or did I make something wrong? Regards, Tino --

I actually do use a lockless algorithm in LTTng and don't have to disable interrupts around tracing. This is how I get the kind of performance the Google folks expect. I would recommend to stay with interrupt disable + per-cpu spinlock (slow and heavy locking) for v1, but to keep in mind that we might want to go for a more lightweight LTTng does it, no disaster happened in the past 2-3 years. :) I guess we could manage to deal with NMI tracing specfically using the NMI tracing is a ...

Slight correction. You can annotate the function with "notrace" and that function will not be traced. So the "only be disabled on a per-file Currently my code calls "ring_buffer_time_stamp" to get the time stamp, whatever it will be. Currently it is using sched_clock, but since I have it as a wrapper, it shouldn't be too hard to modify later. I'll also add a "ring_buffer_time_stamp_normalize(ts)" function to be called on reading of the trace. This will normalize whatever time stamp ...

hm, i'd really hope hw makers see the light and actually make the hw do it all. Signs are that they are cozying up to these ideas. Good and fast timestamps are important, and it is _infinitely_ more easy to do it in hw than in sw. Firstly they need a low-frequency (10khz-100khz) shared clock line across all CPUs. A single line - and since it's low frequency it could be overlaid on some existing data line and filtered out. That works across NUMA nodes as well and physics allows it to ...

i do not understand this argument of yours. (really) 1) is your point that we might lock up? 2) or perhaps that the timestamps update only once every jiffy, and are in essence useless because they show the same value again and again? the latter is true, and that's why we were pushed hard in the past by tracer users towards using GTOD timestamps. Everyone's favorite suggestion was: "why dont you use gettimeofday internally in the tracer???". We resisted that because GTOD ...

here is the observations from my second blind attempt - this time to show that we can trace even lockdep internals just fine. I applied the patch attached below: it removes all the -pg removals from kernel/Makefile and restores the notrace markings in kernel/lockdep.c that commit 1d09daa5 ("ftrace: use Makefile to remove tracing from lockdep") removed. then i enabled the whole lockdep machinery (to insert as much extra code as possible): CONFIG_DEBUG_SPINLOCK=y ...

Hi Ingo, I completely agree with both Linus and you that accuracy utterly matters. I currently provide a time source meant to meant the tracing requirements and support architectures lacking synchronized TSC (or tsc at all) in my lttng tree. Feel free to have a look. I've had statisfied users relying on these time sources for about 3 years. See the lttng-timestamp-* commits in git://git.kernel.org/pub/scm/linux/kernel/git/compudj/linux-2.6-lttng.git The one in question here (x86) is ...

Can this possibly be true? I mean, light travels only one foot every nanosecond. Can it really keep nanosecond accuracy up to dozens of meters away? If you send the same signal to CPU1 that is 1 foot away, as well as send it to CPU2 that is 2 feet away. CPU2 will get that signal at least 1 nanosec after CPU1 receives it. Of course if the hardware is smart enough to know this topology, then it could account for these delays in traffic. -- Steve --

Steve got the _worst-case_ cpu_clock() difference down to 60 usecs not so long ago. It might have regressed since then, it's really hard to do it without cross-CPU synchronization. ( But it's not impossible, as Steve has proven it, because physical time goes on linearly on each CPU so we have a chance to do it: by accurately correlating the GTOD timestamps we get at to-idle/from-idle times to the TSC. ) And note that i'm not only talking about cross-CPU synchronization, i'm also ...

firstly, for the sake of full disclosure, the very first versions of the latency tracer (which, through hundreds of revisions, morphed into ftrace), used raw TSC timestamps. I stuck to that simple design for a _long_ time because i shared your exact views about robustness and simplicity. But it was pure utter nightmare to get the timings right after the fact, and i got a _lot_ of complaints about the quality of timings, and i could never _trust_ the timings myself for certain types of ...

Pretty much all CPUs word align on a 8 byte bounder (until we get those 128bit boxes running), but not all can word align on 4 bytes. I was hoping to make the buffer output somewhat the same across archs. Otherwise, this is going to be quite a complex mess IMHO. -- Steve --

Yep, even on those ;-) -- Steve --

Umm. cpu_clock() isn't even cross-cpu synchronized, and has actually thrown away all the information that can make it so, afaik. At least the comments say "never more than 2 jiffies difference"). You do realize that if you want to order events across CPU's, we're not talking about "jiffies" here, we're talking about 50-100 CPU _cycles_. You also ignore the early trace issues, and have apparently not used it for FTRACE. You also ignore the fact that without TSC, it goes into the same ...

Hmm, sched_clock gives ns accuracy unless the tsc is disabled. And in that case, we don't have any CPU clock :-/ -- Steve --

The log entries should be reserved with interrupts disabled anyway, and they are per-CPU, so there are no atomicity issues. For NMI's, things get more exciting. I'd really prefer NMI's to go to a separate ring buffer entirely, because otherwise consistency gets really hard. Using lockless algorithms for a variable-sized pool of pages is a disaster waiting to happen. I don't think we can currently necessarily reasonably trace NMI's, but it's something to keep in mind as required ...

No, no. The timestamp code is all in the ring buffer code. That was why I refused to have the layering without it. And hell no, nobody should *ever* read the "tsc_delta" fields etc. Those are entirely internal to the buffering. If any user _ever_ reads or writes those on its own, it's a bug, plain and simple. So when you read trace events, you should get the event data and the timestamp from the trace buffer routines. Nobody should ever even _see_ the internal trace buffer ...

Even on architectures with non-synchronized TSCs ? -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --

There is part of the type stuff that belongs in the lower layer, it seems - the padding events for the up-to-end-of-page buffering, and the timestamp extensions. It seems wrong to split those across two layers. But perhaps we can keep a couple of bits for this, and three of the bits to represent the length of the data payload (maybe in 4 byte multiples rather than bytes?) That'd let up to 28 bytes as a payload in a short event. --

Even in my last version I added a "TIME_STAMP" type that can be used in the future to add some kind of synchronization into the trace, that reads GTOD or whatnot. But as you can see, I've been trying to implement these various ideas, since the devil is in the details and the code is the details. How do you get this GTOD read in the ring buffer? If the ring buffer does it without any knowledge from the tracer, it may be doing it a inappropriate times. This would also imply that the GTOD ...

We do no such thing. Guys, the heartbeat is a _separate_ thing from overflow handling. You don't handle overflow by having a heartbeat that beats fifty times a second just to insert events, just so that the TSC delta would always fit in 27 bits. That would work, but be stupid. It would mean that you fill up your event buffer with uninteresting crud just because nothing happens. Yes, many people want to have a heartbeat (a "Mark" event) every once in a while, but what I suggest is ...

The above I added because they just made the function tracer output quite ugly and bloated. The lockdep got messing when it was debugging the locks used in the tracer that was tracing lockdep. The above had nothing to do with what kind of clock we used. We added recursion protection, but it was still producing ugly output. --

note, CONFIG_LOCKSTAT - which hooks deep inside lockdep, uses cpu_clock() too for timings, for similar reasons. Lockdep and lockstat both have a very robust design and a very good track record to prove it. you'd be correct in pointing out that we _do_ have a relatively high regression count in cpu_clock()/sched_clock(), but the reason for that is that its implementation balances on the narrow edge of doability. It implements a very unstable set of requirements: "absolutely fast" pitted ...

I've been just using sched_clock() which already normalizes to ns. But I use a wrapper (ring_buffer_time_stamp) so we can decide on how to keep track later. If we do not normalize, then we must come up yet another generic way to read the CPU clock for all archs. And then we also need to come up with another generic way to normalize it later for output. If I'm missing that this already exists, then I'll go and use it, but I do not think that tracing is worthy enough to implement this ...

Simple solution: turn off cpufreq whilst tracing is on ;-) Harder: Keep a timebase and frequency divisor on a per-cpu basis and calculate your offsets from there. This brings you down to HPET resolution though --

That suggests that frequency changes should be recorded at a lower layer as well, along with full timestamps and deltas, so that a log parser can correctly generate the timestamps without having to parse higher-level trace records. Maybe the simplest thing to do is make the full timestamp records also include frequency and offset information (to deal with discontinuities caused by things like a vcpu switching between physical cpus with unsynced tscs). J --

Really, we traced all these files for ages. I can restore it if it's worthwile - but lockdep totally kills the usability of function traces, it inserts thousands of uninteresting events over and over again. Note commit c349e0a0, there i added -no-pg for robustness reasons (we locked up) - back then the scheduler clock was within sched.c. Now it is all separated out cleanly in kernel/sched_clock.o and i think we can add yes, that's true. And that's why we absolutely want to have ...

Oh, and I didn't notice (because Steven pointed out "notrace" and I didn't see any of them), that in order to get things to work you had just added CFLAGS_REMOVE_lockdep.o = -pg CFLAGS_REMOVE_lockdep_proc.o = -pg CFLAGS_REMOVE_mutex-debug.o = -pg CFLAGS_REMOVE_rtmutex-debug.o = -pg CFLAGS_REMOVE_cgroup-debug.o = -pg CFLAGS_REMOVE_sched_clock.o = -pg CFLAGS_REMOVE_sched.o = -mno-spe -pg all ovr the place, which was part of my argument against this crap in the first place. Yes, by ...

yes, that's natural. Anything that isnt super-important to backmerge should go into a separate patch. Ingo --

That surprises me - I thought a reasonable amount of code was cut as Fedora 9 and ubuntu intrepid already have full capabilities support and modern libcap. Sles is set to ship with a modern libcap, and according to what Andreas is saying, if we can provide them with the no_file_caps boot option then suse is willing to have a kernel with capabilities turned on. I think gentoo still comes with libcap-1. Need to look into changing that. I suppose the next baby-step will be to do get rid ...

I think you have enough pieces in place to get that "something better" _very_ quickly. Or I'd feel worse about abusing those poor little grey cells. ;) --

Just this fix Jeff --

Ack. Sorry about that. Wrong tree. Here's the right one. ;-) Signed-off-by: Drew Moseley <dmoseley@mvista.com> diff --git a/drivers/pnp/base.h b/drivers/pnp/base.h index 9fd7bb9..3532984 100644 --- a/drivers/pnp/base.h +++ b/drivers/pnp/base.h @@ -4,6 +4,7 @@ */ extern spinlock_t pnp_lock; +extern struct device_attribute pnp_interface_attrs[]; void *pnp_alloc(long size); int pnp_register_protocol(struct pnp_protocol *protocol); @@ -16,7 +17,6 @@ struct pnp_card ...

looks good to me. and, I tested this patch on x86_64 mmotm 0923 and it works well. Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --

This is totally broken, I gather you are thinking the bug is fixed since the counts always match up. Well that's mainly because you know don't do Hmm? I think you should try and describe the problem you are seeing instead, then we can perhaps find the real issue. -- Jens Axboe --

Hey Paul, curious, why do they not look like the same list? -serge --

Because one of them is named &tpm_chip_list, a global variable, and the other seemed to be returned from a function taking a struct device as an argument. This is indeed consistent with an element in this list being hung off of the struct device, so perhaps I was just being insufficiently persistent in tracking things down. Thanx, Paul --

And so chip->data_buffer (and data_pending) may *only* be accessed by the owner of the chip, who has set chip->is_open? Could you comment that in tpm.h for future reference? I've been trying to push for better commenting of precisely how the locking is expected to work, but I think that was misunderstood as asking for email --

That might be the cleanest logical way to do it actually. But for the moment I'm happy not to pull tmpfs apart :) Even if it seems like the wrong way around, at least it is insulated to within mm/ --

It seems like once you've done that you might consider extracting the page allocator from shmem so that drm, tmpfs and sysv IPC would share the same underlying memory manager API. --=20 keith.packard@intel.com

OK, that's all that can be asked I guess. Low level object / memory OK. I will have to add some facilities to allow mmaps that go back through to tmpfs and be swappable... Thanks for the data point. --

Actually, I think the pages must be allowed to be freed, and that we don't put a requirement on "pageable" to keep swap-space slots for these pages. If we hit an OOM-condition during suspend-to-memory that's bad, but let's say we required "pageable" to keep swap space slots for us, the result would perhaps be that another device wasn't able to suspend, or a user-space program was killed due to lack of swap-space prior to suspend. I'm not really sure what's the worst situation, but my ...

Pity. Anyway, I accept that, let's move on. I guess so. A big problem of ioctls is just that they had been easier to add so they got less thought and review ;) If your ioctls are stable, Well, no not a seperate filesystem to do the pageable backing store, but a filesystem to do your object management. If there was a need for pageable You can map them to userspace if you just take a page at a time and insert them into the page tables at fault time (or mmap time if you ...

Note that this can occur as a result of a suspend-to-memory transition at which point *all* of the objects in VRAM will need to be preserved in main memory, and so the pages aren't really 'freed', they just don't need to have valid contents, but the system should be aware that the space may be needed at some point in the future. --=20 keith.packard@intel.com

This actually is a regression for which I'm sorry. Can you please check if the appended patch restores the previous behavior? Thanks, Rafael --- From: Rafael J. Wysocki <rjw@sisk.pl> ACPI: Make /proc/acpi/wakeup interface handle PCI devices Make the ACPI /proc/acpi/wakeup interface set the appropriate wake-up bits of physical devices corresponding to the ACPI devices and make those bits be set initially for devices that are enabled to wake up by default. This is needed to restore ...

I would entirely agree with this but we have the "N:1" case that I described. (multiple vectors which by design should target one CPU.) That sounds remarkable close saying the sysadmin has to know about each devices attributes. If interpreted that way, I'll argue that's not realistic in 99% of the cases and certainly not how sysadmins Yes, good point. That's certainly a better approach and could precede the "second proposal" above. ie driver queries how many domains it should "plan" for, ...

On Wed, 24 Sep 2008 16:35:27 +0200 I'd say always. I'd never dare overclock something that's powered, even if we're not currently communicating with it. Remember to deal with the case of a powered but unclocked card. This will primarily happen during card init, but it could should up later as Agreed. --=20 -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is ...

Here's that part in case it's helpful :) Feel free to roll it into your patch. -Eric Make xfs_fs_log_dummy() return errors which can then be returned by xfs_fs_lockfs(), once it is capable of doing so. Signed-off-by: Eric Sandeen <sandeen@sandeen.net> --- Index: linux-2.6/fs/xfs/xfs_fsops.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_fsops.c 2008-08-04 15:30:31.000000000 -0500 +++ linux-2.6/fs/xfs/xfs_fsops.c 2008-09-25 ...

Hi, Takashi I use git to generate patches. (I run git-fetch origin, git-fetch-rebase origin, and git-format-patch origin) There are two patch, one for the addition of HDMI, and one for the fix for our aza controller. Please check it. Thanks -----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de]=20 Sent: Monday, September 22, 2008 5:58 PM To: Wei Ni Cc: peerchen; Pavel Hofman; Peer Chen; alsa-devel; linux-kernel; akpm Subject: Re: [alsa-devel] [PATCH] add the nvidia HDMI ...

OK. I'll review and test your latest patch without MMUPageSize part. (maybe today's midnight or tommorow) Thanks! --

Yes, I think that xorg/xorg i915 driver/libdrm/GEM/whatever are the biggest suspect currently, according to the data that has been gathered so far. Still, what confuses me a little bit -- the EEPROM of the card is set to all 0xff, once the corruption happens. Isn't that a quite a coincidence, that bytes representing "nothing" in this context are used? If being set to 0 (it's so easy to call memset(0) on a bogus pointer, there are usually lots of them in the code) or to random garbage, ...

Well the non-GEM paths are really the old codepaths we used in the older drivers.. So unless we do something really dumb... I'd target three areas PAT, pciaccess and e1000e itself. Dave. --

But the xorg intel driver shipped with xorg 7.4 already has support for GEM, right? So there could still be some bug in the GEM-aware driver Yes, booting with 'nopat' is on my list to try immediately after we are This we could catch easily even with strace, right? -- Jiri Kosina SUSE Labs --

I should be able to test the mmap fix independently of the e1000 breakage at least... lemme try it out now... -- Jesse Barnes, Intel Open Source Technology Center --

Okay, I just had a scary and hopefully stupid thought. Especially Intel often has backchannels between the chipset and the Ethernet controller for management functions -- anything from WoL to IPMI -- generally over some kind of low-speed serial bus. We're not in a situation where the EEPROM can be touched from the chipset via the SMBus or some other non-CPU channel? -hpa --

I guess it's more about the E1000's serial configuration EEPROM, the registers seem to live in BAR0 (EECD and for reading perhaps EERD). Corrupted EEPROM (and thus PCI config registers) can easily result in a dead machine. I will be writing a tool for writing 82541PI EEPROMs on a custom board soon (unless there is one available, for Linux, of course), I'm not sure it's the flash that is corrupted. Anyway booting the laptop should be quite easy (physically disabling the EEPROM on ...

On Fri, Sep 26, 2008 at 7:42 AM, Jesse Brandeburg It rules out PAT I suppose, they have seen the issue as well. Dave. --

Yup on my laptop these were far away and I wondered what could mangle things that badly. Well I'm out of the race, my attempts to re-write my eeprom using an eeprom from an equivalent laptop have totally failed and my BIOS won't boot anymore - so my laptop is == a brick. Dave. --

That was exactly the point I was trying to make, that these error paths will probably also need auditing, once we rule out the possibility of NVRAM being overwritten from kernelspace. Thanks, -- Jiri Kosina SUSE Labs --

Actually there is no way of not shipping GEM when shipping xorg 7.4, isn't it? So definitely GEM could be potential cause here, I think. -- Jiri Kosina SUSE Labs --

We have confirmation that this isn't GEM related; according to the Novell bug at https://bugzilla.novell.com/show_bug.cgi?id=425480 people have hit the problem with kernels w/o GEM. That doesn't rule out i915 (though I don't think any changes have gone in since 2.6.26 that would have caused this) or xf86-video-intel. It's possible that X is getting confused about BAR mappings somehow, resulting in a clobbered e1000e NVRAM, but why would the kernel version matter in that case? The only ...

Good. We will use this on affected machines after we start some real At least for debugging purposes I'd propose to put a printk() there with process name, and the range it tries to map. Thanks, -- Jiri Kosina SUSE Labs --

That seems a bit drastic, particularly when the debugging was beginning to point to another culprit. We have equal case at this point to disable r8169 and i915_drm, no? Jeff --

Something else to worry about is bisections. People seeing an unrelated issue with .27 after release may well be asked to do a bisection and could then run into the issue even if it is fixed before the release. Guess we'll need to wait and see what the root cause is to know if that's Extra datapoint. As far as I've seen this problem has not yet been reported by any people running Debian. This could point to X.Org as Debian currently has 7.3 while I think the reports so far have been ...

Perhaps the entire chip has been erased with the "ERAL" (erase all) command. Requires previously issued EWEN (erase/write enable). Each command seems to require several writes to the EEPROM control register. -- Krzysztof Halasa --

The problem here is that what we desperately need first is a method to restore the original EEPROM contents after it gets corrupted (David Airlie has, sadly, apparently bricked his notebook while trying to do so). Without this, we can put a lot of debugging/protecting patches into the kernel, but we won't be able to succesfully verify anything, because testing wouldn't be possible. Added Jesse and Karsten to CC, as they are working on such a tool right now, as far as I know. -- ...

You got this working ... congrats! :) Small suggestion: next time you resend this, make sure that $SUBJECT mentions it's a UART driver. Maybe even that it's a SPI UART driver. That should help get more comments. This is a bit picky, but it's the first thing I noticed when scanning the patch ... wierd comment layout! Either indent those all, or (better) convert to kerneldoc style. Potentially less picky: probe() doesn't lock max3100s[], neither does remove(), and in fact there ...

Map the first sub-buffer at the end of the buffer, for temporary convenience. Make relay buffers 'circular' for writing by mapping the first subbuf at end of last subbuf. This is so we can do writes across last subbuf boundary without adding special write logic. This is a temporary state of affairs and it all goes away in a future patch, but it's here now so things will still work. --- kernel/relay.c | 26 +++++++++++++++----------- 1 files changed, 15 insertions(+), 11 ...

relay should probably have had a flags param from the beginning; it wasn't originally added because it wasn't originally needed - it probably would have helped avoid some of the callback contortions that were added due to a lack of flags. This adds them and does a small amount of low-hanging cleanup, and is also in preparation for some new flags in future patches. --- block/blktrace.c | 5 ++--- include/linux/relay.h | 19 ++++++++++--------- kernel/relay.c | 20 ...

Clean up remaining padding-related junk. Removes the rest of the padding-related junk. Also simplifies the subbuf_start callback a bit. --- block/blktrace.c | 5 +++-- include/linux/relay.h | 12 ++---------- kernel/relay.c | 19 ++++--------------- virt/kvm/kvm_trace.c | 7 ++++--- 4 files changed, 13 insertions(+), 30 deletions(-) diff --git a/block/blktrace.c b/block/blktrace.c index 150c5f7..271b7b7 100644 --- a/block/blktrace.c +++ b/block/blktrace.c @@ ...

Remove padding-related code from relay_read()/relay_splice_read() et al. Because we no longer write padding, we no longer have to read it or account for it anywhere else, greatly simplifying the related code. --- kernel/relay.c | 149 ++++++++------------------------------------------------ 1 files changed, 20 insertions(+), 129 deletions(-) diff --git a/kernel/relay.c b/kernel/relay.c index 15e4de2..21b3e19 100644 --- a/kernel/relay.c +++ b/kernel/relay.c @@ -966,72 +966,13 @@ static ...

Clean up relay_switch_subbuf() and make waking up consumers optional. Over time, relay_switch_subbuf() has accumulated some cruft - this patch cleans it up and at the same time makes available some of it available as common functions that any subbuf-switch implementor would need (this is partially in preparation for the next patch, which makes the subbuf-switch function completely replaceable). It also removes the hard-coded reader wakeup and moves it into a replaceable callback called ...

I think we need to be a bit clearer about the terminology: A batch is a bunch of things that can be optionally deferred so they can be done in chunks. A transaction is something that must either complete successfully, or have no effect at all. Doing multiple things in a transaction means that they must all complete or none. (In general we assume there's nothing about these low-level pagetable operations which can fail, so we can ignore the failure part of transactions.) In this case, a ...

I still can't see the point of having now 3 functions instead of just one such as ptep_modify_protection(). I don't see what it buys you other than adding gratuituous new interfaces. Ben;. --

Perhaps this helps: Context switches between guest<->hypervisor are relatively expensive. The more work we can make each context switch perform the better, because we can amortize the cost. Rather than synchronously switching between the two every time one wants to express a state change to the other, we batch those changes up and only sync when its important. While there are batched outstanding changes in one, the other will have a somewhat out of date view of the state. At this level, ...

This patch (as1141) adds code to use the device type's pm_op methods, if they are defined. It fixes a regression in the USB PM code; the various suspend and resume methods are defined in the device type rather than in the bus, because USB devices have to be handled differently from USB interfaces. Without the patch, those methods never get called. The patch also fixes a couple of spelling errors. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jiri Slaby ...

Hm, these changes are not needed in the current mainline, so there's a patch in -next that removes the code added by this patch. --

On the bright side, that means more people should have the hardware to test it on (including me :-). I've certainly used the camera enable/disable at some point. But I could have missed the error message, and frankly I don't use the camera or cardreader very often. I'll have a bash at it tomorrow. Sitsofe says it reproduced on kernel.org 2.6.21 (presumably with an out-of-tree eeepc module). So I guess this isn't a simple git-bisect job - more thinking required... Thanks Alan --

We probably need to make a special xics flow handler for -rt that does what Milton suggested, ie, bring down the CPU priority right away and only EOI later or something like that, instead of masking/unmasking. I don't know what are the other potential issues with the HEA though. Ben. --

Do you mean creating a custom fasteoi handler into xics.c? Also, it's not clear to me from looking at the code how you go about changing the Don't know either, but that I can test. Thanks, Sebastien. --

Yep, except as it behaves in way that the current -rt fasteoi flow That's what I gathered from looking at the sources. Thanks, Sebastien. --

So do I, it was just to make sure I was not hit by another interrupt while handling the previous one and thus reduce the number of hypothesis. I sure do not say that it cannot happen, just that that path is not taken Whoops, my bad, in the non threaded case, there's no mask at all, only an Looks like it is, but I cannot say for sure, the only observable effect That may be, but I'm only looking at the code (read no specifications at hand) Now, that is quite interesting ...

Actually, this "pm+1" breaks the case where migrate_pages() calls unmap_and_move() multiple times on the same page. In this case, we need the while loop to look at pm instead of pm+1 first. So we can't cache pm+1 in private, but caching pm is ok. There will be 1 while loop instead of 0 in the regular case. Updated patch (with more comments) coming soon. Brice --

I agree with Christoph here, I think that the timeout is unneeded. Regards, Ric --

When 2.4 was the cutting edge kernel. I don't remember the dates or versions exactly. David --

> Aren't parport still probing it's own port if pnp failed ? Could be; I haven't looked. I just assumed parport didn't do the legacy probe because Martin reported that the port didn't work when PNPACPI was enabled. And I retract my "parport.nopnp" idea. A positive statement like "parport.legacy" or something along the lines of "look here" would be better. It's safe to use PNP to probe; it just won't find anything. All we want is something to tell parport to do the legacy probe ...

Tejun, sorry for misspelling your name as Tijo :-/ Do I hit your spamfilter with my KSYMOOPS enabled debug outputs or some sort of that? If not, sorry for the inconvenience and take your time. Regards, Konsti -- GPG KeyID EF62FCEF Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF --

applied --

since most of the important cpumasks in high-perf codepaths are already pre-constructed and embedded in some existing object (say task_struct), i think a variant of #3 is the best approach: - get rid of cpumask_t and use 'struct cpumask' everywhere. - do not expose normal kernel code to struct cpumask's definition, only declare the type via 'struct cpumask;' in sched.h - a'la kmem_cache_t. - even hide the structure from sched.h - use an extra indirection for struct ...

No. That's already broken. You cannot return a cpumask_t, regardless of interface. We must not do it regardless of how we pass those things around, since it generates _yet_ another temporary on the stack for the return slot for any kind of structure. So all cpumask functions should always return pointers and/or take pointers to be filled in. That's true *regardless* of how we actually are to then allocate them. So forget returning cpumasks. It's irrelevant. What _is_ relevant is ...

Good point -- I guess I do need to implement the CLASSIC_RCU piece of this in any case. Thanx, Paul --

Sad to say, they do affect mainline -- I can reproduce these problems in 2.6.27-rc7. Thomas has given me a couple of fixes that got rid of earlier problems in which jiffies would stop counting, and I believe has located the cause of at least one other problem. Thanx, Paul --

Mike, also notice this: it's always during driver init, as indicated by the (+) in the dump ('+' means that the module is in the process of being loaded, but module load has not completed): calling cciss_init+0x0/0x2e [cciss] HP CISS Driver (v 3.6.20) ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 54 cciss 0000:42:08.0: PCI INT A -> Link[LNKA] -> GSI 54 (level, high) -> IRQ 54 cciss0: <0x3238> at PCI 0000:42:08.0 IRQ 503 using DAC BUG: unable to handle kernel NULL pointer dereference at ...

We should rework/remove this (maybe later), if it makes no longer sense to keep it. If we had have a force_cpu_type implementation this could be thrown away. But as long as it is in it's better to have it documented. -- Advanced Micro Devices, Inc. Operating System Research Center email: robert.richter@amd.com --

Could you create a separate patch that introduces this new kernel parameter? This would make it easier to send all other changes upstream. We already discussed the need of this parameter. Maybe it would fit better to have a more generalized paramater for this that could be reused then by other archs/models as well. Something like force_pmu_detection that could be used for all new CPUs (also other models) that do not yet have a specific kernel implementation. Even better would a sysfs entry ...

Sorry for the late answer. 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 --

Hi Jan, thanks for the info. I didn't find this gem until today when I am cleaning up my emails... Cheers, Fei --

Hi Greg, For me this is used in the next patch (for mtrr/main.c) to suppress an unnecessary warning when running as a VMware guest: http://lkml.org/lkml/2008/9/24/144 We already have code to suppress warning under KVM so the above patch suppress warnings for VMware guest also. H. Peter Anvin and Alok kataria are also proposing we may need a more general approach for detecting hypervisors that can be used for some other quirks. Thanks. -- Li, Yan --

I think if Virtual PC has similar problems we should add codes to detect Virtual PC to be used by mtrr/main.c. A general interface might not be good for this specific problem (false MTRR blank warning) since we have no way to know all VMs has MTRR set to blank thus handling KVM, VMware and Virtual PC here should be enough for now. If you can tell me what manufacture vendor string is in Virtual PC I can make another similar patch using dmi_name_in_vendors(). So at first I'd like to see the ...

Oh, cool, thanks! -- Li, Yan --

Hmm...what can a IN on an unknown port cause on native hardware, if a port is not being used it would return 0xFFFFFFFF in eax, and if you have a real device there (a sane one), what can IN result in apart from reading some IO register/counter value in eax ? If there is anything apart from the above 2 outcomes, please let me know exactly what you mean. Thanks, Alok --

Don't give al-quieda any ideas. --

You accessed a bloody I/O port! If you think it's harmless because it was an IN, you're sorely mistaken. -hpa --

Why do we need to do this within the kernel, what is that going to achieve? People can do this easily in userspace if they need to detect this, I think there's a patch for util-linux-ng adding such a simple utility that handles almost all of the known virtualization engines right now. thanks, greg k-h --

This, of course, is what CPUID is for. -hpa --

Sorry for joining the discussion this late. But i only noticed this after somebody pointed me to it. Even if there is anything on that port on native hardware it would work perfectly well and is _safe_. First let me post the code to access this backdoor port (the way it should really be done ) ------------------------------------------------------------------------------- #define VMWARE_BDOOR_MAGIC 0x564D5868 #define VMWARE_BDOOR_PORT 0x5658 #define VMWARE_BDOOR_CMD_GETVERSION ...

It's not a false warning. It's a true warning. -hpa --

First, you are assuming all devices are "sane". This is obviously wrong -- you're poking in hyperspace, and you don't know if you're going to hit someone's ancient controller card that perhaps drives a medical accelerator for all you know. Second, you are assuming that devices you call "sane" don't have I/O ports with read side effects. Many, if not most, devices have some I/O ports with read side effects, especially read-clear semantics and/or queue drain operations. Third, in the ...

You accessed an unknown I/O port. This means you caused an unknown action in an unknown peripheral device. This could cause ANYTHING to happen. -hpa --

Ah, I was hoping they were all doing this, as it seems the most "sane" manner. Good luck :) greg k-h --

We pretty much have to, just as we have to work around bugs in, say, AMD's microcode. We have avoided it so far, but it's gotten to a breaking point, and rather than having ad hoc hacks scattered all over the place I want a centralized test site setting a single global variable. Unfortunately, hypervisor vendors haven't adopted a uniform detection scheme (CPUID level 0x40000000 is sometimes mentioned as a pseudo-standard, but it's not universal, and not all virtualization solutions ...

You can say that warning is justified because it's true that the MTRR's are all blank in VMware. But that warning is no good to VMware users since it's by-design all MTRR's are blank. For example, we've scripts watching the log for lines containing "warning" and "error" on all production servers. So this warning actually is "false" to VMware guest users. A KERN_INFO message should be enough here. We already have a checking to suppress warning on KVM so I think we should also suppress the ...

Hi Peter, It would be really helpful if you could explain me when can this go wrong or what kinds of problems can this cause on native hardware. Thanks, --