From: Andi Kleen <ak@muc.de>
To: Bernd Schubert <bernd-schubert@web.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
nfs@lists.sourceforge.net
Subject: Re: x86_64: 32bit emulation problems
Date: 1 Mar 2005 22:48:32 +0100
Date: Tue, 1 Mar 2005 22:48:32 +0100 [thread overview]
Message-ID: <20050301214832.GA44624@muc.de> (raw)
In-Reply-To: <200503012207.02915.bernd-schubert@web.de>
On Tue, Mar 01, 2005 at 10:07:01PM +0100, Bernd Schubert wrote:
> Hello Andi,
>
> sorry, due to some mail sending/refusing problems, I had to resend to the
> nfs-list, which prevented the answers there to be posted to the other CCs.
>
> > It is most likely some kind of user space problem. I would change
> > it to int err = stat(dir, &buf);
> > and then go through it with gdb and see what value err gets assigned.
> >
> > I cannot see any kernel problem.
>
> The err value will become -1 here.
strace didn't say so, and normally it doesn't lie about things like this.
> > bernd@hitchcock tests>./test_stat32 /mnt/test/yp
> > stat for /mnt/test/yp failed
> > ernno: 75 (Value too large for defined data type)
errno is undefined unless a system call returned -1 before or
you set it to 0 before.
> > But why does stat64() on a 64-bit kernel tries to fill in larger data than
A 64bit kernel has no stat64(). All stats are 64bit.
> > on a 32-bit kernel and larger data also only for nfs-mount points? Hmm, I
> > will tomorrow compare the tcp-packges sent by the server.
>
> So I still think thats a kernel bug.
Your data so far doesn't support this assertion.
-Andi
next prev parent reply other threads:[~2005-03-01 21:48 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-28 20:54 x86_64: 32bit emulation problems Bernd Schubert
2005-02-28 21:00 ` Bernd Schubert
2005-03-01 20:24 ` Andi Kleen
2005-03-01 21:07 ` Bernd Schubert
2005-03-01 21:07 ` Bernd Schubert
2005-03-01 21:48 ` Andi Kleen [this message]
2005-03-01 22:30 ` Bernd Schubert
2005-03-01 22:30 ` Bernd Schubert
2005-03-01 23:07 ` Andi Kleen
2005-03-01 22:10 ` Andreas Schwab
2005-03-01 22:10 ` Andreas Schwab
2005-03-01 22:19 ` Andi Kleen
2005-03-01 23:22 ` Andreas Schwab
2005-03-01 23:22 ` Andreas Schwab
2005-03-01 23:19 ` Bernd Schubert
2005-03-01 23:39 ` Andreas Schwab
2005-03-01 23:39 ` Andreas Schwab
2005-03-01 23:46 ` Andreas Schwab
2005-03-01 23:46 ` Andreas Schwab
2005-03-02 8:18 ` Andi Kleen
2005-03-02 9:13 ` Trond Myklebust
2005-03-02 11:33 ` Bernd Schubert
2005-03-02 16:53 ` Trond Myklebust
2005-03-02 18:14 ` Bernd Schubert
2005-03-03 9:19 ` Andi Kleen
2005-03-03 21:16 ` Bernd Schubert
2005-03-03 21:32 ` Andi Kleen
2005-03-03 21:37 ` Trond Myklebust
2005-03-03 21:46 ` Andi Kleen
2005-03-03 22:21 ` Trond Myklebust
2005-03-03 9:12 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2005-02-28 21:08 Bernd Schubert
2005-02-28 22:26 ` Trond Myklebust
2005-02-28 23:14 ` Bernd Schubert
2005-02-28 23:43 ` Bernd Schubert
2005-03-01 0:47 ` Dan Stromberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050301214832.GA44624@muc.de \
--to=ak@muc.de \
--cc=bernd-schubert@web.de \
--cc=linux-kernel@vger.kernel.org \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.