[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: XFree86 4.1.0: call for help



Kostas Gewrgiou wrote:
> 
> On Wed, 20 Jun 2001, Michel Dänzer wrote:
> 
> > Kostas Gewrgiou wrote:
> > >
> > > Since fbdev is handling the console there is no need to restore
> > > vga fonts/colormap (i don't know if it is possible to run vgacon
> > > under some of the ibm machines, if yes then it is needed there)
> >
> > That's my point, either we don't need anything anywhere (we don't need to
> > save the VGA mode with fbcon) or we need nothing on some machines and
> > everything on others. Saving and restoring only part of the VGA context
> > doesn't make sense to me.
> 
> Hmm you have a point there, i have a feeling that the text/colormap
> was not crasing in the isa i/o access but in the isa mem ones,
> (we mmap 0xA0000, i wonder what lives there since isa mem definitely
> isn't)

The segfault occurred in an inb(), is that also used for ISA mem?


> > > > So, what can we do? We can't put arch or OS specific code to handle
> > > > this in vgaHW either. Maybe it's really best to handle it in the
> > > > kernel?
> > >
> > > Everything that is os/arch specific more or less goes in
> > > xfree86/os-support adding something like
> > > xf86isIOAvailable(device/screen/whatever) is what we need.
> >
> > Which won't work without kernel assistance, will it? So we could as well
> > just let the existing syscall handle everything.
> 
> We don't need any more kernel assistance, just to fix the syscall to
> return an error for the AGP bus of Uni-N if we can't do any io there.

Agreed, that's what I meant by 'let the existing syscall handle everything'.
:)


> > > We still need to workout a way to handle multiple ioBases btw, there are
> > > other paths in the code that will do io in the wrong base and we need
> > > to handle this. Anyone with a second card in the pci bus will end up
> > > getting the isa io access for the agp card in the wrong card and thats
> > > not what we want.
> >
> > Yup, but that's for 4.2 at the earliest...
> 
> Since 4.1 went out broken we can't do much now, the best solution will
> be to disable the ioctl (since we don't get the right base anyway)

You mean the syscall, right?


-- 
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member



Reply to: