similar to: [PATCH 08/16] btrfs: nuke pdflush from comments

We use set_bit() to assign ordered extent''s flags, but in the related tracepoint we don''t do the same thing, which makes the trace output not to parse flags correctly. Also, since the flags are bits stuff, we change to use __print_flags with a ''delim'' instead of __print_symbolic. Signed-off-by: Liu Bo <bo.li.liu@oracle.com> ---

2011/10/26 Sage Weil <sage@newdream.net>: > On Wed, 26 Oct 2011, Christian Brunner wrote: >> >> > Christian, have you tweaked those settings in your ceph.conf?  It would be >> >> > something like ''journal dio = false''.  If not, can you verify that >> >> > directio shows true when the journal is initialized from your osd log?

Has anyone hit this bug yet? I just hit it yesterday. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150653 -- Computer House Calls, Networks, Security, Web Design: http://www.emmanuelcomputerconsulting.com What businesses are in Brunswick, Maryland? Check Brunswick First! http://www.checkbrunswickfirst.com My "Foundation" verse: Isa 54:17 No weapon that is formed against thee

Hi. A friend of mine was doing real-time video decoding on Fedora Core 13 and he had a performance glitch (1/2 a second freeze) every 5-10 seconds. "top" showed flush-253:0 process at the moment of the freeze. Major device number 253 corresponds to device-mapper. I advised my friend to re-install his FC13 without LVM, to see if the glitch is related to LVM. After re-installing FC13

To make Btrfs code more robust, several return value checks where memory allocation can fail are introduced. I use BUG_ON where I don''t know how to handle the error properly, which increases the number of using the notorious BUG_ON, though. Signed-off-by: Yoshinori Sano <yoshinori.sano@gmail.com> --- fs/btrfs/compression.c | 6 ++++++ fs/btrfs/extent-tree.c | 4 ++++

Hi, I''ve discovered that some btrfs code doesn''t check whether kmalloc() call succeeded. I poorly understand what this code does and how it can be changed, maybe it would be happy with __GFP_NOFAIL. Also there are BUG_ON() after kmalloc()''s, if they could be changed not to panic it would be great. --- ./fs/btrfs/compression.c 2010-07-06 16:45:48.000000000 +0400 +++

I noticed that if the free space cache has an error writing out it''s data it won''t actually error out, it will just carry on. This is because it doesn''t check the return value of btrfs_wait_ordered_range, which didn''t actually return anything. So fix this in order to keep us from making free space cache look valid when it really isnt. Thanks, Signed-off-by:

please pull git://charm.itp.tuwien.ac.at/mattems/klibc/.git maks for the change: maximilian attems: [klibc] simplify nuke fixes boot failures due to unexpected error returns usr/utils/nuke.c | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/usr/utils/nuke.c b/usr/utils/nuke.c index 01b300f..9470bcf 100644 --- a/usr/utils/nuke.c +++

gets assigned a value without any further usage. Signed-off-by: maximilian attems <max at stro.at> --- usr/kinit/ipconfig/main.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/usr/kinit/ipconfig/main.c b/usr/kinit/ipconfig/main.c index b392e6a..d912f6d 100644 --- a/usr/kinit/ipconfig/main.c +++ b/usr/kinit/ipconfig/main.c @@ -484,7 +484,7 @@ static int

On 07/25/2017 01:31 PM, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. > > The only special case is nouveau and tda988x which used one function > for both legacy modeset code and -nv50 atomic world instead of 2 > vtables. But amounts to exactly the same. > > v2: Rebase over the panel/brideg refactorings in stm/ltdc. s/brideg/bridge

On Tue, 2017-07-25 at 10:01 +0200, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. > > The only special case is nouveau and tda988x which used one function > for both legacy modeset code and -nv50 atomic world instead of 2 > vtables. But amounts to exactly the same. > > v2: Rebase over the panel/brideg refactorings in stm/ltdc. > >

Hi Ville. Nice patch - and diffstat looks good: > 63 files changed, 217 insertions(+), 392 deletions(-) There is an item in the Documentation/gpu/todo.rst that describes this. Could you drop this from todo.rst in this patch too. > diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c > index bb6528b01cd0..6dca5344c0b3 100644 > ---

Full_Name: Bj?rn-Helge Mevik Version: 2.1.0 OS: GNU/Debian 3.0 Linux Submission from: (NULL) (80.111.104.162) In Appendix B R coding standards of the Writing R Extensions manual, Emacs/ESS users are encouraged to use (add-hook 'ess-mode-hook (lambda () (ess-set-style 'C++) ;; [snip] (add-hook 'local-write-file-hooks

They are not used in the regression test suite anymore, and are not even built in CMake build tree. -- Alexey Samsonov, Mountain View, CA -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140430/c015da10/attachment.html>

>> Ouch, indeed... Is it ok it has no build rules? > > I think that it should have build rules. If nothing else, can you file a bug report on this? It is building using configure + make. In good old days the perfect shuffle tables for PPC were generated through the normal build process like .td files. However, this was pretty useless - they do not change and thus perfectshuffle was

On Wed, Apr 30, 2014 at 1:37 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Alexey Samsonov" <samsonov at google.com> > > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Wednesday, April 30, 2014 3:30:12 PM > > Subject: [LLVMdev] Is it ok to nuke fpcmp and

On Fri, 03 Apr 2020, abhinavk at codeaurora.org wrote: > On 2020-04-03 13:39, Ville Syrjala wrote: >> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c >> index fec1c33b3045..e3d5f011f7bd 100644 >> --- a/drivers/gpu/drm/drm_modes.c >> +++ b/drivers/gpu/drm/drm_modes.c >> @@ -759,9 +759,7 @@ int drm_mode_vrefresh(const struct drm_display_mode

On Wed, May 7, 2014 at 8:28 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Anton Korobeynikov" <anton at korobeynikov.info> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: "Alexey Samsonov" <samsonov at google.com>, "LLVM Developers Mailing > List" <llvmdev at

To make Btrfs code more robust, several return value checks where memory allocation can fail are introduced. I use BUG_ON where I don''t know how to handle the error properly, which increases the number of using the notorious BUG_ON, though. Signed-off-by: Yoshinori Sano <yoshinori.sano@gmail.com> --- fs/btrfs/compression.c | 6 ++++++ fs/btrfs/extent-tree.c | 2 ++

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) Carlos Palminha (17): drm/virtio: removed optional dummy encoder mode_fixup function. drm/udl: removed optional