search for: patchworks

https://bugzilla.netfilter.org/show_bug.cgi?id=1009 Pablo Neira Ayuso <pablo at netfilter.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #2 from Pablo Neira Ayuso <pablo at netfilter.org> --- There are already kernel

Hi all, The GlusterFS development team now uses Patchwork for managing patches. Both internal development patches and public submissions, and their status can be viewed at http://patches.gluster.com. Submitting a git formatted patch to gluster-devel at nongnu.org (with the word PATCH in the subject) will get the patch sucked into patchwork and its progress can be tracked from the web UI then

Hello everyone, I''ve asked the kernel.org admins to setup patchwork tracking for the btrfs mailing list. This is a pretty cool tool that tracks patches sent to the list and makes it easy to download and apply them. I''ll be the main consumer of this, but you can check out the interface at: http://patchwork.kernel.org/project/linux-btrfs/list/ -chris -- To unsubscribe from

Hi! I haven't had much luck asking around in IRC, so I figured this would be the next place to start. As many of you know I've been working on getting nouveau into good shape with igt-gpu-tools, now that we've finally finished implementing CRC support thannks to nvidia's help. I should note that the patches for this have been accepted into nouveau, Ben's just working on

Hi, I own a Yunto-Q 700 (made 2000 by online usv systems) and a Yunto-Q 1200 (made 2010). They both work with blazer_ser, but didn't shutdown. I straced the proprietary driver and found the ups expected the return time given with _5_ digits instead of 4, else the command was ignored by the ups. And the Yunto don't send rating/manufacturer informations. I don't want to commit this to

On Tue, Jul 30, 2019 at 11:54:53AM -0400, Michael S. Tsirkin wrote: > On Tue, Jul 30, 2019 at 05:43:29PM +0200, Stefano Garzarella wrote: > > This series tries to increase the throughput of virtio-vsock with slight > > changes. > > While I was testing the v2 of this series I discovered an huge use of memory, > > so I added patch 1 to mitigate this issue. I put it in this

On 03/20/2017 01:20 PM, PJ Welsh wrote: > No warning, but still just reboots with no notice. > Is there any other system info you need? > Thanks > PJ > Try the new 4.9.16-24 packages there now. (reworked the config based on a fedora kernel) > On Mon, Mar 20, 2017 at 11:47 AM, Johnny Hughes <johnny at centos.org > <mailto:johnny at centos.org>> wrote: >

https://bugzilla.netfilter.org/show_bug.cgi?id=1114 Bug ID: 1114 Summary: set: Can't add elements after flushing a full set with size description Product: nftables Version: unspecified Hardware: x86_64 OS: Ubuntu Status: NEW Severity: normal Priority: P5

mode_fixup function for encoder drivers became optional with patch http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com This patch set nukes all the dummy mode_fixup implementations. (made on top of Daniel topic/drm-misc branch) Changes v1->v2: incorporated Daniel comments * added signed-off-by line to all patches * threading enabled due to

mode_fixup function for encoder drivers became optional with patch http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com This patch set nukes all the dummy mode_fixup implementations. (made on top of Daniel topic/drm-misc branch) Changes v1->v2: incorporated Daniel comments * added signed-off-by line to all patches * threading enabled due to

Hi, Could CentOS kernel keepers apply following patch on current kernel? http://patchwork.ozlabs.org/patch/95785/ (Current as: 2.6.32-71.29.1.el6.x86_64) With the patch applied, and a ".local" kernel built, I get 30% higher throughput with vmxnet3 in my IP routing node, than when using e1000 "card" at the same. Without the patch, the TCP flow over vmxnet3 driver on a

> -----Original Message----- > From: Takashi Iwai <tiwai at suse.de> > Sent: Thursday, August 15, 2019 9:57 AM > To: Alex Deucher > Cc: Karol Herbst; Limonciello, Mario; nouveau; Rafael J . Wysocki; LKML; dri-devel; > Linux ACPI Mailing List; Alex Hung; Ben Skeggs; David Airlie > Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to >

On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > smp_read_barrier_depends, smp_store_release and smp_load_acquire match > the asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h instead. > This statement doesn't fit MIPS barriers variations. Moreover, there is a reason

On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > smp_read_barrier_depends, smp_store_release and smp_load_acquire match > the asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h instead. > This statement doesn't fit MIPS barriers variations. Moreover, there is a reason

On Thu, 2018-09-06 at 17:43 -0400, Lyude Paul wrote: > Since we're about to use this in nouveau_backlight.c. Same thing as > DRM_WARN_ONCE, DRM_INFO_ONCE, etc... Can you redefine this in terms of the patches I submitted instead? https://lore.kernel.org/patchwork/patch/979598/ https://lore.kernel.org/patchwork/patch/979601/ > Signed-off-by: Lyude Paul <lyude at redhat.com>

On Thu, Jul 12, 2018 at 11:26:12AM +0800, Jason Wang wrote: > > > On 2018?07?11? 19:59, Michael S. Tsirkin wrote: > > On Wed, Jul 11, 2018 at 01:12:59PM +0800, Jason Wang wrote: > > > > > > On 2018?07?11? 11:49, Tonghao Zhang wrote: > > > > On Wed, Jul 11, 2018 at 10:56 AM Jason Wang <jasowang at redhat.com> wrote: > > > > >

On Thu, Jul 12, 2018 at 11:26:12AM +0800, Jason Wang wrote: > > > On 2018?07?11? 19:59, Michael S. Tsirkin wrote: > > On Wed, Jul 11, 2018 at 01:12:59PM +0800, Jason Wang wrote: > > > > > > On 2018?07?11? 11:49, Tonghao Zhang wrote: > > > > On Wed, Jul 11, 2018 at 10:56 AM Jason Wang <jasowang at redhat.com> wrote: > > > > >

On Tue, Jul 30, 2019 at 05:43:29PM +0200, Stefano Garzarella wrote: > This series tries to increase the throughput of virtio-vsock with slight > changes. > While I was testing the v2 of this series I discovered an huge use of memory, > so I added patch 1 to mitigate this issue. I put it in this series in order > to better track the performance trends. > > v5: > - rebased

This series tries to increase the throughput of virtio-vsock with slight changes. While I was testing the v2 of this series I discovered an huge use of memory, so I added patch 1 to mitigate this issue. I put it in this series in order to better track the performance trends. v5: - rebased all patches on net-next - added Stefan's R-b and Michael's A-b v4:

This series tries to increase the throughput of virtio-vsock with slight changes. While I was testing the v2 of this series I discovered an huge use of memory, so I added patch 1 to mitigate this issue. I put it in this series in order to better track the performance trends. v5: - rebased all patches on net-next - added Stefan's R-b and Michael's A-b v4: