From: Wanpeng Li
Introduce __vmx_flush_tlb() to handle specific vpid.
Signed-off-by: Wanpeng Li
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/vmx.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 65607415
From: Andrey Smetanin
Insert Hyper-V HV_X64_MSR_VP_INDEX into msr's emulated list,
so QEMU can set Hyper-V features cpuid HV_X64_MSR_VP_INDEX_AVAILABLE
bit correctly. KVM emulation part is in place already.
Necessary to support loading of winhv.sys in guest, which in turn is
required to support
From: Steve Rutherford
In order to support a userspace IOAPIC interacting with an in kernel
APIC, the EOI exit bitmaps need to be configurable.
If the IOAPIC is in userspace (i.e. the irqchip has been split), the
EOI exit bitmaps will be set whenever the GSI Routes are configured.
In particular,
From: Wanpeng Li
VPID is used to tag address space and avoid a TLB flush. Currently L0 use
the same VPID to run L1 and all its guests. KVM flushes VPID when switching
between L1 and L2.
This patch advertises VPID to the L1 hypervisor, then address space of L1
and L2 can be separately treated and
From: Wanpeng Li
Add the INVVPID instruction emulation.
Reviewed-by: Wincy Van
Signed-off-by: Wanpeng Li
Signed-off-by: Paolo Bonzini
---
arch/x86/include/asm/vmx.h | 1 +
arch/x86/kvm/vmx.c | 23 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a
Uniprocessor 32-bit randconfigs can disable the local APIC, and posted
interrupts require reserving a vector on the LAPIC, so they are
incompatible.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/vmx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx.c b/arch
From: Andrey Smetanin
HV_X64_MSR_VP_RUNTIME msr used by guest to get
"the time the virtual processor consumes running guest code,
and the time the associated logical processor spends running
hypervisor code on behalf of that guest."
Calculation of this time is performed by task_cputime_adjusted(
Hi all,
these are the patches that will be merged Real Soon Now(tm) to kvm/next.
Since all of them have been lying around for a while, I am sending them
out again for everyone's information.
Thanks,
Paolo
Andrey Smetanin (3):
kvm/x86: Hyper-V HV_X64_MSR_RESET msr
kvm/x86: Hyper-V HV_X64_MS
From: Wanpeng Li
Adjust allocate/free_vid so that they can be reused for the nested vpid.
Signed-off-by: Wanpeng Li
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/vmx.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86
On 07/31/2015 01:27 PM, Daniel Phillips wrote:
On Friday, July 31, 2015 8:37:35 AM PDT, Raymond Jennings wrote:
Returning ENOSPC when you have free space you can't yet prove is safer
than
not returning it and risking a data loss when you get hit by a
write/commit
storm. :)
Remember when delaye
Jan Kara writes:
> On Sun 09-08-15 22:42:42, OGAWA Hirofumi wrote:
>> Jan Kara writes:
>>
>> > I'm not sure about which ENOSPC issue you are speaking BTW. Can you
>> > please ellaborate?
>>
>> 1. GUP simulate page fault, and prepare to modify
>> 2. writeback clear dirty, and make PTE read-only
On Sun 09-08-15 22:42:42, OGAWA Hirofumi wrote:
> Jan Kara writes:
>
> > I'm not sure about which ENOSPC issue you are speaking BTW. Can you
> > please ellaborate?
>
> 1. GUP simulate page fault, and prepare to modify
> 2. writeback clear dirty, and make PTE read-only
> 3. snapshot/reflink make
Jan Kara writes:
> I'm not sure about which ENOSPC issue you are speaking BTW. Can you
> please ellaborate?
1. GUP simulate page fault, and prepare to modify
2. writeback clear dirty, and make PTE read-only
3. snapshot/reflink make block cow
4. driver called GUP modifies page, and dirty page wit
On Fri 31-07-15 13:44:44, OGAWA Hirofumi wrote:
> Jan Kara writes:
>
> >> > Yes, if userspace truncates the file, the situation we end up with is
> >> > basically the same. However for truncate to happen some malicious process
> >> > has to come and truncate the file - a failure scenario that is
On Fri 31-07-15 17:16:45, Daniel Phillips wrote:
> On Friday, July 31, 2015 5:00:43 PM PDT, Daniel Phillips wrote:
> >Note: Hirofumi's email is clear, logical and speaks to the
> >question. This branch of the thread is largely pointless, though
> >it essentially says the same thing in non-technical
On Friday, July 31, 2015 5:00:43 PM PDT, Daniel Phillips wrote:
Note: Hirofumi's email is clear, logical and speaks to the
question. This branch of the thread is largely pointless, though
it essentially says the same thing in non-technical terms. Perhaps
your next response should be to Hirofumi,
On Friday, July 31, 2015 3:27:12 PM PDT, David Lang wrote:
On Fri, 31 Jul 2015, Daniel Phillips wrote:
On Friday, July 31, 2015 11:29:51 AM PDT, David Lang wrote: ...
you weren't asking about any particular feature of Tux, you
were asking if we were still willing to push out stuff that
brea
On Fri, 31 Jul 2015, Daniel Phillips wrote:
On Friday, July 31, 2015 11:29:51 AM PDT, David Lang wrote:
We, the Linux Community have less tolerance for losing people's data and
preventing them from operating than we used to when it was all tinkerer's
personal data and secondary systems.
So r
On Friday, July 31, 2015 11:29:51 AM PDT, David Lang wrote:
We, the Linux Community have less tolerance for losing people's data and
preventing them from operating than we used to when it was all tinkerer's
personal data and secondary systems.
So rather than pushing optimizations out to everyo
On Friday, July 31, 2015 11:29:51 AM PDT, David Lang wrote:
If you define this as "loosing our mojo", then yes we have.
A pity. There remains so much to do that simply will not get
done in the absence of mojo.
Regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux
On Fri, 31 Jul 2015, Daniel Phillips wrote:
Subject: Re: [FYI] tux3: Core changes
On Friday, July 31, 2015 8:37:35 AM PDT, Raymond Jennings wrote:
Returning ENOSPC when you have free space you can't yet prove is safer than
not returning it and risking a data loss when you get hit by a
On Friday, July 31, 2015 8:37:35 AM PDT, Raymond Jennings wrote:
Returning ENOSPC when you have free space you can't yet prove is safer than
not returning it and risking a data loss when you get hit by a write/commit
storm. :)
Remember when delayed allocation was scary and unproven, because pro
Jan Kara writes:
>> > Yes, if userspace truncates the file, the situation we end up with is
>> > basically the same. However for truncate to happen some malicious process
>> > has to come and truncate the file - a failure scenario that is acceptable
>> > for most use cases since it doesn't happen
On Sun 05-07-15 21:54:45, OGAWA Hirofumi wrote:
> Jan Kara writes:
>
> >> I'm not sure I'm understanding your pseudocode logic correctly though.
> >> This logic doesn't seems to be a page forking specific issue. And
> >> this pseudocode logic seems to be missing the locking and revalidate of
> >
Jan Kara writes:
>> I'm not sure I'm understanding your pseudocode logic correctly though.
>> This logic doesn't seems to be a page forking specific issue. And
>> this pseudocode logic seems to be missing the locking and revalidate of
>> page.
>>
>> If you can show more details, it would be hel
On Mon 22-06-15 00:36:00, OGAWA Hirofumi wrote:
> Jan Kara writes:
> > So there are a few things to have in mind:
> > 1) There is nothing like a "writeable" page. Page is always writeable (at
> > least on x86 architecture). When a page is mapped into some virtual address
> > space (or more of them
Jan Kara writes:
Hi,
> So there are a few things to have in mind:
> 1) There is nothing like a "writeable" page. Page is always writeable (at
> least on x86 architecture). When a page is mapped into some virtual address
> space (or more of them), this *mapping* can be either writeable or read-on
On 05/27/2015 02:37 PM, Pavel Machek wrote:
> On Wed 2015-05-27 11:09:25, Daniel Phillips wrote:
>> On Wednesday, May 27, 2015 12:41:37 AM PDT, Pavel Machek wrote:
>>> On Fri 2015-05-15 02:38:33, Daniel Phillips wrote:
On 05/14/2015 08:06 PM, Rik van Riel wrote: ...
>>>
>>> Umm. Why do you t
On Wed 2015-05-27 11:09:25, Daniel Phillips wrote:
> On Wednesday, May 27, 2015 12:41:37 AM PDT, Pavel Machek wrote:
> >On Fri 2015-05-15 02:38:33, Daniel Phillips wrote:
> >>On 05/14/2015 08:06 PM, Rik van Riel wrote: ...
> >
> >Umm. Why do you think it is only issue for executable files?
>
> I m
On Wednesday, May 27, 2015 12:41:37 AM PDT, Pavel Machek wrote:
On Fri 2015-05-15 02:38:33, Daniel Phillips wrote:
On 05/14/2015 08:06 PM, Rik van Riel wrote: ...
Umm. Why do you think it is only issue for executable files?
I meant: files with code in them, that will be executed. Please excu
On Tue 26-05-15 13:22:38, Daniel Phillips wrote:
> On 05/26/2015 02:00 AM, Jan Kara wrote:
> > On Tue 26-05-15 01:08:56, Daniel Phillips wrote:
> >> On Tuesday, May 26, 2015 12:09:10 AM PDT, Jan Kara wrote:
> >>> E.g. video drivers (or infiniband or direct IO for that matter) which
> >>> have buff
On Fri 2015-05-15 02:38:33, Daniel Phillips wrote:
> On 05/14/2015 08:06 PM, Rik van Riel wrote:
> > On 05/14/2015 08:06 PM, Daniel Phillips wrote:
> >>> The issue is that things like ptrace, AIO, infiniband
> >>> RDMA, and other direct memory access subsystems can take
> >>> a reference to page A,
On 05/26/2015 02:36 PM, Rik van Riel wrote:
> On 05/26/2015 04:22 PM, Daniel Phillips wrote:
>> On 05/26/2015 02:00 AM, Jan Kara wrote:
>>> So my opinion is: Don't fork the page if page_count is elevated. You can
>>> just wait for the IO if you need stable pages in that case. It's slow but
>>> it's
On 05/26/2015 04:22 PM, Daniel Phillips wrote:
> On 05/26/2015 02:00 AM, Jan Kara wrote:
>> So my opinion is: Don't fork the page if page_count is elevated. You can
>> just wait for the IO if you need stable pages in that case. It's slow but
>> it's safe and it should be pretty rare. Is there any
On 05/26/2015 02:00 AM, Jan Kara wrote:
> On Tue 26-05-15 01:08:56, Daniel Phillips wrote:
>> On Tuesday, May 26, 2015 12:09:10 AM PDT, Jan Kara wrote:
>>> E.g. video drivers (or infiniband or direct IO for that matter) which
>>> have buffers in user memory (may be mmapped file), grab references t
Hi Sergey,
On 05/26/2015 03:22 AM, Sergey Senozhatsky wrote:
>
> Hello,
>
> is it possible to page-fork-bomb the system by some 'malicious' app?
Not in any new way. A page fork can happen either in the front end,
where it has to wait for memory like any other normal memory user,
or in the backe
On Tue 26-05-15 19:22:39, Sergey Senozhatsky wrote:
> On (05/26/15 01:08), Daniel Phillips wrote:
> > On Tuesday, May 26, 2015 12:09:10 AM PDT, Jan Kara wrote:
> > > E.g. video drivers (or infiniband or direct IO for that matter) which
> > >have buffers in user memory (may be mmapped file), grab r
On (05/26/15 01:08), Daniel Phillips wrote:
> On Tuesday, May 26, 2015 12:09:10 AM PDT, Jan Kara wrote:
> > E.g. video drivers (or infiniband or direct IO for that matter) which
> >have buffers in user memory (may be mmapped file), grab references to pages
> >and hand out PFNs of those pages to th
On Tue 2015-05-26 01:09:59, Daniel Phillips wrote:
> On Monday, May 25, 2015 11:13:46 PM PDT, David Lang wrote:
> >I'm assuming that Rik is talking about whatever has the reference to the
> >page via one of the methods that he talked about.
>
> This would be a good moment to provide specifics.
Hm
On Tue 26-05-15 01:08:56, Daniel Phillips wrote:
> On Tuesday, May 26, 2015 12:09:10 AM PDT, Jan Kara wrote:
> > E.g. video drivers (or infiniband or direct IO for that matter) which
> >have buffers in user memory (may be mmapped file), grab references to pages
> >and hand out PFNs of those pages
On Monday, May 25, 2015 11:13:46 PM PDT, David Lang wrote:
I'm assuming that Rik is talking about whatever has the
reference to the page via one of the methods that he talked
about.
This would be a good moment to provide specifics.
Regards,
Daniel
--
To unsubscribe from this list: send the l
On Tuesday, May 26, 2015 12:09:10 AM PDT, Jan Kara wrote:
E.g. video drivers (or infiniband or direct IO for that matter) which
have buffers in user memory (may be mmapped file), grab references to pages
and hand out PFNs of those pages to the hardware to store data in them...
If you fork a pag
On Mon 25-05-15 23:11:11, Daniel Phillips wrote:
> On Monday, May 25, 2015 11:04:39 PM PDT, David Lang wrote:
> >if the page gets modified again, will that cause any issues? what
> >if the page gets modified before the copy gets written out, so
> >that there are two dirty copies of the page in the
On 05/21/2015 03:53 PM, Daniel Phillips wrote:
> On Wednesday, May 20, 2015 8:51:46 PM PDT, David Lang wrote:
>> how do you prevent it from continuing to interact with the old version
>> of the page and never see updates or have it's changes reflected on
>> the current page?
>
> Why would it do th
On Mon, 25 May 2015, Daniel Phillips wrote:
On Monday, May 25, 2015 11:04:39 PM PDT, David Lang wrote:
if the page gets modified again, will that cause any issues? what if the
page gets modified before the copy gets written out, so that there are two
dirty copies of the page in the process of
On Monday, May 25, 2015 11:04:39 PM PDT, David Lang wrote:
if the page gets modified again, will that cause any issues?
what if the page gets modified before the copy gets written out,
so that there are two dirty copies of the page in the process of
being written?
David Lang
How is the page
On Mon, 25 May 2015, Daniel Phillips wrote:
On Monday, May 25, 2015 9:25:44 PM PDT, Rik van Riel wrote:
On 05/21/2015 03:53 PM, Daniel Phillips wrote:
On Wednesday, May 20, 2015 8:51:46 PM PDT, David Lang wrote:
how do you prevent it from continuing to interact with the old version
of the pag
On Monday, May 25, 2015 9:25:44 PM PDT, Rik van Riel wrote:
On 05/21/2015 03:53 PM, Daniel Phillips wrote:
On Wednesday, May 20, 2015 8:51:46 PM PDT, David Lang wrote:
how do you prevent it from continuing to interact with the old version
of the page and never see updates or have it's changes r
On Wednesday, May 20, 2015 8:51:46 PM PDT, David Lang wrote:
how do you prevent it from continuing to interact with the old
version of the page and never see updates or have it's changes
reflected on the current page?
Why would it do that, and what would be surprising about it? Did
you have a
On Wed, 20 May 2015, Daniel Phillips wrote:
On 05/20/2015 03:51 PM, Daniel Phillips wrote:
On 05/20/2015 12:53 PM, Rik van Riel wrote:
How does tux3 prevent a user of find_get_page() from reading from
or writing into the pre-COW page, instead of the current page?
Careful control of the dirty
On 05/20/2015 03:51 PM, Daniel Phillips wrote:
> On 05/20/2015 12:53 PM, Rik van Riel wrote:
>> How does tux3 prevent a user of find_get_page() from reading from
>> or writing into the pre-COW page, instead of the current page?
>
> Careful control of the dirty bits (we have two of them, one each
>
On 05/20/2015 12:53 PM, Rik van Riel wrote:
> On 05/20/2015 12:22 PM, Daniel Phillips wrote:
>> On 05/20/2015 07:44 AM, Jan Kara wrote:
>>> On Tue 19-05-15 13:33:31, David Lang wrote:
>
>>> Yeah, that's what I meant. If you create a function which manipulates
>>> page cache, you better make it
On 05/20/2015 12:22 PM, Daniel Phillips wrote:
> On 05/20/2015 07:44 AM, Jan Kara wrote:
>> On Tue 19-05-15 13:33:31, David Lang wrote:
>> Yeah, that's what I meant. If you create a function which manipulates
>> page cache, you better make it work with other functions manipulating page
>> cache.
On Wed, 20 May 2015, Daniel Phillips wrote:
On 05/20/2015 07:44 AM, Jan Kara wrote:
Yeah, that's what I meant. If you create a function which manipulates
page cache, you better make it work with other functions manipulating page
cache. Otherwise it's a landmine waiting to be tripped by some u
On 05/20/2015 07:44 AM, Jan Kara wrote:
> On Tue 19-05-15 13:33:31, David Lang wrote:
>> On Tue, 19 May 2015, Daniel Phillips wrote:
>>
I understand that Tux3 may avoid these issues due to some other mechanisms
it internally has but if page forking should get into mm subsystem, the
On Tue 19-05-15 13:33:31, David Lang wrote:
> On Tue, 19 May 2015, Daniel Phillips wrote:
>
> >>I understand that Tux3 may avoid these issues due to some other mechanisms
> >>it internally has but if page forking should get into mm subsystem, the
> >>above must work.
> >
> >It does work, and by ex
On Tue, 19 May 2015, Daniel Phillips wrote:
I understand that Tux3 may avoid these issues due to some other mechanisms
it internally has but if page forking should get into mm subsystem, the
above must work.
It does work, and by example, it does not need a lot of code to make
it work, but the
-writeback.c hook, which is by me. The main part you may be
>> interested in is rmap.c, which addresses the issues raised at the
>> 2013 Linux Storage Filesystem and MM Summit 2015 in San Francisco.[1]
>>
>>LSFMM: Page forking
>>http://lwn.net/Articles/548091/
&
ested in is rmap.c, which addresses the issues raised at the
> 2013 Linux Storage Filesystem and MM Summit 2015 in San Francisco.[1]
>
>LSFMM: Page forking
>http://lwn.net/Articles/548091/
>
> This is just a FYI. An upcoming Tux3 report will be a tour of the page
> for
On 05/17/2015 07:20 PM, Rik van Riel wrote:
> On 05/17/2015 09:26 AM, Boaz Harrosh wrote:
>> On 05/14/2015 03:59 PM, Rik van Riel wrote:
>>> The issue is that things like ptrace, AIO, infiniband
>>> RDMA, and other direct memory access subsystems can take
>>> a reference to page A, which Tux3 clone
On Sat, May 16, 2015 at 03:38:04PM -0700, David Lang wrote:
> On Fri, 15 May 2015, Mel Gorman wrote:
>
> >On Fri, May 15, 2015 at 02:54:48AM -0700, Daniel Phillips wrote:
> >>
> >>
> >>On 05/15/2015 01:09 AM, Mel Gorman wrote:
> >>>On Thu, May 14, 2015 at 11:06:22PM -0400, Rik van Riel wrote:
> >>
On 05/18/2015 05:20 AM, Rik van Riel wrote:
> On 05/17/2015 09:26 AM, Boaz Harrosh wrote:
>> On 05/14/2015 03:59 PM, Rik van Riel wrote:
>>> On 05/14/2015 04:26 AM, Daniel Phillips wrote:
Hi Rik,
>> <>
>>>
>>> The issue is that things like ptrace, AIO, infiniband
>>> RDMA, and other direct mem
On 05/17/2015 09:26 AM, Boaz Harrosh wrote:
> On 05/14/2015 03:59 PM, Rik van Riel wrote:
>> On 05/14/2015 04:26 AM, Daniel Phillips wrote:
>>> Hi Rik,
> <>
>>
>> The issue is that things like ptrace, AIO, infiniband
>> RDMA, and other direct memory access subsystems can take
>> a reference to page
On 05/14/2015 03:59 PM, Rik van Riel wrote:
> On 05/14/2015 04:26 AM, Daniel Phillips wrote:
>> Hi Rik,
<>
>
> The issue is that things like ptrace, AIO, infiniband
> RDMA, and other direct memory access subsystems can take
> a reference to page A, which Tux3 clones into a new page B
> when the pr
On Fri, 15 May 2015, Mel Gorman wrote:
On Fri, May 15, 2015 at 02:54:48AM -0700, Daniel Phillips wrote:
On 05/15/2015 01:09 AM, Mel Gorman wrote:
On Thu, May 14, 2015 at 11:06:22PM -0400, Rik van Riel wrote:
On 05/14/2015 08:06 PM, Daniel Phillips wrote:
The issue is that things like ptrac
On Fri, May 15, 2015 at 02:54:48AM -0700, Daniel Phillips wrote:
>
>
> On 05/15/2015 01:09 AM, Mel Gorman wrote:
> > On Thu, May 14, 2015 at 11:06:22PM -0400, Rik van Riel wrote:
> >> On 05/14/2015 08:06 PM, Daniel Phillips wrote:
> The issue is that things like ptrace, AIO, infiniband
> >>>
On 05/15/2015 01:09 AM, Mel Gorman wrote:
> On Thu, May 14, 2015 at 11:06:22PM -0400, Rik van Riel wrote:
>> On 05/14/2015 08:06 PM, Daniel Phillips wrote:
The issue is that things like ptrace, AIO, infiniband
RDMA, and other direct memory access subsystems can take
a reference to
On 05/14/2015 08:06 PM, Rik van Riel wrote:
> On 05/14/2015 08:06 PM, Daniel Phillips wrote:
>>> The issue is that things like ptrace, AIO, infiniband
>>> RDMA, and other direct memory access subsystems can take
>>> a reference to page A, which Tux3 clones into a new page B
>>> when the process wri
inly by Hirofumi, except
> >>> the fs-writeback.c hook, which is by me. The main part you may be
> >>> interested in is rmap.c, which addresses the issues raised at the
> >>> 2013 Linux Storage Filesystem and MM Summit 2015 in San Francisco.[1]
> >>>
> >
gt; >> interested in is rmap.c, which addresses the issues raised at the
> >> 2013 Linux Storage Filesystem and MM Summit 2015 in San Francisco.[1]
> >>
> >>LSFMM: Page forking
> >>http://lwn.net/Articles/548091/
> >>
> >> This is ju
in is rmap.c, which addresses the issues raised at the
>>> 2013 Linux Storage Filesystem and MM Summit 2015 in San Francisco.[1]
>>>
>>>LSFMM: Page forking
>>>http://lwn.net/Articles/548091/
>>>
>>> This is just a FYI. An upcoming Tux3 report
015 in San Francisco.[1]
>>
>>LSFMM: Page forking
>>http://lwn.net/Articles/548091/
>>
>> This is just a FYI. An upcoming Tux3 report will be a tour of the page
>> forking design and implementation. For now, this is just to give a
>> general sense of wh
ested in is rmap.c, which addresses the issues raised at the
> 2013 Linux Storage Filesystem and MM Summit 2015 in San Francisco.[1]
>
>LSFMM: Page forking
>http://lwn.net/Articles/548091/
>
> This is just a FYI. An upcoming Tux3 report will be a tour of the page
> forking d
Filesystem and MM Summit 2015 in San Francisco.[1]
LSFMM: Page forking
http://lwn.net/Articles/548091/
This is just a FYI. An upcoming Tux3 report will be a tour of the page
forking design and implementation. For now, this is just to give a
general sense of what we have done. We heard there are
Hi!
I detected a problem with an Intel (imsm, ICH) RAID1 reported as "clean" by
Linux, while the BIOS and Windows claimed the RAID is in state "rebuild". This
was for an older kernel, and the bug had been reported to openSUSE bugzilla as
bug #902000. Anyone interested can find the details there
My name is Lewis Baach, Attorney at law. Sequel to your non response to my
previous email, I am re-sending this to you again thus; A deceased client of
mine, that shares the same last name as yours,who died as the result of a
heart-related condition on January 28th 2009. I have contacted you to
--
My name is Lewis,Sequel to your non response to my previous email, I
am re-sending this to you again thus; A deceased client of mine, that
shares the same last name as yours,left behind some certain funds
which I would like you to help distribute.
Regards,
Lewis Baach
--
To unsubscri
Hello,
I am asking for your partnership in re-profiling funds.
Regards,
Tan Kong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
Original Message
Subject: Re: [PATCH] net: check net.core.somaxconn sysctl values
Date: Wed, 31 Jul 2013 07:37:37 -0700
From: Eric Dumazet
To: Roman Gushchin
CC: David S. Miller , raise.s...@gmail.com,
ebied...@xmission.com, net...@vger.kernel.org, linux-kernel@vger.kernel
On Wed, 2012-07-25 at 15:38 +0200, Dan Luedtke wrote:
> New output option html5 writes validating HTML5 and adds
> CSS classes ready to be selected by third-party stylesheets.
An example, generated with the patched version of kernel-doc:
https://www.nonattached.net/lanyfs/doc-linux.php
Uses CSS
Hi Thierry
Thierry Merle wrote:
Hi Mauro,
Mauro Carvalho Chehab a écrit :
Em Ter, 2007-11-06 às 18:25 +0100, Markus Hirschmann escreveu:
Hello Kernel-Developer,
Module quickcam_messenger seems to be broken (tried 2.6.18 and 2.6.22)
on 2 different NSLU2 (ARM). Picture is attached. Same kern
Hi Mauro,
Mauro Carvalho Chehab a écrit :
> Em Ter, 2007-11-06 às 18:25 +0100, Markus Hirschmann escreveu:
>
>> Hello Kernel-Developer,
>>
>> Module quickcam_messenger seems to be broken (tried 2.6.18 and 2.6.22)
>> on 2 different NSLU2 (ARM). Picture is attached. Same kernel and module
>> can
Em Ter, 2007-11-06 às 18:25 +0100, Markus Hirschmann escreveu:
> Hello Kernel-Developer,
>
> Module quickcam_messenger seems to be broken (tried 2.6.18 and 2.6.22)
> on 2 different NSLU2 (ARM). Picture is attached. Same kernel and module
> can be used without any problems on x86 here. I don't ha
Hello Kernel-Developer,
Module quickcam_messenger seems to be broken (tried 2.6.18 and 2.6.22)
on 2 different NSLU2 (ARM). Picture is attached. Same kernel and module
can be used without any problems on x86 here. I don't have any ARM
device beside the NSLU2, so I cannot check.
The solution wa
Running FC6 (updated this am) the temp sensors GNOME applet works with
the kernel.org kernel, not the FC6 kernel. This has been true for a
while, and I've stopped chasing it, I don't really care right now, since
the sensors command works fine and that's what my daemon checks.
Using 2.6.23-rc8
Hello,
tcp_vegas produces division by zero kernel oopses in dom0 when running
a Xen-patched 2.6.16.28 kernel. I have tracked down the problem to
line #256 in tcp_vegas.c: presumably due to flaky Xen timing, the rtt
seems to get zero from time to time (adding 1 to the rtt variable
solves the probl
On Tue, 2007-01-09 at 13:33 +0200, Indrek Kruusa wrote:
> >> Is there vendor interest in unionfs?
>
> > MANY live cds seem to use it
>
>
> I'd like to add that also in embedded area (flash storage) the UnionFS
> helps in some cases.
I'll chime in as well. Ubuntu uses unionfs extensively for
>> Is there vendor interest in unionfs?
> MANY live cds seem to use it
I'd like to add that also in embedded area (flash storage) the UnionFS
helps in some cases.
thanks,
Indrek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PRO
This is just a heads-up to the folk who read LKML more than more specialized
Linux lists ... there's work afoot to clean up the I2C core and make it fit
the driver model better. (Some would say "overdue work...".)
The most interesting/useful part (IMO) is summarized in the appended message;
you c
No problem .. There are some other tests in there though .. I've been
using them for stress testing .. Apparently you don't need HRT on to use
them either.
Daniel
On Wed, 2005-08-31 at 11:19 -0400, Steven Rostedt wrote:
> On Wed, 2005-08-31 at 08:13 -0700, Daniel Walker wrote:
> > Sorry, that's
On Wed, 2005-08-31 at 08:12 -0700, Daniel Walker wrote:
> There is already a suite HRT of tests they include a nanosleep jitter
> test with 8 or 9 other tests..
>
> find them inside the hrt-support patch at http://high-res-timer.sf.net
Wow, they are hidden nicely :-)
I was looking for a tar ball
On Wed, 2005-08-31 at 08:13 -0700, Daniel Walker wrote:
> Sorry, that's http://high-res-timers.sf.net/
Thanks,
But I always seem to prefer to rewrite the wheel than to use one that
already exists. ;-) Probably explains why my cars are always in the
shop!
-- Steve
-
To unsubscribe from this li
Sorry, that's http://high-res-timers.sf.net/
Daniel
On Wed, 2005-08-31 at 11:01 -0400, Steven Rostedt wrote:
> Thomas,
>
> I just was wondering how the HR Timers were in the latest -rtX patch and
> wrote my own little jitter test using nanosleep. Here's the results:
>
> On vanilla 2.6.13-rc7-
There is already a suite HRT of tests they include a nanosleep jitter
test with 8 or 9 other tests..
find them inside the hrt-support patch at http://high-res-timer.sf.net
Daniel
On Wed, 2005-08-31 at 11:01 -0400, Steven Rostedt wrote:
> Thomas,
>
> I just was wondering how the HR Timers were
Thomas,
I just was wondering how the HR Timers were in the latest -rtX patch and
wrote my own little jitter test using nanosleep. Here's the results:
On vanilla 2.6.13-rc7-git1 (Yes I need to get over to 2.6.13)
# ./jitter
starting calibrate
finished calibrate: 2133.9060MHz 2133906034
time sle
Hi!
> >> > Code is not ready now => it can never be fixed? Thats quite a strange
> >> > conclusion to make.
> >>
> >> It seems there is an fundamental incompatibility with ACPI power off.
> >> As best as I can tell the normal case of device_suspend(PMSG_SUSPEND)
> >> works reasonably well in 2.6.
Hi.
On Wed, 2005-08-10 at 03:25, Eric W. Biederman wrote:
> Pavel Machek <[EMAIL PROTECTED]> writes:
>
> > Hi!
> >
> >> >> There as been a fair amount of consensus that calling
> >> >> device_suspend(...) in the reboot path was inappropriate now, because
> >> >> the device suspend code was too im
Pavel Machek <[EMAIL PROTECTED]> writes:
> Hi!
>
>> >> There as been a fair amount of consensus that calling
>> >> device_suspend(...) in the reboot path was inappropriate now, because
>> >> the device suspend code was too immature. With this latest
>> >> piece of evidence it seems to me that in
Hi!
> >> There as been a fair amount of consensus that calling
> >> device_suspend(...) in the reboot path was inappropriate now, because
> >> the device suspend code was too immature. With this latest
> >> piece of evidence it seems to me that introducing device_suspend(...)
> >> in kernel_powe
Pavel Machek <[EMAIL PROTECTED]> writes:
> Hi!
>
>> There as been a fair amount of consensus that calling
>> device_suspend(...) in the reboot path was inappropriate now, because
>> the device suspend code was too immature. With this latest
>> piece of evidence it seems to me that introducing de
101 - 200 of 228 matches
Mail list logo
