All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Zimmerman <mdz@debian.org>
To: Jeff Dike <jdike@addtoit.com>
Cc: user-mode-linux-devel@lists.sourceforge.net,
	224431@bugs.debian.org, 224502@bugs.debian.org,
	debian-glibc@lists.debian.org
Subject: Re: [uml-devel] 2.4.22-[67] problems
Date: Sun, 21 Dec 2003 20:08:57 -0800	[thread overview]
Message-ID: <20031222040857.GV9354@alcor.net> (raw)
In-Reply-To: <200312220025.hBM0PlFI012918@ccure.user-mode-linux.org>

On Sun, Dec 21, 2003 at 07:25:47PM -0500, Jeff Dike wrote:

> mdz@debian.org said:
> > I have just verified this myself.  Building user-mode-linux
> > 2.4.22-7um-1 on woody works fine (even when running on unstable), but
> > building it on unstable does not.
> 
> Conversely, does a unstable-built UML run on woody?

The unstable-built UML is broken on woody as well.  So far, my most
reproducible test case so far (not 100%, but close) is to start up a netcat
listener, and connect to it with input from /dev/zero, i.e. just push a
bunch of data over a TCP connection.  What happens is this:

rootstrap:~# nc -v -l -p 1234 >/dev/null </dev/null &
[2] 138
rootstrap:~# listening on [any] 1234 ...

rootstrap:~# nc -v -v localhost 1234 </dev/zero
connect to [127.0.0.1] from localhost [127.0.0.1] 1028
localhost [127.0.0.1] 1234 (?) open
select fuxored : Function not implemented
too many output retries : Broken pipe
 sent 27820032, rcvd 0
[2]+  Exit 1                  nc -v -l -p 1234 >/dev/null </dev/null

The relevant netcat source code isn't doing anything unusual:

    rr = select (16, ding2, 0, 0, timer2);      /* here it is, kiddies */
    if (rr < 0) {
        if (errno != EINTR) {           /* might have gotten ^Zed, etc ?*/
          holler ("select fuxored");
          close (fd);
          return (1);
        }
    } /* select fuckup */

so select is returning ENOSYS, but, as can be seen from the transfer
statistics, it succeeds many times before it fails.

Some other times, a program will simply hang (sometimes even stalling the
boot process), or segfault.

> > The one built on unstable randomly sees ENOSYS from certain system
> > calls, such as select, read and mmap.
> 
> Only those, or are there others that you can tell are failing?  Offhand, I
> don't see any commonality between those three, in terms of their interactions
> with the host.

Those are the ones that I have been able to easily identify.

select came from the netcat test you see above.

mmap was evident from the APT HTTP method:

/usr/lib/apt/methods/http: error while loading shared libraries: libc.so.6: cannot map zero-fill pages: Error 38

(that error is from dl-load.c in glibc, and as far as I can tell indicates
that mmap gave ENOSYS).

basename from coreutils seemed to see write(2) failing:

basename: write error: Function not implemented

I also saw unlink do it, in dpkg:

dpkg: error processing /var/cache/apt/archives/debhelper_4.0.2_all.deb (--unpack):
failed to rmdir/unlink `/usr/share/man/man1/dh_compress.1.gz.dpkg-tmp': Function not implemented

apt occasionally blows up read()ing from a socket as well:

(none):~# apt-get update
Get:1 http://debian woody/main Packages [1774kB]
Err http://debian woody/main Packages
  Error reading from server - read (38 Function not implemented)
Get:2 http://debian woody/main Release [95B]
Fetched 95B in 0s (259B/s)
Failed to fetch http://debian/dists/woody/main/binary-i386/Packages  Error reading from server - read (38 Function not implemented)
Reading Package Lists... Done
Building Dependency Tree... Done
E: Some index files failed to download, they have been ignored, or old ones used instead.

> > I would appreciate any suggestions for how to track this problem down
> > further.
> 
> The randomness is strange.  It suggests that somehow interrupts are getting
> in the way.  One possibility would be host system calls returning ENOSYS
> instead of EINTR.  I don't see much possibility that that's what's actually
> happening, but that's the sort of thing I'd think about.

Can you think of any way that userland changes could produce that kind of
effect?  I don't think I would know where to look.  My kernel didn't change,
and the problem seems to occur on different host kernels.

I tried running UML under strace; this produces an impressive amount of
output, but made it much more difficult to reproduce the bug.  I finally got
it to happen under strace, and I have a 226M logfile (7M gzipped) from the
session, if you're interested in taking a look.  I've put it up at
http://people.debian.org/~mdz/temp/uml.strace.gz.  I don't see any host
system calls returning ENOSYS; the only failures are some very
innocuous-looking EINTRs and a few EAGAINs that looks like they're
associated with a terminal device.

-- 
 - mdz


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

  reply	other threads:[~2003-12-22  4:09 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-20  1:13 [uml-devel] 2.4.22-[67] problems Matt Zimmerman
2003-12-20 17:14 ` Jeff Dike
2003-12-21  0:47   ` Matt Zimmerman
2003-12-21 15:58     ` BlaisorBlade
2003-12-21 22:40       ` Matt Zimmerman
2003-12-21 23:16         ` Matt Zimmerman
2003-12-22  0:25           ` Jeff Dike
2003-12-22  4:08             ` Matt Zimmerman [this message]
2003-12-22  5:49               ` Daniel Jacobowitz
2003-12-22  9:08                 ` Matt Zimmerman
2004-01-05 17:51                   ` Adam Heath
2004-01-05 18:10                     ` Matt Zimmerman
2003-12-24 12:48         ` BlaisorBlade
2003-12-21  0:52   ` Matt Zimmerman
2003-12-21  1:06     ` Matt Zimmerman
2003-12-28  9:33       ` Matt Zimmerman
2003-12-28  9:51         ` Matt Zimmerman
2003-12-28  9:52           ` Matt Zimmerman
2004-01-06  2:59             ` Jeff Dike
2003-12-28 10:12           ` Matt Zimmerman
2003-12-28 11:30             ` Matt Zimmerman
2003-12-30 18:43               ` Resolution (Re: [uml-devel] 2.4.22-[67] problems) Matt Zimmerman
2004-01-06  2:58                 ` Jeff Dike
2004-01-06  7:41                   ` Nuno Silva
2004-01-06  8:02                     ` Matt Zimmerman
2004-01-06  8:20                       ` Nuno Silva
2004-01-06  8:47                         ` Nuno Silva
2004-01-06  9:20                     ` Nuno Silva
2004-01-06 17:13                       ` Matt Zimmerman
2004-01-09  7:22                         ` Nuno Silva
2004-01-08  7:07                   ` Matt Zimmerman
2004-01-12 18:36                     ` [uml-devel] Panic with slirp transport and gcc 3.3 Matt Zimmerman
2004-01-13 15:25                       ` [uml-devel] " Bill Allombert
2004-01-13 17:30                         ` Jeff Dike
2004-01-13 17:44                           ` Bill Allombert
2004-01-13 18:51                           ` Matt Zimmerman
2004-01-16  2:38                             ` Jeff Dike
2004-01-16  2:38                               ` Matt Zimmerman
2004-01-16 20:04                                 ` Jeff Dike
2004-01-16 19:49                                   ` Matt Zimmerman
2004-01-17  0:42                                     ` Matt Zimmerman
2003-12-21  1:29   ` [uml-devel] 2.4.22-[67] problems Matt Zimmerman
2003-12-20 19:05 ` Nick Craig-Wood

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=20031222040857.GV9354@alcor.net \
    --to=mdz@debian.org \
    --cc=224431@bugs.debian.org \
    --cc=224502@bugs.debian.org \
    --cc=debian-glibc@lists.debian.org \
    --cc=jdike@addtoit.com \
    --cc=user-mode-linux-devel@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.