Re: 3D with MGA on XFree86 4.3.0 / 5.0-RELEASE?
--- Glenn Johnson [EMAIL PROTECTED] 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 0x0f80 - 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 0xf780-0xf7ff,0xf77fc000-0xf77f,0xf600-0xf6ff 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 [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: 3D with MGA on XFree86 4.3.0 / 5.0-RELEASE?
Glenn Johnson writes: On Wed, Mar 12, 2003 at 03:38:02PM -0800, J. Kanowitz wrote: With 4.3.0, I've not seen the usual reminder about the driver, and blindly specifying WITH_MATROX_GXX_DRIVER (without bothering to pore over the build output; see previous comment on 'lazy') doesn't do the trick: No, it is not an option for XFree86-4.3. Matrox has not made an updated version available yet. I am not sure if the current code from Matrox will build with XFree86-4.3 but that would leave you with an older mga driver. I would guess that Matrox will eventually update their driver but unless you are running multi-displays you probably do not need it. I'm using a G450 with a TFT which makes using the HAL necessary. I merely copied the old mga_hal_drv.o from 4.2.1 and it works just fine. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: 3D with MGA on XFree86 4.3.0 / 5.0-RELEASE?
On Thu, 13-Mar-2003 at 13:32:21 +0100, Gary Jennejohn wrote: Glenn Johnson writes: On Wed, Mar 12, 2003 at 03:38:02PM -0800, J. Kanowitz wrote: With 4.3.0, I've not seen the usual reminder about the driver, and blindly specifying WITH_MATROX_GXX_DRIVER (without bothering to pore over the build output; see previous comment on 'lazy') doesn't do the trick: No, it is not an option for XFree86-4.3. Matrox has not made an updated version available yet. I am not sure if the current code from Matrox will build with XFree86-4.3 but that would leave you with an older mga driver. I would guess that Matrox will eventually update their driver but unless you are running multi-displays you probably do not need it. I'm using a G450 with a TFT which makes using the HAL necessary. I merely copied the old mga_hal_drv.o from 4.2.1 and it works just fine. It is also needed for TV-Out support on the G400-DH. -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
3D with MGA on XFree86 4.3.0 / 5.0-RELEASE?
Keeping this brief, I'm a lazy sod, and it's fairly obvious the 4.3.0 integration is in flux. I've got a G200: drm0: Matrox G200 (AGP) mem 0xf780-0xf7ff,0xf77fc000-0xf77f,0xf600-0xf6ff irq 11 at device 0.0 on pci1 On: FreeBSD mustelid.gateway.2wire.net 5.0-RELEASE FreeBSD 5.0-RELEASE #0: Sat Feb 8 22:13:06 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MUSTELID i386 Under previous versions of XFree86 4, I've built /usr/ports/x11-servers/XFree86-4-Server with -DWITH_MATROX_GXX_DRIVER and all has been well. [It was never well without the Matrox code; I'm honestly not sure if that's supposed to be the case.] With 4.3.0, I've not seen the usual reminder about the driver, and blindly specifying WITH_MATROX_GXX_DRIVER (without bothering to pore over the build output; see previous comment on 'lazy') doesn't do the trick: (II) Loading sub module mga_hal (II) LoadModule: mga_hal (WW) Warning, couldn't open module mga_hal (II) UnloadModule: mga_hal (EE) MGA: Failed to load module mga_hal (module does not exist, 0) Annoyingly, this means GL apps lock my system, or more specifically for those tracking such things, they manage to mung something that kills the keyboard to the point of inoperative num/scroll/caps LEDs, while leaving the USB mouse (and the rest of the system) mostly operative. atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 ums0: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM), rev 1.10/3.00, addr 2, iclass 3/1 -- So after all that blather, all I want to know is: A. Is mga_hal [deprecated|not yet available|broken], or do I just need to stop being stupid? B. If the last, where should I be looking to start not being stupid? -Thanks, (Doubleplusthanks to all who've brought 5.0 to -RELEASE, of course!) -Joe Floid Kanowitz To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: 3D with MGA on XFree86 4.3.0 / 5.0-RELEASE?
On Wed, Mar 12, 2003 at 03:38:02PM -0800, J. Kanowitz wrote: Keeping this brief, I'm a lazy sod, and it's fairly obvious the 4.3.0 integration is in flux. I've got a G200: drm0: Matrox G200 (AGP) mem 0xf780-0xf7ff,0xf77fc000-0xf77f,0xf600-0xf6ff irq 11 at device 0.0 on pci1 On: FreeBSD mustelid.gateway.2wire.net 5.0-RELEASE FreeBSD 5.0-RELEASE #0: Sat Feb 8 22:13:06 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MUSTELID i386 Under previous versions of XFree86 4, I've built /usr/ports/x11-servers/XFree86-4-Server with -DWITH_MATROX_GXX_DRIVER and all has been well. [It was never well without the Matrox code; I'm honestly not sure if that's supposed to be the case.] The need for the HAL depends on the card in question. For the G200, it is only needed for multi-display support. I believe it _may_ be needed for some functionality of the Matrox PowerDesk but I am not sure about that because I do not use it. With 4.3.0, I've not seen the usual reminder about the driver, and blindly specifying WITH_MATROX_GXX_DRIVER (without bothering to pore over the build output; see previous comment on 'lazy') doesn't do the trick: No, it is not an option for XFree86-4.3. Matrox has not made an updated version available yet. I am not sure if the current code from Matrox will build with XFree86-4.3 but that would leave you with an older mga driver. I would guess that Matrox will eventually update their driver but unless you are running multi-displays you probably do not need it. (II) Loading sub module mga_hal (II) LoadModule: mga_hal (WW) Warning, couldn't open module mga_hal (II) UnloadModule: mga_hal (EE) MGA: Failed to load module mga_hal (module does not exist, 0) 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. Annoyingly, this means GL apps lock my system, or more specifically for those tracking such things, they manage to mung something that kills the keyboard to the point of inoperative num/scroll/caps LEDs, while leaving the USB mouse (and the rest of the system) mostly operative. 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. -- Glenn Johnson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
