Re: [9fans] suicide message on vmware
On Fri, 06 Jun 2014 10:48:21 +0530 Ramakrishnan Muthukrishnan vu3...@gmail.com wrote: Well, looks like I cannot run any binaries anymore and getting the suicide message! I don't have anything critical on this vm image and can re-install it. But I want to see if I can recover it and how. I will re-read the syscall 53 thread to look for any solutions. Aren't the old binaries saved under the same name but prefixed with _? If you haven't rebooted yet, you can use those to copy the new kernel to the FAT partition. Ramakrishnan On Fri, Jun 6, 2014 at 9:35 AM, Ramakrishnan Muthukrishnan vu3...@gmail.com wrote: On Fri, Jun 6, 2014 at 8:51 AM, erik quanstrom quans...@quanstro.net wrot e: On Thu Jun 5 23:17:37 EDT 2014, vu3...@gmail.com wrote: Hi, I just saw a suicide message on 9atom running on plan9 while updating the system: % replica/pull -v /dist/replica/network After a while, I saw this printed, but the replica/pull is proceeding without any problem. (not completely readable because stats window overwrote the screen) ... bad sys call number 53 pc 101c6 timesync 57: suicide: sys: bad syscall pc=0x101c6 nsec! argh! Ah, I should have remembered. So, I guess, I got the updating sequence wrong? First upgrade kernel, then upgrade the rest? -- Ramakrishnan -- Ramakrishnan
Re: [9fans] suicide message on vmware
On Fri, Jun 6, 2014 at 11:30 AM, Bakul Shah ba...@bitblocks.com wrote: On Fri, 06 Jun 2014 10:48:21 +0530 Ramakrishnan Muthukrishnan vu3...@gmail.com wrote: Well, looks like I cannot run any binaries anymore and getting the suicide message! I don't have anything critical on this vm image and can re-install it. But I want to see if I can recover it and how. I will re-read the syscall 53 thread to look for any solutions. Aren't the old binaries saved under the same name but prefixed with _? If you haven't rebooted yet, you can use those to copy the new kernel to the FAT partition. Thanks, I didn't know that old binaries are kept prefixed with _. Very nice! I copied the kernels from David (9legacy.org/download/kernel.tar.bz2), untar'ed it. This copied into /386/9pcf. Then I do: 9fat: _cp /386/9pcf /n/9fat/9pcf But I get an error message: '/n/9fat/9pcf clone failed'.
Re: [9fans] suicide message on vmware
On Fri, 06 Jun 2014 13:02:14 +0530 Ramakrishnan Muthukrishnan vu3...@gmail.com wrote: On Fri, Jun 6, 2014 at 11:30 AM, Bakul Shah ba...@bitblocks.com wrote: On Fri, 06 Jun 2014 10:48:21 +0530 Ramakrishnan Muthukrishnan vu3rdd@gmail .com wrote: Well, looks like I cannot run any binaries anymore and getting the suicide message! I don't have anything critical on this vm image and can re-install it. But I want to see if I can recover it and how. I will re-read the syscall 53 thread to look for any solutions. Aren't the old binaries saved under the same name but prefixed with _? If you haven't rebooted yet, you can use those to copy the new kernel to the FAT partition. Thanks, I didn't know that old binaries are kept prefixed with _. Very nice! I copied the kernels from David (9legacy.org/download/kernel.tar.bz2), untar'ed it. This copied into /386/9pcf. Then I do: I don't know what's on 9legacy.org. Copy the labs kernel from /386/9pcf since after reboot it will support the updated labs binaries that use nsec() syscall. My assumption is you are running an old kernel with new binaries. 9fat: _cp /386/9pcf /n/9fat/9pcf But I get an error message: '/n/9fat/9pcf clone failed'. 9fat: will use the new binaries! Look at /rc/bin/9fat: and follow the steps using the old binaries. The following may be enough. _dossrv _mount -c /srv/dos /n/9fat /dev/sdC0/9fat Unless dossrv is already running (use _ps) and /n/9fat is already mounted, in which case you will have to _unmount it and kill dossrv.
Re: [9fans] suicide message on vmware
Hi, On Fri, Jun 6, 2014 at 1:30 PM, Bakul Shah ba...@bitblocks.com wrote: On Fri, 06 Jun 2014 13:02:14 +0530 Ramakrishnan Muthukrishnan vu3...@gmail.com wrote: On Fri, Jun 6, 2014 at 11:30 AM, Bakul Shah ba...@bitblocks.com wrote: On Fri, 06 Jun 2014 10:48:21 +0530 Ramakrishnan Muthukrishnan vu3rdd@gmail .com wrote: Well, looks like I cannot run any binaries anymore and getting the suicide message! I don't have anything critical on this vm image and can re-install it. But I want to see if I can recover it and how. I will re-read the syscall 53 thread to look for any solutions. Aren't the old binaries saved under the same name but prefixed with _? If you haven't rebooted yet, you can use those to copy the new kernel to the FAT partition. Thanks, I didn't know that old binaries are kept prefixed with _. Very nice! I copied the kernels from David (9legacy.org/download/kernel.tar.bz2), untar'ed it. This copied into /386/9pcf. Then I do: I don't know what's on 9legacy.org. Copy the labs kernel from /386/9pcf since after reboot it will support the updated labs binaries that use nsec() syscall. My assumption is you are running an old kernel with new binaries. Yes. 9fat: _cp /386/9pcf /n/9fat/9pcf But I get an error message: '/n/9fat/9pcf clone failed'. 9fat: will use the new binaries! Look at /rc/bin/9fat: and Ah, that's right. Thanks. follow the steps using the old binaries. The following may be enough. _dossrv _mount -c /srv/dos /n/9fat /dev/sdC0/9fat Worked perfectly! Thanks. -- Ramakrishnan
[9fans] Glenda's world weary cousin
Glenda's world weary cousin https://pbs.twimg.com/media/BpZjUjXIYAIJiua.jpg -Steve
Re: [9fans] What is Plan9 exactly?
I'm a Unix fan, I use BSD, Minix, Linux, and any unix-like OS I can get my hands on. Why? P.S. The kernel is monolithic. Although, IIRC, there were attempts to make it a hybrid. 2014-06-05 23:33 GMT+03:00 Yoann Padioleau p...@fb.com: Nice! On Jun 4, 2014, at 8:14 PM, s...@9front.org wrote: https://urldefense.proofpoint.com/v1/url?u=http://code.google.com/p/plan9front/wiki/fqa0k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=%2FN9d7W2LRwZks3eyFNLr8Q%3D%3D%0Am=932ql2s0yZzSIWvDmA7Ow3MAsKVfP6fSFQC%2Fj%2BdntMU%3D%0As=5073da3bad45a50f3d32794c907cb48394fd92ea90ebf6a999b2470190f58110 sl
Re: [9fans] Glenda's world weary cousin
On 06/06/2014 11:10, Steve Simon wrote: Glenda's world weary cousin https://pbs.twimg.com/media/BpZjUjXIYAIJiua.jpg Maybe the nsec patch would have been refused by this guy, right?! (not a troll, just kidding!) Nicolas
Re: [9fans] What is Plan9 exactly?
P.S. The kernel is monolithic. Although, IIRC, there were attempts to make it a hybrid. this is far from the full story. because of the mount driver, many things may be in the kernel or userland according to what makes sense. for example, the ip stack has moved back and forth several times. the usb interface implementations are in user space. etc. partfs(8) (sic, should be in section 4) and sdloop(3) in 9atom are both loopback drivers that appear to be served through sd(3), but partfs is in userspace and sdloop is in the kernel. likewise, resources can be imported from other machines' kernels or userspace in the same way. for example, i can import a gateway's ip stack and use it directly as if it were local. thus, while the kernel is fairly traditional, the capabilities are not. - erik
Re: [9fans] Glenda's world weary cousin
On Fri Jun 6 08:16:20 EDT 2014, nberc...@yahoo.fr wrote: On 06/06/2014 11:10, Steve Simon wrote: Glenda's world weary cousin https://pbs.twimg.com/media/BpZjUjXIYAIJiua.jpg Maybe the nsec patch would have been refused by this guy, right?! (not a troll, just kidding!) there was no patch. it just went in. - erik
Re: [9fans] suicide message on vmware
On Jun 5, 2014, at 8:15 PM, Ramakrishnan Muthukrishnan vu3...@gmail.com wrote: Hi, I just saw a suicide message on 9atom running on plan9 while updating the system: % replica/pull -v /dist/replica/network I missed that you were running 9atom. Using old binaries to copy the new kernel to /n/9fat and rebooting means now you're running the bell labs kernel. I don't know how different the two kernels are but if you want to continue running 9atom everything, you may have to undo nsec related changes in the userland. More generally, as this nsec change demonstrates, if you rely on sources over which you have no control you also have local changes, you pretty much have to treat the external sources as a vendor branch and do a careful merge to avoid such surprises.
[9fans] MIPS _xdec kernel vs. user land
i know it's not used much, but this is very curious, and if the kernel version is correct, the user space version needs correcting, too. the rb kernel version starts with TEXT_xdec(SB), $0 SYNC why is a sync necessary? i would think, if LL/SC don't do what they do atomicly, then we've already lost, otherwise no sync is necessary. - erik
Re: [9fans] What is Plan9 exactly?
thus, while the kernel is fairly traditional, the capabilities are not. They should be, but tradition is slow to catch on. L.
Re: [9fans] suicide message on vmware
On Fri Jun 6 11:26:13 EDT 2014, ba...@bitblocks.com wrote: On Jun 5, 2014, at 8:15 PM, Ramakrishnan Muthukrishnan vu3...@gmail.com wrote: Hi, I just saw a suicide message on 9atom running on plan9 while updating the system: % replica/pull -v /dist/replica/network I missed that you were running 9atom. Using old binaries to copy the new kernel to /n/9fat and rebooting means now you're running the bell labs kernel. I don't know how different the two kernels are but if you want to continue running 9atom everything, you may have to undo nsec related changes in the userland. More generally, as this nsec change demonstrates, if you rely on sources over which you have no control you also have local changes, you pretty much have to treat the external sources as a vendor branch and do a careful merge to avoid such surprises. that's not how replica works. replica respects local changes. however, since in this case two different databases were mixed up, there is little chance that the user has a sane system. - erik
Re: [9fans] suicide message on vmware
On Fri, Jun 6, 2014 at 9:05 PM, erik quanstrom quans...@quanstro.net wrote: On Fri Jun 6 11:26:13 EDT 2014, ba...@bitblocks.com wrote: On Jun 5, 2014, at 8:15 PM, Ramakrishnan Muthukrishnan vu3...@gmail.com wrote: Hi, I just saw a suicide message on 9atom running on plan9 while updating the system: % replica/pull -v /dist/replica/network I missed that you were running 9atom. Using old binaries to copy the new kernel to /n/9fat and rebooting means now you're running the bell labs kernel. I don't know how different the two kernels are but if you want to continue running 9atom everything, you may have to undo nsec related changes in the userland. More generally, as this nsec change demonstrates, if you rely on sources over which you have no control you also have local changes, you pretty much have to treat the external sources as a vendor branch and do a careful merge to avoid such surprises. that's not how replica works. replica respects local changes. however, since in this case two different databases were mixed up, there is little chance that the user has a sane system. What is the recommended way keep a 9atom system up to date? -- Ramakrishnan
Re: [9fans] suicide message on vmware
that's not how replica works. replica respects local changes. however, since in this case two different databases were mixed up, there is little chance that the user has a sane system. What is the recommended way keep a 9atom system up to date? running pull as user glenda, same as the standard distribution. there are options to update just parts of the system at a time. - erik
Re: [9fans] suicide message on vmware
On Fri, Jun 6, 2014 at 8:54 PM, Bakul Shah ba...@bitblocks.com wrote: On Jun 5, 2014, at 8:15 PM, Ramakrishnan Muthukrishnan vu3...@gmail.com wrote: Hi, I just saw a suicide message on 9atom running on plan9 while updating the system: % replica/pull -v /dist/replica/network I missed that you were running 9atom. Using old binaries to copy the new kernel to /n/9fat and rebooting means now you're running the bell labs kernel. I don't know how different the two kernels are but if you want to continue running 9atom everything, you may have to undo nsec related changes in the userland. I thought that replica/pull on a 9atom would pull 9atom binaries and not the labs version. Looks like that assumption is wrong? -- Ramakrishnan
Re: [9fans] suicide message on vmware
I thought that replica/pull on a 9atom would pull 9atom binaries and not the labs version. Looks like that assumption is wrong? only on .iso versions of 9atom several years old. to correct this issue, you'd have to sync /usr/glenda/bin/rc/pull first. - erik
Re: [9fans] suicide message on vmware
On Fri, Jun 6, 2014 at 9:25 PM, erik quanstrom quans...@quanstro.net wrote: I thought that replica/pull on a 9atom would pull 9atom binaries and not the labs version. Looks like that assumption is wrong? only on .iso versions of 9atom several years old. to correct this issue, you'd have to sync /usr/glenda/bin/rc/pull first. Thanks. I just discovered the existence of /dist/replica/atom which is used by /usr/glenda/bin/rc/pull script. -- Ramakrishnan
Re: [9fans] suicide message on vmware
On Fri Jun 6 12:08:28 EDT 2014, vu3...@gmail.com wrote: On Fri, Jun 6, 2014 at 9:25 PM, erik quanstrom quans...@quanstro.net wrote: I thought that replica/pull on a 9atom would pull 9atom binaries and not the labs version. Looks like that assumption is wrong? only on .iso versions of 9atom several years old. to correct this issue, you'd have to sync /usr/glenda/bin/rc/pull first. Thanks. I just discovered the existence of /dist/replica/atom which is used by /usr/glenda/bin/rc/pull script. yup! did you do it some other way? that is, did i leave something dangerous lying about? - erik
Re: [9fans] suicide message on vmware
On Fri, Jun 6, 2014 at 9:56 PM, erik quanstrom quans...@quanstro.net wrote: On Fri Jun 6 12:08:28 EDT 2014, vu3...@gmail.com wrote: On Fri, Jun 6, 2014 at 9:25 PM, erik quanstrom quans...@quanstro.net wrote: I thought that replica/pull on a 9atom would pull 9atom binaries and not the labs version. Looks like that assumption is wrong? only on .iso versions of 9atom several years old. to correct this issue, you'd have to sync /usr/glenda/bin/rc/pull first. Thanks. I just discovered the existence of /dist/replica/atom which is used by /usr/glenda/bin/rc/pull script. yup! did you do it some other way? that is, did i leave something dangerous lying about? Well, this morning when I tried to update, I did this: replica/pull -v /dist/replica/network # instead of /dist/replica/atom instead of invoking the /usr/glenda/bin/rc/pull (which pulls from /dist/replica/atom). Sorry for the confusion. Entirely my fault and ignorance. -- Ramakrishnan
[9fans] power _xinc vs ainc
the /sys/src/9/ppc kernel adds this line to both _xinc and _xdec DCBF(R4)/* fix for 603x bug */ would this also be needed for the c library version? - erik
Re: [9fans] suicide message on vmware
On Fri, 06 Jun 2014 11:35:08 EDT erik quanstrom quans...@quanstro.net wrote: On Fri Jun 6 11:26:13 EDT 2014, ba...@bitblocks.com wrote: On Jun 5, 2014, at 8:15 PM, Ramakrishnan Muthukrishnan vu3...@gmail.com wrote: Hi, I just saw a suicide message on 9atom running on plan9 while updating the system: % replica/pull -v /dist/replica/network I missed that you were running 9atom. Using old binaries to copy the new ke rnel to /n/9fat and rebooting means now you're running the bell labs kernel. I don't know how different the two kernels are but if you want to continue ru nning 9atom everything, you may have to undo nsec related changes in the user land. More generally, as this nsec change demonstrates, if you rely on sources ov er which you have no control you also have local changes, you pretty much h ave to treat the external sources as a vendor branch and do a careful merge to avoid such surprises. that's not how replica works. replica respects local changes. however, since in this case two different databases were mixed up, there is little chance that the user has a sane system. What two databases? Replica respects local changes at the file level. You still have to do a manual merge if the server version changed as well. The bigger issue is that the unit of update needs to be a *set* of files that take a system from one consistent state to another. If you update only a subset of files, you may be left with an inconsistent system. Another issue: your local changes may depend on the contents of a file that you never changed so the update can overwrite it with new and possibly incompatible contents. For all these reasons external sources should go in a vendor branch. And I never understood why binaries are pulled. It is not like on Linux/*BSD where building binaries takes a long time. And replica ( related scripts) can't deal with changes like syscall updates. For a foolproof update in case of incompatible kernel changes (and if you're running the same distribution as you pulled from), you should 1. build all binaries and new kernels (but not install) 2. install the new kernel ( loader) on the boot partition 3. reboot 4. install new binaries 5. reboot If you have local changes, you have to add 0. pull in a vendor branch and merge changes
Re: [9fans] suicide message on vmware
What two databases? the divergent versions of /sys/lib/dist/replica/plan9.db and its log on the sources and 9atom. Replica respects local changes at the file level. You still have to do a manual merge if the server version changed as well. that's what i said, but this is remove vs remote, and replica is unable to deal with this sort of issue. The bigger issue is that the unit of update needs to be a *set* of files that take a system from one consistent state to another. If you update only a subset of files, you may be left with an inconsistent system. it would be a great feature, but it's unrelated to this failure. i'm part of the way there with the patch system in atom. in theory a few scripts could allow one to add changes as required. unfortunately, it's pretty easy for this to go wrong, even with tools like hg. For a foolproof update in case of incompatible kernel changes (and if you're running the same distribution as you pulled from), you should if one recalls back to the beginning of the 4th edition, the install cd would upgrade things as well as to initial installs. - erik
Re: [9fans] Glenda's world weary cousin
On Fri, Jun 6, 2014 at 7:14 AM, Nicolas Bercher nberc...@yahoo.fr wrote: On 06/06/2014 11:10, Steve Simon wrote: Glenda's world weary cousin https://pbs.twimg.com/media/BpZjUjXIYAIJiua.jpg Maybe the nsec patch would have been refused by this guy, right?! (not a troll, just kidding!) I thought patch/apply just copied candidate patches to sorry? (definitely a troll, not kidding!)
Re: [9fans] Plan 9 image for Google Compute Engine?
DONE, now beer. http://code.google.com/p/plan9front/source/detail?r=2f51489d42116c85159dc1649ab82cec9a766542 -- cinap
[9fans] glenda at 3200x1800x32
i was kindly sent this by someone who's had success with a modern laptop: Hello Erik Just tried the latest usb image and wanted to let you know it works quite well. I get this message, though: acpinitr: pm1sts 0x400 pm1en 0x100 repeated all the time, getting a lot of context switching if i read stats -lmisce correctly. The screen cat [can] get to 3200x1800x32 with vesa, which is the native panel resolution, and it works quite well. This laptop has an intel and a nvidia card. I guess it is using the intel by default. ... The notebook also has two disks (liteon mstata 32GB and samsung evo 250GB) and both get listed in /dev/sd*. They are partitioned using GPT partition tables, which i guess 9atom does not handle yet. So here is another proof that plan9 can run on recent hardware, including beautiful notebooks :) sadly, no onboard ethernet. i think the usb stick ethernet should work with a little poking. - erik
Re: [9fans] glenda at 3200x1800x32
So here is another proof that plan9 can run on recent hardware, including beautiful notebooks :) Is any more specific information available about the manufacturer and model of the laptop? sl
Re: [9fans] glenda at 3200x1800x32
On Sat Jun 7 00:34:03 EDT 2014, s...@9front.org wrote: So here is another proof that plan9 can run on recent hardware, including beautiful notebooks :) Is any more specific information available about the manufacturer and model of the laptop? i quote, dell xps 15 (model 9530) from late 2013 - erik
[9fans] advanced core Linux kernel features not in plan9
Hi, I was curious to know which core features of the Linux kernel are not implemented in the plan9 kernel. By core I mean that I know plan9 does not have all the drivers, filesystems, buses, etc Linux has, but it has many of its core features (virtual memory, paging, swapping, demand loading, copy on write, etc), and even more. For instance I was not able to find any code related to the buffer cache Linux has. If you open a big file in a plan9 process, then close it, and later you open it again, will you pay the IO again? Or is it cached somewhere?
Re: [9fans] advanced core Linux kernel features not in plan9
I was curious to know which core features of the Linux kernel are not implemented in the plan9 kernel. By core I mean that I know plan9 does not have all the drivers, filesystems, buses, etc Linux has, but it has many of its core features (virtual memory, paging, swapping, demand loading, copy on write, etc), and even more. on a good day with the right kernel you may get paging with plan 9, but never swapping. i've turned it off in my kernels, and it's not coming back. it's hard to use with multiple page sizes, and as charles notes, devices are either big enough to not need it, or too small to have anything to page out to. For instance I was not able to find any code related to the buffer cache Linux has. If you open a big file in a plan9 process, then close it, and later you open it again, will you pay the IO again? Or is it cached somewhere? there is no buffer cache in plan 9. file servers do cache, but they are typically not on the same box, so it should be clear why there is no buffer cache. - erik
Re: [9fans] advanced core Linux kernel features not in plan9
theres a kernel file cache for cached mounts (see the -C option), tho its broken in labs plan9. pages of executables are cached. the disk fileservers implement a buffer cache to avoid going to disk and do lazy writing out dirty filesystem blocks. plan9 is a distributed system. the disk fileservers are really network fileservers. and the local kernel isnt the only mutator so it cant invalidate the cache without going to the fileserver. -- cinap
