Steve Schmidtke wrote:
> Well, any ping actually, will work pinging to the host slirp is attached
> to - that's a special case. I mentioned it to poke fun at myself for a
> bug I thought I had found.
Ah, yes :-)
> Yup, even better. I'll remember it for the doc.
And it all works great now I hacked the source code - I built a .deb, so
if anyone else wants it, let me know.
David
--
David Coulson http://davidcoulson.net/
d@... http://journal.davidcoulson.net/

david@... wrote:
>>From inside uml? The slackware 8 ping sort of works ;)
>
>Interesting - How does it do that then? I don't see how slirp on the host
>can open a raw socket for the ping
Well, any ping actually, will work pinging to the host slirp is attached to
- that's a special case. I mentioned it to poke fun at myself for a bug I
thought I had found.
>I just made a ~/.slirprc
Yup, even better. I'll remember it for the doc.
Steve Schmidtke
_________________________________________________________________
Unlimited Internet access for only $21.95/month. Try MSN!
http://resourcecenter.msn.com/access/plans/2monthsfree.asp

Steve Schmidtke wrote:
> good. The slip transport should be suffering from the same problem,
> I'll see if I can pretty something up for Jeff for those. I'm surprised
> the other transports don't show problems, they don't register hh
> functions either...
Well, tuntap works fine here - I don't use any of the other transports
frequently.
> From inside uml? The slackware 8 ping sort of works ;)
Interesting - How does it do that then? I don't see how slirp on the
host can open a raw socket for the ping
> yes, and thanks, I'm not the only one with that problem... :)
I just made a ~/.slirprc and put;
-b 8388608
Seems to work fine, and I don't have to do anything special.
> Either way, changing the baudrate will probably get you 20K+ per sec,
> which then seems to be limited by something in the slirp binary.
> There's a q&d hack I have for the slirp sources as well :)
Oh, poop. That answers my other question then.
David
--
David Coulson http://davidcoulson.net/
d@... http://journal.davidcoulson.net/

david@... wrote:
>Now I got slirp working, I've hit another snag. I went to download
>'linux-2.4.19.tar.bz2' with wget and it goes at around >18-20kbytes/sec.
compile from the slirp sources, and try turning on FULL_BOLT or something
like that, IIRC.
Hmmm, time to write some documentation/howto for slirp networking in UML.
Steve Schmidtke
_________________________________________________________________
Broadband? Dial-up? Get reliable MSN Internet Access.
http://resourcecenter.msn.com/access/plans/default.asp

>Steve Schmidtke wrote:
>>Try this change to the patch for slirp_header_cache():
>>
>>- return(0);
>>+ return(-1);
>
>That did the job. I just did a dist-upgrade over slirp and it works great.
good. The slip transport should be suffering from the same problem, I'll
see if I can pretty something up for Jeff for those. I'm surprised the
other transports don't show problems, they don't register hh functions
either...
>Like an idiot, I tried to test it with ping - Forgot that doesn't work as a
>non-root user.
From inside uml? The slackware 8 ping sort of works ;)
>Now to another problem. It maxes out at 10k/sec, due to the 115200 baud
>default. I tried to use 1250000 with the command '/usr/bin/slirp baudrate
>1250000', but it ended up with UML thinking that 'baudrate' and '1250000'
>were options to it's command line, which obviously didn't work. Any
>suggestions?
yes, and thanks, I'm not the only one with that problem... :) The proper
solution for now is to write a slirp wrapper, something like this:
#!/bin/sh
exec /usr/local/bin/slirp 'baudrate 1250000'
and call the wrapper from the setup string:
eth0=slirp,,./bin/slirpwrapper.sh
The dirty hack is to do this in slirp_setup:
init->argw.argv[i++] = str;
while(*str && *str!=',') {
+ if(*str=='_') *str=' ';
str++;
}
if(*str!=',')
Which changes underscores to spaces and lets you write:
eth0=slirp,,slirp,baudrate_1250000
Jeff hasn't put in the hack, and with being able to call a wrapper, I don't
see an issue leaving it that way for now.
Either way, changing the baudrate will probably get you 20K+ per sec, which
then seems to be limited by something in the slirp binary. There's a q&d
hack I have for the slirp sources as well :)
>Thanks,
>David
>
>--
>David Coulson http://davidcoulson.net/
>d@... http://journal.davidcoulson.net/
_________________________________________________________________
Choose an Internet access plan right for you -- try MSN!
http://resourcecenter.msn.com/access/plans/default.asp

Now I got slirp working, I've hit another snag. I went to download
'linux-2.4.19.tar.bz2' with wget and it goes at around 18-20kbytes/sec.
I'm on cable here and downloading from http://www.kernel.org usually goes at
~300-350kbytes/sec
I get the following from slirp when I ifconfig my eth0;
[autodetect SLIP/CSLIP, MTU 1500, MRU 1500, 8388608 baud]
If my counting skills are up to par, that's 1Mbit.
David
--
David Coulson http://davidcoulson.net/
d@... http://journal.davidcoulson.net/

Steve Schmidtke wrote:
> Try this change to the patch for slirp_header_cache():
>
> - return(0);
> + return(-1);
That did the job. I just did a dist-upgrade over slirp and it works great.
> Using the host address, or an address you plan to connect to, will cause
> problems, but otherwise any private address should do - the one slirp
> reccomends on boot is usually good. For routing, this is what I do:
>
> route add default dev eth0
Like an idiot, I tried to test it with ping - Forgot that doesn't work
as a non-root user. I just checked the slirp documentation again, and it
seems that lots of IPs in the 10.2.0.0/24 network are used by slirp for
special things, so I'll use 10.2.0.15 for the UML.
Now to another problem. It maxes out at 10k/sec, due to the 115200 baud
default. I tried to use 1250000 with the command '/usr/bin/slirp
baudrate 1250000', but it ended up with UML thinking that 'baudrate' and
'1250000' were options to it's command line, which obviously didn't
work. Any suggestions?
Thanks,
David
--
David Coulson http://davidcoulson.net/
d@... http://journal.davidcoulson.net/

david@... wrote:
>Steve Schmidtke wrote:
>>Hmmm, it may be a side effect of the patch, but I doubt it.
>
>It's only the slirp transport which throws up the panic.
Try this change to the patch for slirp_header_cache():
- return(0);
+ return(-1);
there may be random memory used if the function says it succeeded - if it
fails, could you break on the hard header routines and bt them? I'd like to
know where they are specifically being called from.
If that doesn't work, try changing the interface type in slirp_init:
- dev->type = ARPHRD_ETHER;
+ dev->type = ARPHRD_SLIP;
slirp doesn't have the guts for real ethernet, and maybe shouldn't be
pretending to be.
>BTW, how should I set up my eth0 when using slirp? What IP address should I
>give it and how should routeing be configured?
Using the host address, or an address you plan to connect to, will cause
problems, but otherwise any private address should do - the one slirp
reccomends on boot is usually good. For routing, this is what I do:
route add default dev eth0
Steve Schmidtke
_________________________________________________________________
Get a speedy connection with MSN Broadband. Join now!
http://resourcecenter.msn.com/access/plans/freeactivation.asp

Steve Schmidtke wrote:
> Hmmm, it may be a side effect of the patch, but I doubt it.
It's only the slirp transport which throws up the panic.
> Is there
> anything special about the mounts? Does the uml boot without them?
> Also, slirp cannot NFS mount from servers that don't have "insecure" set
> in their exports (it's a user process on the host and has to remap root
> reserved ports, like NFS, to >=1024, possibly confusing things in the UML).
Sorry, my mistake. It's not actually setting up mounts, it's setting up
exports (there aren't any anyway). My console output is as follows:
Starting kernel log daemon: klogd.
Starting portmap daemon: portmap.
Setting NIS domainname to: davidcoulson.net
Starting NIS services: ypbind
Not starting NFS kernel daemon: No exports.
Kernel panic: kernel BUG at slab.c:1443!
BTW, how should I set up my eth0 when using slirp? What IP address
should I give it and how should routeing be configured?
--
David Coulson http://davidcoulson.net/
d@... http://journal.davidcoulson.net/

david@... wrote:
>I'm playing with 2.4.19-17um, with the slirp transport. It all works
>fine until my Debian image goes to start ypbind and then it panics.
Hmmm, I'm suspecting more transports will have this problem, but try the
attached patch for slirp... it stubs out no-op hard header routines, the
existence of which are not being tested for before use.
Steve Schmidtke
_________________________________________________________________
Unlimited Internet access -- and 2 months free! Try MSN.
http://resourcecenter.msn.com/access/plans/2monthsfree.asp

Hello!
On Tue, Oct 22, 2002 at 06:50:53PM +0400, Oleg Drokin wrote:
> > Reproducion is simple: just telnet to another host, set DISPLAY to
> > your host:0 (or whatever it is for you, have not tried with ssh
> > redirection), start UML as usual. Bug will appear.
> I can't make this happen with 2.5.44-1.
> xterms seem to behave fine here.
Ok, I was able to reproduce it again, seems that if the other host
is multi CPU one and if you start UML with several CPUs as well,
it's easier to trigger. (though once I was able to trigger it locally)
Problem is when our irq is called several times in a row therefore
second time it overwrites good fs with some cruft.
In the patch I tried to stick a printk() inside of added code path and I see it
is actually triggered.
Here's the fix.
I tried to fix it by doing free_irq() directly before up(), but that
did not helped for whatever reason.
Bye,
Oleg
===== arch/um/drivers/xterm_kern.c 1.2 vs edited =====
--- 1.2/arch/um/drivers/xterm_kern.c Sat Oct 19 11:16:02 2002
+++ edited/arch/um/drivers/xterm_kern.c Tue Oct 22 18:53:05 2002
@@ -23,6 +23,11 @@
{
struct xterm_wait *xterm = data;
+ if ( xterm->new_fd != -1 && xterm->new_fd != -EAGAIN) {
+ /* Evil race, where our handler got called immediatelly again
+ before we even had a chance to deregister irq */
+ return;
+ }
xterm->new_fd = os_rcv_fd(xterm->fd, &xterm->pid);
if(xterm->new_fd == -EAGAIN)
return;

Hello!
On Mon, Oct 21, 2002 at 03:59:05PM -0500, Jeff Dike wrote:
> > Reproducion is simple: just telnet to another host, set DISPLAY to
> > your host:0 (or whatever it is for you, have not tried with ssh
> > redirection), start UML as usual. Bug will appear.
> I can't make this happen with 2.5.44-1.
> xterms seem to behave fine here.
Well, the strange thing is that I cannot make it happen toady too. Even
with yesterdays binaries.
Oh well, I hope this problem won't arise next time I wil need to run UML
on remote hoxt with VTs on xterms.
Bye,
Oleg

From: Doug Alcorn <doug@...>
Date: Mon, 21 Oct 2002 14:30:58 -0400
Subject: [linux-usb-devel] status of UML usb host controller
>I saw a message in the archives saying there was a patch for UML to
>add a USB host controller. However, I can't find the patch. I've
>emailed the announcement author with no result. Does anyone have this
>patch? Even if it's old, I'd still like to see it. Getting it
>updated/ported to 2.5 is something I'm interested in doing.
I sent out a version for uml-2.4.18-52um on August 21 to the uml-devel list
Alas while I have finally gotten a version ported to 2.5 and it enumerates
the devices it does not create the usbfs files correctly. The orignal
version by Johan Verrept was for 2.4.0-test6 and while I was able to get a
fair forward port to 2.4.18-52um but in 2.5 the rapid changes to usb, the
build system, and user-mode-linux have kept me running in place.
If you are interested I have the partially working version for 2.5.44 it
should be about 10K bzipped 40K plain text
I suppose that I should bring the 2.4.18-52um version forward to 2.4.19-17um
also.
Um, where did send your request I don't recall it on linux-usb-devel or
user-mode-linux-devel?