linux-um.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Peter Hovorka <peter@fusselt.net>
To: user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] Strange behaviour in eth assignments
Date: Sat, 19 Aug 2006 18:38:51 +0200	[thread overview]
Message-ID: <200608191838.51481.peter@fusselt.net> (raw)
In-Reply-To: <200608191653.43641.blaisorblade@yahoo.it>

Hi,

> > ./um2.6.16.27-bb1 ubd0=root_fs ubd1=swap_fs eth0=tuntap,tap112
>
> Do you really mean "tap112"? 

Yes, Sir.

> Nobody I think tried this. > I've checked  
> for bugs in parsing, but there is none. Please give more details and
> try a saner setting, or elaborate on the reason of this strange
> setting. At least let's determine if changing it causes the bug not
> to show up.

I've used taps according to the used IP in a range of 1-254 since 2002 - 
and I've never experienced any problems in doing so. So tap112 is quite 
a sane setting - for me at least it is.

I have tried other tap settings in a range from tap1-254 (and even 
simple tunctls without assigning a special number) - with the same 
results.

> The other possibility is that something in the guest image (I'm not
> talking about the kernel, but about the rootfs) is calling ifrename.
> But since some kernels don't do that, this is probably not the case.

I have tried this with three more or less different file systems after 
your mail to the list (and I should have done earlier - only thing I 
hadn't thought of), as there are:

- Ubuntu Server 6.0.6 LTS
- Fedora Core 5
- Debian Sarge

The problem seems to be Ubuntu - FC5 and Debian Sarge do well. No 
problems with them. I would like to use Ubuntu, though - so it would be 
nice to have a workaround or at least the cause for this to happen.

> > mem=100M
>
> You'd better use a round amount (128 or 96M), I don't know if that's
> a problem but that's strange.

There has never been a single problem in assigning memory outside the 
'round amount' row. I've assigned thousands of instances with 34, 35, 
36 MB or 67, 68, 69 MB or 130, 131, 132 MB and so on. 

I have tried other memory options after your comment from above, but it 
doesn't change the strange behaviour.

> If this were, say, a buffer overflow, or a bug because tap112 does
> not exist, the source causes "unspecified behaviour", so totally
> unrelated changes can change the actual behaviour to change.

Tap112 did exist, I set them up manually not by the uml_helper. As I 
said, older Kernel versions did not show any problems of this kind. I 
double and triple checked everything I could from a user's perspective 
and it took me several days until I packed my bag to look out for Jeff 
in the #uml and to finally post to uml-devel - the only thing I didn't 
take a closer look at was the file system respectively the distro.

Kind regards,
Peter

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
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:[~2006-08-19 16:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-17 10:56 [uml-devel] Strange behaviour in eth assignments Peter Hovorka
2006-08-19 14:53 ` Blaisorblade
2006-08-19 16:38   ` Peter Hovorka [this message]
2006-08-20 10:24     ` Blaisorblade
2006-08-20 14:38       ` Peter Hovorka
2006-08-20 18:03         ` alessandro salvatori
2006-08-26 12:35           ` Peter Hovorka
2006-08-26 13:07             ` Blaisorblade
2006-08-28 12:02               ` Nix
2006-08-20  0:42   ` Jeff Dike
2006-08-20 10:23     ` Blaisorblade

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=200608191838.51481.peter@fusselt.net \
    --to=peter@fusselt.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).