[9fans] changes on sources
Russ Cox
you need a new 9load to run the new kernels.]
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
memory mappings.
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.
Enjoy.
- rsc, jmk
Russ Cox
Russ
Federico Benavento
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
Russ Cox
> screen and hangs the machine.
Is this on a machine that the April VESA kernels worked on?
Russ
Federico Benavento
>
> Russ
>
--
Federico G. Benavento
Sascha Wildner
> Hi,
>
> 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".
>
> screen and hangs the machine.
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
copydist loop.
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"
for 1600x1200x32.
Sascha
Sascha Wildner
> "rio: can't open display: initdisplay: /dev/draw/new: no frame buffer"
>
> for 1600x1200x32.
...which isn't supported by my card. Just tried 1600x1200x16 and it too
locks up with garbage on the screen.
Sascha
Federico G. Benavento
aux/vga -m vesa -p
and remember, that you need to have monitor=vesa in your plan9.ini.
Federico G.Benavento
---
/bin/fortune:
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.
Russ Cox
Russ
Federico G. Benavento
to my plan9.ini.
the kernel was crashing and aux/vga -m vesa -p, didn't print
the video modes.
Federico G.Benavento
---
/bin/fortune:
Life is a yo-yo, and mankind ties knots in the string.
Sascha Wildner
> What kind of video card do you have?
NVIDIA GeForce Go 6800 (in a Dell Inspiron 9300)
Sascha
Russ Cox
> to my plan9.ini.
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?
Russ
Federico G. Benavento
>> to my plan9.ini.
>
> 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?
>
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
dumpstack
ktrace /kernel/path f0108052 f0eb0dac << EOF
...
iallocb: no memory 0/33005568
> Russ
Federico G.Benavento
---
/bin/fortune:
Good day to avoid cops. Crawl to work.
Russ Cox
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.
Russ
Charles Forsyth
>failed the kernel crashed.
>Main max 61880272 cur 603078 Free 2080 alloc 6027230
>iallocb: no memory 0/33005568
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.
andrey mirtchovski
minimal configurations. haven't had a single problem yet.
nothing integrated though.
Federico G. Benavento
yes
I didn't express myself correctly,
what I wanted to say is that I saw this when trying to allocate very big images,
Federico G.Benavento
---
/bin/fortune:
Tai Chi is self-defense for people on Quaaludes.
Gabriel Diaz
The lastest iso works for me. On a Compaq Nx7010 with a Radeon 9200 mobile. Vesa works fine at 1024x768 (doesn't remember de color depth, but i think is 24).
Gabi