Ani Joshi wrote:
>
> On Wed, 20 Jun 2001, Michel [iso-8859-1] Dänzer wrote:
>
> > You're talking about the status quo, Kostas about the way it should be.
> > Just because it's not like that now doesn't mean we don't have to care
> > about it anymore.
>
> If he's talking about "the way it should
On Wed, 20 Jun 2001, Kostas Gewrgiou wrote:
> I think that the crash in vgaHW is because of isa mem accesses, if this is
> the case a better fix will be to mmap the right memory range for the
> machines that have one and to handle the lack of one in pmacs.
The crash is in readDacData, which rea
On Wed, 20 Jun 2001, Michel [iso-8859-1] Dänzer wrote:
> You're talking about the status quo, Kostas about the way it should be. Just
> because it's not like that now doesn't mean we don't have to care about it
> anymore.
If he's talking about "the way it should be", then totally removing all
f
On Wed, 20 Jun 2001 [EMAIL PROTECTED] wrote:
> >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.
>
> We can do _IO_, not ISA mem. Some cards require IOs accesses to
> some VGA registers so we need the sysc
[EMAIL PROTECTED] wrote:
>
> >The segfault occurred in an inb(), is that also used for ISA mem?
>
> If you get that for read and not write, then you are probably getting
> machine checks, which usually means IO to an incorrect address. Are
> you sure your card is answering to VGA IOs ?
I'm a bi
>The segfault occurred in an inb(), is that also used for ISA mem?
If you get that for read and not write, then you are probably getting
machine checks, which usually means IO to an incorrect address. Are
you sure your card is answering to VGA IOs ?
>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 0xA, i wonder what lives there since isa mem definitely
>isn't)
RAM. Actually kernel code :( There no way to access ISA mem on
most Macs.
>We don't ne
On Wed, 20 Jun 2001, 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 ye
On Wed, 20 Jun 2001, Ani Joshi wrote:
>
>
> On Wed, 20 Jun 2001, Kostas Gewrgiou wrote:
>
> > The #ifdef __powerpc__ isn't right (and we can't use os specific
> > code in the drivers) so the fix has to go in another layer,
> > crippling another os to fix our problems isn't the right solution.
>
>
Ani Joshi wrote:
>
> On Wed, 20 Jun 2001, Kostas Gewrgiou wrote:
>
> > The #ifdef __powerpc__ isn't right (and we can't use os specific
> > code in the drivers) so the fix has to go in another layer,
> > crippling another os to fix our problems isn't the right solution.
>
> Well, that's not real
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
On Wed, 20 Jun 2001, Kostas Gewrgiou wrote:
> The #ifdef __powerpc__ isn't right (and we can't use os specific
> code in the drivers) so the fix has to go in another layer,
> crippling another os to fix our problems isn't the right solution.
Well, that's not really true. There's already lots o
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, e
Kostas Gewrgiou wrote:
>
> On Wed, 20 Jun 2001, Michel Dänzer wrote:
>
> > Kostas Gewrgiou wrote:
> > >
> > > On Tue, 19 Jun 2001, Ani Joshi wrote:
> > >
> > > > On Tue, 19 Jun 2001, Michel [iso-8859-1] Dänzer wrote:
> > > >
> > > > > That would be nice, unfortunately it doesn't. For the record,
On Wed, 20 Jun 2001, Michel Dänzer wrote:
> Kostas Gewrgiou wrote:
> >
> > On Tue, 19 Jun 2001, Ani Joshi wrote:
> >
> > > On Tue, 19 Jun 2001, Michel [iso-8859-1] Dänzer wrote:
> > >
> > > > That would be nice, unfortunately it doesn't. For the record, here's the
> > > > patch against xf-4_1-bran
Michel Dänzer wrote:
> While we're at it: The last other real issue in the r128 driver is mostly
> exposed by Xv: the data is moved to the framebuffer word by word, but it
> gets swapped depending on the current depth, so the video is broken. Does
> anyone have a better idea than to use different
Kostas Gewrgiou wrote:
>
> On Tue, 19 Jun 2001, Ani Joshi wrote:
>
> > On Tue, 19 Jun 2001, Michel [iso-8859-1] Dänzer wrote:
> >
> > > That would be nice, unfortunately it doesn't. For the record, here's the
> > > patch against xf-4_1-branch I tested:
> >
> >
> > Please try the attached patch.
On Tue, 19 Jun 2001, Ani Joshi wrote:
>
>
> On Tue, 19 Jun 2001, Michel [iso-8859-1] Dänzer wrote:
>
> >
> > That would be nice, unfortunately it doesn't. For the record, here's the
> > patch
> > against xf-4_1-branch I tested:
>
>
> Please try the attached patch. This fixes the problem on PCI m
On Tue, 19 Jun 2001, Michel [iso-8859-1] Dänzer wrote:
>
> That would be nice, unfortunately it doesn't. For the record, here's the patch
> against xf-4_1-branch I tested:
Please try the attached patch. This fixes the problem on PCI machines and
could possibly fix yours too.
It is against th
Ani Joshi wrote:
>
> Michel,
>
> I looked into the situation and found out why its crashing on your
> machine.
BTW it doesn't crash the whole machine, the server just segfaults. Nothing
dramatic. :)
> The vgaHW pointer is not setting the IOBase, so when it tries to
> read that it crashes. Do t
>If it indeed allows the server to start without Option "UseFBDev": yes. Can't
>hurt to try I guess... BenH seemed to suggest that it really can't work this
>way though.
>
It may work. Depends if you get the iobase from the AGP bus or the
PCI bus. What can't work is both...
Ben.
"Michel Dänzer" <[EMAIL PROTECTED]> writes:
> "Jason E. Stewart" wrote:
> >
> > Is this fix sufficient to get get 'Option "Display" "CRT"' working?
>
> If it indeed allows the server to start without Option "UseFBDev": yes. Can't
> hurt to try I guess... BenH seemed to suggest that it really can
"Jason E. Stewart" wrote:
>
> "Ani Joshi" <[EMAIL PROTECTED]> writes:
>
> > I looked into the situation and found out why its crashing on your
> > machine. The vgaHW pointer is not setting the IOBase, so when it
> > tries to read that it crashes. Do this in r128_driver.c:
> >
> > after the hwre
"Ani Joshi" <[EMAIL PROTECTED]> writes:
> I looked into the situation and found out why its crashing on your
> machine. The vgaHW pointer is not setting the IOBase, so when it
> tries to read that it crashes. Do this in r128_driver.c:
>
> after the hwrec is alloced (vgaHWGetHWRec())
>
> {
>
Michel,
I looked into the situation and found out why its crashing on your
machine. The vgaHW pointer is not setting the IOBase, so when it tries to
read that it crashes. Do this in r128_driver.c:
after the hwrec is alloced (vgaHWGetHWRec())
{
vgaHWPtr hwp;
vgaHWGetIOBase(hw
[EMAIL PROTECTED] wrote:
>
> > > I should make you guys aware that the XFree86 test packages I have made
> > > available contain David S. Miller's PCI domains patch. For the most
> > > part this seems to affect only SPARC, but I don't want you guys to go
> > > chasing shadows in stock 4.1.0 sourc
> > I should make you guys aware that the XFree86 test packages I have made
> > available contain David S. Miller's PCI domains patch. For the most part
> > this seems to affect only SPARC, but I don't want you guys to go chasing
> > shadows in stock 4.1.0 sources to troubleshoot issues that may
Branden Robinson wrote:
>
> On Thu, Jun 14, 2001 at 02:50:07PM +0200, Michel Dänzer wrote:
> > Benjamin Herrenschmidt wrote:
> > > That's the case. I mean it should know all busses and does support all 3
> > > uninorth busses. Is it called properly for the AGP bus (bus 0) by XFree
> > > ?
> >
> >
On Thu, Jun 14, 2001 at 02:50:07PM +0200, Michel Dänzer wrote:
> Benjamin Herrenschmidt wrote:
> > That's the case. I mean it should know all busses and does support all 3
> > uninorth busses. Is it called properly for the AGP bus (bus 0) by XFree ?
>
> >From current lnx_video.c:
I should make yo
Benjamin Herrenschmidt wrote:
>
> >
> >That's the problem, it doesn't work on AGP. outb works but inb segfaults.
> >
> >The syscall should only return an iobase for known working busses IMHO.
> At the
> >very least, it shouldn't return any for busses known not to work.
> >
>
> That's the case. I
>
>That's the problem, it doesn't work on AGP. outb works but inb segfaults.
>
>The syscall should only return an iobase for known working busses IMHO.
At the
>very least, it shouldn't return any for busses known not to work.
>
That's the case. I mean it should know all busses and does support all
Benjamin Herrenschmidt wrote:
>
> >> We need a way to use multiple ioBases from inside xfree to fix the
> >> problem. The best solution will be to disable ISA I/O for now and get a
> >> better fix later on.
> >
> >No, that's not the solution. The solution is to get the kernel to return
> >the *co
>> We need a way to use multiple ioBases from inside xfree to fix the problem.
>> The best solution will be to disable ISA I/O for now and get a better fix
>> later on.
>
>No, that's not the solution. The solution is to get the kernel to return
>the *correct* iobase for the sepecific devfn, right
On 1 Jun, this message from Adam Goode echoed through cyberspace:
> Sorry if this is completely wrong, but would Michel Lanners's
> "PCI Fixup" code be helpful here?
>
> http://www.cpu.lu/~mlan/linux/dev/pci.html
Not really, since that is only a dirty hack to make IO port access
somewhat more s
On Fri, 1 Jun 2001, Ani Joshi wrote:
> On Sat, 2 Jun 2001, Michel [ISO-8859-1] Dänzer wrote:
> > I might do that, but then is there any benefit of vgaHW working on a Mac? It
> > seems to work fine without, so I might as well hack the syscall to fail.
>
> Yes, vgaHW is very much indeed needed on Ma
On Sat, 2 Jun 2001, Michel [ISO-8859-1] Dänzer wrote:
> I might do that, but then is there any benefit of vgaHW working on a Mac? It
> seems to work fine without, so I might as well hack the syscall to fail.
Yes, vgaHW is very much indeed needed on Mac (or pretty much any
platform). For boards
Ani Joshi wrote:
On Fri, 1 Jun 2001, Kostas Gewrgiou wrote:
__NR_pciconfig_iobase
Another approach might be to make it only return an ioBase for known working
configurations, is that feasible?
We need a way to use multiple ioBases from inside xfree to fix the problem.
The best solution
Sorry if this is completely wrong, but would Michel Lanners's
"PCI Fixup" code be helpful here?
http://www.cpu.lu/~mlan/linux/dev/pci.html
Adam Goode
P.S. I'm not on the linuxppc-dev list, just debian-powerpc, so I've only
replied to the debian list.
On Fri, Jun 01, 2001 at 10:00:16AM -0700
On Fri, 1 Jun 2001, Ani Joshi wrote:
>
>
> On Fri, 1 Jun 2001, Kostas Gewrgiou wrote:
>
> > > __NR_pciconfig_iobase
> > >
> > > Another approach might be to make it only return an ioBase for known
> > > working
> > > configurations, is that feasible?
> >
> > We need a way to use multiple ioBases
On Fri, 1 Jun 2001, Kostas Gewrgiou wrote:
> > __NR_pciconfig_iobase
> >
> > Another approach might be to make it only return an ioBase for known working
> > configurations, is that feasible?
>
> We need a way to use multiple ioBases from inside xfree to fix the problem.
> The best solution will
> btw mmap("/proc/bus/pci/...") was added around 2.4.4 right ?
Yep 2.4.5. From memory the X patches I saw did not allow the
X server to fall back to mmap("/dev/mem") which is important.
Anton
On Fri, 1 Jun 2001, Michel Dänzer wrote:
>
> Anton Blanchard wrote:
>
> > > - r128 doesn't work without UseFBDev at least on Pismos (I suspect all
> > > UniNorth Macs) because we're now trying to do ISA I/O with the help of a
> > > new system call, but the server crashes. It works fine on those ma
Anton Blanchard wrote:
> > - r128 doesn't work without UseFBDev at least on Pismos (I suspect all
> > UniNorth Macs) because we're now trying to do ISA I/O with the help of a
> > new system call, but the server crashes. It works fine on those machines
> > without it, so what would we lose by disab
Hi,
> - r128 doesn't work without UseFBDev at least on Pismos (I suspect all
> UniNorth Macs) because we're now trying to do ISA I/O with the help of a new
> system call, but the server crashes. It works fine on those machines without
> it, so what would we lose by disabling it in r128 #ifdef __
The release is imminent and looking good (I've been able to fix DRI on r128 in
the last minute :), but there are a few issues left:
- r128 doesn't work without UseFBDev at least on Pismos (I suspect all
UniNorth Macs) because we're now trying to do ISA I/O with the help of a new
system call, but
45 matches
Mail list logo
