search for: upconvert

This email is also sent to cluster-devel at redhat.com. Since this issue is about both dlm and ocfs2, I send the email here to look for help from upstream. This is an already known issue. on ocfs2 with user space cluster stack, run the test script from http://people.redhat.com/~teigland/make_panic on the mounted ocfs2 volume from 2 nodes simultaneously, the access to ocfs2 volume on both nodes

Rodger Combs wrote: > I've run into some issues using Opus with source files in channel layouts > other than the default 8. For instance, 2.1 isn't supported, so I have to > either downconvert to 2.0 or upconvert to 5.1 (which usually involves adding > empty channels, which prevents the playback device from upconverting to the > native layout). > To address this, I've put together an initial draft of an I-D I'd like to > run by this list for feedback. > Here's the RFCXML: > And...

David, So here are the two patches. Remove all patches that you have and apply these. The first one is straight forward. The second one will hopefully fix the livelock issue you have been encountering. People reviewing the patches should note that the second one is slightly different than the one I posted earlier. It removes the BUG_ON in the if condition where we jump to update_holders. The

I've run into some issues using Opus with source files in channel layouts other than the default 8. For instance, 2.1 isn't supported, so I have to either downconvert to 2.0 or upconvert to 5.1 (which usually involves adding empty channels, which prevents the playback device from upconverting to the native layout). To address this, I've put together an initial draft of an I-D I'd like to run by this list for feedback. Here's the RFCXML: And the resulting TXT: This is...

...<martin.leese at stanfordalumni.org> wrote: > > Rodger Combs wrote: > >> I've run into some issues using Opus with source files in channel layouts >> other than the default 8. For instance, 2.1 isn't supported, so I have to >> either downconvert to 2.0 or upconvert to 5.1 (which usually involves adding >> empty channels, which prevents the playback device from upconverting to the >> native layout). >> To address this, I've put together an initial draft of an I-D I'd like to >> run by this list for feedback. >> Here's...

...ot;, ".f16\t$Sd, $Sn, $Sm", [(set HPR:$Sd, (fadd HPR:$Sn, HPR:$Sm))]>, // <~~~ new match rule using HPR This is straightforward business so far, but I already learned the hard way that the conversion are the tricky ones, so I repeat this for an f16 -> f32 upconvert: def VCVTBHS: ASuI<0b11101, 0b11, 0b0010, 0b01, 0, (outs SPR:$Sd), (ins HPR:$Sm), IIC_fpCVTSH, "vcvtb", ".f32.f16\t$Sd, $Sm", [(set SPR:$Sd, (fpextend HPR:$Sm))]>, // <~~~~ new match rule using HPR and SPR Require...

Thanks a lot for the suggestions! I will look into using vld1/vst1, sounds good. I am custom lowering the bitcasts, that's now the only place where FP_TO_FP16 and FP16_TO_FP nodes are created to avoid inefficient code generation. I will double check if I can't achieve the same without using these nodes (because I really would like to get completely rid of them). Cheers, Sjoerd.

...ot;, ".f16\t$Sd, $Sn, $Sm", [(set HPR:$Sd, (fadd HPR:$Sn, HPR:$Sm))]>, // <~~~ new match rule using HPR This is straightforward business so far, but I already learned the hard way that the conversion are the tricky ones, so I repeat this for an f16 -> f32 upconvert: def VCVTBHS: ASuI<0b11101, 0b11, 0b0010, 0b01, 0, (outs SPR:$Sd), (ins HPR:$Sm), IIC_fpCVTSH, "vcvtb", ".f32.f16\t$Sd, $Sm", [(set SPR:$Sd, (fpextend HPR:$Sm))]>, // <~~~~ new match rule using HPR and SPR Require...

Hi all, I'm trying to understand and quantify network traffic for a 32 node high performance OCFS2 installation. Part of what I'm doing is attempting to size the network hardware requirements. To do this I need some help understanding the kinds and amounts of traffic generated during "normal" use. Once populated, the system will have a very high READ to WRITE op ratio. I

...rt_trans ocfs2: Remove unused old_id in ocfs2_commit_cache ocfs2: Add some trace log for orphan scan ocfs2: dlm dlmlock_remote needs to account for remastery ocfs2: dlm Take inflight reference count for remotely mastered resrouce too ocfs2: Wakeup down convert thread just after clearing OCFS2-LOCK-UPCONVERT-FINISHING ocfs2: dlm Hard code the values for enums ocfs2: dlm Minor cleanup ocfs2: dlm Cleanup dlmdebug.c ocfs2: dlm make existing convertion precedent over new lock ocfs2: dlm Cleanup mlogs in dlmthread.c dlmast.c and dlmdomain.c ocfs2: Treat writes as new when holes span across page boundary ocf...

On Tue, Nov 4, 2014 at 2:57 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 4, 2014, at 7:04 AM, Robinson, Paul < > Paul_Robinson at playstation.sony.com> wrote: > > >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Sean Silva > >> > >> You haven't established that you really need

...would raise large and definite bitcode versioning problems. > On the other hand, Android RenderScript does use LLVM bitcode as its portable storage format. We have bitcode writers stretching back to 2 funky versions of LLVM 2.9 (really pre-3.0). The default writer for us is based on 3.2, and we upconvert any pre-3.x bitcode that we have to 3.2 (or something more modern if we can). There have definitely been issue in the past (attribute changes, removal/update of opcodes, etc.), but we have always found a way to adapt. We are definitely aware that any 4.x change could break our readers/writers, alth...

This patch plugs a race between the downconvert thread and an unlock ast message. Specifically, after the downconvert worker has done its task, the dc thread needs to check whether an unlock ast made the downconvert moot. Reported-by: David Teigland <teigland at redhat.com> Signed-off-by: Sunil Mushran <sunil.mushran at oracle.com> Acked-by: Mark Fasheh <mfasheh at sus.com> ---

Hi, we have recently started to use ocfs2 on some RHEL 5.5 servers (ocfs2-1.4.7) Some days ago, two servers sharing an ocfs2 filesystem, and with quite virtual services, stalled, in what it seems on ocfs2 issue. This are the lines in their messages files: =====node heraclito (0)======================================== /Dec 4 09:15:06 heraclito kernel: o2net: connection to node parmenides

Please review the list of patches being applied to the ocfs2 1.4 tree. All patches list the mainline commit hash. Thanks Sunil

We're using a storage solution involving two SunFire X4500 servers using DRBD to replicate a 15TB partition across the network with ocfs2 on top. We're sharing the partition from one server over NFS and the other is mounted read-only at present. The DBRD backing store is software RAID 60 on 40 disks. We've been seeing periodic issues whereby our NFS clients (Debian Lenny) are very