this ape program gives a floating point exception error:
#include
void
main(){
strtod("421567849e316", 0);
}
this made awk crash when i was running dumpvacroots.
it dies at /sys/src/ape/lib/ap/stdio/strtod.c:473
but it looks a bit involved for me to dive into right now,
i'm afraid.
continuing my litany of vmware woes:
my vmware snarf buffer doesn't seem to read correctly.
e.g.
term% echo hello > snarf
term% cat snarf
term% pwd
/mnt/vmware
term%
the data is correctly copied into the system (mac os)
snarf buffer, but nothing ever comes back the other way.
unfortunately the
actually, i lied when i said that nothing ever comes
out of the snarf buffer. if i copy some text externally
(inside mac os), then i get it, just once, inside plan 9/vmware.
reading it seems to clear it.
e.g.
term% cat /dev/snarf
hello world
term% cat /dev/snarf
term%
2009/7/30 roger peppe :
>
On Thu, Jul 30, 2009 at 11:22 AM, roger peppe wrote:
> actually, i lied when i said that nothing ever comes
> out of the snarf buffer. if i copy some text externally
> (inside mac os), then i get it, just once, inside plan 9/vmware.
> reading it seems to clear it.
>
Isn't this related to the soft
hi,
would an installation on SATA-IIdisk be smooth provided I have HD on sdE0, and
CD on sdE1 (with appropriately modified plan9.ini)?? (going forSATA-CD if yes),
thanks,
++pac
I found that it's just easier running a cpu server in vmware and drawterm
to it, that way I get snarf working properly, plus I see the files on the
host in /mnt/term
On Thu, Jul 30, 2009 at 6:34 AM, Gorka Guardiola wrote:
> On Thu, Jul 30, 2009 at 11:22 AM, roger peppe wrote:
>> actually, i lied w
On Thu Jul 30 00:05:45 EDT 2009, el...@andrew.cmu.edu wrote:
> 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(Sa
On Thu Jul 30 04:42:29 EDT 2009, rogpe...@gmail.com wrote:
> this ape program gives a floating point exception error:
>
> #include
> void
> main(){
> strtod("421567849e316", 0);
> }
>
> this made awk crash when i was running dumpvacroots.
> it dies at /sys/src/ape/lib/ap/stdio/strtod.c:473
2009/7/30 erik quanstrom :
> fixed,
>
> http://9fans.net/archive/2009/01/234
ok, thanks, i had a very vague memory of this, but obviously
my googling was inadequate.
did you submit a patch? i can't see one.
i will if not - it's an annoying error.
(and, as you say, why not just use the usual strt
Hi, sorry for this cross posting, I posted it to inferno yesterday but
I'm not getting through (non of my mail is, must work that out)
I've been trying to sign some data with a generated secret using the
attached Limbo. Afaik the secret is ok, it passed checkSK in keyring.c
I got as far as here
On Thu Jul 30 08:18:45 EDT 2009, rogpe...@gmail.com wrote:
> 2009/7/30 erik quanstrom :
> > fixed,
> >
> > http://9fans.net/archive/2009/01/234
>
> ok, thanks, i had a very vague memory of this, but obviously
> my googling was inadequate.
>
> did you submit a patch? i can't see one.
> i will if n
> unfortunately the source for vmwarefs doesn't seem to
> be available, so i can't investigate further.
http://9fans.net/archive/2008/12/180
Dave Eckhardt
!> ; echo 421567849e316 | awk '{print}'
> 421567849e316
> ; 9fs sources
> ; ; echo 421567849e316 | /n/sources/plan9/386/bin/awk '{print}'
> /n/sources/plan9/386/bin/awk: floating point exception 6
> source line 1
- erik
sorry. i accidentally deleted the first line of that reply:
it will be mpdiv via mpmod via mpexp via rsaencrypt,
with a zero modulus (which suggests the key wasn't unpacked correctly).
but if you make an entry in the bugs list ... etc
if you make an entry in the bugs list at inferno-os.googlecode.com i'll look at
it shortly.
On Thu, 30 Jul 2009, erik quanstrom wrote:
On Thu Jul 30 00:05:45 EDT 2009, el...@andrew.cmu.edu wrote:
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<(USTK
> On Thu, 30 Jul 2009, erik quanstrom wrote:
>
>> On Thu Jul 30 00:05:45 EDT 2009, el...@andrew.cmu.edu wrote:
>>> 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:
>>>
>>>
> > plan 9 threads are cooperatively scheduled. so
> > the correct term is proc. but you are correct,
> > another proc sharing memory with this one
> > could be running. however, that proc would
> > not have access to this proc's stack. (rfork
> > doesn't allow shared stack.) and even if it
>
hm... what about the other stuff port/sysfile.c?
they also just checks pointers with validaddr and then call
into the device handler without locking anything / holding
anything.
--
cinap
--- Begin Message ---
> On Thu, 30 Jul 2009, erik quanstrom wrote:
>
>> On Thu Jul 30 00:05:45 EDT 2009, el.
ok, forget it... the segments are actualy reference counted.
so a process would not be able to unmap a segment in
another process.
--
cinap
--- Begin Message ---
> On Thu, 30 Jul 2009, erik quanstrom wrote:
>
>> On Thu Jul 30 00:05:45 EDT 2009, el...@andrew.cmu.edu wrote:
>>> My familiarity with
... but you can still shrink segments for other processes :-)
(this crashes the kernel)
--
cinap
--- Begin Message ---
hm... what about the other stuff port/sysfile.c?
they also just checks pointers with validaddr and then call
into the device handler without locking anything / holding
anything.
Hi,
I am trying to implement a toy fs using the 9p protocol. I've been
reading Francisco's intro to plan 9 and section 5 of the manual pages,
and I have to say I am surprised because I am actually learning from
them; plan 9 man pages are really readable :-) (not to mention
Francisco's fine intro).
> I think you may be right, Elly. Multithreaded programs indeed have their
> stack running outside the stack segment, so this could happen there.
> splhi won't even do on a multiprocessor. One should probably lock down
> the segment.
> We've never seen this happen, of course — or rather, we haven
Hi,
How come you can't TWalk along an open Fid?
Thanks,
-- vs
just stop processes with s->ref > 1 from freeing parts of s with ibrk.
it's not as if anything ever does in practice.
2009/7/30 hugo rivera :
> [...] there's no way two different files point to the
> same data structure (but maybe two different fids do?) so reference
> counting is unnecessary, am I right?
no, because a file can be opened several times.
when you open a file you get a new fid.
so if you've got res
2009/7/29 erik quanstrom :
>> 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 fail
On Thu, Jul 30, 2009 at 8:28 AM, Venkatesh Srinivas wrote:
> How come you can't TWalk along an open Fid?
In the original 9P protocol, that didn't make sense,
because walk always updated the fid it was starting from.
If you open a fid and then walk it elsewhere,
is it still open? Is that an implic
> Speaking of, I had a disk in my server die recently, and eventually
> it affected the nvram partition. So of course, when I booted up it
> couldn't read it and prompted me for the auth credentials, then tried
> to write back to nvram, got an i/o error and rebooted.
> The reboot could have been
Sorry for the off-topic post, but I'm striking out on google, and I'm virtually
certain that someone here will know...
Does anyone happen to have the ISBN's for the 7th Edition manual set?
Volume I is 0-03-061742-1, but I can't seem to find the others...
Thanks in advance!
-Ben
On Thu, Jul 30, 2009 at 1:08 PM, Russ Cox wrote:
> On Thu, Jul 30, 2009 at 8:28 AM, Venkatesh Srinivas wrote:
>> How come you can't TWalk along an open Fid?
>
> In the original 9P protocol, that didn't make sense,
> because walk always updated the fid it was starting from.
> If you open a fid and t
it's the latest version of VMWare Fusion AFAIK...
Ahh, my apologies. I had incorrectly assumed "VMWare Workstation".
And you said VMWare 2.x, which is exceedingly old...
Tim Newsham
http://www.thenewsh.com/~newsham/
>with a zero modulus (which suggests the key wasn't unpacked correctly).
my deliberate mistake (it won't be using rsaencrypt but rsadecrypt)
happened to highlight the actual problem, which is that strtosk
shouldn't accept a string that looks to me (if not to it)
like a public key not a private/sec
2009/7/30 Roman V Shaposhnik :
> 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.
Not with ceph itself, but the description and terminology they use
remind me a lot
2009/7/31 erik quanstrom :
>> Speaking of, I had a disk in my server die recently, and eventually
>> it affected the nvram partition. So of course, when I booted up it
>> couldn't read it and prompted me for the auth credentials, then tried
>> to write back to nvram, got an i/o error and rebooted.
> >
> > no. it happens to me all the time. (when there is no
> > place to write nvram, as when no disk is partitioned.)
>
> OK, but you won't hit an error in that case either. I was wondering
> whether the i/o problem was tripping it up.
> -sqweek
factotum handles this case.
- erik
no it doesn't, I had this a few days ago, moving disks about so
nvram couldn't be found. I could still boot the system but I had to enter
the nvram info from the keyboard, it did then try to write the data back
which (of course) fails - perhaps it was this write to a dead disk that
caused the boot
On Thu Jul 30 14:13:18 EDT 2009, st...@quintile.net wrote:
> no it doesn't, I had this a few days ago, moving disks about so
> nvram couldn't be found. I could still boot the system but I had to enter
> the nvram info from the keyboard, it did then try to write the data back
> which (of course) fai
> it would surely make it easier for unix implementations. i have had
> plenty of issues with that in o9fs.
>
> but as yourself pointed out, what would that walk mean?
as i also pointed out, there's no problem if
the walk is creating a new fid. it would be unopened.
russ
also, do you know about:
http://plan9.bell-labs.com/7thEdMan/
-Steve
I sure do, but I'm looking for the printed copies.
Thanks though!!
-Ben
-Original Message-
From: 9fans-boun...@9fans.net on behalf of Steve Simon
Sent: Thu 7/30/2009 2:32 PM
To: 9fans@9fans.net
Subject: Re: [9fans] off topic: manual sets
also, do you know about:
http://plan9.bell-lab
appologies,
I managed to junk half my email, I meant to add:
v1 0-03-061742-1
v2 0-03-061743-X
I have had success buying some older Unix box
from both abebooks.com and alibris.com.
-Steve
42 matches
Mail list logo
