On Tuesday 28 July 2009 17:42:23 Corey wrote:
> My experience is indicating a different reality,
> or I'm still not interpreting my experience correctly.
>
It was definitely the latter.
On Tuesday 28 July 2009 16:50:15 erik quanstrom wrote:
> you should note that this has absolutely zero to do
> The problem isn't confined to unnecessary warning messages
> being printed.
>
> What about the 'arena arenas00: header is out-of-date' error,
> and the subsequent re-indexing (on every reboot) which occurs
> as a result of the condition?
Despite the mention of "date" in the message,
the logic be
> My standalone terminal is always doing the index, the problem seemed
> to have just suddenly showed up for no reason - the system hasn't crashed,
> I'm not doing anything 'weird', and I always run fshalt before shutting
> down. And this persists across fresh installs.
Not sure what you mean by
On Tuesday 28 July 2009 21:24:01 Corey wrote:
> On Tuesday 28 July 2009 18:42:05 Russ Cox wrote:
> > It's not a question of time zones. Time zones don't matter.
> > It's just that the clock was wrong before and later is
> > correct--there are many reasons this might happen--
> > and venti shouldn
On Tuesday 28 July 2009 18:42:05 Russ Cox wrote:
> On Tue, Jul 28, 2009 at 3:16 PM, erik quanstrom
wrote:
> > ignoring little bugs is the path to ruin.
>
> That's why the print should just go away entirely.
> The code assumes that the time from one boot
> to the next only ever increases, which has
On Tue, Jul 28, 2009 at 3:16 PM, erik quanstrom wrote:
> ignoring little bugs is the path to ruin.
That's why the print should just go away entirely.
The code assumes that the time from one boot
to the next only ever increases, which has been
demonstrated not to be true. Maybe during one
boot you
> Approximately how long is 'some time'? (so I know how long to wait)
5-10 minutes. /sys/log/timesync should be informative.
> My point though is that yes, it makes the timezone change take
> effect immediately - and it likewise causes the 'creation time after
> last write time' /dev/kprint's t
On Tuesday 28 July 2009 16:50:15 erik quanstrom wrote:
> > #6 - reboot, (first-time login), as glenda:
> > - remove -L switch from $TIMESYNCARGS in /rc/bin/termrc
>
> if the time was already correct modulo timezone, why did you do this?
>
My (ill-founded?) reasoning went like this:
* -L
> #6 - reboot, (first-time login), as glenda:
> - remove -L switch from $TIMESYNCARGS in /rc/bin/termrc
if the time was already correct modulo timezone, why did you do this?
also, after allowing the machine to run for some time, does timesync
cause the system time (date -n) to jump? i.e
On Tuesday 28 July 2009 06:22:19 erik quanstrom wrote:
> > > -L used with -r to indicate the real time clock is in
> > >local time rather than GMT. This is useful on PCs that
> > >also run the Windows OS.
> >
> > I must be stuck in some sort of logic err
On Tue Jul 28 18:16:08 EDT 2009, davide...@cs.cmu.edu wrote:
> > The right fix is probably to comment out the print in venti
> > and move on, which you have already done.
>
> I'd suggest: if the time is off by more than 24 hours, warn once.
> That will mean timezone problems will be silently ignor
> The right fix is probably to comment out the print in venti
> and move on, which you have already done.
I'd suggest: if the time is off by more than 24 hours, warn once.
That will mean timezone problems will be silently ignored, but
something "really odd" will still make it presence known.
> If
I don't think we need to debate the exact semantics of
time on Plan 9 in order to figure this out.
It's easy to believe that the installer and the main distribution
end up with different time settings, no matter what the exact
details are. The right fix is probably to comment out the print
in ven
> > -L used with -r to indicate the real time clock is in
> >local time rather than GMT. This is useful on PCs that
> >also run the Windows OS.
> >
>
> I must be stuck in some sort of logic error, so please correct me where I'm
> wrong:
>
> * the Plan
> * set up venti manually after the install, and after I've set the timezone
Sorry if I'am being a pedant, but its not the timezone - that
is an offset that effects how dates and times are printed, plan9
like Unix always uses UTC for all time/date stamps. The problem is
the time in the RTC chip wa
On Monday 27 July 2009 17:35:31 erik quanstrom wrote:
> > "I suspect what's happening is the motherboard clock is set in
> > the future, you are formatting venti based on that time, and then later
> > firing up timesync which interprets the RTC as local time. If your RTC is
> > set to UTC and you'r
> "I suspect what's happening is the motherboard clock is set in
> the future, you are formatting venti based on that time, and then later
> firing up timesync which interprets the RTC as local time. If your RTC is
> set to UTC and you're in the western hemisphere, the RTC clock will be
> ahead
On Monday 27 July 2009 15:52:28 erik quanstrom wrote:
> > ls -l /386/bin/venti
> >
> > reboot
> >
> >
> > ... but the changes I applied to arena.c do show up; which
> > leads me to believe my changes aren't being used by the
> > system.
>
> no you're not missing anything except for the sleezy trick
>
> ls -l /386/bin/venti
>
> reboot
>
>
> ... but the changes I applied to arena.c do show up; which
> leads me to believe my changes aren't being used by the
> system.
no you're not missing anything except for the sleezy trick.
venti is built into the kernel. you will also need to rebuild
On Monday 27 July 2009 13:38:58 erik quanstrom wrote:
> as long as you're editing venti
> source, you could print out both dates. that would give a
> better picture of what's really going on.
>
I think I must be missing something, this is what I did:
cd /sys/src/cmd/venti/srv
acme arena.c
cd
What does the BIOS setup screen say about the motherboard clock's idea of
the time? I suspect what's happening is the motherboard clock is set in
the future, you are formatting venti based on that time, and then later
firing up timesync which interprets the RTC as local time. If your RTC is
set
On Monday 27 July 2009 13:38:58 erik quanstrom wrote:
> > each time using the same process/steps) - and now it doesn't go away,
> > even on a completely fresh install, even after I wiped the drives
> > completely.
>
> what's your disk wiping procdure?
>
I reboot with a gentoo linux rescue cd.
I r
> each time using the same process/steps) - and now it doesn't go away,
> even on a completely fresh install, even after I wiped the drives completely.
what's your disk wiping procdure?
> Now, every time I install plan 9 on this machine, even when I don't change
> the clock or timezone in any way
On Monday 27 July 2009 09:28:39 Russ Cox wrote:
> On Sun, Jul 26, 2009 at 6:03 PM, Corey wrote:
> > The following is being printed to the console non-stop:
> > err 2: arena arenas00 creation time after last write time
> > arena arenas00: header is out-of-date
> > Apparently my clock/date was set a
On Sun, Jul 26, 2009 at 6:03 PM, Corey wrote:
> The following is being printed to the console non-stop:
> err 2: arena arenas00 creation time after last write time
> arena arenas00: header is out-of-date
> Apparently my clock/date was set a day ahead when I installed the terminal.
>
> How do I corr
25 matches
Mail list logo
