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 the
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 machines and
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. This fixes the
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
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-branch I tested:
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, here's
the patch
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
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 of
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
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 really true.
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.
Well,
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 yes then it
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 need
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 ?
[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 bit
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 syscall to
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
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 reads
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 be, then
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;
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())
{
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 hwrec is alloced
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't work this
way
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.
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 this in
[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 sources to
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 now it
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 mean it should
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 you guys
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
?
From current
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 be
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
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 Mac (or
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 sane
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,
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
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 disabling it
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 machines
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, 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 be to
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,
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
42 matches
Mail list logo
