A few files changed on sources today.
The major change was pushing out the new pc mmu code, which
runs with the kernel at 0xF0000000 instead of 0x80000000. There
are some other kernel-maintained data structures at 0xE0000000.
User processes can have everything underneath, so 3.5GB.
The new code has a cleaner separation of virtual and physical
addresses, which should address the various mmukmap2 panics
that people have reported over the years. It also lets the PC kernel
use up to 4GB of memory, minus whatever is used by device
To boot one of these new kernels you will need to copy the new
/386/9load to your 9fat or floppy disk so that it can cope with
the new kernel load address. (It will still handle the old ones too.)
Various other changes got pushed out with the new mmu code.
The kernel no longer assumes that there are two memory banks.
Instead there is an array Conf.mem which can be made larger
as needed. This should help with the sparc revival.
The pc kernels have the changes from the VESA kernels from April.
This means that resizing the screen once rio is running should be
possible, and running with monitor=vesa should use the VESA
extensions to set up the screen.
The pc kernels use the BIOS E820 memory map when available
rather than poking at each megabyte until they decide there's
no more. If you have a system where this causes problems,
you can put *noe820scan= in plan9.ini, and then please let us know
so we can try to fix them.
The devsd internals are shuffled around a bit to make hot-swap
disks and the like a bit easier to support.
There is also a new driver sdmv50xx for the Marvell 88SX5040
family of SATA cards. Thank you to Coraid.
Libmach and all the programs that depend on it now use what
should be a 64-bit safe interface, in preparation for the AMD64.
Much of it is only lightly tested, so if you see strange behavior,
let us know.
A few programs have been updated to be 64-bit safe.
Others have not.
The distribution floppy and CD should be updated tomorrow
morning by the nightly rebuild.
As always, if you see problems mail 9fans or 9trouble or submit patches.
- rsc, jmk
I've tried to boot the latest kernel, and I get this error message from aux/vga.
aux/vga was complaining about:
mkvbe: '/dev/realmode' file does not exist
so, I checked /sys/src/9/pc/realmode.c and I realized that
nobody was calling realmodelink(), so moved realmode in
/sys/src/9/pc/pcf from the "misc" section to "link".
now aux/vga doesn't complain anymore, but it freezes the
screen and hangs the machine.
Federico G. Benavento
Is this on a machine that the April VESA kernels worked on?
Federico G. Benavento
I have a similar problem.
The VESA ISO from 9grid.de kinda worked for me. I did have problems with
all modes having some lines of garbage at the top (what seemed to me
like the video memory's start address somehow being wrong). This caused
rio being shifted horizontally in many modes but in 1024x768x8 the
garbage ended just at the end of a line so that worked. Unfortunately
the 9grid.de iso missed a file so the installer would go into a
An ISO from downloaded from the "Additional Software" link about an hour
ago will either lock up with garbage on the screen (tested with
640x480x8 and 1024x768x8) or bail out with
"rio: can't open display: initdisplay: /dev/draw/new: no frame buffer"
...which isn't supported by my card. Just tried 1600x1200x16 and it too
locks up with garbage on the screen.
aux/vga -m vesa -p
and remember, that you need to have monitor=vesa in your plan9.ini.
If you give a man a fire, he'll be warm for a day. If you set a man on fire, he'll be warm for the rest of his life.
the kernel was crashing and aux/vga -m vesa -p, didn't print
the video modes.
Life is a yo-yo, and mankind ties knots in the string.
NVIDIA GeForce Go 6800 (in a Dell Inspiron 9300)
Please report these things! If the E820 scan isn't working,
I'd like to know. I can't fix problems I don't know about.
> the kernel was crashing and aux/vga -m vesa -p, didn't print
> the video modes.
What do you mean by "the kernel was crashing"? Without
trying to use vesa at all?
>> the kernel was crashing and aux/vga -m vesa -p, didn't print
>> the video modes.
> What do you mean by "the kernel was crashing"? Without
> trying to use vesa at all?
no, was something with the vesa support, because when allocimage
failed the kernel crashed.
272152 byte free
Main max 61880272 cur 603078 Free 2080 alloc 6027230
Image max 61880272 cur 55469088 Free 514223680 alloc 4045088
ktrace /kernel/path f0108052 f0eb0dac << EOF
iallocb: no memory 0/33005568
Good day to avoid cops. Crawl to work.
The collective 9fans crowd knows more than I do about that.
There were a few issues with the E820 maps and one bug in
the Neomagic video driver, but Jim and I have fixed them.
Everything that worked before should still work. The real issue
is vesa. I had a few reports of people not being able to use vesa
with the April kernels on certain machines. I don't expect the
current kernels to fix those problems. (There were also reports
of not being able to use Mach64 cards in non-vesa mode, and
I did fix that.)
I didn't intend to put vesa in just yet, but It happened that
when I cleaned up the pc mmu code, I needed to change all
the vga code to understand the difference between virtual
and physical addresses. I had already done that particular
cleanup in the vesa code, so I just picked those up. The vesa
code is as tested as it was back in April, which is as tested as
people here were able to. Now that it's in the default kernel
I hope that it will get more testing. As I said above, it shouldn't
non-vesa configurations should be unaffected.
People are running the kernel on terminals at Bell Labs with
no problems, but they're not using vesa since they all had
supported hardware before.
I booted the latest Plan 9 on my Thinkpad X40 last night and
it just worked, using vesa (Intel 82852/855GM graphics chip).
In the cheaper, so-called integrated chipsets,
which use system memory for video memory, I wonder if
the kernel is trying to use the memory as real memory
at the same time that the vesa bios is trying to use it
as video memory. The E820 map should have helped
this, not made it worse, but who knows.
that's not allocimage failing (directly).
it might be exhausting main with image descriptors,
but it's at least possible that something else is consuming Main.
nothing integrated though.
I didn't express myself correctly,
what I wanted to say is that I saw this when trying to allocate very big images,
Tai Chi is self-defense for people on Quaaludes.