On Mon, Apr 13, 2015 at 04:05:28PM +, Eric Van Hensbergen wrote:
Well, technically fid 3 isn't 'open', only fid 2 is open - at least
according to the protocol. fid 3 and fid 2 are both clones of fid 1.
However, thanks for the alternative workaround. If you get a chance, can
you check
immediately
after that. Easier to just feed that string to nd_set_link() and _not_
kfree it until -put_link() (which becomes kfree_put_link() in that case).
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
---
diff --git a/fs/9p/v9fs.h b/fs/9p/v9fs.h
index 099c771..48d35d8 100644
--- a/fs/9p/v9fs.h
On Sun, Apr 12, 2015 at 12:42:35PM -, Eric Van Hensbergen wrote:
In other words, it only uses the open fd to derrive a path and then
executes the getattr off of that path. If that path no longer exists
(because of unlink or remove) then you are hosed. In my understanding, the
work
On Tue, Jul 08, 2014 at 05:33:16PM +0100, Peter Maydell wrote:
Incidentally, combination of --enable-gprof and (default) --enable-pie
won't build - it dies with ld(1) complaining about relocs in gcrt1.o.
This sounds like a toolchain bug to me :-)
Debian stable/amd64, gcc 4.7.2, binutils
On Wed, Jul 09, 2014 at 08:14:12AM -0700, Richard Henderson wrote:
On 07/08/2014 10:47 PM, Al Viro wrote:
So env-fpcr_flush_to_zero = env-fpcr_dnod env-fpcr_undz; is another
bug - needs s/dnod/unfd/ there...
That's exactly what I was looking at, thanks.
BTW, that (unimplementeds being
On Mon, Jul 07, 2014 at 11:03:08PM -0700, Richard Henderson wrote:
On 07/07/2014 09:20 PM, Al Viro wrote:
and I'm reasonably sure that this is what they did internally. You are
proposing to do 4 cases in all their messy glory in qemu itself...
Yes. Primarily because we *have* to do so
On Tue, Jul 08, 2014 at 08:32:55PM +0100, Peter Maydell wrote:
On 8 July 2014 18:20, Al Viro v...@zeniv.linux.org.uk wrote:
On Tue, Jul 08, 2014 at 05:33:16PM +0100, Peter Maydell wrote:
Incidentally, combination of --enable-gprof and (default) --enable-pie
won't build - it dies with ld
On Tue, Jul 08, 2014 at 09:05:10AM +0100, Peter Maydell wrote:
The code we have currently may well be buggy, but the correct
It is ;-/ We set TARGET_FPE_FLTINV unconditionally there. BTW, what's
the reason why all these cpu_loop() instances can't go into
linux-user/arch/something? Is that
On Tue, Jul 08, 2014 at 09:59:33PM -0700, Richard Henderson wrote:
On 07/08/2014 01:20 PM, Al Viro wrote:
Aha... So you've caught that one already... I've looked at your branch;
AFAICS, the only thing missing there is treating stores to FPCR.DNOD in
system mode as not implemented (which
On Tue, Jul 08, 2014 at 07:54:36AM +0100, Al Viro wrote:
On Mon, Jul 07, 2014 at 11:03:08PM -0700, Richard Henderson wrote:
On 07/07/2014 09:20 PM, Al Viro wrote:
and I'm reasonably sure that this is what they did internally. You are
proposing to do 4 cases in all their messy glory
On Tue, Jul 08, 2014 at 11:12:20AM -0700, Richard Henderson wrote:
On 07/08/2014 09:13 AM, Al Viro wrote:
Frankly, I suspect that it's better to have qemu-system-alpha behave like
the actual hardware does (including FPCR.DNOD can't be set) and keep the
linux-user behaviour
On Tue, Jul 08, 2014 at 12:04:10PM -0700, Richard Henderson wrote:
Just one thing - 0x1f will make 32bit hosts whine about integer
constant being too large. So will 0x1ful, unfortunately - it
really ought to be ull.
I did use ull on the branch.
Aha... So
On Mon, Jul 07, 2014 at 07:11:58AM -0700, Richard Henderson wrote:
A couple of points here:
1) We should never raise this in user-only mode. In that mode, we emulate the
whole fpu stack, all the way through from HW to the OS completion handler.
How is that different from other cases where
On Mon, Jul 07, 2014 at 09:20:28AM -0700, Richard Henderson wrote:
How is that different from other cases where we have an exception raised
by an fp operation?
In all other cases we know we're going to send SIGFPE. That's either through
a
non /S insn which the kernel wouldn't touch, or
On Sat, Jul 05, 2014 at 02:40:55AM +0100, Al Viro wrote:
a) softfloat.c raises flags we don't care about. So checking that
FP_STATUS.float_exception_flags is non-zero is *not* good - we catch
false positives that way.
b) DNZ has effect *only* for /S insns. Without /S denorm means INV
On Sat, Jul 05, 2014 at 10:09:51PM +0100, Al Viro wrote:
Anyway, the current delta (on top of 26f86) follows; seems to get IEEE
insns behave on non-finite arguments as they do on 21264. The main
exception is that register bitmask supplied to trap isn't calculated in
a bunch of cases; since
On Thu, Jul 03, 2014 at 09:30:05PM -0700, Richard Henderson wrote:
Another one is probably not worth bothering - PERR, CTPOP, CTLZ, UNPKBx and
PKxB
don't accept literal argument. For one thing, as(1) won't let you generate
those, so it would have to be explicit
.long 0x70001620
Denorms fun:
a) softfloat.c raises flags we don't care about. So checking that
FP_STATUS.float_exception_flags is non-zero is *not* good - we catch
false positives that way.
b) DNZ has effect *only* for /S insns. Without /S denorm means INV and
that's it. FPCR.INV isn't set, at that.
On Sat, Jul 05, 2014 at 02:40:55AM +0100, Al Viro wrote:
d) at least on EV6 and EV67 DNOD *still* trips INV. According to the
manual suppression of INV by DNOD is optional. And while their text
might be interpreted as INV is suppressed if operation with denorm
wouldn't result in something
More bugs: addl/v should sign-extend the result, as addl does.
As it is, we have
uint64_t helper_addlv(CPUAlphaState *env, uint64_t op1, uint64_t op2)
{
uint64_t tmp = op1;
op1 = (uint32_t)(op1 + op2);
if (unlikely((tmp ^ op2 ^ (-1UL)) (tmp ^ op1) (1UL 31))) {
On Thu, Jul 03, 2014 at 07:51:04AM +0100, Al Viro wrote:
FWIW, why not just generate
trunc_i64_i32 tmp, va
trunc_i64_i32 tmp2, vb
muls2_i32 tmp2, tmp, tmp, tmp2
ext32s_i64 vc, tmp2
maybe_overflow_32 tmp
where maybe_overflow throws IOV unless tmp is 0 or -1
On Thu, Jul 03, 2014 at 01:19:19PM -0700, Richard Henderson wrote:
Grr... Wrong check, obviously - we want to check that tmp + MSB(tmp2) is 0.
Something like
setcond_32 tmp2, tmp2, zero, TCG_COND_LT
add_i32 tmp, tmp2, tmp
callhelper_IOV_if_not_zero
On Fri, Jul 04, 2014 at 12:05:37AM +0100, Peter Maydell wrote:
On 3 July 2014 23:47, Al Viro v...@zeniv.linux.org.uk wrote:
How can that be correct? Suppose a = b = 0. We get
tcg_gen_eqv_i64(tmp, va, vb); - tmp = -1
tcg_gen_mov_i64(tmp2, va); - tmp2 = 0
tcg_gen_add_i64
On Thu, Jul 03, 2014 at 01:19:19PM -0700, Richard Henderson wrote:
I believe I have a tidy solution to these /v insns. New patch set shortly.
OK, looks sane. Next (trivial) bug: in translate_one()
case 0xF800:
/* WH64 */
/* No-op */
break;
should be
On Wed, Jul 02, 2014 at 06:50:27AM +0100, Al Viro wrote:
AFAICS, it leaves two possibilities - EV45 (AS200) vs. EV6 (DS10) and EV67
(qemu) _or_ some change in the kernel. I'll build 3.x kernel for DS10 and
post the results; shouldn't take long...
Actually, it's simpler - note that on *all
I'm interested in the results of the following test.
DS10:
/su : 1/3 -i---
/sui : 1/3 -i---
/su : min*min -i--u
/sui : min*min -i--u
/: (long)4.5 -i---
/sv : (long)4.5 -i---
/svi : (long)4.5 -i---
/: (long)max -i---
/sv : (long)max
On Wed, Jul 02, 2014 at 08:26:53AM -0700, Richard Henderson wrote:
On 07/01/2014 11:17 PM, Al Viro wrote:
If we don't want FE_INEXACT seen by fetestexcept() after rounding 4.5, we'd
better not use FPCR.INE - *all* variants of actual hardware (at least from
21064A to 21264) set that sucker
On Tue, Jul 01, 2014 at 10:03:06AM -0700, Richard Henderson wrote:
On 06/30/2014 01:56 PM, Al Viro wrote:
On Mon, Jun 30, 2014 at 11:39:43AM -0700, Richard Henderson wrote:
Looks good.
I've split it up into a couple of smaller patches, made some sylistic
tweaks
and pushed
On Tue, Jul 01, 2014 at 11:30:19AM -0700, Richard Henderson wrote:
On 07/01/2014 11:23 AM, Peter Maydell wrote:
On 1 July 2014 18:50, Al Viro v...@zeniv.linux.org.uk wrote:
Which glibc version? Better yet, could you throw preprocessed source
my way? UP1000 box is not in a good shape
On Wed, Jul 02, 2014 at 05:05:08AM +0100, Al Viro wrote:
OK, DS10 resurrected and so far seems to be stable (I'll know by tomorrow;
there's a possibility that chipset heatsink is dodgy, but so far it seems
to be doing OK). That gives us a EV6 box.
Which glibc version it is? I don't see
On Mon, Jun 30, 2014 at 11:39:43AM -0700, Richard Henderson wrote:
Looks good.
I've split it up into a couple of smaller patches, made some sylistic tweaks
and pushed it to
git://github.com/rth7680/qemu.git axp-next
I'm starting to do some testing now, but a glance though would be
On Mon, Jun 30, 2014 at 09:56:35PM +0100, Al Viro wrote:
FWIW, it might be better to do what float64_to_int64_round_to_zero() is doing
-
i.e.
if (shift = 0) {
if (shift 64)
ret = frac shift;
if (shift 11 || a == LIT64
On Tue, Jul 01, 2014 at 05:34:45AM +0100, Al Viro wrote:
VAX operations are serious mess, but I'm not sure if we have them actually
used anywhere in Linux kernel or userland. Always possible, of course, but...
Grr... Truncated mail, sorry. Missing part:
_If_ we decide that we want CVTGQ
On Tue, Jun 24, 2014 at 02:32:46PM -0700, Richard Henderson wrote:
On 06/24/2014 02:24 PM, Al Viro wrote:
Al, off to figure out the black magic TCG is using to generate calls...
If you've a helper
DEF_HELPER_1(halt, void, i64)
then
gen_helper_halt(...)
will generate the tcg ops
On Wed, Jun 25, 2014 at 10:27:11AM +0100, Peter Maydell wrote:
I think it's OK to put extra float_flags in, provided you can define
their semantics in terms that make sense for more than one
architecture (even if only one arch actually happens to need them).
The input_denormal/output_denormal
On Wed, Jun 25, 2014 at 08:01:17AM +0100, Al Viro wrote:
On Tue, Jun 24, 2014 at 02:32:46PM -0700, Richard Henderson wrote:
On 06/24/2014 02:24 PM, Al Viro wrote:
Al, off to figure out the black magic TCG is using to generate calls...
If you've a helper
DEF_HELPER_1(halt, void, i64
On Tue, Jun 24, 2014 at 05:34:23AM +0100, Al Viro wrote:
First of all, kudos - with current qemu tree qemu-alpha-system is
working pretty well - debian install and a *lot* of builds work just fine.
As in, getting from lenny to pretty complete squeeze toolchain, including gcj,
openjdk6
On Tue, Jun 24, 2014 at 11:33:32AM -0700, Richard Henderson wrote:
return (unsigned long)x;// SVCTQ/SVC
CVTTQ/SVC, of course...
Clearly a gross misunderstanding of what bits are actually computed, never
mind
what gets signaled.
On Tue, Jun 24, 2014 at 11:23:01AM -0700, Richard Henderson wrote:
env-error_code = error;
if (retaddr) {
cpu_restore_state(cs, retaddr);
+ env-pc += 4;
This one needs a different fix, since dynamic_excp is also used from
alpha_cpu_unassigned_access, and I'm pretty
On Tue, Jun 24, 2014 at 01:57:52PM -0700, Richard Henderson wrote:
On 06/24/2014 01:32 PM, Al Viro wrote:
If you have any ideas for testing, I do have working hw (the box that is
currently alive is ev45, though; I _can_ try to boot a UP1000 one, but
I make no promises regarding its fans
First of all, kudos - with current qemu tree qemu-alpha-system is
working pretty well - debian install and a *lot* of builds work just fine.
As in, getting from lenny to pretty complete squeeze toolchain, including gcj,
openjdk6 and a lot of crap needed to satisfy build-deps of those, plus
41 matches
Mail list logo
