Re: [9fans] kw IC
On Fri, Sep 3, 2010 at 5:47 PM, ron minnich rminn...@gmail.com wrote: They have the added advantage of the exponent after the I. Reminds me of the degrees of infinity. So instead of sucketh-null, I guess they are sucketh-1? Ron, the suck is uncountable ak
Re: [9fans] too many system calls.
Is ratrace usable on native Plan 9 (I understand it's in use on 9vx
thus far)? I don't see a /proc/n/syscall file for any of my processes;
is there some kernel patch for this?
Thanks,
ak
On Fri, Sep 3, 2010 at 10:14 PM, ron minnich rminn...@gmail.com wrote:
Glibc /bin/date on Linux runs around 140 system calls. A quick pass
with ratrace shows that plan 9 /bin/date has 10.
The conclusion is clear: plan 9 date has way too much overhead. It's
1/14 the number of system calls of Glibc; why's it so big?
A quick pass on getpid() fixes the problem:
#include u.h
#include libc.h
#include tos.h
int
getpid(void)
{
return _tos-pid;
}
Now we're down to seven system calls. 1/20 of glibc. Much better! :-)
ron
Re: [9fans] 8086 Interpreter
In theory, with these I would simply get a binary file from the assembly, which I could then run on, say, dosbox in 8086 mode in Windows? You'd get a raw file with instructions in it. It would be up to you to turn that into an appropriate executable. (If you renamed it foo.com that would probably be enough for DOS.) Russ
Re: [9fans] too many system calls.
On Sat Sep 4 03:59:16 EDT 2010, aku...@mail.nanosouffle.net wrote: Is ratrace usable on native Plan 9 (I understand it's in use on 9vx thus far)? I don't see a /proc/n/syscall file for any of my processes; is there some kernel patch for this? acid is perfectly capabible of doing this. see the man page on acid(1) which covers the truss library. - erik
Re: kw I²C
eric quanstrom: if i read the marvell specification correctly, it uses i²s, not i²c. wikipedia has a pointer to the phillips specification. It uses i²s to for the data (sound) transport. the control for the codec is seperate, the codec is a cs42l51, which has an i²s interface for data and either an i²c or spi interface for control, with the spi write-only. Bankim Bhavsar: Though Immediate Command/Response Interface should work, CORB/RIRB is the recommended way to send/receive commands/responses from the codec. Reading the datasheet of the codec, I havn't found any mention of CORB or RIRB, so I would hazard a guess that that's not what I want. But still, what is CORB/RIRB? In light of further digging, the functional specification does talk about TWSI Bus Operation. twsi ≅ i²c. I guess I'll work on that now. Which, according to the openrd schematics, connects to the audio codec and the SMBus connector. ... tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] too many system calls.
On Sat, Sep 4, 2010 at 12:58 AM, Akshat Kumar aku...@mail.nanosouffle.net wrote: Is ratrace usable on native Plan 9 (I understand it's in use on 9vx thus far)? I don't see a /proc/n/syscall file for any of my processes; is there some kernel patch for this? One could take the modified version of my syscall tracing code that jmk put into the 9k kernel and put that into the regular plan 9 kernel. He did a very nice job of making it almost completely live in port and it's a good lesson in getting it right, worth looking at. Paper submitted to iwp9 ... I don't run any systems in my lab with the 9 kernel any more so I have not been motivated to make the change myself. I have used ratrace heavily on Blue Gene for debugging, and it's been much easier to use than Acid in that environment. I still use acid truss at times, when ratrace is not available, but I find ratrace far more useful when it is there. Actually, I now realize it's worse than that: I've stopped using systems that don't have ratrace because I find debugging problems without some sort of syscall trace to be too time-consuming. Note that it's easy to drop ratrace into scripts and that's handy. The getpid change I described here is now in my bitbucket repo https://rminn...@bitbucket.org/rminnich/sysfromiso That code builds and works on 9vx. I know there were some issues a few weeks ago with the builds which is why I mention it here. You should be able to build that userland code and run it on any Plan 9 system. I have built that tree to support arm, for example. The vx32 I am using is a combo of changes from yiyu and me and is found at https://rminn...@bitbucket.org/rminnich/vx32 ron
Re: [9fans] kw I²C
Though Immediate Command/Response Interface should work, CORB/RIRB is the recommended way to send/receive commands/responses from the codec. Reading the datasheet of the codec, I havn't found any mention of CORB or RIRB, so I would hazard a guess that that's not what I want. But still, what is CORB/RIRB? Sorry for the confusion. I think you are referring to a different audio card. For the Intel High-Definition Audio Controller (http://www.intel.com/standards/hdaudio/pdf/HDAudio_01.pdf) CORB = Command Output Ring Buffer RIRB = Response Input Ring Buffer This is the mechanism used by HDAudio Controller to communicate with the codec attached. -Bankim.
[9fans] latest plan9.iso
Anyone tried to install from a very recent plan9.iso? I just downloaded the latest one this morning. I'm trying to install into a VMware ESXi virtual machine. I installed another just about a week ago, and did not encounter any trouble. I frequently have to plug in the correct SCSI device for the CD, but this time, I get the following message before the boot from: prompt: cpu0: 2796MHz PentiumIV/Xeon loop 47254 apm ax=f000 cx=f000 dx=40 di= ebx=564f esi=-1 no ethernet interfaces recognized bus dev type vid did intl memory 0 17/0 02 00 00 1022 2000 11 0:1401 128 0 18/0 02 00 00 1022 2000 11 0:1481 128 Unknown boot device: sdD0!cdboot!9pcflop.gz Boot devices: fd0 boot from: I can specify sdC0!cdboot!9pcflop.gz, and it'll load the installer, but it doesn't detect the virtual hard drive. In the past, the official plan9.iso has had no trouble on ESXi. I'm downloading 9atom as I type this, but just wanted to see if anyone else has had trouble with the latest official iso... Many thanks! -Ben
Re: [9fans] latest plan9.iso
apologies for the noise... please disregard. Thought I had the lsilogic controller working once before, but guess not. buslogic it is. -Original Message- From: 9fans-boun...@9fans.net on behalf of Benjamin Huntsman Sent: Sat 9/4/2010 3:37 PM To: 9fans@9fans.net Subject: [9fans] latest plan9.iso Anyone tried to install from a very recent plan9.iso? I just downloaded the latest one this morning. I'm trying to install into a VMware ESXi virtual machine. I installed another just about a week ago, and did not encounter any trouble. I frequently have to plug in the correct SCSI device for the CD, but this time, I get the following message before the boot from: prompt: cpu0: 2796MHz PentiumIV/Xeon loop 47254 apm ax=f000 cx=f000 dx=40 di= ebx=564f esi=-1 no ethernet interfaces recognized bus dev type vid did intl memory 0 17/0 02 00 00 1022 2000 11 0:1401 128 0 18/0 02 00 00 1022 2000 11 0:1481 128 Unknown boot device: sdD0!cdboot!9pcflop.gz Boot devices: fd0 boot from: I can specify sdC0!cdboot!9pcflop.gz, and it'll load the installer, but it doesn't detect the virtual hard drive. In the past, the official plan9.iso has had no trouble on ESXi. I'm downloading 9atom as I type this, but just wanted to see if anyone else has had trouble with the latest official iso... Many thanks! -Ben winmail.dat
Re: [9fans] latest plan9.iso
On Sat Sep 4 19:09:33 EDT 2010, bhunts...@mail2.cu-portland.edu wrote: apologies for the noise... please disregard. Thought I had the lsilogic controller working once before, but guess not. buslogic it is. [...] cpu0: 2796MHz PentiumIV/Xeon loop 47254 apm ax=f000 cx=f000 dx=40 di= ebx=564f esi=-1 no ethernet interfaces recognized bus dev type vid did intl memory 0 17/0 02 00 00 1022 2000 11 0:1401 128 0 18/0 02 00 00 1022 2000 11 0:1481 128 Unknown boot device: sdD0!cdboot!9pcflop.gz yet there appears to be something wrong. the 1022/2000 (amd 79c970) should be recognized. - erik
[9fans] resizing desktops uncer vmware vs. parallels
For ages I've run diskless terminals under Parallels, and aux/vga would quite cheerfully resize the Parallels window to match anything I told it. Recently I had to migrate from Parallels to Fusion. Resizing doesn't work any more. Furthermore, I'm buggered if I can programmatically figure out what combinations of screen size+depth will work in Fusion without making the terminal instance panic. The list archives and the wiki are absent of advice.
[9fans] resizing desktops under vmware vs. parallels
[ Let me try again, this time hitting Post vs |fmt :-) ] For ages I've run diskless terminals under Parallels, and aux/vga would quite cheerfully resize the Parallels window to match anything I told it. Recently I had to migrate from Parallels to Fusion. Resizing doesn't work any more. Furthermore, I'm buggered if I can programmatically figure out what combinations of screen size+depth will work in Fusion without making the terminal instance panic. The list archives and the wiki are absent of advice. Looking at the aux/vga output I also can't parse a set of likely screen dimension values. Has anyone else successfully wrestled with this?
Re: [9fans] latest plan9.iso
i came across this the other day - i thought i'd finally found a machine for which P9 supports nothing. in fact i beat you - no PCI devices at all. any help appreciated. it boots any flavour of windows. new HP Pav quadcore. brucee On Sun, Sep 5, 2010 at 11:02 AM, erik quanstrom quans...@quanstro.net wrote: On Sat Sep 4 19:09:33 EDT 2010, bhunts...@mail2.cu-portland.edu wrote: apologies for the noise... please disregard. Thought I had the lsilogic controller working once before, but guess not. buslogic it is. [...] cpu0: 2796MHz PentiumIV/Xeon loop 47254 apm ax=f000 cx=f000 dx=40 di= ebx=564f esi=-1 no ethernet interfaces recognized bus dev type vid did intl memory 0 17/0 02 00 00 1022 2000 11 0:1401 128 0 18/0 02 00 00 1022 2000 11 0:1481 128 Unknown boot device: sdD0!cdboot!9pcflop.gz yet there appears to be something wrong. the 1022/2000 (amd 79c970) should be recognized. - erik
Re: [9fans] latest plan9.iso
On Sat Sep 4 22:56:22 EDT 2010, bruce.el...@gmail.com wrote:
i came across this the other day - i thought i'd finally found a
machine for which P9 supports nothing.
in fact i beat you - no PCI devices at all.
any help appreciated. it boots any flavour of windows. new HP Pav quadcore.
9atom has this change to 9load. this fixed up a funky
motherboard with ipmi.
pci.c:528,535 - /n/sources/plan9/sys/src/boot/pc/pci.c:514,520
* according to the spec.
*/
n = inl(PciADDR);
-
- if(!(n 0x7f03)){
+ if(!(n 0x7FF0)){
outl(PciADDR, 0x8000);
outb(PciADDR+3, 0);
if(inl(PciADDR) 0x8000){
perhaps this will help. if not the value of n would
be interesting.
in the same vein, i've got several machines in the lab
that have pci busses = 64. this change was all that
was required (and setting *pcimaxbno in the .ini
file for the kernel)
pci.c:37,43 - /n/sources/plan9/sys/src/boot/pc//pci.c:36,42
static Lock pcicfglock;
static Lock pcicfginitlock;
static int pcicfgmode = -1;
- static int pcimaxbno = 255;
+ static int pcimaxbno = 7;
static int pcimaxdno;
static Pcidev* pciroot;
static Pcidev* pcilist;
i'm tempted to set maxbno to 255 in the kernel as well, but
i don't think i understand why it was set to less than 255
in the first place. if this is just a speedup, i'd be tempted.
anyone with first-hand knowledge?
- erik
