Date: Fri, 14 Mar 2003 00:12:28 -0800 (PST) From: "J. Kanowitz" <jkanowitz@snet.net> To: Glenn Johnson <glennpj@charter.net> Cc: FreeBSD-questions@FreeBSD.ORG Subject: Re: 3D with MGA on XFree86 4.3.0 / 5.0-RELEASE? Message-ID: <20030314081228.23485.qmail@web80304.mail.yahoo.com> In-Reply-To: <20030313002047.GA1909@gforce.johnson.home>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Glenn Johnson <glennpj@charter.net> wrote:
Thanks for the response!
> Try the following in your XF86Config file in the
> "Device" section:
>
> Option "NoHal" "true"
>
> That will prevent the server from trying to load the
> HAL module.
That does prevent the failure message, but hasn't
changed anything else.
>
> > Annoyingly, this means GL apps lock my system
[...]
> Not sure what is going on here but the HAL module is
> not necessary to
> run GL apps, at least not on my G400. It could be
> different on a G200
> but I doubt it. Do you have DRI enabled in
> XF86Config? If so, verify
> that direct rendering is on. You can check by
> running glxinfo and
> examining the output. Near the top of the output is
> a line that will
> tell you if direct rendering is on. That would be
> the first step.
glxinfo indeed reports direct rendering enabled and
good to go... and it isn't. I *believe* I've seen the
same scenario with 4.2.0 on my previous G200ed box,
which was a uniprocessor Athlon/4-STABLE; now I'm on a
dual-P2 SMP BX board (that becoming important in a
moment) with 5.0.
Having noticed the following in XFree86.0.log:
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such file or
directory)
drmOpenDevice: open result is -1, (No such file or
directory)
drmOpenDevice: Open failed
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such file or
directory)
drmOpenDevice: open result is -1, (No such file or
directory)
drmOpenDevice: Open failed
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmGetBusid returned ''
(II) MGA(0): [drm] loaded kernel module for "mga"
driver
[...snip...]
(II) MGA(0): [drm] installed DRM signal handler
(II) MGA(0): [DRI] installation complete
(II) MGA(0): [drm] Mapped 128 DMA buffers
(II) MGA(0): [drm] failure adding irq handler, there
is a device already using that irq
[drm] falling back to irq-free operation
(==) MGA(0): Direct rendering enabled
and
ACPI-0314: *** Error: Invalid signature where RSDP
indicates RSDT/XSDT should be located
ACPI-0181: *** Error: AcpiLoadTables: Could not
load RSDT: AE_BAD_SIGNATURE
ACPI-0213: *** Error: AcpiLoadTables: Could not
load tables: AE_BAD_SIGNATURE
ACPI: table load failed: AE_BAD_SIGNATURE
in dmesg, and having a stick of 256MB "32x4" SDRAM
installed, of which only the first 128MB is
addressable (which is what's breaking ACPI, as my BIOS
is smart enough to identify the stick as 256MB, albeit
an unsupported 256MB, and seems to be trying to put
the RSDT out at 0x0fffff80 - the end of 256MB, which
doesn't really exist...) ... I'm quite willing to
declare Too Many Variables, throw up my hands, and at
least wait until I can get ACPI back with a [more
sensible | less masochistically insane | "supported"]
configuration.
I believe I read something, somewhere about "irq-free
operation" with mga not being expected to function
just yet, but I'm too disorganized to relocate the
reference.
FWIW on the conflict (I'll need to school myself
before I pretend to understand what the IOAPIC line's
telling me, but I don't mind doing that on my own
time)-
mustelid# dmesg | grep "irq 11"
IOAPIC #0 intpin 16 -> irq 11
drm0: <Matrox G200 (AGP)> mem
0xf7800000-0xf7ffffff,0xf77fc000-0xf77fffff,0xf6000000-0xf6ffffff
irq 11 at device 0.0 on pci1
----
As far as I'm concerned, I've got my answer - at least
theoretically, I should *not* be needing mga_hal, and
the fact that it *did* work under 4.2.x may have been
a minor miracle/benefit of using Matrox's driver - and
I'll get down to poking at detangling my
IRQs/configuring the machine properly so it can do it
for me before assuming XFree86 is the problem. ;)
If anyone has reason to want the full XFree86 log,
dmesg, or anything else, just poke me.
-Joe "Floid" Kanowitz
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030314081228.23485.qmail>