Re: [9fans] lguest on 2.6.25
Ok, still, it would be great to know how to set the time, as my time is way off (by more than 4 hours). Best++ John On Mon, 25 Aug 2008 15:44:39 -0700 "ron minnich" <[EMAIL PROTECTED]> wrote:http://www.unixtimestamp.com/ > I just realized that even one timesync is too much. You should not > run any at all. The hardware clock is set from Linux and I don't even > allow it to be set. It makes no sense to do that. > > So don't let timesync run. > > thanks > > ron >
[9fans] Anyone handy with Alpha assembler?
Anyone around here still familiar with Alpha assembler (and the Alpha kernel in general) willing to point me in the right direction? Supposing one wanted to implement instruction emulation for the BWX extensions, etc, like Tru64 and OpenVMS do, so that you can run the same binaries on EV4 and EV5, where would be the best place to hook in? illegal0 in /sys/src/9/alphapc/l.s or illegal in /sys/src/9/alphapc/trap.c? Furthermore, how would one obtain the faulting instruction? Best I can tell, it's the Ureg *ur passed to illegal in trap.c or 8(R30) from illegal0. Thanks in advance! -Ben <>
Re: [9fans] lguest on 2.6.25
I just realized that even one timesync is too much. You should not run any at all. The hardware clock is set from Linux and I don't even allow it to be set. It makes no sense to do that. So don't let timesync run. thanks ron
Re: [9fans] lguest on 2.6.25
Hello. For one timesync couldn't write to the rtc, so I commented out the lines in cpurc. Well, here timesync is not the problem, time is reported incorrectly, and I do not really know how to set it. I tried echoing unix time into '#r' and /dev/rtc, with no luck: $sysname# ls -l /dev/rtc --rw-rw-r-- r 0 bootes bootes 0 Apr 23 20:43 /dev/rtc $sysname# echo -n '1219699386' > /dev/rtc echo: write error: permission denied (on the hostowners console) Also cron still spews messages flooding it's log with lines like this: Aug 26 02:29:41 time went backward Which might be related to time issues.. rgds On Mon, 25 Aug 2008 20:54:53 +0200 [EMAIL PROTECTED] wrote: > > Well, i don't think I am starting two timesync, ps a shows only one: > > If Xen is anything to go by, time keeping is a problem in > virtualisation. And Erik is misguiding you :-) > > Thing is, if timesync is wresting with the clock as it seems to do if > two instances are running, it does consume a lot of cpu time, > according to experiences reported on this list. But it's possible > that timesync is wrestling with the virtual executive rather than with > another instance of itself. > > Would it hurt you to run without timesync? > > ++L > >
Re: [9fans] lguest on 2.6.25
hello, On Mon, 25 Aug 2008 20:54:53 +0200 [EMAIL PROTECTED] wrote: > > Well, i don't think I am starting two timesync, ps a shows only one: > > If Xen is anything to go by, time keeping is a problem in > virtualisation. And Erik is misguiding you :-) > > Thing is, if timesync is wresting with the clock as it seems to do if > two instances are running, it does consume a lot of cpu time, > according to experiences reported on this list. But it's possible > that timesync is wrestling with the virtual executive rather than with > another instance of itself. > > Would it hurt you to run without timesync? will try, thanks :-) > > ++L > > John
Re: [9fans] lguest on 2.6.25
> Well, i don't think I am starting two timesync, ps a shows only one: If Xen is anything to go by, time keeping is a problem in virtualisation. And Erik is misguiding you :-) Thing is, if timesync is wresting with the clock as it seems to do if two instances are running, it does consume a lot of cpu time, according to experiences reported on this list. But it's possible that timesync is wrestling with the virtual executive rather than with another instance of itself. Would it hurt you to run without timesync? ++L
Re: [9fans] lguest on 2.6.25
Hello again,
Well, i don't think I am starting two timesync, ps a shows only one:
cpu% ps a |grep timesync
bootes 770:00 0:00 92K Preadtimesync
I also can not write to /dev/rtc, so the timesync part of cpurc fails, this
part in particular
=snip
if(! ps|grep -s timesync) {
aux/timesync -n pool.ntp.org
if (test -e '#r/rtc') @ {
sleep 10# let timesync correct the time
awk '{print $1}' /dev/time >'#r/rtc'# fix hw clock
} &
}
=
awk: i/o error occurred while closing /dev/stdout
input record /dev/time:1
source line 1
I have also tried to compile the kernel by doing:
cpu% fcp /n/sources/contrib/rminnich/lguest/lg25.tgz $home/src; cd $home/src;
tar xzf lg25.tgz;
cpu% mkdir src/boot
cpu% mkdir src/ip
cpu% mkdir src/pc
cpu% mkdir src/port
cpu% rc bin/rc/lguest
cpu% mk 'conf=lguestcpu'
.
8c -FTVw lgkbd.c
../port/portdat.h:536 dat.h:130 lgkbd.c:4 syntax error, last name: Tval
mk: 8c -FTVw lgkbd.c : exit status=rc 887: 8c 889: error
Any help would be appreciated, this timesync problem is causing me quite some
headaches :-)
Thanks
John
On Mon, 25 Aug 2008 10:59:37 -0400
erik quanstrom <[EMAIL PROTECTED]> wrote:
> >> both the excessive load and these messages sound like a timesync problem.
> >>
> >
> > yeah, that's really weird. One option is to set up the kernels without
> > any fancy timers -- just use the old PC timers.
>
> do you think that's the problem?
>
> time jumping backwards doesn't seem like something that could
> be traced to some oddity of the lguest environment. (at least i
> lack the imagination to know how this could happen.) it sounds
> more like the traditional problem of having started two timsyncs.
>
> it any event, fixing timesync properly is likely to fix the excessive
> load problem.
>
> - erik
>
>
Re: [9fans] Any Brits going to iwp9? ...
> ... and any great travel plans to share? Hardly a Brit and going via Italy, but I'll be there. ++L
Re: [9fans] Any Brits going to iwp9? ...
I'm currently enjoying cheap wine with some friends in Saloniki. If you get a cheap ticket you can go to Volos from here with the bus (it is much more comfortable than the train). From the airport to the bus station you will have to travel to the other side of the city, which can take quite some time (there will be a munical bus numbered 78, which will go to both the bus (ΚΤΕΛ) and train station for 1€). Taxis are a bit expensive from the airport, but it's still affordable here. Here is the timetable for the munical bus: http://www.oasth.gr/routes/route_eng.php?route_num=78 The timetables for the ΚΤΕΛ busses will hopefully be updated in time: http://www.ktelvolou.gr/dromologia_ath_ther.html I'm going to start studying in Germany in a few weeks, so I'm not sure if I'm able to come. Germans from NRW should try to get a germanwings ticket fast (they're still quite cheap; got one for under 100€). Perhaps some other guy could tell how to get to Volos from Athens...
Re: [9fans] lguest on 2.6.25
On Mon, Aug 25, 2008 at 7:59 AM, erik quanstrom <[EMAIL PROTECTED]> wrote: > it any event, fixing timesync properly is likely to fix the excessive > load problem. good to know. I probably jumped to the wrong conclusion. ron
Re: [9fans] lguest on 2.6.25
>> both the excessive load and these messages sound like a timesync problem. >> > > yeah, that's really weird. One option is to set up the kernels without > any fancy timers -- just use the old PC timers. do you think that's the problem? time jumping backwards doesn't seem like something that could be traced to some oddity of the lguest environment. (at least i lack the imagination to know how this could happen.) it sounds more like the traditional problem of having started two timsyncs. it any event, fixing timesync properly is likely to fix the excessive load problem. - erik
Re: [9fans] lguest on 2.6.25
On Mon, Aug 25, 2008 at 7:52 AM, ron minnich <[EMAIL PROTECTED]> wrote: > On Mon, Aug 25, 2008 at 3:56 AM, erik quanstrom <[EMAIL PROTECTED]> wrote: >>> Hello, >>> I have gotten the lguest port working on the 2.6.25.0 kernel, it works >>> mighty fine here. >>> The load issue for me is only on plan9, on the host I can see with 'top' >>> that the lguest guest isn't consuming all the cpu, so this might ust be a >>> plan9 problem. I have also seen quite a few messages in /sys/log/cron i get >>> a lot of lines saying: >>> $sysname Aug 25 08:31:14 time went backward >> >> both the excessive load and these messages sound like a timesync problem. >> > > yeah, that's really weird. One option is to set up the kernels without by 'kernel' here I mean linux kernel, sorry. ron
Re: [9fans] lguest on 2.6.25
On Mon, Aug 25, 2008 at 3:56 AM, erik quanstrom <[EMAIL PROTECTED]> wrote: >> Hello, >> I have gotten the lguest port working on the 2.6.25.0 kernel, it works >> mighty fine here. >> The load issue for me is only on plan9, on the host I can see with 'top' >> that the lguest guest isn't consuming all the cpu, so this might ust be a >> plan9 problem. I have also seen quite a few messages in /sys/log/cron i get >> a lot of lines saying: >> $sysname Aug 25 08:31:14 time went backward > > both the excessive load and these messages sound like a timesync problem. > yeah, that's really weird. One option is to set up the kernels without any fancy timers -- just use the old PC timers. ron
Re: [9fans] Any Brits going to iwp9? ...
> Any Brits going to iwp9? ... > ... and any great travel plans to share? yes, and "i must sort that out" -Steve
[9fans] Any Brits going to iwp9? ...
... and any great travel plans to share? DaveL
Re: [9fans] lguest on 2.6.25
> Hello, > I have gotten the lguest port working on the 2.6.25.0 kernel, it works mighty > fine here. > The load issue for me is only on plan9, on the host I can see with 'top' that > the lguest guest isn't consuming all the cpu, so this might ust be a plan9 > problem. I have also seen quite a few messages in /sys/log/cron i get a lot > of lines saying: > $sysname Aug 25 08:31:14 time went backward both the excessive load and these messages sound like a timesync problem. - erik
Re: [9fans] lguest on 2.6.25
On Sun, 24 Aug 2008 23:58:21 -0500 "Alex Lee" <[EMAIL PROTECTED]> wrote: > On Sun, Aug 24, 2008 at 11:32 PM, ron minnich <[EMAIL PROTECTED]> wrote: > [snip] > >> lguestnetwork is > > > > see this line? It's a variable read in /rc/bin/cpurc. You can check > > that script and see how it can be set so that networking is a little Hello, I have gotten the lguest port working on the 2.6.25.0 kernel, it works mighty fine here. The load issue for me is only on plan9, on the host I can see with 'top' that the lguest guest isn't consuming all the cpu, so this might ust be a plan9 problem. I have also seen quite a few messages in /sys/log/cron i get a lot of lines saying: $sysname Aug 25 08:31:14 time went backward I found routed networking to be the simplest, nat gives me the creeps. So here is my way to start the lguest guest, I hope it will be helpful: snip #!/bin/bash set -x /root/bin/lguest --tunnet=$1 --block=/dev/mirror/plan9cpu \ 512 /home/johnny/9lguestcpu.2.6.25.elf 'bootargs=local!#S/sd00/fossil;sysname=9soul;bootdisk=local!#S/sd00/fossil' sleep 10 ip route add $3 via $1 dev $2 ip route del 192.168.0.0/24 dev $2 echo 1 > /proc/sys/net/ipv4/conf/$2/proxy_arp echo 1 > /proc/sys/net/ipv4/ip_forward echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp snip $1 is the host ip, $2 is the tap interface the guest will use, and $3 is the ip the guest will have. This method only works for static networking, also you will need to install the iproute2 utilities. These command also assume the your net is 192.168.0.0 netmask 255.255.255.0, change that to whatever suits you. Cheers, John > > better. More I do not recall and the machine is not nearby ... > > > [snip] > >> 2. I can ping from the host machine to the lguest interface > >> (192.168.19.2), but when I try to connect with drawterm the connection > >> is refused. > > > > Try restarting the listen? that's an odd one. If you telnet to the > > port from the host to the guest what do you see? > > Ah, I see now. I added "lguestnetwork=NAT" to parameters in RUNLGUEST, > and now both networking and drawterm are working great! > > >> 3. lguest always runs at full CPU. How can I figure out why this is > >> happening? (I don't feel comfortable running lguest for more than a > >> few minutes at a time -- the laptop gets pretty hot.) > > > > hmm. I have not seen this one. Again, not sure why this is happening. > > But the halt > > may not be working. Possibly the API has changed -- not sure. > > > > ron > > Let me know if there's any information that I can provide to help with > this. Many thanks for all the hard work that you've put into doing > this port. > > Best, > Alex > >
