hi, sorry for not answering sooner, i''ve had a busy time.. okay: the current semistable tree works fine, though i can''t verify if they disappeared because of code changes, or because i replaced the duron 700 with a p4 2.4ghz. the mouse problem was my own stupidity, i really had an usb mouse on that machine, and didn''t check. sorry for the sloppy bug report. devfs is deprecated in 2.6 anyway, so i won''t experiment with those compile options anymore. i''m still finding some other rough edges here and there, for example xen_readlog(sp?) stops working for me after creating and destroying a few domains.. no crashes so far though. another thing i remember to be irritating is that shutdown -h now in dom0 reboots the machine instead of halting it, i''m not sure if that''s true for the current tree. also i''d like to make a pre-announcement: soniq networks is going to develop and maintain a debian based xen distribution, called xenian. i''m working on it right now, but as we''re busy with our new office, waiting for our leased line, and so on, a beta release before november is improbable. cheers, paul ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> i''m still finding some other rough edges here and there, for example > xen_readlog(sp?) stops working for me after creating and destroying a > few domains.. no crashes so far though.I think I know what is causing that. It should be easy to fix.> another thing i remember to be irritating is that shutdown -h now in > dom0 reboots the machine instead of halting it, i''m not sure if that''s > true for the current tree.If you specify ''noreboot'' on the Xen command line then it will halt instead of rebooting. Fixing this up properly so that Xen reboots or halts depending on the command executed in DOM0 is not that hard. Cheers, Keir ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Hi xen-people, I have a strange problem. One of my various xen test boxes doesn''t accept to set its time. Basically, it''s stuck to RTC time. ntpdate, date, hwclock all "seem" to work, but they don''t actually change the system time. The only way I have to change it right now is to change it in the BIOS, which is not a good thing. Since I heavily "stripped down" the Debian version on this box, maybe I broke something somewhere. While I''m trying to debug how settimeofday() syscall work, I''m wondering if there is some cross-domain time synchronization : are they always in perfect sync, or should I run some kind of ntp stuff in each subdomain ? Or only domain 0 would be enough ? Thanks, -- Nicolas Bougues Axialys Interactive ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> I have a strange problem. One of my various xen test boxes doesn''t > accept to set its time. Basically, it''s stuck to RTC time. > > ntpdate, date, hwclock all "seem" to work, but they don''t actually > change the system time. The only way I have to change it right now is > to change it in the BIOS, which is not a good thing. > > Since I heavily "stripped down" the Debian version on this box, maybe > I broke something somewhere.Sadly, settimeofday is broken :-( In domain 0 it ought to set a new time down in Xen, visible to all domains.> While I''m trying to debug how settimeofday() syscall work, I''m > wondering if there is some cross-domain time synchronization : are > they always in perfect sync, or should I run some kind of ntp stuff in > each subdomain ? Or only domain 0 would be enough ?If settimeofday in domain 0 would update the RTC via Xen, then that would be adequate. All other domains automatically remain synchronized with the RTC. This shouldn''t be a hard fix -- Rolf may have done it already but not checked it in! Cheers, Keir ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Fri, Oct 17, 2003 at 10:20:30AM +0200, Nicolas Bougues wrote:> While I''m trying to debug how settimeofday() syscall work, I''m > wondering if there is some cross-domain time synchronization : are > they always in perfect sync, or should I run some kind of ntp stuff in > each subdomain ? Or only domain 0 would be enough ?yeah, i''ve noticed this too.. all dom''s are stuck to system time. one interpretation of correct behaviour probably would be to leave time synchronization to dom0, which isn''t working right now (without doing some voodoo i might not know about) paul ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Fri, Oct 17, 2003 at 09:39:37AM +0100, Keir Fraser wrote:> > I have a strange problem. One of my various xen test boxes doesn''t > > accept to set its time. Basically, it''s stuck to RTC time. > > > > ntpdate, date, hwclock all "seem" to work, but they don''t actually > > change the system time. The only way I have to change it right now is > > to change it in the BIOS, which is not a good thing. > > > > Since I heavily "stripped down" the Debian version on this box, maybe > > I broke something somewhere. > > Sadly, settimeofday is broken :-( >Well, yes, actually I just realized that it doesn''t work anywhere. I noticed that in arch/xeno/kernel/time.c, do_settimeofday() has a #if 0 which prevents it from doing anything.> > While I''m trying to debug how settimeofday() syscall work, I''m > > wondering if there is some cross-domain time synchronization : are > > they always in perfect sync, or should I run some kind of ntp stuff in > > each subdomain ? Or only domain 0 would be enough ? > > If settimeofday in domain 0 would update the RTC via Xen, then that > would be adequate. All other domains automatically remain synchronized > with the RTC. >By RTC, you mean the hardware RTC ? Doesn''t xen maintain a system time on its own ? As long as xen system time is settable via a domain 0 user tool (ntp-alike), I don''t really care about the hardware RTC. -- Nicolas Bougues Axialys Interactive ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> By RTC, you mean the hardware RTC ? Doesn''t xen maintain a system time > on its own ?Since domain 0 can''t currently set Xen''s syetm time, using the RTC is the only way to get a stable (crystal-based) timebase.> As long as xen system time is settable via a domain 0 user tool > (ntp-alike), I don''t really care about the hardware RTC.Tracking the RTC is a nice default --- if DOM0 is running ntp then we can track updates from DOM0 instead. This really shouldn''t be that hard to implement. -- Keir ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > > By RTC, you mean the hardware RTC ? Doesn''t xen maintain a system time > > on its own ? > > Since domain 0 can''t currently set Xen''s syetm time, using the RTC is > the only way to get a stable (crystal-based) timebase. > > > As long as xen system time is settable via a domain 0 user tool > > (ntp-alike), I don''t really care about the hardware RTC. > > Tracking the RTC is a nice default --- if DOM0 is running ntp then we > can track updates from DOM0 instead. This really shouldn''t be that > hard to implement.Hmmm.... I''ve taken a thorough look at the code. Not pleasant :-( It actually needs a fair bit of fixing up. It''ll be my first thing to do when I get back from presenting Xen at SOSP, at the end of next week. -- Keir ------------------------------------------------------- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> I have a strange problem. One of my various xen test boxes doesn''t > accept to set its time. Basically, it''s stuck to RTC time. > > ntpdate, date, hwclock all "seem" to work, but they don''t actually > change the system time. The only way I have to change it right now is > to change it in the BIOS, which is not a good thing.The checked-in tree (ssh://xen@xen.bkbits.net/xeno-unstable.bk) now contains a number of fixes for the handling of time. Briefly, Xen now reads the RTC at start of day and by default will track that with the precision of the periodic timer crystal. Xen''s estimate of the wall-clock time can only be updated by domain 0 (this may be fixed in the future by introducing some access/update capabilities). If domain 0 runs ntpdate, ntpd, etc. then the synchronised time will automatically be pushed down to Xen every minute (and written to the RTC every 11 minutes, just as normal x86 Linux does). All other domains always track Xen''s wall-clock time: setting the date, or running ntpd, on these domains will not affect their wall-clock time!! If this is a problem then I can add a sysctl which would turn this off if desired (i.e., setting the flag would prevent the domain from tracking Xen''s estimate of wall-clock time). Note that the wall-clock time exported by Xen is UTC --- all domains must have appropriate timezone handling (eg. a correct /etc/localtime file). Hope this is useful! Keir Fraser ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Mon, Oct 27, 2003 at 05:06:48PM +0000, Keir Fraser wrote:> > > I have a strange problem. One of my various xen test boxes doesn''t > > accept to set its time. Basically, it''s stuck to RTC time. > > > > ntpdate, date, hwclock all "seem" to work, but they don''t actually > > change the system time. The only way I have to change it right now is > > to change it in the BIOS, which is not a good thing. > > The checked-in tree (ssh://xen@xen.bkbits.net/xeno-unstable.bk) > now contains a number of fixes for the handling of time. > > Briefly, Xen now reads the RTC at start of day and by default will > track that with the precision of the periodic timer crystal. > > Xen''s estimate of the wall-clock time can only be updated by domain 0 > (this may be fixed in the future by introducing some access/update > capabilities). If domain 0 runs ntpdate, ntpd, etc. then the > synchronised time will automatically be pushed down to Xen > every minute (and written to the RTC every 11 minutes, just as normal > x86 Linux does).It would be nice to have a selectable "disparate system times", as a normal standalone machine would act. Allowing each domain kernel to keep track of its own unique system time (and ensuring that each domain gets the interrupts to update their clock reliably) would be great for development and QA environments.> All other domains always track Xen''s wall-clock time: setting the > date, or running ntpd, on these domains will not affect their > wall-clock time!! If this is a problem then I can add a sysctl which > would turn this off if desired (i.e., setting the flag would prevent > the domain from tracking Xen''s estimate of wall-clock time).For development environments, it really would help to be able to disable this behavior. There''s nothing quite like fiddling with the clock, troubleshooting some timestamp behavior, only to find the system time "fixed" after a testing run. UML''s system clock is really more a suggestion than a real usable time source as a result of some of the host''s system time confusion. Try a "sleep 10" in a UML image, and see how long it *really* takes. I''d hate to see this happen to Xen as well. - Ian C. Blenke <ian@blenke.com> ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > All other domains always track Xen''s wall-clock time: setting the > > date, or running ntpd, on these domains will not affect their > > wall-clock time!! If this is a problem then I can add a sysctl which > > would turn this off if desired (i.e., setting the flag would prevent > > the domain from tracking Xen''s estimate of wall-clock time). > > For development environments, it really would help to be able to disable > this behavior. There''s nothing quite like fiddling with the clock, > troubleshooting some timestamp behavior, only to find the system time > "fixed" after a testing run.Okay, I can add a command-line option and/or sysctl switch to modify this behaviour quite easily. I have some other tweaks I''ll be making shortly, so I''ll add this at the same time.> UML''s system clock is really more a suggestion than a real usable time > source as a result of some of the host''s system time confusion. Try a > "sleep 10" in a UML image, and see how long it *really* takes. I''d hate > to see this happen to Xen as well.I''m not sure what you mean. Neither Xen nor Xenolinux "lose" ticks. There are still some more cleanups to be made to the time interface, but Xen does at least provide a stable time base. -- Keir ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > For development environments, it really would help to be able to disable > > this behavior. There''s nothing quite like fiddling with the clock, > > troubleshooting some timestamp behavior, only to find the system time > > "fixed" after a testing run. > > Okay, I can add a command-line option and/or sysctl switch to modify > this behaviour quite easily. I have some other tweaks I''ll be making > shortly, so I''ll add this at the same time.There are now two ways to cause a domain to run its wallclock independently from Xen: 1. Specify ''independent_wallclock'' on the command line. 2. ''echo 1 >/proc/sys/xeno/independent_wallclock''. To reenable tracking of Xen wallclock: 1. ''echo 0 >/proc/sys/xeno/independent_wallclock''. -- Keir ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel