[9fans] ape strtod crash
this ape program gives a floating point exception error:
#include stdlib.h
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.
[9fans] vmware snarf problem
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 source for vmwarefs doesn't seem to be available, so i can't investigate further. any ideas?
Re: [9fans] vmware snarf problem
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 rogpe...@gmail.com: continuing my litany of vmware woes: my vmware snarf buffer doesn't seem to read correctly.
Re: [9fans] vmware snarf problem
On Thu, Jul 30, 2009 at 11:22 AM, roger pepperogpe...@gmail.com 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 software Russ wrote for vmware (nda protected) and which stopped being updated?. I know there was a special snarf for vmware. -- - curiosity sKilled the cat
[9fans] installation on SATA
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
Re: [9fans] vmware snarf problem
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 Guardiolapau...@gmail.com wrote: On Thu, Jul 30, 2009 at 11:22 AM, roger pepperogpe...@gmail.com 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 software Russ wrote for vmware (nda protected) and which stopped being updated?. I know there was a special snarf for vmware. -- - curiosity sKilled the cat -- Federico G. Benavento
Re: [9fans] Race condition in /sys/src/9/pc/trap.c?
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(Sargs)-BY2WD)) 703 validaddr(sp, sizeof(Sargs)+BY2WD, 0); 704 705 up-s = *((Sargs*)(sp+BY2WD)); We verify that the address is correct; is there any reason another thread in the same address space cannot start running after line 703 completes and unmap that memory, causing us to access unmapped memory at line 705? The system call entry is itself an interrupt gate, but line 689 is spllo(), and we appear to hold no locks at this point. 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 did, plan 9 stacks don't shrink. let's suppose that the address is invalid later. the kernel always moves data to/from user buffers outside of any locks because even valid targets may be paged out. if the address is truely invalid, waserror() will be true and the else branch starting at 714 will be executed - erik
Re: [9fans] ape strtod crash
On Thu Jul 30 04:42:29 EDT 2009, rogpe...@gmail.com wrote:
this ape program gives a floating point exception error:
#include stdlib.h
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.
fixed,
http://9fans.net/archive/2009/01/234
- erik
Re: [9fans] ape strtod crash
2009/7/30 erik quanstrom quans...@quanstro.net: 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 strtod?)
[9fans] [limbo] I tried keyring, but it was the wrong number
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 with the debugging, I don't know how to work out
which function is being called
/usr/local/inferno-os/libinterp/keyring.c:999
c-signa = (*sa-vec-sign)(b, sk-key);
running :
% sign_test secret
[$Keyring] Broken: mpdiv: divide by zero
sh: 5 $Keyring:mpdiv: divide by zero
; stack 5
unknown fn() Module $Keyring PC 1445847206
unknown fn() Module ./sign_test.dis PC 42
externalexec() sh.b:919.2, 30
rsa
maht
l7w4uJyl+UlC6y4cG/tGYaKRcb5ep1igRvlfumxj3aEBDHu1vKZsmMmHzHGCQZl1B9MlAdY+paCoNqP+In1nCcYdn9S9zIBACz9TLXIk9xGCKKhvPw5rlgSwPOEKVcK7O/kvMhZUOPKm+Woefgx9HaenWX2CqzUr56j8kFyZcN1Ax5/zMzzE4d26mHipGOZdWtmjIad8/vYQW9dlOE1U5JCKVQzlyrclzTdYzZ76oVHaDtojjLU8gtOzRxLWmARbU7++QORvgYEOyv+e86fi9iWQlvGsK9FxMci/t+utKlymG4ZE2Cc5+pv0BDp/1Zmd63i8nyyikW/g8EuGBiLyA78l0DcuucOvtSBHc+0tdpZ9/MooNI/p3hMWrBUqPnodwQidQ1cSw+hZaPAMZlE8ipwnhk6SZErRa/+0ZRAfPAvPsxo/hbvfFbK0yG9OqR/4FhVpF+hihn1sSdIdKL11t7lH7x2u0uiSLRn7FH9KuQhflrbfUKeNIAFATzEYyiRZONh4/DG0Hw3PqVTbQXG771p7yDLP4oE5DJmXVZT6JpOWjPUZ/mUeVLCSiuK9EXCAFG0uCjzeWFMnEvPITyiRmp7g2+y4NdO4XgiRr09kmnTkTLXTah9WeF5P7D4HXZsmPiB0S9e+oywmF3DhnWHbgPCK9g+8cYjHziF6HsJ4lsU=
HQ==
eFd8bxsih+qn1QFCbnfWt12ffYVT5dOH8atL7CD/wW4JqMwLuO3sMo4t6MP0jE2RyGmql4abndexjHBoc6FAEJRMde9YvKxWGpNTn6EmJQ3i0Mw062O2bicHXGvcDw0zZIfV+5YffJ0jUw2K8TYK9DWEubvRkJzt2wpwCJAPw3Gu9plW86vISTREipSpbAYmus/rT6glV3O0ssVQRyLZZdO9KPiS8Dj6q5XTq+gEkZkxWzo/gUBKeWobbVWPtlu7MMQ1yYkI/Md1qdOPuGqrLSaez/125PWOvY2POZea/kl66bEcHjDEDWE0Sfluimplement Sign;
include sys.m;
sys: Sys;
sprint: import sys;
include draw.m;
include keyring.m;
keyring: Keyring;
DigestState, PK: import keyring;
Sign: module {
init: fn(nil: ref Draw-Context, args: list of string);
};
Metafilesizemax: con 8*1024;
hash := sha1;
# usage: sign_test [hashname] secretkey
init(nil: ref Draw-Context, argv: list of string)
{
sys = load Sys Sys-PATH;
keyring = load Keyring Keyring-PATH;
if(len argv 1)
hash = hd tl argv;
(skd, err) := readstdin(Metafilesizemax);
if(err != nil) {
} else {
sk := keyring-strtosk(string skd);
if(sk == nil) {
warn(malformed secret key);
} else {
bytes := array of byte some data;
dstate := keyring-sha1(bytes, len bytes, nil, nil);
if(dstate == nil) {
warn(failed to make digest);
} else {
exp := 1258801674; # long time in the future
cert := keyring-sign(sk, exp, dstate, hash);
if(cert == nil)
warn(did not make certificate);
else
sys-print(%s,
keyring-certtostr(cert));
}
}
}
}
readstdin(maxsize: int): (array of byte, string)
{
n := sys-readn(sys-fildes(0), d := array[maxsize] of byte, len d);
if(n 0)
return (nil, sprint(read stdin %r));
if(n == len d)
return (nil, sprint(file stdin too large));
return (d[:n], nil);
}
warn(s: string)
{
sys-fprint(sys-fildes(2), %s\n, s);
}
Re: [9fans] vmware snarf problem
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
Re: [9fans] ape strtod crash
! ; 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
Re: [9fans] Race condition in /sys/src/9/pc/trap.c?
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(USTKTOP-BY2PG) || sp(USTKTOP-sizeof(Sargs)-BY2WD)) 703 validaddr(sp, sizeof(Sargs)+BY2WD, 0); 704 705 up-s = *((Sargs*)(sp+BY2WD)); We verify that the address is correct; is there any reason another thread in the same address space cannot start running after line 703 completes and unmap that memory, causing us to access unmapped memory at line 705? The system call entry is itself an interrupt gate, but line 689 is spllo(), and we appear to hold no locks at this point. 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 did, plan 9 stacks don't shrink. What if sp points inside a segment which is not the actual stack segment? Then could someone else come along and segdetach() it in between the two mentioned lines? let's suppose that the address is invalid later. the kernel always moves data to/from user buffers outside of any locks because even valid targets may be paged out. if the address is truely invalid, waserror() will be true and the else branch starting at 714 will be executed - erik -- Elly 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't noticed this as the cause of a crash. Sape
Re: [9fans] Race condition in /sys/src/9/pc/trap.c?
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 did, plan 9 stacks don't shrink. What if sp points inside a segment which is not the actual stack segment? Then could someone else come along and segdetach() it in between the two mentioned lines? see below: let's suppose that the address is invalid later. the kernel always moves data to/from user buffers outside of any locks because even valid targets may be paged out. if the address is truely invalid, waserror() will be true and the else branch starting at 714 will be executed if you think this is possible, why don't you build a test case and prove that it can happen. the easiest way would be to disable the check completely. - erik
Re: [9fans] Race condition in /sys/src/9/pc/trap.c?
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 ---BeginMessage--- 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(USTKTOP-BY2PG) || sp(USTKTOP-sizeof(Sargs)-BY2WD)) 703 validaddr(sp, sizeof(Sargs)+BY2WD, 0); 704 705 up-s = *((Sargs*)(sp+BY2WD)); We verify that the address is correct; is there any reason another thread in the same address space cannot start running after line 703 completes and unmap that memory, causing us to access unmapped memory at line 705? The system call entry is itself an interrupt gate, but line 689 is spllo(), and we appear to hold no locks at this point. 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 did, plan 9 stacks don't shrink. What if sp points inside a segment which is not the actual stack segment? Then could someone else come along and segdetach() it in between the two mentioned lines? let's suppose that the address is invalid later. the kernel always moves data to/from user buffers outside of any locks because even valid targets may be paged out. if the address is truely invalid, waserror() will be true and the else branch starting at 714 will be executed - erik -- Elly 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't noticed this as the cause of a crash. Sape ---End Message---
Re: [9fans] Race condition in /sys/src/9/pc/trap.c?
ok, forget it... the segments are actualy reference counted. so a process would not be able to unmap a segment in another process. -- cinap ---BeginMessage--- 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(USTKTOP-BY2PG) || sp(USTKTOP-sizeof(Sargs)-BY2WD)) 703 validaddr(sp, sizeof(Sargs)+BY2WD, 0); 704 705 up-s = *((Sargs*)(sp+BY2WD)); We verify that the address is correct; is there any reason another thread in the same address space cannot start running after line 703 completes and unmap that memory, causing us to access unmapped memory at line 705? The system call entry is itself an interrupt gate, but line 689 is spllo(), and we appear to hold no locks at this point. 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 did, plan 9 stacks don't shrink. What if sp points inside a segment which is not the actual stack segment? Then could someone else come along and segdetach() it in between the two mentioned lines? let's suppose that the address is invalid later. the kernel always moves data to/from user buffers outside of any locks because even valid targets may be paged out. if the address is truely invalid, waserror() will be true and the else branch starting at 714 will be executed - erik -- Elly 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't noticed this as the cause of a crash. Sape ---End Message---
Re: [9fans] Race condition in /sys/src/9/pc/trap.c?
... but you can still shrink segments for other processes :-)
(this crashes the kernel)
--
cinap
---BeginMessage---
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
---BeginMessage---
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(USTKTOP-BY2PG) || sp(USTKTOP-sizeof(Sargs)-BY2WD))
703 validaddr(sp, sizeof(Sargs)+BY2WD, 0);
704
705 up-s = *((Sargs*)(sp+BY2WD));
We verify that the address is correct; is there any reason another thread
in the same address space cannot start running after line 703 completes
and unmap that memory, causing us to access unmapped memory at line 705?
The system call entry is itself an interrupt gate, but line 689 is
spllo(), and we appear to hold no locks at this point.
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
did, plan 9 stacks don't shrink.
What if sp points inside a segment which is not the actual stack segment?
Then could someone else come along and segdetach() it in between the two
mentioned lines?
let's suppose that the address is invalid later.
the kernel always moves data to/from user
buffers outside of any locks because even
valid targets may be paged out. if the address
is truely invalid, waserror() will be true and
the else branch starting at 714 will be executed
- erik
-- Elly
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't noticed
this as the cause of a crash.
Sape
---End Message---
---End Message---
#include u.h
#include libc.h
void
main(int argc, char **argv)
{
char *buf;
int fd;
if((fd = open(/dev/zero, OREAD)) 0)
sysfatal(open);
buf = (char*)0x60;
segattach(0, memory, buf, 2*4096);
switch(rfork(RFPROC|RFMEM)){
case -1:
sysfatal(fork);
break;
case 0:
for(;;){
read(fd, buf+4096, 4096);
}
}
sleep(1000);
segbrk(buf, buf+4096);
}
Re: [9fans] Race condition in /sys/src/9/pc/trap.c?
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't noticed
this as the cause of a crash.
just to beat a dead horse, i disabled the check in question
and ran the following program with an invalid address.
the program faulted and the kernel did not care.
; cat evil.c
#include u.h
#include libc.h
extern void evil(void);
void
main(void)
{
evil();
exits();
}
; cat evil.s
TEXT evil(SB), $0
PUSHL SP
MOVL$0xa000, SP
MOVL$1, AX
INT $64
POPLSP
RET
% 8.out
8.out 78: suicide: invalid address 0xa000/24 in sys call pc=0x1046
- erik
[9fans] 9p question
Hi, How come you can't TWalk along an open Fid? Thanks, -- vs
Re: [9fans] Race condition in /sys/src/9/pc/trap.c?
just stop processes with s-ref 1 from freeing parts of s with ibrk. it's not as if anything ever does in practice.
Re: [9fans] 9p fids and references
2009/7/30 hugo rivera uai...@gmail.com: [...] 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 resources associated with the file, as opposed to resources private to the fid, you have to reference count them (or poison any fids that point to the file, if you *really* want the resource to go away)
Re: [9fans] nvram
2009/7/29 erik quanstrom quans...@quanstro.net: 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. 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 caused by some other problem shortly after (the motherboard seems to have given up on me also), but it raised the question - does an unsuccesful write to nvram halt the boot process? -sqweek
Re: [9fans] 9p question
On Thu, Jul 30, 2009 at 8:28 AM, Venkatesh Srinivasm...@acm.jhu.edu 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 implicit close? And the operation isn't needed by the Plan 9 kernel anyway, so out it goes. In the current 9P protocol, I think it would be fine to allow a walk to start at an open fid as long as newfid was being used to create a new fid. This would make it easy to implement fchdir on Unix. Russ
Re: [9fans] nvram
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 caused by some other problem shortly after (the motherboard seems to have given up on me also), but it raised the question - does an unsuccesful write to nvram halt the boot process? no. it happens to me all the time. (when there is no place to write nvram, as when no disk is partitioned.) - erik
[9fans] off topic: manual sets
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
Re: [9fans] 9p question
On Thu, Jul 30, 2009 at 1:08 PM, Russ Coxr...@swtch.com wrote: On Thu, Jul 30, 2009 at 8:28 AM, Venkatesh Srinivasm...@acm.jhu.edu 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 implicit close? And the operation isn't needed by the Plan 9 kernel anyway, so out it goes. In the current 9P protocol, I think it would be fine to allow a walk to start at an open fid as long as newfid was being used to create a new fid. This would make it easy to implement fchdir on Unix. 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? iru
Re: [9fans] vmware installation problems
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/
Re: [9fans] [limbo] I tried keyring, but it was the wrong number
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/secret one, producing something with plenty of zero mpint potential divisors. b00f!
Re: [9fans] ceph
2009/7/30 Roman V Shaposhnik r...@sun.com: 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 of lustre (seems like it's a userspace version) which we use at work. Does a damn fine job - as long as you get a stable version. We have run into issues trying out new versions several times... -sqweek
Re: [9fans] nvram
2009/7/31 erik quanstrom quans...@quanstro.net: 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 caused by some other problem shortly after (the motherboard seems to have given up on me also), but it raised the question - does an unsuccesful write to nvram halt the boot process? 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
Re: [9fans] nvram
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
Re: [9fans] nvram
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 process to die. -Steve
Re: [9fans] nvram
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) fails - perhaps it was this write to a dead disk that caused the boot process to die. i hate to disagree. but i think you may have typed your auth information incorrectly — that does cause a panic. but not having a plan9.nvr or nvram partition does not. here's a demo i just ran: baxley# 9fat: baxley# rm /n/9fat/plan9.nvr baxley# echo reboot/dev/reboot [...] 2040M memory: 108M kernel data, 1931M user, 2556M swap sdE0: LBA 3,931,200 sectors SATADOM H Type rs1.a000 20090504AA13 [newdrive] readnvram: couldn't find nvram can't read nvram: unknown device in # filename authid: bootes authdom: plan9.quanstro.net secstore key: password: can't write key to nvram: unknown device in # filename version...time... nit: starting /bin/rc baxley# now if i mistype my auth information, i get version...authpanic: boot process died: unknown entication failed (auth_proxy rpc write: : bad key), trying mount anyways boot: mount /: attach -- unknown user or failed authentication dumpstack unfortunately, at this point i'm stuck in a reboot loop and i can only disconnect the offending media. - erik
Re: [9fans] 9p question
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
Re: [9fans] off topic: manual sets
also, do you know about: http://plan9.bell-labs.com/7thEdMan/ -Steve
Re: [9fans] off topic: manual sets
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-labs.com/7thEdMan/ -Steve winmail.dat
