Re: [9fans] changes on sources

Re: [9fans] changes on sources

[Federico G. Benavento]

btw, I was having problems with vesa, till I added "*noe820scan="
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.

Re: [9fans] changes on sources

[Russ Cox]

> btw, I was having problems with vesa, till I added "*noe820scan="
> 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

Re: [9fans] changes on sources

[erik quanstrom]

russ, 

so what are the current tested configurations these days?

erik

Re: [9fans] changes on sources

[Russ Cox]

> so what are the current tested configurations these days?

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

Re: [9fans] changes on sources

[andrey mirtchovski]

i've booted the new kernels on various nvidia graphics hardware in
minimal configurations. haven't had a single problem yet.

nothing integrated though.

Re: [9fans] changes on sources

[Federico G. Benavento]

>>no, was something with the vesa support, because when allocimage
>>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.

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.

Re: [9fans] changes on sources

[Gabriel Diaz]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

Hi

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



2005/11/11, Federico G. Benavento <benavento@gmail.com>:
>
> >>no, was something with the vesa support, because when allocimage
> >>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.
>
> 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.
>
>

[-- Attachment #2: Type: text/html, Size: 1262 bytes --]

Re: [9fans] changes on sources

[Federico G. Benavento]

>> btw, I was having problems with vesa, till I added "*noe820scan="
>> 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.
> 
sorry

>> 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.

Re: [9fans] changes on sources

[Charles Forsyth]

>no, was something with the vesa support, because when allocimage
>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.

Re: [9fans] changes on sources

[Federico G. Benavento]

to see what video modes are available run:

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.

[9fans] changes on sources

[Russ Cox]

[The short version: lots of new binaries and features;
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

Re: [9fans] changes on sources

[Russ Cox]

First round of bug fixes now on sources.

Russ

Re: [9fans] changes on sources

[Federico Benavento]

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".

now aux/vga doesn't complain anymore, but it freezes the
screen and hangs the machine.

--
Federico G. Benavento

Re: [9fans] changes on sources

[Russ Cox]

> now aux/vga doesn't complain anymore, but it freezes the
> screen and hangs the machine.

Is this on a machine that the April VESA kernels worked on?

Russ

Re: [9fans] changes on sources

[Federico Benavento]

> Is this on a machine that the April VESA kernels worked on?
>
Yes

> Russ
>

--
Federico G. Benavento

Re: [9fans] changes on sources

[Sascha Wildner]

Federico Benavento wrote:
> 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".
> 
> now aux/vga doesn't complain anymore, but it freezes the
> 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

-- 
http://yoyodyne.ath.cx

Re: [9fans] changes on sources

[Russ Cox]

What kind of video card do you have?

Russ

Re: [9fans] changes on sources

[Sascha Wildner]

Russ Cox wrote:
> What kind of video card do you have?

NVIDIA GeForce Go 6800 (in a Dell Inspiron 9300)

Sascha

-- 
http://yoyodyne.ath.cx

Re: [9fans] changes on sources

[Sascha Wildner]

Sascha Wildner wrote:
> "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

-- 
http://yoyodyne.ath.cx