search for: gamari

...Bug ID: 67878 Assignee: nouveau at lists.freedesktop.org Summary: Hardware freeze after resume from suspend QA Contact: xorg-team at lists.x.org Severity: critical Classification: Unclassified OS: Linux (All) Reporter: bgamari at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: Driver/nouveau Product: xorg Created attachment 83798 --> https://bugs.freedesktop.org/attachment.cgi?id=83798&action=edit dmesg output from boot to attem...

Rafael Espíndola <rafael.espindola at gmail.com> writes: >> I suspected this was the case. Is a rework of prefix support likely to >> make it in for 3.5? >> > > Unlikely. It has branched already and I don't know of anyone working on it. > Fair enough. If there is consensus around a reasonably concrete proposal I would be happy to put together a patch

...k it's a reasonable proposal, but obviously I floated it. :) Let's try to get a second opinion. Again, it's a syntax something like: define void @foo() prefix [i8* x 2] { i8* @a, i8* @b } prologue [i8 x 4] c"\xde\xad\xbe\xef" { ret void } On Thu, Aug 21, 2014 at 1:58 PM, Ben Gamari <bgamari.foss at gmail.com> wrote: > Ben Gamari <bgamari.foss at gmail.com> writes: > > > Rafael Espíndola <rafael.espindola at gmail.com> writes: > > > >>> I suspected this was the case. Is a rework of prefix support likely to > >>> make...

Rafael Espíndola <rafael.espindola at gmail.com> writes: > On 25 May 2014 21:29, Ben Gamari <bgamari.foss at gmail.com> wrote: >> Sure. I think the only reason our use of aliases worked previously was >> that the optimizer elided them long before they could make it into an >> object file. > > If that is the case, you should be able to just directly replace al...

On Sun, 11 Apr 2010 18:03:00 +0300, Avi Kivity <avi@redhat.com> wrote: > On 04/09/2010 05:56 PM, Ben Gamari wrote: > > On Mon, 29 Mar 2010 00:08:58 +0200, Andi Kleen<andi@firstfloor.org> wrote: > > > >> Ben Gamari<bgamari.foss@gmail.com> writes: > >> ext4/XFS/JFS/btrfs should be better in this regard > >> > >> > > I am using bt...

Rafael Espíndola <rafael.espindola at gmail.com> writes: > Now that aliases can have any expressions, can't you use something like > > @data = private global [2 x i32] [i32 42, i32 43] > @symbol = alias getelementptr ([2 x i32]* @data, i32 0, i32 1) > > This produces > > .Ldata: > .long 42 # 0x2a > .long 43

Chris Mason on 10 Feb 13:17: > Excerpts from Ben Gamari''s message of 2011-02-09 21:52:20 -0500: > > Over the last several months there have been many claims regarding > > the release of the rewritten btrfsck. Unfortunately, despite > > numerous claims that it will be released Real Soon Now(c), I have > > yet to see even...

Rafael Espíndola <rafael.espindola at gmail.com> writes: > On 25 May 2014 21:29, Ben Gamari <bgamari.foss at gmail.com> wrote: >> >> For a while now LLVM has started rejecting aliases referring to things >> other than definitions[1]. > > We started checking for it. Aliases are just another label in an > object file. The linker itself doesn't know they...

Rafael Espíndola <rafael.espindola at gmail.com> writes: > On 20 July 2014 18:18, Ben Gamari <bgamari.foss at gmail.com> wrote: >> Rafael Espíndola <rafael.espindola at gmail.com> writes: >> >>> Now that aliases can have any expressions, can't you use something like >>> >>> @data = private global [2 x i32] [i32 42, i32 43] >>>...

Peter: Please feel free to correct me if there are any inaccuracies below. For a while now LLVM has started rejecting aliases referring to things other than definitions[1]. This unfortunately breaks GHC's LLVM code generator which referes to most symbols through aliases. This is done in two situations, 1. As place-holders for external symbols. As the code generator does not

...on main, so I confused problems with gdb with problems with the program I'm trying to debug! Incidentally, my remark about mingw-w64 problems in other communities alluded to the Haskell development community, where an ABI incompatibility was discovered about a year ago. It is discussed by Ben Gamari here https://gitlab.haskell.org/ghc/ghc/-/issues/19945. Dominick On Wed, Jan 18, 2023 at 12:56 PM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > On 1/18/23 17:39, Dominick Samperi wrote: > > Thanks, > > But this didn't work. It installs msys2 along with lots of...

...[2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063909.html [3] http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-February/047514.html [4] http://www.haskell.org/pipermail/ghc-devs/2013-September/002565.html [5] https://ghc.haskell.org/trac/ghc/ticket/4213#comment:12 [6] https://github.com/bgamari/llvm/compare/symbol-offset -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140527/d604a681/attachment.sig>

...e debug info (for R or packages, depending on what you need to debug). > > Incidentally, my remark about mingw-w64 problems in other communities > alluded to the Haskell development > community, where an ABI incompatibility was discovered about a year > ago. It is discussed by Ben Gamari here > https://gitlab.haskell.org/ghc/ghc/-/issues/19945. From a quick look it seems to be an incompatibility between two libraries implementing POSIX regular expressions, essentially a name clash, they just need to make sure to consistently use one of them. It is not a problem of MinGW-W64...

While going through an old todo list I found that these patches had fallen by the way-side. About a year ago I initiated a discussion[1] with the Linux kernel folks regarding the lack of any useable fadvise support on the kernel side. As a result, I was observing extremely poor performance on my server after backup as executable pages were being swapped out in favor of data waiting to be flushed

I've recently been trying to track down the root cause of my server's persistent issue of thrashing horribly after being left inactive. It seems that the issue is likely my nightly backup schedule (using rsync) which traverses my entire 50GB home directory. I was surprised to find that rsync does not use fadvise to notify the kernel of its use-once data usage pattern. It looks like a

Warning for kernel folks: I'm not much of an mm person; let me know if I got anything horribly wrong. Many folks use rsync in their nightly backup jobs. In these applications, speed is of minimal concern and should be sacrificed in order to minimize the effect of rsync on the rest of the machine. When rsync is working on a large directory it can quickly fill the page cache with written data,

...kages, depending on what you need to debug). >> >> >> Incidentally, my remark about mingw-w64 problems in other communities >> alluded to the Haskell development >> community, where an ABI incompatibility was discovered about a year ago. >> It is discussed by Ben Gamari here >> https://gitlab.haskell.org/ghc/ghc/-/issues/19945. >> >> From a quick look it seems to be an incompatibility between two libraries >> implementing POSIX regular expressions, essentially a name clash, they just >> need to make sure to consistently use one of the...

On 1/18/23 17:39, Dominick Samperi wrote: > Thanks, > > But this didn't work. It installs msys2 along with lots of other > stuff, and gdb would not start as before (missing DLL's). > > Then I tried to run the command you suggested again, and there was a > warning from the package manager about a cycle detected, but now gdb > starts with the following messages...

Firstly, do you need "main.dsp" defined as an external symbol, or can all external references go via "main"? If the answer is the latter, that will make the solution simpler. If only the latter, you will need to make a change to LLVM here: http://llvm-cs.pcc.me.uk/lib/CodeGen/AsmPrinter/AsmPrinter.cpp#650 Basically you would need to add a hook to the TargetLoweringObjectFile

We have a disk array behind two external SATA port multipliers (four disks on each multiplier) which has been running btrfs (RAID 1 for both data and metadata). Unfortunately, earlier today it seems one of the SATA cables came loose, resulting in the kernel (2.6.37) eventually OOPSing although apparently not before writing quite a bit of data. Upon reboot, I was met with the dreaded,