Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[YAMANASHI Takeshi]

Just allow me to describe my case...

> > 	p = KADDR(0xD0000); /*RSC: changed from 0xC0000 */
 :
> Sadly I don't remember why I changed that.
> It was a long time ago.  I think umbscan is just
> flawed at the moment

umbscan thought that the starting umb address is
0xCA000.  But reading the cis mapped at the
address ever returned 0xFF.  The change fixed the
cis reading problem and 3C562 started to work.

Thanks.
--

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[paurea]

Russ Cox writes:
 > > VBE/AF Standard 1.0
 >
 > Right.  If I recall correctly and nothing has changed since
 > then (neither is overwhemlingly likely; it was 1999), most
 > cards don't bother implementing this part of the standard.
 >

What about the other standards?. Using sw cursor and VESA for other
things how many cards would be really supported?. (just a question out
of shear curiosity).
--
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Charles Forsyth]

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

i think that's what we found when we did VESA-based
work for Inferno.  i'm happy to parcel that up yet
again if anyone's seriously interested in adapting it
for Plan 9, or even current Inferno, or anything else
for that matter, but it takes time to find all the bits,
so be reasonably sure you're going to have the stamina.
other `buts': it relied on software cursors in Inferno;
it relied on non-trivial changes to the bootstrap code
to do real-mode (unreal mode more like) BIOS calls
to gather data before loading the kernel, because cards
didn't implement the 32-bit variants; and it's all
a bit involved.

[-- Attachment #2: Type: message/rfc822, Size: 1571 bytes --]

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c
Date: Wed, 18 Sep 2002 07:38:59 -0400
Message-ID: <c638d4fcbdf1f3ffb4afccb80d0178b0@plan9.bell-labs.com>

> VBE/AF Standard 1.0

Right.  If I recall correctly and nothing has changed since
then (neither is overwhemlingly likely; it was 1999), most
cards don't bother implementing this part of the standard.

Russ

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[rob pike, esq.]

That wasn't my point.  My point was that I don't consider an
absolute necessity that every possible device be supported.
I favor simplicity and maintainability over universality.

-rob

--On Wednesday, September 18, 2002 6:18 AM +0200 Lucio De Re
<lucio@proxima.alt.za> wrote:

> On Tue, Sep 17, 2002 at 07:13:59PM -0400, rob pike, esq. wrote:
>> How much complexity should the kernel have - and require people to
>> maintain -  for low-deployment devices?
>>
> Only as much as can't be put somewhere else.  That's the problem with
> a monolithic kernel: _everything_ that needs to be in there will
> eventually appear in it.
>
> Was it dhog that was working on loadable kernel drivers?
>
> ++L

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Lucio De Re]

On Wed, Sep 18, 2002 at 12:42:05PM -0400, rob pike, esq. wrote:
>
> That wasn't my point.  My point was that I don't consider an
> absolute necessity that every possible device be supported.
> I favor simplicity and maintainability over universality.
>
There's tension between these objectives, with the marketplace
driving one end and good practice resisting.

I vote on your side, but I accept that there is a price to pay.
I particularly baulk when backwards compatibility suffers, because
obsolescence is unaffordable but unstoppable in the third world
(developing countries).

Guess who's keenly aware that the World Summit on Sustainable
Development was held on his doorstep?

++L

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Russ Cox]

> VBE/AF Standard 1.0

Right.  If I recall correctly and nothing has changed since
then (neither is overwhemlingly likely; it was 1999), most
cards don't bother implementing this part of the standard.

Russ

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[paurea]

Russ Cox writes:
 > VESA actually says nothing about hardware cursors
 > last I checked; if you're going the VESA route you
 > really want to reduce the necessary code to zero.
 > There's an important qualitative difference
 > between zero and non-zero.  Mainly, people who
 > don't write drivers are still up to the task of
 > writing zero lines of code.



Taken from www.vesa.org/standards.htm. this is the reason I thought VESA
standards supported hw cursors...

August
1996
VBE/AF Standard 1.0: The VBE/AF 1.0 defines the interface of a new operating system portable, loadable device driver architecture that will provide access to accelerated graphics hardware. Some of the accelerator functions supported include hardware cursors, multi buffering, solid and transparent off-screen bitmaps, rectangel filling, line drawing and polygon filling.


I found the part of writing the hw cursor support for the sis630 the easy part
of the driver, though. That is why I said that mode switching or whatever
could be done using VESA and add the specific code of the hw cursor appart.

By the way if you are writing a VESA driver and I can help in any way (even
with my lack of knowledge), tell me. I have given a lot of thought to it.
--
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Lucio De Re]

On Wed, Sep 18, 2002 at 12:49:03AM -0400, Russ Cox wrote:
>
> we already have loadable kernel modules.
> they are called user-level file servers.

Agreed.  But they have to straddle the user-kernel context, at a
price - Microsoft tried to keep graphics out the kernel, with well
known results (NT 3.51).

Being able to add kernel-level file servers would be an interesting
proposition, although I would have trouble understanding the concept
:-)

++L

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Russ Cox]

we already have loadable kernel modules.
they are called user-level file servers.

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Lucio De Re]

On Tue, Sep 17, 2002 at 07:13:59PM -0400, rob pike, esq. wrote:
> How much complexity should the kernel have - and require people to
> maintain -  for low-deployment devices?
>
Only as much as can't be put somewhere else.  That's the problem with
a monolithic kernel: _everything_ that needs to be in there will
eventually appear in it.

Was it dhog that was working on loadable kernel drivers?

++L

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Russ Cox]

> Isn't always there the possibility to add a hwcursor also?. I think hw
> cursors are directly supported by VESA standards, but I think one
> thing is independant from another. Isn't it possible to use VESA for
> mode switching or whatever and reduce the code you have to write for
> the card to write the hwcursor support?.

VESA actually says nothing about hardware cursors
last I checked; if you're going the VESA route you
really want to reduce the necessary code to zero.
There's an important qualitative difference
between zero and non-zero.  Mainly, people who
don't write drivers are still up to the task of
writing zero lines of code.

> Another question. What is the software cursor really necessary for?
> (other than in vmware). Do there really exist modern cards
> which don't support hardware cursor?.

Full-screen VMware is another thing I'd forgotten
about.  But yes, most modern cards have hardware
cursors.

Russ

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[paurea]

Russ Cox writes:
 > Usually the code also complicates lots of other
 > aspects of the system, so it's been easier just to
 > implement the hardware cursor drivers.  If I ever
 > really want VESA-based drivers, I'll need a software
 > cursor implementation.

Isn't always there the possibility to add a hwcursor also?. I think hw
cursors are directly supported by VESA standards, but I think one
thing is independant from another. Isn't it possible to use VESA for
mode switching or whatever and reduce the code you have to write for
the card to write the hwcursor support?.

 >I have some ideas about
 > doing it without complicating everything else,
 > but they're not particularly well formed.

Another question. What is the software cursor really necessary for?
(other than in vmware). Do there really exist modern cards
which don't support hardware cursor?.
--
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[rob pike, esq.]

> Can someone remind me why we can't use software cursors in 4e?

Another way of saying is that when the draw code was written, replacing
the bitblt driver, software cursors were left out in order to simplify things.
If you don't attempt to remove support for old cruft, it accumulates forever.
Complete rewrites are an excellent opportunity to eliminate unnecessary
compatibilities, and I think the case for software cursors  remains
weak unless you're in the 0.1% of the population that needs the support.
How much complexity should the kernel have - and require people to
maintain -  for low-deployment devices?

-rob

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Russ Cox]

> Can someone remind me why we can't use software cursors in 4e?

Because the code doesn't exist.

Usually the code also complicates lots of other
aspects of the system, so it's been easier just to
implement the hardware cursor drivers.  If I ever
really want VESA-based drivers, I'll need a software
cursor implementation.  I have some ideas about
doing it without complicating everything else,
but they're not particularly well formed.

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[rob pike, esq.]

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

Because the code was hideous (the mouse is hideous enough as is) and
because almost all VGAs in use have hardware support.

The mouse needs its Nth complete rethink, given the advent of USB mice.
It's someone else's turn, though.

-rob

[-- Attachment #2: Type: message/rfc822, Size: 1484 bytes --]

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c
Date: Tue, 17 Sep 2002 18:08:06 -0400
Message-ID: <20020917220806.3872.qmail@g.bio.cse.psu.edu>

| page that it allocates for the hardware cursor.

Can someone remind me why we can't use software cursors in 4e?

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Scott Schwartz]

| page that it allocates for the hardware cursor.

Can someone remind me why we can't use software cursors in 4e?

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[David Gordon Hogan]

> Oops. I did not combine using the wavelan and trying
> to use the i81x driver. If I do have a wavelan in the
> pcmcia slot and I let aux/vga be run (trying i81x on
> thinkpad R31, mouseport ps2, vgasize 640x480x8, monitor xga)
> I get:
>
> panic: mmuwalk2: va 80526000 entry 4001E3

The i81x driver uses mmuwalk() to get the PTE of a single
page that it allocates for the hardware cursor.  It needs this
to mark the memory as uncached, otherwise the hardware
cursor won't update correctly.  Unfortunately, this strategy
only works if the cursor is allocated in the first 4M of memory.
After that, it isn't possible to single out an individual page
in the kernel virtual mapping.  Hence the panic.

I'm not sure how to fix this.  It might be neccesary to change
the page table to make the appropriate 4M region use a level
2 page table.

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Axel Belinfante]

Oops. I did not combine using the wavelan and trying
to use the i81x driver. If I do have a wavelan in the
pcmcia slot and I let aux/vga be run (trying i81x on
thinkpad R31, mouseport ps2, vgasize 640x480x8, monitor xga)
I get:

panic: mmuwalk2: va 80526000 entry 4001E3

ktrace /kernel/path 80106720 807bf234
[11 lines of numbers omitted]
cpu0: exiting

Booting the same kernel, but without wavelan,
or without running aux/vga (e.g. by specifying mouseport 'a a')
does not give the panic.
The kernel is newer than the remainder of the system.
I'll update the machine from sources and retry.

Axel.

I wrote:
> I tried (changed /sys/src/9/pc/memory.c)
> and the wavelan works now on the R31.
> I did not yet check if this change makes a difference
> (in a negative way) on `my' other systems.

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Axel Belinfante]

I tried (changed /sys/src/9/pc/memory.c)
and the wavelan works now on the R31.
I did not yet check if this change makes a difference
(in a negative way) on `my' other systems.

W.r.t. the R31: Unfortunately, vga does not work (yet?)
(tried the i81x driver).
(the screen changes color slowly in a (when I saw it first time)
 disturbing way -- not everything changes at the same time --
 until I end up with a white/grey screen. no mouse, no menus)

Axel.

> On the thinkpad R31 I'm playing with right now the wavelan is not
> recognized. I wonder whether this (well-timed :-) thread gave me
> the explanation and the fix. I'll try it and report the result.
>
> Axel.
>
> > i know it's needed on earlier thinkpads, at least, to allow pcmcia
> > cards to work.  i remember a frustrating attempt to get a modem card
> > going on the butterfly thinkpad that was resolved by a similar change
> > (once i'd finally noticed that a Linux pcmcia configuration file
> > handled the thinkpad specially and started its equivalent scan at
> > 0xD0000, presumably because the thinkpad has got something else there).
>

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Axel Belinfante]

On the thinkpad R31 I'm playing with right now the wavelan is not
recognized. I wonder whether this (well-timed :-) thread gave me
the explanation and the fix. I'll try it and report the result.

Axel.

> i know it's needed on earlier thinkpads, at least, to allow pcmcia
> cards to work.  i remember a frustrating attempt to get a modem card
> going on the butterfly thinkpad that was resolved by a similar change
> (once i'd finally noticed that a Linux pcmcia configuration file
> handled the thinkpad specially and started its equivalent scan at
> 0xD0000, presumably because the thinkpad has got something else there).

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Charles Forsyth]

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

i know it's needed on earlier thinkpads, at least, to allow pcmcia
cards to work.  i remember a frustrating attempt to get a modem card
going on the butterfly thinkpad that was resolved by a similar change
(once i'd finally noticed that a Linux pcmcia configuration file
handled the thinkpad specially and started its equivalent scan at
0xD0000, presumably because the thinkpad has got something else there).

[-- Attachment #2: Type: message/rfc822, Size: 2242 bytes --]

From: YAMANASHI Takeshi <uncover@beat.cc.titech.ac.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c
Date: Tue, 17 Sep 2002 13:19:15 0900
Message-ID: <200209170418.g8H4Ikv240064@mail-o.cc.titech.ac.jp>

Just allow me to describe my case...

> > 	p = KADDR(0xD0000); /*RSC: changed from 0xC0000 */
 :
> Sadly I don't remember why I changed that.
> It was a long time ago.  I think umbscan is just
> flawed at the moment

umbscan thought that the starting umb address is
0xCA000.  But reading the cis mapped at the
address ever returned 0xFF.  The change fixed the
cis reading problem and 3C562 started to work.

Thanks.
--

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Russ Cox]

> I noticed boot/pc/memory.c has the line:
> 	p = KADDR(0xD0000); /*RSC: changed from 0xC0000 */
> but 9/pc/memory.c remains still:
> 	p = KADDR(0xC0000);
>
> I don't know what I did, but without changing the
> 9/pc/memory.c according to boot's, 3C562 didn't work
> on my laptop (MITSUBISHI Pedion).

Sadly I don't remember why I changed that.
It was a long time ago.  I think umbscan is just
flawed at the moment -- we really need to grab
the BIOS memory map before we dive into
protected mode, and use that instead of guessing
at these things.

Russ

[9fans] /sys/src/^(9 boot)^/pc/memory.c

[YAMANASHI Takeshi]

I noticed boot/pc/memory.c has the line:
	p = KADDR(0xD0000); /*RSC: changed from 0xC0000 */
but 9/pc/memory.c remains still:
	p = KADDR(0xC0000);

I don't know what I did, but without changing the
9/pc/memory.c according to boot's, 3C562 didn't work
on my laptop (MITSUBISHI Pedion).

Russ>
> I still do one-machine kernel development more often
> than I'd like, and it's just no fun.

I had to do one-machine kernel investigation in this case
for I have only one laptop.  It was somewhere between
reasonable pain and extreme fun.
--