* Re: [PATCH] tcp: do not promote SPLICE_F_NONBLOCK to socket O_NONBLOCK
From: Evgeniy Polyakov @ 2008-07-19 8:51 UTC (permalink / raw)
To: Octavian Purdila; +Cc: netdev, linux-kernel, axboe
In-Reply-To: <200807182143.38624.opurdila@ixiacom.com>
Hi Octavian.
On Fri, Jul 18, 2008 at 09:43:38PM +0300, Octavian Purdila (opurdila@ixiacom.com) wrote:
> The flag gets propagated to splice_to_pipe (so there is no need to propagate
> the check in skb_splice_bits) but we don't have SPLICE_F_NONBLOCK set, we are
> on the blocking usecase.
Hmm, than how does it concerns SPLICE_F_NONBLOCK feature change? Your
patch does not touch this behaviour.
Anyway, in case of not having SPLICE_F_NONBLOCK it does not deadlock,
but waits until someone reads from the other side of the pipe. It blocks
and expects reader to unblock it.
It looks like you have two unexpected independent issues with splice:
ability to perform non-blocking reading from the socket into the pipe
when SPLICE_F_NONBLOCK is set,
and blocking waiting for reader to get data from the pipe when
SPLICE_F_NONBLOCK is not set. Is it correct?
If so, the former is a feature, which allows to have some progress when
receiving queue is empty: one can start getting data from the pipe,
i.e. splice data out of the pipe to the different file descriptor.
So, this flag means both non-blocking pipe operations _and_ non-blocking
receiving from the socket.
For the blocking in pipe_wait() when pipe is full and SPLICE_F_NONBLOCK
is not set, then it is just a pipe behaviour, which is used as a
temporal storage for the requested data. It is not some buffer, which is
returned to the userspace when it is full (or indication of it), but a
pipe, where you put page pointers, so when pipe is full and opened in
blocking mode, writer sleeps waiting or reader to get some data out of it
and thus awake writer. It is not a deadlock, but very expected behaviour
of the pipe: to block when pipe is full waiting for reader to get data.
Hope this will clarify this discussion a bit, so it would not look like
talk of blind and deaf :)
--
Evgeniy Polyakov
^ permalink raw reply
* Re: From 2.4 to 2.6 to 2.7?
From: Rene Herman @ 2008-07-19 8:52 UTC (permalink / raw)
To: Craig Milo Rogers
Cc: Jan Engelhardt, Linus Torvalds, Stoyan Gaydarov, linux-kernel,
Alan Cox, gorcunov, akpm, mingo
In-Reply-To: <20080719080002.GA11272@isi.edu>
On 19-07-08 10:00, Craig Milo Rogers wrote:
> In <487D7781.6000407@keyaccess.nl>, Rene Herman proposed [somewhat
> arbitrary] transition to 2.8 and 2.9, and specified that 3.0 should
> be until when world domination by Linux is near.
Nonono, that's all backwards! This is about having a 3.0 release BRING
ABOUT world domination!
</tongue in cheek> and all but that was my point -- with a not at least
ostensibly feature driven scheme you loose out on all the hype, press,
marketing and, frankly, on the fun.
Really, find me a single Linux developer who wouldn't try just a little
bit harder for a big 3.0 release. This is still a community, not yet a
boring office schedule...
Rene.
^ permalink raw reply
* [Qemu-devel] [PATCH] APIC: Do not start zero-period timers
From: Jan Kiszka @ 2008-07-19 8:32 UTC (permalink / raw)
To: qemu-devel
The APIC timer must not start when the initial count is (still) zero.
This caused occasional stalls when booting secondary CPUs of Linux SMP
guests.
Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
---
hw/apic.c | 2 ++
1 file changed, 2 insertions(+)
Index: b/hw/apic.c
===================================================================
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -566,6 +566,8 @@ static void apic_timer_update(APICState
d = (current_time - s->initial_count_load_time) >>
s->count_shift;
if (s->lvt[APIC_LVT_TIMER] & APIC_LVT_TIMER_PERIODIC) {
+ if (!s->initial_count)
+ goto no_timer;
d = ((d / ((uint64_t)s->initial_count + 1)) + 1) * ((uint64_t)s->initial_count + 1);
} else {
if (d >= s->initial_count)
^ permalink raw reply
* [REGRESSION?] -no-kvm-irqchip broken with kvm.git
From: Jan Kiszka @ 2008-07-19 8:43 UTC (permalink / raw)
To: kvm-devel
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
Hi,
I'm currently facing problems to get kvm working with -no-kvm-irqchip.
It used to be fine up to kvm-71, but with latest git my Linux guest
stalls during early boot:
[ 22.631200] Freeing unused kernel memory: 324k freed
[ 22.857098] SCSI subsystem initialized
[ 22.892601] scsi0 : ata_piix
[ 22.903604] scsi1 : ata_piix
[ 22.904473] ata1: PATA max MWDMA2 cmd 0x00000000000101f0 ctl 0x00000000000103f6 bmdma 0x000000000001c000 irq 14
[ 22.917692] ata2: PATA max MWDMA2 cmd 0x0000000000010170 ctl 0x0000000000010376 bmdma 0x000000000001c008 irq 15
This seems to be a kernel-side issue, replacing the module set with the
one that came with -71 fixes the issue. Maybe due to
vmx_complete_interrupts refactoring?
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
^ permalink raw reply
* [-mm][splitlru][PATCH 3/3] revert to unevictable-lru-infrastructure-kconfig-fix.patch
From: kosaki.motohiro @ 2008-07-19 8:42 UTC (permalink / raw)
To: linux-mm, akpm
Cc: KOSAKI Motohiro, Li Zefan, Hugh Dickins, Lee Schermerhorn,
Rik van Riel
In-Reply-To: <20080719084213.588795788@jp.fujitsu.com>
[-- Attachment #1: revert-kconfig.patch --]
[-- Type: text/plain, Size: 2187 bytes --]
CONFIG_UNEVICTABLE_LRU automatically turn on CONFIG_PAGE_WALKER.
it cause build error on nommu machine.
Now, it is unnecessary because munlock was rewritten.
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
CC: Li Zefan <lizf@cn.fujitsu.com>
CC: Hugh Dickins <hugh@veritas.com>
CC: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
CC: Rik van Riel <riel@redhat.com>
---
init/Kconfig | 1 -
mm/Kconfig | 5 -----
mm/Makefile | 2 +-
3 files changed, 1 insertion(+), 7 deletions(-)
Index: b/init/Kconfig
===================================================================
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -803,7 +803,6 @@ source "arch/Kconfig"
config PROC_PAGE_MONITOR
default y
depends on PROC_FS && MMU
- select PAGE_WALKER
bool "Enable /proc page monitoring" if EMBEDDED
help
Various /proc files exist to monitor process memory utilization:
Index: b/mm/Kconfig
===================================================================
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -209,14 +209,9 @@ config VIRT_TO_BUS
def_bool y
depends on !ARCH_NO_VIRT_TO_BUS
-# automatically selected by UNEVICTABLE_LRU or PROC_PAGE_MONITOR
-config PAGE_WALKER
- def_bool n
-
config UNEVICTABLE_LRU
bool "Add LRU list to track non-evictable pages"
default y
- select PAGE_WALKER
help
Keeps unevictable pages off of the active and inactive pageout
lists, so kswapd will not waste CPU time or have its balancing
Index: b/mm/Makefile
===================================================================
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -13,7 +13,7 @@ obj-y := bootmem.o filemap.o mempool.o
prio_tree.o util.o mmzone.o vmstat.o backing-dev.o \
page_isolation.o $(mmu-y)
-obj-$(CONFIG_PAGE_WALKER) += pagewalk.o
+obj-$(CONFIG_PROC_PAGE_MONITOR) += pagewalk.o
obj-$(CONFIG_BOUNCE) += bounce.o
obj-$(CONFIG_SWAP) += page_io.o swap_state.o swapfile.o thrash.o
obj-$(CONFIG_HAS_DMA) += dmapool.o
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [-mm][splitlru][PATCH 2/3] split LRU: munlock rework
From: kosaki.motohiro @ 2008-07-19 8:42 UTC (permalink / raw)
To: linux-mm, akpm
Cc: KOSAKI Motohiro, Li Zefan, Hugh Dickins, Lee Schermerhorn,
Rik van Riel
In-Reply-To: <20080719084213.588795788@jp.fujitsu.com>
[-- Attachment #1: munlock-rework.patch --]
[-- Type: text/plain, Size: 7004 bytes --]
current munlock processing use to pagewalk.
its cause two problems.
- build error on nommu machine
- runtime error on HIGHPTE machine.
This patch fixes it.
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
CC: Li Zefan <lizf@cn.fujitsu.com>
CC: Hugh Dickins <hugh@veritas.com>
CC: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
CC: Rik van Riel <riel@redhat.com>
---
mm/mlock.c | 152 ++++++++++++++-----------------------------------------------
1 file changed, 35 insertions(+), 117 deletions(-)
Index: b/mm/mlock.c
===================================================================
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -147,18 +147,33 @@ static void munlock_vma_page(struct page
* vma->vm_mm->mmap_sem must be held for write.
*/
static int __mlock_vma_pages_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end)
+ unsigned long start, unsigned long end,
+ int mlock)
{
struct mm_struct *mm = vma->vm_mm;
unsigned long addr = start;
struct page *pages[16]; /* 16 gives a reasonable batch */
- int write = !!(vma->vm_flags & VM_WRITE);
int nr_pages = (end - start) / PAGE_SIZE;
int ret;
+ int gup_flags = 0;
+
+ VM_BUG_ON(start & ~PAGE_MASK);
+ VM_BUG_ON(end & ~PAGE_MASK);
+ VM_BUG_ON(start < vma->vm_start);
+ VM_BUG_ON(end > vma->vm_end);
+ VM_BUG_ON((!rwsem_is_locked(&mm->mmap_sem)) &&
+ (atomic_read(&mm->mm_users) != 0));
+
+ /*
+ * mlock: don't page populate if page has PROT_NONE permission.
+ * munlock: the pages always do munlock althrough
+ * its has PROT_NONE permission.
+ */
+ if (!mlock)
+ gup_flags |= GUP_FLAGS_IGNORE_VMA_PERMISSIONS;
- VM_BUG_ON(start & ~PAGE_MASK || end & ~PAGE_MASK);
- VM_BUG_ON(start < vma->vm_start || end > vma->vm_end);
- VM_BUG_ON(!rwsem_is_locked(&vma->vm_mm->mmap_sem));
+ if (vma->vm_flags & VM_WRITE)
+ gup_flags |= GUP_FLAGS_WRITE;
lru_add_drain_all(); /* push cached pages to LRU */
@@ -171,9 +186,9 @@ static int __mlock_vma_pages_range(struc
* get_user_pages makes pages present if we are
* setting mlock.
*/
- ret = get_user_pages(current, mm, addr,
+ ret = __get_user_pages(current, mm, addr,
min_t(int, nr_pages, ARRAY_SIZE(pages)),
- write, 0, pages, NULL);
+ gup_flags, pages, NULL);
/*
* This can happen for, e.g., VM_NONLINEAR regions before
* a page has been allocated and mapped at a given offset,
@@ -202,8 +217,12 @@ static int __mlock_vma_pages_range(struc
* us. Check after acquiring page lock.
*/
lock_page(page);
- if (page->mapping)
- mlock_vma_page(page);
+ if (page->mapping) {
+ if (mlock)
+ mlock_vma_page(page);
+ else
+ munlock_vma_page(page);
+ }
unlock_page(page);
put_page(page); /* ref from get_user_pages() */
@@ -221,120 +240,19 @@ static int __mlock_vma_pages_range(struc
return 0; /* count entire vma as locked_vm */
}
-/*
- * private structure for munlock page table walk
- */
-struct munlock_page_walk {
- struct vm_area_struct *vma;
- pmd_t *pmd; /* for migration_entry_wait() */
-};
-
-/*
- * munlock normal pages for present ptes
- */
-static int __munlock_pte_handler(pte_t *ptep, unsigned long addr,
- unsigned long end, struct mm_walk *walk)
-{
- struct munlock_page_walk *mpw = walk->private;
- swp_entry_t entry;
- struct page *page;
- pte_t pte;
-
-retry:
- pte = *ptep;
- /*
- * If it's a swap pte, we might be racing with page migration.
- */
- if (unlikely(!pte_present(pte))) {
- if (!is_swap_pte(pte))
- goto out;
- entry = pte_to_swp_entry(pte);
- if (is_migration_entry(entry)) {
- migration_entry_wait(mpw->vma->vm_mm, mpw->pmd, addr);
- goto retry;
- }
- goto out;
- }
-
- page = vm_normal_page(mpw->vma, addr, pte);
- if (!page)
- goto out;
-
- lock_page(page);
- if (!page->mapping) {
- unlock_page(page);
- goto retry;
- }
- munlock_vma_page(page);
- unlock_page(page);
-
-out:
- return 0;
-}
-
-/*
- * Save pmd for pte handler for waiting on migration entries
- */
-static int __munlock_pmd_handler(pmd_t *pmd, unsigned long addr,
- unsigned long end, struct mm_walk *walk)
-{
- struct munlock_page_walk *mpw = walk->private;
-
- mpw->pmd = pmd;
- return 0;
-}
-
-
-/*
- * munlock a range of pages in the vma using standard page table walk.
- *
- * vma->vm_mm->mmap_sem must be held for write.
- */
-static void __munlock_vma_pages_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end)
-{
- struct mm_struct *mm = vma->vm_mm;
- struct munlock_page_walk mpw = {
- .vma = vma,
- };
- struct mm_walk munlock_page_walk = {
- .pmd_entry = __munlock_pmd_handler,
- .pte_entry = __munlock_pte_handler,
- .private = &mpw,
- .mm = mm,
- };
-
- VM_BUG_ON(start & ~PAGE_MASK || end & ~PAGE_MASK);
- VM_BUG_ON((!rwsem_is_locked(&mm->mmap_sem)) &&
- (atomic_read(&mm->mm_users) != 0));
- VM_BUG_ON(start < vma->vm_start);
- VM_BUG_ON(end > vma->vm_end);
-
- lru_add_drain_all(); /* push cached pages to LRU */
- walk_page_range(start, end, &munlock_page_walk);
- lru_add_drain_all(); /* to update stats */
-}
-
#else /* CONFIG_UNEVICTABLE_LRU */
/*
* Just make pages present if VM_LOCKED. No-op if unlocking.
*/
static int __mlock_vma_pages_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end)
+ unsigned long start, unsigned long end,
+ int mlock)
{
- if (vma->vm_flags & VM_LOCKED)
+ if (mlock && (vma->vm_flags & VM_LOCKED))
make_pages_present(start, end);
return 0;
}
-
-/*
- * munlock a range of pages in the vma -- no-op.
- */
-static void __munlock_vma_pages_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end)
-{
-}
#endif /* CONFIG_UNEVICTABLE_LRU */
/*
@@ -357,7 +275,7 @@ int mlock_vma_pages_range(struct vm_area
is_vm_hugetlb_page(vma) ||
vma == get_gate_vma(current))) {
downgrade_write(&mm->mmap_sem);
- nr_pages = __mlock_vma_pages_range(vma, start, end);
+ nr_pages = __mlock_vma_pages_range(vma, start, end, 1);
up_read(&mm->mmap_sem);
/* vma can change or disappear */
@@ -392,7 +310,7 @@ void munlock_vma_pages_range(struct vm_a
unsigned long start, unsigned long end)
{
vma->vm_flags &= ~VM_LOCKED;
- __munlock_vma_pages_range(vma, start, end);
+ __mlock_vma_pages_range(vma, start, end, 0);
}
/*
@@ -469,7 +387,7 @@ success:
*/
downgrade_write(&mm->mmap_sem);
- ret = __mlock_vma_pages_range(vma, start, end);
+ ret = __mlock_vma_pages_range(vma, start, end, 1);
if (ret > 0) {
mm->locked_vm -= ret;
ret = 0;
@@ -495,7 +413,7 @@ success:
* while. Should we downgrade the semaphore for both lock
* AND unlock ?
*/
- __munlock_vma_pages_range(vma, start, end);
+ __mlock_vma_pages_range(vma, start, end, 0);
}
out:
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [-mm][splitlru][PATCH 1/3] introduce __get_user_pages()
From: kosaki.motohiro @ 2008-07-19 8:42 UTC (permalink / raw)
To: linux-mm, akpm
Cc: KOSAKI Motohiro, Li Zefan, Hugh Dickins, Lee Schermerhorn,
Rik van Riel
In-Reply-To: <20080719084213.588795788@jp.fujitsu.com>
[-- Attachment #1: __get_user_pages.patch --]
[-- Type: text/plain, Size: 3336 bytes --]
new munlock processing need to GUP_FLAGS_IGNORE_VMA_PERMISSIONS.
because current get_user_pages() can't grab PROT_NONE pages theresore
it cause PROT_NONE pages can't munlock.
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
CC: Li Zefan <lizf@cn.fujitsu.com>
CC: Hugh Dickins <hugh@veritas.com>
CC: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
CC: Rik van Riel <riel@redhat.com>
---
mm/internal.h | 8 ++++++++
mm/memory.c | 37 +++++++++++++++++++++++++++++++------
2 files changed, 39 insertions(+), 6 deletions(-)
Index: b/mm/memory.c
===================================================================
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1108,12 +1108,17 @@ static inline int use_zero_page(struct v
return !vma->vm_ops || !vma->vm_ops->fault;
}
-int get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
- unsigned long start, int len, int write, int force,
+
+
+int __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long start, int len, int flags,
struct page **pages, struct vm_area_struct **vmas)
{
int i;
- unsigned int vm_flags;
+ unsigned int vm_flags = 0;
+ int write = !!(flags & GUP_FLAGS_WRITE);
+ int force = !!(flags & GUP_FLAGS_FORCE);
+ int ignore = !!(flags & GUP_FLAGS_IGNORE_VMA_PERMISSIONS);
if (len <= 0)
return 0;
@@ -1137,7 +1142,9 @@ int get_user_pages(struct task_struct *t
pud_t *pud;
pmd_t *pmd;
pte_t *pte;
- if (write) /* user gate pages are read-only */
+
+ /* user gate pages are read-only */
+ if (!ignore && write)
return i ? : -EFAULT;
if (pg > TASK_SIZE)
pgd = pgd_offset_k(pg);
@@ -1169,8 +1176,9 @@ int get_user_pages(struct task_struct *t
continue;
}
- if (!vma || (vma->vm_flags & (VM_IO | VM_PFNMAP))
- || !(vm_flags & vma->vm_flags))
+ if (!vma ||
+ (vma->vm_flags & (VM_IO | VM_PFNMAP)) ||
+ (!ignore && !(vm_flags & vma->vm_flags)))
return i ? : -EFAULT;
if (is_vm_hugetlb_page(vma)) {
@@ -1245,6 +1253,23 @@ int get_user_pages(struct task_struct *t
} while (len);
return i;
}
+
+int get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long start, int len, int write, int force,
+ struct page **pages, struct vm_area_struct **vmas)
+{
+ int flags = 0;
+
+ if (write)
+ flags |= GUP_FLAGS_WRITE;
+ if (force)
+ flags |= GUP_FLAGS_FORCE;
+
+ return __get_user_pages(tsk, mm,
+ start, len, flags,
+ pages, vmas);
+}
+
EXPORT_SYMBOL(get_user_pages);
pte_t *get_locked_pte(struct mm_struct *mm, unsigned long addr,
Index: b/mm/internal.h
===================================================================
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -243,4 +243,12 @@ static inline void mminit_validate_memmo
}
#endif /* CONFIG_SPARSEMEM */
+#define GUP_FLAGS_WRITE 0x1
+#define GUP_FLAGS_FORCE 0x2
+#define GUP_FLAGS_IGNORE_VMA_PERMISSIONS 0x4
+
+int __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long start, int len, int flags,
+ struct page **pages, struct vm_area_struct **vmas);
+
#endif
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [-mm][splitlru][PATCH 0/3] munlock rework
From: kosaki.motohiro @ 2008-07-19 8:42 UTC (permalink / raw)
To: linux-mm, akpm
--
old munlock processing of unevictable-lru use pagewalk.
because get_user_pages() can't grab PROT_NONE page.
then, current -mm has two problem.
- build error on nommu machine
- runtime error on HIGHPTE machine.
So, I hope rework below concept
Old implementation
- use pagewalk
New implementation
- use __get_user_pages()
I tested this patch on
IA64: >24H stress workload
x86_64: ditto
x86_32 with HIGHPTE: only half hour
Li-san, Could you please try to this patch on your 32bit machine?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [Qemu-devel] Re: target arm fstat64 bug
From: matthieu castet @ 2008-07-19 8:39 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <loom.20080716T203556-537@post.gmane.org>
Hi,
any comment on this ?
You can look at
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git \
;a=blob;f=include/asm-arm/stat.h;h=42c0c13999d5ffa4f8458d2825cd121a41dd8595; \
hb=HEAD
to see the kernel header and compare with qemu one.
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] Add DMA_ATTR_WEAK_ORDERING dma attribute and use in Cell IOMMU code
From: Arnd Bergmann @ 2008-07-19 8:36 UTC (permalink / raw)
To: Jeremy Kerr
Cc: Roland Dreier, Hans Boettiger, linuxppc-dev, Peter Altevogt,
cbe-oss-dev
In-Reply-To: <200807191729.22067.jk@ozlabs.org>
On Saturday 19 July 2008, Jeremy Kerr wrote:
>
> > Ok, this is the previous version of the patch from Mark, which
> > does exactly that. Please use this one instead.
>
> So, should we add a:
>
> From: Mark Nelson <markn@au1.ibm.com>
>
Yes, of course. I keep losing this line when sending patches through
quilt and kmail.
Arnd <><
^ permalink raw reply
* Re: HVM direct boot broken in xen-unstable
From: Daniel P. Berrange @ 2008-07-19 8:35 UTC (permalink / raw)
To: Byrne, John (HP Labs); +Cc: xen-devel@lists.xensource.com
In-Reply-To: <469F2699A483D44BA6D2B311B1089D3A39A8FE2696@GVW1096EXB.americas.hpqcorp.net>
On Sat, Jul 19, 2008 at 12:52:07AM +0000, Byrne, John (HP Labs) wrote:
> Hi!
>
> On x86_64, changeset 18081, running/building on rhel5, trying to use
> the HVM direct boot causes the domain to reboot immediately and then
> the log says the domain is restarting too rapidly. No obvious hints
> as to where the problem is. If I build the in-tree ioemu code, things
> work. Any clues as to where to look or how to get some useful debugging
> output?
It appears the code is missing from the external ioemu code. The original
changesets for HVM kernel boot were
changeset: 16959:17cce0554151
user: Keir Fraser <keir.fraser@citrix.com>
date: Fri Feb 01 11:14:53 2008 +0000
summary: Direct Linux boot: Support booting relocatable Linux kernels.
changeset: 16960:67ca9c37ef02
user: Keir Fraser <keir.fraser@citrix.com>
date: Fri Feb 01 11:16:37 2008 +0000
summary: Direct Linux boot: Support booting non-relocatable Linux kernels.
Part of the first changeset is missing, and all of the second. So the
kernel will be getting overwritten by the HVM firmware hence the crashes
of the guest you see
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
^ permalink raw reply
* Re: Sharing variables/memory between host and guest ?
From: Avi Kivity @ 2008-07-19 8:29 UTC (permalink / raw)
To: Arn; +Cc: kvm
In-Reply-To: <896ae46a0807141443p78df612csb5801d8ae7af17ca@mail.gmail.com>
Arn wrote:
>>> How can one share memory (a few variables not necessarily a page)
>>> between host/hypervisor and guest VM ?
>>>
>>>
>> If you use the -mem-path qemu option, all guest memory will be in a file on
>> tmpfs. You can mmap that file and access all guest memory. Of course, this
>> is hitting the problem with a fairly bit hammer; more refined approaches are
>> possible.
>>
>
> Could you outline the other approaches ?
>
>
Have qemu expose the shared memory as a pci device, and write a guest
driver to exploit it. This is what the vga emulation does.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: Temporarily squelching multipathd errors
From: Christophe Varoqui @ 2008-07-19 8:27 UTC (permalink / raw)
To: daniel.keisling; +Cc: device-mapper development
> Greetings,
>
> I perform SAN-based snapshots on OCFS2 and ext3 filesystems under
> dm-multipath. Before I snapshot the filesystem, I unmount and delete
> the previous night's snapshot LUNs. Doing so causes (correctly)
> multipathd to output the following errors:
>
> <snip>
> ...
> Jul 14 03:16:02 ausracdbd01 multipathd: mpath19: remaining active paths:
> 7
> Jul 14 03:16:02 ausracdbd01 multipathd: sdci: tur checker reports path
> is down
> Jul 14 03:16:02 ausracdbd01 kernel: device-mapper: multipath: Failing
> path 69:80.
> Jul 14 03:16:02 ausracdbd01 multipathd: sdco: tur checker reports path
> is down
> ....
> </snip>
>
> During this snapshot time, I would like to temporarily turn off the
> verbosity of multipathd. Is this possible? It's mostly an annoyance
> factor for me because our nightly centralized syslog scan picks up words
> like 'fail' and generates a report to the system administrators (which
> we then have to ignore for these messages).
>
Why not just remove the multipath from the multipathd topology before deleting the snapvol ?
multipathd -k"del map mpath19"
Regards,
cvaroqui
^ permalink raw reply
* Peculiar memory leack possibly involving forcedeth
From: Sazpaimon @ 2008-07-19 7:58 UTC (permalink / raw)
To: netdev
Hi, on my 2.6.24-1-amd64 Debian box, I seem to be getting a leak related
to forcedeth, leaving my machine unavailable until I reboot it. As my
output from my serial console shows, oom-killer isn't taking effect, and
as such there's nothing that can be done. I'm hoping this call trace
can help track down the issue.
Mem-info:
Node 0 DMA per-cpu:
CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1
usd: 0
Node 0 DMA32 per-cpu:
CPU 0: Hot: hi: 186, btch: 31 usd: 0 Cold: hi: 62, btch: 15
usd: 0
Active:79165 inactive:109684 dirty:0 writeback:0 unstable:0
free:1352 slab:17120 mapped:15 pagetables:32379 bounce:0
Node 0 DMA free:3920kB min:24kB low:28kB high:36kB active:452kB
inactive:136kB present:6084kB pages_scanned:1346 all_unreclaimable? no
lowmem_reserve[]: 0 977 977 977
Node 0 DMA32 free:1488kB min:3984kB low:4980kB high:5976kB
active:316208kB inactive:438600kB present:1000976kB
pages_scanned:2085485 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 150*4kB 1*8kB 1*16kB 1*32kB 1*64kB 1*128kB 0*256kB 0*512kB
1*1024kB 1*2048kB 0*4096kB = 3920kB
Node 0 DMA32: 100*4kB 0*8kB 0*16kB 0*32kB 1*64kB 0*128kB 0*256kB 2*512kB
0*1024kB 0*2048kB 0*4096kB = 1488kB
Swap cache: add 5049008, delete 5049007, find 75384654/75945454, race
412+222
Free swap = 0kB
Total swap = 1959920kB
Free swap: 0kB
257808 pages of RAM
4639 reserved pages
251166 pages shared
1 pages swap cached
printk: 83 messages suppressed.
named: page allocation failure. order:0, mode:0x20
Pid: 30047, comm: named Not tainted 2.6.24-1-amd64 #1
Call Trace:
<IRQ> [<ffffffff80277404>] __alloc_pages+0x2f0/0x309
[<ffffffff8029300f>] kmem_getpages+0x95/0x145
[<ffffffff8029300f>] kmem_getpages+0x95/0x145
[<ffffffff80293578>] fallback_alloc+0x11e/0x18a
[<ffffffff802931ef>] kmem_cache_alloc_node+0x93/0xc4
[<ffffffff803a86c1>] __alloc_skb+0x64/0x12d
[<ffffffff8022ceeb>] __update_rq_clock+0x16/0x8b
[<ffffffff88086841>] :forcedeth:nv_alloc_rx_optimized+0x57/0x198
[<ffffffff88089583>] :forcedeth:nv_do_rx_refill+0x0/0xc3
[<ffffffff880895df>] :forcedeth:nv_do_rx_refill+0x5c/0xc3
[<ffffffff88089583>] :forcedeth:nv_do_rx_refill+0x0/0xc3
[<ffffffff8023dd50>] run_timer_softirq+0x16a/0x1df
[<ffffffff8024ae87>] ktime_get+0xc/0x41
[<ffffffff8023a989>] __do_softirq+0x55/0xc3
[<ffffffff8020cfbc>] call_softirq+0x1c/0x28
[<ffffffff8020ec12>] do_softirq+0x2c/0x7d
[<ffffffff8023a8ef>] irq_exit+0x3f/0x84
[<ffffffff8021dabe>] smp_apic_timer_interrupt+0x40/0x52
[<ffffffff8020ca66>] apic_timer_interrupt+0x66/0x70
<EOI> [<ffffffff802864e6>] page_check_address+0x27/0xea
[<ffffffff80286579>] page_check_address+0xba/0xea
[<ffffffff802865f4>] page_referenced_one+0x4b/0xba
[<ffffffff8028b014>] get_swap_page+0x1a/0x29e
[<ffffffff802871da>] page_referenced+0x6d/0xe2
[<ffffffff8027ae47>] shrink_page_list+0x11b/0x563
[<ffffffff802864e6>] page_check_address+0x27/0xea
[<ffffffff802865c4>] page_referenced_one+0x1b/0xba
[<ffffffff8027a4a1>] isolate_lru_pages+0x5d/0x1d9
[<ffffffff8027b3ac>] shrink_inactive_list+0x11d/0x381
[<ffffffff8027b6f4>] shrink_zone+0xe4/0x107
[<ffffffff80248206>] autoremove_wake_function+0x0/0x2e
[<ffffffff8027c4cd>] try_to_free_pages+0x17b/0x28e
[<ffffffff80248206>] autoremove_wake_function+0x0/0x2e
[<ffffffff802772de>] __alloc_pages+0x1ca/0x309
[<ffffffff8024ab13>] hrtimer_try_to_cancel+0x67/0x70
[<ffffffff80278e1e>] __do_page_cache_readahead+0x79/0x183
[<ffffffff80273a51>] filemap_fault+0x15a/0x30b
[<ffffffff8027e496>] __do_fault+0x68/0x39b
[<ffffffff8028003b>] handle_mm_fault+0x330/0x6d8
[<ffffffff802235ea>] do_page_fault+0x358/0x702
[<ffffffff8024cd35>] getnstimeofday+0x4e/0x85
[<ffffffff8024ae4b>] ktime_get_ts+0x17/0x47
[<ffffffff80252840>] sys_futex+0xfa/0x118
[<ffffffff80416ac9>] error_exit+0x0/0x51
Mem-info:
Node 0 DMA per-cpu:
CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1
usd: 0
Node 0 DMA32 per-cpu:
CPU 0: Hot: hi: 186, btch: 31 usd: 0 Cold: hi: 62, btch: 15
usd: 0
Active:81674 inactive:107148 dirty:0 writeback:0 unstable:0
free:1352 slab:17120 mapped:15 pagetables:32379 bounce:0
Node 0 DMA free:3920kB min:24kB low:28kB high:36kB active:452kB
inactive:136kB present:6084kB pages_scanned:1346 all_unreclaimable? no
lowmem_reserve[]: 0 977 977 977
Node 0 DMA32 free:1488kB min:3984kB low:4980kB high:5976kB
active:326244kB inactive:428456kB present:1000976kB
pages_scanned:2152432 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 150*4kB 1*8kB 1*16kB 1*32kB 1*64kB 1*128kB 0*256kB 0*512kB
1*1024kB 1*2048kB 0*4096kB = 3920kB
Node 0 DMA32: 100*4kB 0*8kB 0*16kB 0*32kB 1*64kB 0*128kB 0*256kB 2*512kB
0*1024kB 0*2048kB 0*4096kB = 1488kB
Swap cache: add 5049008, delete 5049007, find 75384654/75945454, race
412+222
Free swap = 0kB
Total swap = 1959920kB
Free swap: 0kB
257808 pages of RAM
4639 reserved pages
251194 pages shared
1 pages swap cached
printk: 83 messages suppressed.
icecast2: page allocation failure. order:0, mode:0x20
Pid: 24353, comm: icecast2 Not tainted 2.6.24-1-amd64 #1
Call Trace:
<IRQ> [<ffffffff80277404>] __alloc_pages+0x2f0/0x309
[<ffffffff8029300f>] kmem_getpages+0x95/0x145
[<ffffffff8029300f>] kmem_getpages+0x95/0x145
[<ffffffff80293578>] fallback_alloc+0x11e/0x18a
[<ffffffff802931ef>] kmem_cache_alloc_node+0x93/0xc4
[<ffffffff803a86c1>] __alloc_skb+0x64/0x12d
[<ffffffff88086841>] :forcedeth:nv_alloc_rx_optimized+0x57/0x198
[<ffffffff88089583>] :forcedeth:nv_do_rx_refill+0x0/0xc3
[<ffffffff880895df>] :forcedeth:nv_do_rx_refill+0x5c/0xc3
[<ffffffff88089583>] :forcedeth:nv_do_rx_refill+0x0/0xc3
[<ffffffff8023dd50>] run_timer_softirq+0x16a/0x1df
[<ffffffff8023a989>] __do_softirq+0x55/0xc3
[<ffffffff8020cfbc>] call_softirq+0x1c/0x28
[<ffffffff8020ec12>] do_softirq+0x2c/0x7d
[<ffffffff8023a8ef>] irq_exit+0x3f/0x84
[<ffffffff8021dabe>] smp_apic_timer_interrupt+0x40/0x52
[<ffffffff8020ca66>] apic_timer_interrupt+0x66/0x70
<EOI> [<ffffffff80286519>] page_check_address+0x5a/0xea
[<ffffffff80286579>] page_check_address+0xba/0xea
[<ffffffff802865f4>] page_referenced_one+0x4b/0xba
[<ffffffff80286660>] page_referenced_one+0xb7/0xba
[<ffffffff802871da>] page_referenced+0x6d/0xe2
[<ffffffff8027a845>] shrink_active_list+0x228/0x50b
[<ffffffff8027b5f9>] shrink_inactive_list+0x36a/0x381
[<ffffffff8027b6d6>] shrink_zone+0xc6/0x107
[<ffffffff80248206>] autoremove_wake_function+0x0/0x2e
[<ffffffff8027c4cd>] try_to_free_pages+0x17b/0x28e
[<ffffffff80248206>] autoremove_wake_function+0x0/0x2e
[<ffffffff802772de>] __alloc_pages+0x1ca/0x309
[<ffffffff804157a5>] __wait_on_bit_lock+0x5b/0x66
[<ffffffff80278e1e>] __do_page_cache_readahead+0x79/0x183
[<ffffffff80273a51>] filemap_fault+0x15a/0x30b
[<ffffffff8027e496>] __do_fault+0x68/0x39b
[<ffffffff803a4985>] lock_sock_nested+0x9f/0xaa
[<ffffffff8028003b>] handle_mm_fault+0x330/0x6d8
[<ffffffff802235ea>] do_page_fault+0x358/0x702
[<ffffffff80296e5d>] fd_install+0x25/0x59
[<ffffffff803d6786>] tcp_poll+0x0/0x138
[<ffffffff80416ac9>] error_exit+0x0/0x51
^ permalink raw reply
* Re: [RFC][PATCH] introduce a btrfs_iget helper
From: Balaji Rao @ 2008-07-19 8:25 UTC (permalink / raw)
To: Chris Mason; +Cc: linux-btrfs
In-Reply-To: <1216406826.6932.65.camel@think.oraclecorp.com>
On Saturday 19 July 2008 12:17:06 am Chris Mason wrote:
> On Mon, 2008-07-14 at 11:52 +0530, Balaji Rao wrote:
> > Hello,
> >
> > As suggest by Cristoph, this patch factors out a btrfs_iget helper from
> > btrfs_lookup. This is useful in situations such as in NFS export ops.
> >
> > Comments ?
>
> No objections, but I'll wait for the full NFS patch before pulling this
> one in
Cool. Its almost done. I'll send it once I hunt down a bug I'm chasing now.
--
Warm Regards,
Balaji Rao
^ permalink raw reply
* Out-of-repository file remove error
From: Nick Andrew @ 2008-07-19 8:23 UTC (permalink / raw)
To: git
git rm seems to have a problem with removing a file from a repository
when the repository .git and working tree are not in the current
directory. It leaves an index.lock file.
Here's a script to show the bug:
mkdir Bugtest
cd Bugtest
git init
date > newfile
git add newfile
git commit -m 'Added' newfile
cd ..
git --git-dir=Bugtest/.git --work-tree=Bugtest rm newfile
ls -l Bugtest/.git/index.lock
Output:
Initialized empty Git repository in .../Bugtest/.git/
Created initial commit 43dec15: Added
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 newfile
rm 'newfile'
fatal: Unable to write new index file
-rw-r--r-- 1 nick nick 32 Jul 19 18:20 Bugtest/.git/index.lock
I tested on:
git version 1.5.6.2
git version 1.5.6.3.440.g9d8f
Nick.
^ permalink raw reply
* Re: More ethernet port same ip address
From: Bernhard Bock @ 2008-07-19 8:18 UTC (permalink / raw)
To: Michele Petrazzo - Unipex srl; +Cc: netfilter
In-Reply-To: <48819901.6030604@unipex.it>
Hi Michele,
Michele Petrazzo - Unipex srl wrote:
> Here the server have the two ports with 172.16.0.1 and two clients,
> connected into the two others has 172.16.0.3 and 172.16.0.10
>
> It's there a solution for achieve this?
My proposal has nothing to do with netfilter, but you may have a look
into "Proxy ARP".
Basically you give each interface the same IP address, put in host
routes based on interfaces (route add -host 172.16.0.3 dev ethx) and
enable proxy_arp in /proc/sys/net/ipv4/conf/ethx/proxy_arp. This should
do the trick.
best regards
Bernhard
^ permalink raw reply
* Re: SELinux User Guide
From: James Morris @ 2008-07-19 8:12 UTC (permalink / raw)
To: Murray McAllister; +Cc: selinux
In-Reply-To: <48803B08.1030205@redhat.com>
On Fri, 18 Jul 2008, Murray McAllister wrote:
> If anyone has any ideas about what they would like to see in the guide, or any
> corrections to the current topics we would like to include, please let us
> know. As well, user feedback and comments can be left at
> <https://fedoraproject.org/wiki/Docs/Drafts/SELinux_User_Guide/SELinux_Feedback>.
> A Fedora account (https://admin.fedoraproject.org/accounts/) is required to
> use the Wiki - if you do not have one, please do not hesitate to mail me
> directly, or respond to this thread.
There's a documentation TODO page at the selinuxproject.org wiki:
http://selinuxproject.org/page/Documentation_TODO
(Not sure if you've incorported any points from that).
- James
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [patch 1/3] fastboot: Create a "asynchronous" initlevel
From: Rene Herman @ 2008-07-19 8:10 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel, mingo
In-Reply-To: <48819D92.8050904@keyaccess.nl>
On 19-07-08 09:53, Rene Herman wrote:
> On 19-07-08 00:16, Arjan van de Ven wrote:
>
>> +static void __init do_initcalls(void)
>> +{
>> + initcall_t *call;
>> + static DECLARE_WORK(async_work, do_async_initcalls);
>> + int phase = 0; /* 0 = levels 0 - 6, 1 = level 6a, 2 = after level
>> 6a */
>> +
>> + async_init_wq = create_singlethread_workqueue("kasyncinit");
>> +
>> + for (call = __initcall_start; call < __initcall_end; call++) {
>> + if (phase == 0 && call >= __async_initcall_start) {
>> + phase = 1;
>> + queue_work(async_init_wq, &async_work);
>> + }
>> + if (phase == 1 && call >= __async_initcall_end)
>> + phase = 2;
>> + if (phase != 1)
>> + do_one_initcall(*call);
>> + }
>
> I'm not sure about this comment, being not very sure about the semantics
> of late_initcall but shouldn't late_initcall (level 7) wait for 6s to
> have completed?
Following up on this myself -- see for example kernel/power/disk.c:
power_suspend(). It's a late intitcall so that, as it comments, "all
devices are discovered and initialized". However, your first followup
patch makes the USB HCI init async meaning that any USB storage device
might not be ready yet when it runs, no?
Rene.
^ permalink raw reply
* [RFC] webcam sensor module
From: Thierry Merle @ 2008-07-19 8:08 UTC (permalink / raw)
To: Linux and Kernel Video, Jean-Francois Moine, Hans de Goede
Hello all,
While analyzing the w9968cf v4l1 module, I saw that my webcam commands a OV7620 sensor. This sensor has a specific module: ovcamchip (v4l1).
My webcam is a Creative Webcam Go Plus.
In gspca, the zc3xx driver addresses the same sensor, but in only one module containing USB bridge controls and sensor controls.
My question is: why gspca does not use the same infrastructure? I mean 1 module for the USB bridge (like w9968cf) and 1 module for the sensor (like ovcamchip).
My first thought was to re-write w9968cf in the gspca frame but I wanted to keep this modular way of life.
>From a high-level point of view it is similar to analog TV tuners: we have a modular separation between USB bridges (like usbvision) and video decoders (like saa7115).
During my vacation I will analyse a bit further if the gspca infrastructure can be improved to integrate the modular sensor model since it can save some code.
The final aim is to make the w9968cf compatible with the v4l2 decompression library (v4l2-apps/lib/libv4l) that requires that the driver shall be v4l2 compliant.
Cheers,
Thierry
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
^ permalink raw reply
* Re: How update kernel recipe?
From: Koen Kooi @ 2008-07-19 8:00 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <4880E6BF.3070102@atmel.com>
Ulf Samuelsson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Koen Kooi skrev:
> | Ulf Samuelsson wrote:
> | I have built "gpe-image" for AT91SAM9263EK
> | after fixing libsvg-cairo manually due to the LT_VERSION problem.
> |
> | I would like to upgrade the kernel for AT91SAM9263EK.
> | I created a recipe for linux-2.6.25.10 called
> | "packages/linux/linux-atmel_2.6.25.10.bb" (found below)
> |
> |> Yuck! There is *absolutely* no need to define
> |>
> linux-we-are-so-cool-we-have-our-company-name-the-kernel-recipe-filename.bb
> |> files, you should be perfectly able to reuse the linux_2.6.25 recipe, as
> |> avr32 already does.
> |
>
> You do not need to edit (and possibly destroy)
> work done and used by others, but I do not have any problem
> with using the linux_2.6.25 recipe, except is is 2.6.25
> and not 2.6.25.10.
>
> The AVR32 should be updated to patch with 2.6.25.10 as well...
2.6.25.10 for avr32 results in an unbootable kernel, so I'm leaving it
at 2.6.25.6 as it is currently.
>
> If you have a number of linux_<version>, some with and some
> without support for your board, then it is harder to
> get an overview which kernels are supported.
>
> Drawback would be if you lose out on interesting features
> added by others by using a proprietary recipe.
>
> Very few machines seems to use the vanilla linux.
> Is there any move to merge current boards into vanilla linux_<version> ?
>
>
> BR
> Ulf Samuelsson
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.4-svn0 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
>
> iD8DBQFIgOa/AyRRH5cXxqwRAvyPAKCHZUsROJ9+dx59KslBd/zvxH2fkwCgjZsF
> 1BnWC6QuiFRXZ7n+jX9Ga58=
> =EChk
> -----END PGP SIGNATURE-----
^ permalink raw reply
* [linux-dvb] Fwd: Technotrend 3650 and Ubuntu Heron
From: alain @ 2008-07-19 8:02 UTC (permalink / raw)
To: linux-dvb
[-- Attachment #1.1: Type: text/plain, Size: 583 bytes --]
-------- Original Message --------
SUBJECT:
Technotrend 3650 and Ubuntu Heron
DATE:
Sat, 19 Jul 2008 09:46:28 +020
Hi Daniel,
thanks for the good tip.
I succeeded with the make but get stuck here now
alain@TELEVISION:~/3650/multiproto/v4l$ sudo insmod dvb-pll.ko
[sudo] password for alain:
insmod: error inserting 'dvb-pll.ko': -1 Unknown symbol in module
Even editing the stbalgo.c didn't help.
Applying the patch with the include of the sound driver is done
allready.
Anyone another idea or maybe the complied files?
Thanks.
Alain
[-- Attachment #1.2: Type: text/html, Size: 1212 bytes --]
[-- Attachment #2: Type: text/plain, Size: 150 bytes --]
_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
^ permalink raw reply
* Re: [PATCH] qemu: re-add definition for qemu_get_launch_info
From: Avi Kivity @ 2008-07-19 8:01 UTC (permalink / raw)
To: Carlo Marcelo Arenas Belon; +Cc: kvm
In-Reply-To: <20080716100912.GA19629@tapir>
Carlo Marcelo Arenas Belon wrote:
> somehow missing from sysemu.h after a qemu merge and otherwise complaining
> with the following warning :
>
> kvm-71/qemu/migration.c: In function 'migration_init_ssh':
> kvm-71/qemu/migration.c:629: warning: implicit declaration of function 'qemu_get_launch_info'
>
>
Applied, thanks.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: [PATCH] qemu: remove duplicated inclusion of signal.h in qemu-kvm.h
From: Avi Kivity @ 2008-07-19 8:01 UTC (permalink / raw)
To: Carlo Marcelo Arenas Belon; +Cc: kvm
In-Reply-To: <20080716101025.GB19629@tapir>
Carlo Marcelo Arenas Belon wrote:
> added by mistake as part of 4820cce75999b2673a964eb87601229a4bd78ad9
>
>
Applied, thanks.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: READ ME, net-2.6 fully merged
From: David Miller @ 2008-07-19 8:01 UTC (permalink / raw)
To: jarkao2; +Cc: netdev
In-Reply-To: <48819CCC.8070800@gmail.com>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Sat, 19 Jul 2008 09:50:36 +0200
> A little btw. question: I know you are busy now with more serious
> problems and it's not for now, but: after the last net-next-2.6 git
> policy change most of the time neither net-2.6 nor net-next-2.6
> could be treated as current net state. I tried to stick to net-next,
> but it was idle most of the time.
I don't want to merge too much, but I did merge net-2.6 into
net-next-2.6 periodically.
Basically my main impetus to merge is when I know or sense that merge
conflicts are building up.
I would recommend that people work on the tree that is appropriate
for the work they are doing. And outside of a merge window that
means net-2.6 for a bug fix and net-next-2.6 for new work (or bug
fixes to new work).
Inside of the merge window, like we are now, will have everything
going into net-2.6
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.