On Thu, 28 Dec 2006, David Schwartz wrote:
Patents don't provide any ability to keep things secret. Copyright doesn't
apply to a creative work you made yourself, even if it describes the creative
work of another in *functional* detail.
in fact, to get a Patent you are required to explain the
I think these helpers just obfuscate the code, just call
input_report_*() and input_sync() drectly like you used to do.
Fair enough, I had a similar thought. Imre, could you do that update?
Yes, the patch is against the OMAP tree.
Thanks ... still hoping that the OMAP tree will
From: Linus Torvalds [EMAIL PROTECTED]
Date: Thu, 28 Dec 2006 12:14:31 -0800 (PST)
I get corruption - but the whole point is that it's very much pdflush that
should be writing these pages out.
I think what might be happening is that pdflush writes them out fine,
however we don't trap writes
Ok,
with the ugly trace capture patch, I've actually captured this corruption
in action, I think.
I did a full trace of all pages involved in one run, and picked one
corruption at random:
Chunk 14465 corrupted (0-75) (01423fb4-01423fff)
Expected 129, got 0
Written as
On 12/28/06, Arnd Bergmann [EMAIL PROTECTED] wrote:
On Thursday 28 December 2006 03:16, Jon Smirl wrote:
BUG: scheduling while atomic: hald-addon-stor/0x2000/5078
[c02b0289] __sched_text_start+0x5f9/0xb00
[c024a623] net_rx_action+0xb3/0x180
[c01210f2] __do_softirq+0x72/0xe0
[c0105205]
On 12/28/06, Arnd Bergmann [EMAIL PROTECTED] wrote:
On Thursday 28 December 2006 03:16, Jon Smirl wrote:
BUG: scheduling while atomic: hald-addon-stor/0x2000/5078
[c02b0289] __sched_text_start+0x5f9/0xb00
[c024a623] net_rx_action+0xb3/0x180
[c01210f2] __do_softirq+0x72/0xe0
[c0105205]
From: Linus Torvalds [EMAIL PROTECTED]
Date: Thu, 28 Dec 2006 14:37:37 -0800 (PST)
So if we're not losing any dirty bits, what's going on?
What happens when we writeback, to the PTEs?
page_mkclean_file() iterates the VMAs and when it finds a shared
one it goes:
entry =
On Thu, Dec 28, 2006 at 11:39:09PM +0100, Adrian Bunk wrote:
Subject: PCI_MULTITHREAD_PROBE breakage
References : http://lkml.org/lkml/2006/12/12/21
Submitter : Ben Castricum [EMAIL PROTECTED]
Caused-By : Greg Kroah-Hartman [EMAIL PROTECTED]
commit
On Thu, 28 Dec 2006, David Miller wrote:
What happens when we writeback, to the PTEs?
Not a damn thing.
We clear the PTE's _before_ we even start the write. The writeback does
nothing to them. If the user dirties the page while writeback is in
progress, we'll take the page fault and
On Thu, Dec 28, 2006 at 02:57:06PM -0800, Greg KH wrote:
On Thu, Dec 28, 2006 at 11:39:09PM +0100, Adrian Bunk wrote:
Subject: PCI_MULTITHREAD_PROBE breakage
References : http://lkml.org/lkml/2006/12/12/21
Submitter : Ben Castricum [EMAIL PROTECTED]
Caused-By : Greg Kroah-Hartman
On Tue, Dec 19, 2006 at 06:53:22PM +0100, Roman Zippel wrote:
Hi,
On Mon, 18 Dec 2006, Adrian Bunk wrote:
On Mon, Dec 18, 2006 at 11:41:59AM -0500, Robert P. J. Day wrote:
Remove the note in the documentation that suggests people can use
requires for dependencies in Kconfig
Compatibility and stabilization fixes, many centered around msrs, but a
few other corner cases as well.
--
error compiling committee.c: too many arguments to function
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
current_cpu_data invokes smp_processor_id(), which is inadvisable when
preemption is enabled. Switch to boot_cpu_data instead.
Resolves sourceforge bug 1621401.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
Index: linux-2.6/drivers/kvm/svm.c
Instead of doing tricky stuff with the arch dependent virtualization registers,
take a peek at the guest's efer.
This simlifies some code, and fixes some confusion in the mmu branch.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
Index: linux-2.6/drivers/kvm/mmu.c
Resolves sourceforge bug 169 (guest crashes running benchmark software).
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
Index: linux-2.6/drivers/kvm/svm.c
===
--- linux-2.6.orig/drivers/kvm/svm.c
+++ linux-2.6/drivers/kvm/svm.c
@@
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
Index: linux-2.6/drivers/kvm/kvm_main.c
===
--- linux-2.6.orig/drivers/kvm/kvm_main.c
+++ linux-2.6/drivers/kvm/kvm_main.c
@@ -1103,6 +1103,47 @@ void realmode_set_cr(struct kvm_vcpu *vc
These msrs are referenced by benchmarking software when pretending to be
an Intel cpu.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
Index: linux-2.6/drivers/kvm/kvm_main.c
===
--- linux-2.6.orig/drivers/kvm/kvm_main.c
+++
From: Nguyen Anh Quynh [EMAIL PROTECTED]
No need to append _MSR to msr names, a prefix should suffice.
Signed-off-by: Nguyen Anh Quynh [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
Index: linux-2.6/drivers/kvm/vmx.c
__free_page() doesn't like a NULL argument, so check before calling it. A
NULL can only happen if memory is exhausted during allocation of a memory
slot.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
Index: linux-2.6/drivers/kvm/kvm_main.c
Subject: [patch] kvm: fix GFP_KERNEL alloc in atomic section bug
From: Ingo Molnar [EMAIL PROTECTED]
KVM does kmalloc() in an atomic section while having preemption disabled
via vcpu_load(). Fix this by moving the -*_msr setup from the
vcpu_setup method to the vcpu_create method.
(This is also
Ingo Molnar wrote:
Subject: [patch] kvm: fix GFP_KERNEL alloc in atomic section bug
From: Ingo Molnar [EMAIL PROTECTED]
KVM does kmalloc() in an atomic section while having preemption disabled
via vcpu_load(). Fix this by moving the -*_msr setup from the
vcpu_setup method to the vcpu_create
Subject: [patch] kvm: fix GFP_KERNEL allocation in atomic section in
kvm_dev_ioctl_create_vcpu()
From: Ingo Molnar [EMAIL PROTECTED]
fix a GFP_KERNEL allocation in atomic section bug:
kvm_dev_ioctl_create_vcpu() called kvm_mmu_init(), which calls
alloc_pages(), while holding the vcpu. The fix
Ingo Molnar wrote:
Subject: [patch] kvm: fix GFP_KERNEL allocation in atomic section in
kvm_dev_ioctl_create_vcpu()
From: Ingo Molnar [EMAIL PROTECTED]
fix a GFP_KERNEL allocation in atomic section bug:
kvm_dev_ioctl_create_vcpu() called kvm_mmu_init(), which calls
alloc_pages(), while
* Avi Kivity [EMAIL PROTECTED] wrote:
fix a GFP_KERNEL allocation in atomic section bug:
kvm_dev_ioctl_create_vcpu() called kvm_mmu_init(), which calls
alloc_pages(), while holding the vcpu. The fix is to set up the MMU
state earlier, it does not require a loaded CPU state.
Yes it
* Ingo Molnar [EMAIL PROTECTED] wrote:
Yes it does. It calls nonpaging_init_context() which calls
vmx_set_cr3() which promptly trashes address space of the VM that
previously ran on that vcpu (or, if there were none, logs a vmwrite
error).
ok, i missed that. Nevertheless the
Ingo Molnar wrote:
Subject: [patch] kvm: fix GFP_KERNEL allocation in atomic section in
kvm_dev_ioctl_create_vcpu()
From: Ingo Molnar [EMAIL PROTECTED]
fix an GFP_KERNEL allocation in atomic section:
kvm_dev_ioctl_create_vcpu() called kvm_mmu_init(), which calls
alloc_pages(), while holding
* Avi Kivity [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
Subject: [patch] kvm: fix GFP_KERNEL allocation in atomic section in
kvm_dev_ioctl_create_vcpu()
From: Ingo Molnar [EMAIL PROTECTED]
fix an GFP_KERNEL allocation in atomic section:
kvm_dev_ioctl_create_vcpu() called
Ingo Molnar wrote:
I've got a security related question as well: vcpu_load() sets up a
physical CPU's VM registers/state, and vcpu_put() drops that. But
vcpu_put() only does a put_cpu() call - it does not tear down any VM
state that has been loaded into the CPU. Is it guaranteed that (hostile)
On Thu, 28 Dec 2006 14:09:00 +0530
Suparna Bhattacharya [EMAIL PROTECTED] wrote:
+#define init_wait_bit_key(waitbit, word, bit)
\
+ do {\
+ (waitbit)-key.flags = word;
On Thu, 28 Dec 2006 13:53:08 +0530
Suparna Bhattacharya [EMAIL PROTECTED] wrote:
This patchset implements changes to make filesystem AIO read
and write asynchronous for the non O_DIRECT case.
I did s/lock_page_slow/lock_page_blocking/g then merged all these
into -mm, thanks.
-
To unsubscribe
This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19
with patches available
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any
This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
On Fri, 29 Dec 2006, Adrian Bunk wrote:
In Linus' tree, it currently only depends on EXPERIMENTAL.
It seems commit 009af1ff78bfc30b9a27807dd0207fc32848218a wasn't intended
for Linus?
I think we should just remove it.
It's broken.
Nobody cares.
If people want to do concurrent stuff at
Sergei Organov wrote:
Hi, Jiri!
Hi.
I'm so sorry, I don't know what I smoked yesterday, but the latest
version you've sent me does not have this problem anymore! I think I
YES!
copied compiled module to modules directory for different kernel and
thus tested old code all the time. BTW,
On Thu, Dec 28, 2006 at 03:17:53PM -0800, Linus Torvalds wrote:
On Fri, 29 Dec 2006, Adrian Bunk wrote:
In Linus' tree, it currently only depends on EXPERIMENTAL.
It seems commit 009af1ff78bfc30b9a27807dd0207fc32848218a wasn't intended
for Linus?
I think we should just remove
Could someone please test this?
From: Andrew Morton [EMAIL PROTECTED]
Various people have reported machines failing to boot since pci_bus_sem was
switched from a spinlock to an rwsem.
The reason for this is that these people had ide= on the kernel commandline,
and ide_setup() can end up
On Dec 28 2006 19:53, Arjan van de Ven wrote:
On Thu, 2006-12-28 at 19:41 +0100, Daniel Marjamäki wrote:
Hello all!
I sent a patch with this content:
- for (i = 0; i MAX_PIRQS; i++)
- pirq_entries[i] = -1;
+ memset(pirq_entries, -1, sizeof(pirq_entries));
On Thu, 28 Dec 2006, Anton Altaparmakov wrote:
But are chunks 3 and 4 in separate buffer heads? Sorry could not see it
immediately from the output you showed...
No, this is a 4kB filesystem. A single bh per page.
It is just that there may be a different cause rather than buffer dirty
On Thu, 28 Dec 2006, Linus Torvalds wrote:
Ok,
with the ugly trace capture patch, I've actually captured this corruption
in action, I think.
I did a full trace of all pages involved in one run, and picked one
corruption at random:
Chunk 14465 corrupted (0-75)
501 - 539 of 539 matches
Mail list logo
