On Tuesday 28 July 2009 21:24:01 Corey wrote:
On Tuesday 28 July 2009 18:42:05 Russ Cox wrote:
snip
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't
On Tue, Jul 28, 2009 at 2:37 PM, erik quanstromquans...@quanstro.net wrote:
this change as worked well on my personal system and at coraid
for the past 6 months. it just works. even on hitherto unknown
controllers like the orion.
Hmm. A few years ago, I ran into a similar problem and added
Hmm. A few years ago, I ran into a similar problem and added a
variable that could be set in plan9.ini to specify where the nvram
actually is. It works reasonably well
difficult to maintain in a pretty active environment;
one more reason for boot failure.
- erik
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
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 behind
Is an strange problem ... problem with interrupts?
Try to disable some hardware stuff, like the CD-ROM, USB, soundcard, etc.
This problem is only with plan9?
On Wed, Jul 29, 2009 at 4:49 PM, roger pepperogpe...@gmail.com wrote:
well, now i've got another problem...
i'm gettting strange time
This problem is only with plan9?
yup.
although it is plan9-inside-vmware, which could make
a significant difference.
This problem is only with plan9?
yup.
although it is plan9-inside-vmware, which could make
a significant difference.
And you said VMWare 2.x, which is exceedingly old...
Tim Newsham
http://www.thenewsh.com/~newsham/
It might be worth trying to get control back, I think you can do that
for domain squatters that violate trademarks, as is clearly the case
here.
uriel
On Wed, Jul 29, 2009 at 10:58 AM, mahtmattmob...@proweb.co.uk wrote:
Uriel wrote:
Likely Google juice, there are still plenty of high-rank
it's the latest version of VMWare Fusion AFAIK...
2009/7/29 Tim Newsham news...@lava.net:
This problem is only with plan9?
yup.
although it is plan9-inside-vmware, which could make
a significant difference.
And you said VMWare 2.x, which is exceedingly old...
Tim Newsham
Hello Roger,
I'm currently running latest Plan 9 in vmware fusion Version 2.0
(116369). This system has been behaving perfectly on every installation (save
where i really botched something up trying to learn the system).
What is your host OS? I'm running this on Mac OS X 10.5.8
hope
On Wed, Jul 29, 2009 at 1:30 PM, Urielurie...@gmail.com wrote:
It might be worth trying to get control back, I think you can do that
for domain squatters that violate trademarks, as is clearly the case
here.
I think that's only if the trademark owner pursues it, and the US may
have other
This is sort of off-topic, but does anybody have any experience with
Ceph?
http://ceph.newdream.net/
Good or bad war stories (and general thoughts) would be quite welcome.
Thanks,
Roman.
My familiarity with the kernel source code is superficial to say the
least, but it seems to me that this code (from /sys/src/9/pc/trap.c)
contains a race condition:
702 if(sp(USTKTOP-BY2PG) || sp(USTKTOP-sizeof(Sargs)-BY2WD))
703 validaddr(sp, sizeof(Sargs)+BY2WD, 0);
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
15 matches
Mail list logo
