* [9fans] third edition, installation experiences
@ 2000-06-08 19:18 Scott
0 siblings, 0 replies; 15+ messages in thread
From: Scott @ 2000-06-08 19:18 UTC (permalink / raw)
My notes are at home, but here are a few comments from memory.
* The installation instructions didn't say so, but the disk
partitioning programs accept '?' as a command to get some help. That's
useful to learn that you can use 't' to change a fallow partition to
type PLAN9 (a fallow partition conveniently available, since I had been
planning to install Linux there for the last five years but somehow
never got around to it.)
* When the kernel boots, it says something about 128MB swap. In the
second edition, the penalty for having less backing store allocated
than the kernel expected was a panic the first time one of those page
frames was written out. Is that still the case? The installation
instructions suggest that it should be harmless.
* The system complained about not being able to assign an irq to the
printer port.
* The vga stuff works fine with a #9 771 card.
* The installer is willing to try reading from an ext2 partition, but I
had mixed results with that. (Ok, linux was recently installed on a
second disk.) The mini-shell was unwilling to cd into /home, for
unknown reasons. Putting plan9.9gz into / worked around that.
* If you told the install-floppy-maker that you have ethernet,
but then you use the local media to load the distribution, the ip
information never gets configured, which makes ndb/dns pause a while
before timing out. Don't panic if that happens.
* It looks like glenda's home directory has a mode 0555 tmp directory
in it, which should be 0777.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] third edition, installation experiences
@ 2000-06-09 15:58 jmk
0 siblings, 0 replies; 15+ messages in thread
From: jmk @ 2000-06-09 15:58 UTC (permalink / raw)
To: 9fans
Fco. J. Ballesteros <nemo@gsyc.escet.urjc.es> wrote:
Just to let you know that Plan 9 runs just fine on a Dell Inspiron
7k.
BTW, anyone with a Lucent wavelan driver? If none, I'm willing to
write one myself. But would prefer to reuse :-)
thanks for the feedback.
there was a driver for the old wavelan cards which we didn't include
as we were unsure if we were allowed to release it. there's a summer
student just started on writing a driver for the new 802.11 cards,
but a parallel effort on your part wouldn't be a bad thing.
--jim
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] third edition, installation experiences
@ 2000-06-10 17:54 Scott Schwartz
0 siblings, 0 replies; 15+ messages in thread
From: Scott Schwartz @ 2000-06-10 17:54 UTC (permalink / raw)
To: 9fans
A few more first impressions:
The other day I said something about not being able to
assign an irq. The actual error message was:
i8259enable: irq 7 shared but not level
intrenable: couldn't enable irq 7, tbdf 0xffffffff for lpt
According to '#P/irqalloc', irq 7 is assigned to mathemu.
I also had my first crash. I echo-ed "kill" to the control
file of a process '#IOtcpack". Instant reboot.
My cdrom is recognized (cat sdD0/ctl looks sensible), but
the data file is all zeros.
/dev/draw seems slower than /dev/bitblt. I wonder if the difference is
from not doing runtime code generation.
Plumbing is... interesting. I normally like to have several editors
running, keeping different work in different contexts. The new system
makes that difficult, because when one editor opens a file, the
others want to open it too.
^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <rsc@plan9.bell-labs.com>]
* Re: [9fans] third edition, installation experiences
@ 2000-06-10 18:18 ` Russ Cox
2000-06-11 19:09 ` Scott Schwartz
0 siblings, 1 reply; 15+ messages in thread
From: Russ Cox @ 2000-06-10 18:18 UTC (permalink / raw)
To: 9fans
My cdrom is recognized (cat sdD0/ctl looks sensible), but
the data file is all zeros.
See if cdfs(4) is any better than the kernel.
Every once in a while it is.
/dev/draw seems slower than /dev/bitblt. I wonder if the difference is
from not doing runtime code generation.
Yes, that's much of it; the code already has many
special checks to handle the common cases, but
the general case is indeed slower than it ought
to be. I have a runtime code generator started (and stopped,
for the time being), but mostly as an experiment to see what
might be gained. I expect that the problems in keeping the
instruction and data caches up to date on non-x86
and non-Intel x86 chips will make it not practical,
but maybe the win will be enormous. I don't know.
Plumbing is... interesting. I normally like to have several editors
running, keeping different work in different contexts. The new system
makes that difficult, because when one editor opens a file, the
others want to open it too.
Run plumber in the window before starting the editor,
and it will be in its own ``plumbing space''
if you will.
Russ
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] third edition, installation experiences
@ 2000-06-10 18:22 rob pike
0 siblings, 0 replies; 15+ messages in thread
From: rob pike @ 2000-06-10 18:22 UTC (permalink / raw)
To: 9fans
/dev/draw seems slower than /dev/bitblt. I wonder if the difference is
from not doing runtime code generation.
Perhaps. Draw() is also a much more general operator, which causes it to be
slower in the worst case. On the other hand, we (well, Russ) worked on getting
draw() to talk to the graphics accelerator on some of the cards, and there are
simple examples like catting /dev/words where the new system is *much*
faster (factors of 10 or more) than even bitblt was. I hope folks will
connect the code to the hardware on more graphics cards so the speedups
will be more widely available.
On the issue of run-time code generation, we abandoned it because it was
too hard to write portable code to handle the synchronization of instruction
and data caches. The problem is not processors so much as systems; the
details of cache management in different architectures are often delegated
to motherboard makers who choose widely varying ways to handle cache
flushing and make it very hard for a portable program to divine what to do.
If you're just on PCs, it's not so hard, but we use a lot of non-PC machines.
Also, it's possible that the rise of JITs will help this situation, but if the
VGA industry is anything to go by...
Plumbing is... interesting. I normally like to have several editors
running, keeping different work in different contexts. The new system
makes that difficult, because when one editor opens a file, the
others want to open it too.
There was a long discussion about how and whether to handle fan-out in
the plumber. What we did reflects our style of use. If it doesn't suit your
needs, you have the source... Also of course it's mostly controlled by
configuration files, so you might be able to try another arrangement just
by using different plumbing rules. (The fan-out isn't explicit in the
configuration, but I suppose on reflection it could be made to be.) I've
also done tricks where I've rebound things to rearrange plumbing ports
for temporary purposes; that might work well for you.
Failing that, B is a shell script that could easily be adapted to use other
information to direct the file to a port other than edit, or to add
attributes that different editors could check.
-rob
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] third edition, installation experiences
@ 2000-06-10 18:56 presotto
0 siblings, 0 replies; 15+ messages in thread
From: presotto @ 2000-06-10 18:56 UTC (permalink / raw)
To: 9fans
I also had my first crash. I echo-ed "kill" to the control
file of a process '#IOtcpack". Instant reboot.
You shouldn't be able to kill that process, I'll fix that. It's a kernel
process that can leave bad pointers lying around if you terminate it.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] third edition, installation experiences
@ 2000-06-10 19:25 jmk
2000-06-11 19:12 ` Scott Schwartz
2000-06-12 10:27 ` Douglas A. Gwyn
0 siblings, 2 replies; 15+ messages in thread
From: jmk @ 2000-06-10 19:25 UTC (permalink / raw)
To: 9fans
>The other day I said something about not being able to
>assign an irq. The actual error message was:
>
> i8259enable: irq 7 shared but not level
> intrenable: couldn't enable irq 7, tbdf 0xffffffff for lpt
>
>According to '#P/irqalloc', irq 7 is assigned to mathemu.
There's a misunderstanding in the numerology, IRQ 7 has a base vector
added to it of (in this case) 32, so you should look in '#P/irqalloc'
for something using vector 39 (the output actually shows you which
IRQ maps to which vector, important in SMP machines).
The reason for the message is that some other driver has registered as
wanting to use that IRQ already and, as this is an 8259 PIC, you can't
share interrupts unless the corresponding bit is set in the Edge/Level
Control Register (ELCR) and apparently it isn't.
--jim
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] third edition, installation experiences
2000-06-10 19:25 jmk
@ 2000-06-11 19:12 ` Scott Schwartz
2000-06-12 10:27 ` Douglas A. Gwyn
1 sibling, 0 replies; 15+ messages in thread
From: Scott Schwartz @ 2000-06-11 19:12 UTC (permalink / raw)
To: 9fans
jmk:
| There's a misunderstanding in the numerology, IRQ 7 has a base vector
| added to it of (in this case) 32, so you should look in '#P/irqalloc'
| for something using vector 39 (the output actually shows you which
| IRQ maps to which vector, important in SMP machines).
Ah, right. The actual collision was with sb16, documented as using irq7.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9fans] third edition, installation experiences
2000-06-10 19:25 jmk
2000-06-11 19:12 ` Scott Schwartz
@ 2000-06-12 10:27 ` Douglas A. Gwyn
1 sibling, 0 replies; 15+ messages in thread
From: Douglas A. Gwyn @ 2000-06-12 10:27 UTC (permalink / raw)
To: 9fans
jmk@plan9.bell-labs.com wrote:
> > i8259enable: irq 7 shared but not level
> > intrenable: couldn't enable irq 7, tbdf 0xffffffff for lpt
> The reason for the message is that some other driver has registered as
> wanting to use that IRQ already and ...
Unfortunately I'm getting a similar conflict with IRQ 3, which in
my system is assigned for exclusive use of the 3C509B (I had no
real choice as there are no spare IRQs on my system and I even
had to sacrifice a serial port to get that one). I assume this
is because the installation/resulting Plan 9 systems are assuming
the existence of 2 serial ports; how do I disable the second one
(in PLAN9.INI presumably)?
^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <200006081831.OAA25336@smtp1.fas.harvard.edu>]
end of thread, other threads:[~2000-06-15 16:58 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-06-08 19:18 [9fans] third edition, installation experiences Scott
2000-06-09 15:58 jmk
2000-06-10 17:54 Scott Schwartz
[not found] <rsc@plan9.bell-labs.com>
2000-06-10 18:18 ` Russ Cox
2000-06-11 19:09 ` Scott Schwartz
2000-06-10 18:22 rob pike
2000-06-10 18:56 presotto
2000-06-10 19:25 jmk
2000-06-11 19:12 ` Scott Schwartz
2000-06-12 10:27 ` Douglas A. Gwyn
[not found] <200006081831.OAA25336@smtp1.fas.harvard.edu>
[not found] ` <20000608191813.8754.qmail@g.bio.cse.psu.edu>
2000-06-09 8:27 ` Fco. J. Ballesteros
2000-06-12 15:49 ` Lyndon Nerenberg
2000-06-15 9:09 ` Fco. J. Ballesteros
2000-06-15 16:58 ` Lyndon Nerenberg
2000-06-12 9:59 ` kajri jain
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).