[lkml]   [1999]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: holes for ISA boards...
Hirling Endre <> wrote:

>On Fri, 11 Jun 1999, Aaron J. Grier wrote:
>> Any idea what's going on? Is it impossible for me to poke a hole in
>> from 12-16MB so I can hack on this silly ISA board?
>Your patch creates a hole in Linux's virtual address space, but your
>card needs a hole in the physical RAM, or it will conflict with chips
>in that range. I think there's no way to do this with a machine that
>has more than 12M of RAM.

IIRC, ISA busmastering devices are able to treat the conflicting memory as a
physical framebuffer, allowing protected mode writes to be mirrored in
device memory. The X server or device driver has to know how to set this up.

Here's My Rant (tm). Not directed at HE or AJG.

The question of support for ISA accelerated SVGA cards is a FAQ, or ought to
be. IMHO it is shameful that the answer is "You can't do that."

The form of that answer is usually "Buy a new video card." I grit my teeth
at that and think "Don't change the subject." Problem hardware is not the
same thing as a hardware problem.

There are millions of those things out there. They are exactly the cards
that the best kind of novice Linux users are likely to have. Why do I think
that? They are the thrifty users who won't let old hardware gather dust.
They are the cautious ones who want to learn Linux on an old beater before
entrusting the shiny new machine to it. These are people who will look for
efficiencies and file good bug reports. They will be a counterweight to
those who are here for the beer and want lots of bloaty decorations.

It seems like kernel guys have been relying on the X guys to do it, and the
X guys have been waiting for memory hole support from the kernel. Deadlock.
At least that's how it looks to me.

I see three possible solutions to the problem, aside from (pre-1). "Buy a
new video card", which is OT. Other suggestions are solicited.

(1) Modify vm initialization to create the hole, and map it as a physical
framebuffer. This is Aaron's approach, as I understand it. Properly
modified, I think it's the most general and direct way. It is a colossal
frag of vm, but that may be unavoidable with this kind of device. Since it's
large, contiguous. and (I hope) static, the vm hit may not be too severe.

(2) Use bigphysarea to grab everything below 16M. Buy more memory to
compensate for the loss. This map could support a not-yet-invented isafb
device with one physical framebuffer and several virtual ones to swap. Use
the leftovers for sound DMA buffers and the like. This is wasteful and not
really what I want, though it might make a great game machine. X might
really cook too.

(3) I dimly recall that the PCI bridge device was supposed to be able to
remap the ISA bus. If true, this might be the real solution for most of us.
Does the kernel PCI code support such a thing? I'm looking, but I haven't
found any answers yet. PCI gurus? This might sidestep the deadlock and let
existing drivers do the job.

Let me anticipate flamage by saying that I already know Wintel is abolishing
the ISA bus. That won't replace the ones I have but slowly. I sure do hate
to waste old gear.

Whew, Now I Feel Better,

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [W:0.047 / U:26.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site