search for: vregs

Ok so that timeval makes no sense. We'll look into it. Aki > On October 24, 2016 at 12:22 AM Larry Rosenman <larryrtx at gmail.com> wrote: > > > doveadm(mrm): Debug: http-client: conn 127.0.0.1:9998 [1]: Got 200 response > for request [Req38: PUT http://localhost:9998/tika/] (took 296 ms + 8 ms in > queue) > doveadm(mrm): Panic: kevent(): Invalid argument >

According to man page, the only way it can return EINVAL (22) is either bad filter, or bad timeout. I can't see how the filter would be bad, so I'm guessing ts must be bad. Unfortunately I forgot to ask for it, so I am going to have to ask you run it again and run p ts if that's valid, then the only thing that can be bad if the file descriptor 23. Aki > On October 23, 2016 at

doveadm(mrm): Debug: http-client: conn 127.0.0.1:9998 [1]: Got 200 response for request [Req38: PUT http://localhost:9998/tika/] (took 296 ms + 8 ms in queue) doveadm(mrm): Panic: kevent(): Invalid argument Program received signal SIGABRT, Aborted. 0x00000008014e6f7a in thr_kill () from /lib/libc.so.7 (gdb) fr 6 #6 0x00000008011a3e49 in io_loop_handler_run_internal (ioloop=0x801c214e0) at

Hi! Can you try these two patches? Aki On 24.10.2016 08:48, Aki Tuomi wrote: > Ok so that timeval makes no sense. We'll look into it. > > Aki > >> On October 24, 2016 at 12:22 AM Larry Rosenman <larryrtx at gmail.com> wrote: >> >> >> doveadm(mrm): Debug: http-client: conn 127.0.0.1:9998 [1]: Got 200 response >> for request [Req38: PUT

I have already written about something similar (either on the list, or in private communication), so this may look familiar. Here's a scenario I'm observing: First, we have some innocent looking code: vreg(32) = x // vreg(32) = 32-bit register ... = vreg(32) [...] vreg(64).low_half = vreg(32) // vreg(64) = 64-bit register [...] then, after register

On 2019-11-13 09:30, Andrew Bartlett wrote: > Regarding your problem, on linux I use lslocks to debug from here, you > can normally work out which process is holding the lock, which lock it > is waiting on (if any, marked with a *) and gdb that to work out what > is the matter with it, and perhaps why it is in that situation. Hmm... I have no lslocks on FreeBSD; will lsof do? In

Hi! We found some problems with those patches, and ended up doing slightly different fix: https://github.com/dovecot/core/compare/3e41b3d%5E...cca98b.patch Aki On 24.10.2016 10:17, Aki Tuomi wrote: > Hi! > > Can you try these two patches? > > Aki > > > On 24.10.2016 08:48, Aki Tuomi wrote: >> Ok so that timeval makes no sense. We'll look into it. >>

On 2019-11-11 09:41, Andrew Bartlett wrote: >>> and what is the full backtrace on that tdbbackup? >> >> You mean: compile with debug symbols, attach gdb and get stack trace? >> If so, I'll do it, but I'll need some time. > > Yes, that's what I need. Please, find it below: (gdb) bt #0 0x0000000800fcdab8 in _fcntl () from /lib/libc.so.7 #1

I hope I'm sending this report to the right place. I recently upgraded the rsync binaries in a bunch of our Solaris 9 systems from rsync 2.6.9 to rsync 3.0.5 . I have a script that runs in each machine that syncs the file systems from an active drive to a backup drive. Wihtin 3 days, this script had hung in two of the ~20 hosts that I had updated with the new rsync. Those two hosts

that seems to fix this kevent() problem, but I got the following lucene assert. Is that because of previous fails? Also, while I have your attention, is fts_autoindex supposed to work accross NAMESPACES? doveadm(mrm): Debug: Mailbox LISTS/vse-l: Opened mail UID=39483 because: fts indexing doveadm(mrm): Debug: Mailbox LISTS/vse-l: Opened mail UID=39484 because: fts indexing doveadm(mrm): Debug:

...ferent input MIR >> files. We also do this to reduce the chances that a difference in >> previously def-use walks will affect the vreg renaming for subsequent >> walks. This skipping step could be thought of as a kind of vreg number >> reckoning: we skip modulo n vregs so that we are likely to land on the same >> vreg for two different files. >> >> >> >> This approach is completely agnostic of ISA specific semantics so it >> should work for any target. >> >> >> Current status: >> >> At the momen...

On Jan 14, 2013, at 12:56 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > I have already written about something similar (either on the list, or in private communication), so this may look familiar. > > Here's a scenario I'm observing: > > First, we have some innocent looking code: > vreg(32) = x // vreg(32) = 32-bit register >

...on the same vreg number for two different input MIR files. We also do this to reduce the chances that a difference in previously def-use walks will affect the vreg renaming for subsequent walks. This skipping step could be thought of as a kind of vreg number reckoning: we skip modulo n vregs so that we are likely to land on the same vreg for two different files. This approach is completely agnostic of ISA specific semantics so it should work for any target. Current status: At the moment we have a standalone llvm tool that uses a single pass to do the above described transforma...

When we discussed this our line of thought was like this: - LLVM IR already uses %name for SSA values which is closer to what a vreg is than to what a physreg is. It would be neat to draw that parallel to llvm IR. - We wanted another sigil for physregs so they are easy to differentiate from vregs to allow people to differentiate vregs/physregs even if they don't know all the physreg names of a particular architecture. - The $ was somewhat arbitrary because we had few characters left without a meaning in .mir and I found the ampersand better matches symbol names than physregs: - The ampe...

Hi A few of us have discussed enhancing the MIR vregs to include support for named-vregs. At the moment named regs are only supported for physical registers and number regs are reserved for vregs. We've decided that to properly implement a syntax for MIR named vregs we first need to reorganized the sigils used for physical registers and external...

...our line of thought was like this: > > - LLVM IR already uses %name for SSA values which is closer to what a vreg > is than to what a physreg is. It would be neat to draw that parallel to > llvm IR. > - We wanted another sigil for physregs so they are easy to differentiate > from vregs to allow people to differentiate vregs/physregs even if they > don't know all the physreg names of a particular architecture. > - The $ was somewhat arbitrary because we had few characters left without > a meaning in .mir and I found the ampersand better matches symbol names > than...

Can we use %% for vregs? Seems slightly easier to remember %/%% than $/%. Also, %eax and $some_symbol are already familiar from typical assembly syntax and we probably don't want to break that association. It's all a bikeshed, but being more consistent with assembly is probably a win. -- Sean Silva On Dec 25, 2...

...gAlloc? > > This should definitely be done during regalloc. It seems that LiveIntervals will need to be taught about the new form of virtual registers. Hrm. I'm going to try to break this work up as much as possible. Also, do you see any problems with using the following class for vregs? It makes it possible to not have to go through and update every call site for a large number of functions. class vreg : public std::pair<unsigned,unsigned> { public: vreg(unsigned f) : std::pair<unsigned,unsigned>(f, 0) {} }; If this definition is OK, where should it live? It...

...g regalloc. > > It seems that LiveIntervals will need to be taught about the new form of > virtual registers. Hrm. I'm going to try to break this work up as much as > possible. Splitting up the work is good :) > Also, do you see any problems with using the following class for vregs? It > makes it possible to not have to go through and update every call site for a > large number of functions. > > class vreg : public std::pair<unsigned,unsigned> { > public: > vreg(unsigned f) : std::pair<unsigned,unsigned>(f, 0) {} > }; > > If this defi...

> I think pseudo-instructions should also define isPseudo = 1 Ah yes, thank you. > I expect that before your custom inserter, the value produced by your pseudo instruction was in a vreg. You just have to reuse this vreg to put the result of your "stuff". > If you run llc with --print-before-all, you should be able to see the actual sequence. That's exactly my problem.