Fear and loathing in FreeBSD 7.2 (AGP issues and fixes)
Paul B. Mahol
onemda at gmail.com
Sun May 17 00:43:59 UTC 2009
On 5/17/09, Bill Paul <wpaul at freebsd.org> wrote:
>
> So. I decided to test FreeBSD 7.2 on my Averatec AV1020 ED1 laptop. (It
> currently has 6.0-RELEASE on it, and while it runs fine, I figured now
> was a good time to update it.) I ran into two problems with it, and I
> thought it would be a good idea to share how I resolved them, just in
> case anyone else is foolish enough to follow in my tracks.
>
> The laptop has a RaLink RT2560 wireless chipset. The ral(4) driver
> supports this chip out of the box, however that driver doesn't support
> WPA2 Enterprise, which I need for work. To get around this, I use
> the Windows NDIS driver with Project Evil. Unfortunately, the driver
> that comes with the laptop (version 3.0.3.0000) is buggy, and will
> trigger a kernel panic in certain conditions. It seems to have trouble
> parsing information from certain newer kinds of devices, which causes
> some of the code inside the driver binary to dereference a bogus pointer.
>
> This is not a problem with FreeBSD or Project Evil: I discovered that
> the same driver blue-screens Windows XP as well (a testament to just
> how closely Project Evil emulates Windows: it even emulates its crashes).
> Luckily there is a slightly newer driver available that fixes this issue
> (3.1.0.000), though I had to hunt a bit to find it. I put copies of
> the .SYS and .INF at:
>
> http://www.freebsd.org/~wpaul/7_2_RELEASE/wifi
>
> The other problems I had were with graphics. The Averatec has an Intel
> 82855GME graphics controller. With FreeBSD 6.0, I had it working nicely
> with DRI and everything. With FreeBSD 7.2 and xorg 1.6.0, I saw some
> peculiar problems.
>
> The most glaring issue was that after running X -configure for the first
> time and testing the resulting xorg.conf file, I found that the X server
> would not respond to the mouse or keyboard. After some digging, I found
> that this was due to the AutoAddDevices feature (described in xorg.conf(5))
> being on by default. If AutoAddDevices is on, then AllowEmptyInput is also
> turned on, but the description for AllowEmptyInput says: "If AllowEmptyInput
> is on, devices using the kbd, mouse or vmmouse driver are ignored." I
> don't know what's supposed to happen instead, but it wasn't working. I
> had to add:
>
> Option "AutoAddDevices" "False"
>
> to my xorg.conf to turn this off in order for my mouse and keyboard to
> work.
>
> On a related note, the X server seems to ignore a lot of what you put
> in xorg.conf in favor of its autoselected defaults. I tried to use
> "DefaultDepth 24" to force the screen color depth, but it seems to
> always ignore this and use a depth of 32 bits. It seems to work ok, but
> I thought this was odd. If I tell it to do something, it should do it.
> This used to work in earlier X releases.
Well, at least with intel driver on i915GM using anything lower than
defaults will cause interesting artefacts on various games: alephone & oolite.
>
> More curiously, X -configure decided for some reason that my laptop
> had two graphics cards instead of one. This apparently has to do with
> the fact that the gracphic device has two PCI functions:
>
> vgapci0 at pci0:0:2:0: class=0x030000 card=0x031914ff chip=0x35828086
> rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics
> Device'
> class = display
> subclass = VGA
> vgapci1 at pci0:0:2:1: class=0x038000 card=0x031914ff chip=0x35828086
> rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics
> Device'
> class = display
>
> X -configure created a "Card" and "Screen" section for both of these, even
> though it should only have created one. I had to edit the xorg.conf to
> remove the duplicates. (This was something else that worked correctly in
> older versions of X.)
>
> Once I settled those issues, the X server worked, but I found that I
> was unable to use DRI. FreeBSD was correctly loading the agp, drm and
> i915 drivers, but the X server refused to activate DRI support. According
> to the Xorg.log.0 file, it was failing to allocate a couple of regions
> of physical memory from the AGP driver. I finally traced this down to
> the agp_i810 code in the kernel. In agp_i810_alloc_memory(), it says:
>
> [...]
> } else if (type == 2) {
> /*
> * Type 2 is the contiguous physical memory type, that hands
> * back a physical address. This is used for cursors on
> i810.
> * Hand back as many single pages with physical as the user
> * wants, but only allow one larger allocation (ARGB cursor)
> * for simplicity.
> */
> if (size != AGP_PAGE_SIZE) {
> if (sc->argb_cursor != NULL)
> return 0;
>
> [...]
>
> I'm all for simplicity, but this is bogus: the Intel video driver wants
> to allocate three ranges of physical memory for cursors, but only the
> first one succeeds. Two additional allocates for 40K and 16K both fail
> because of this code.
>
> I ended up modifying agp_i810.c to deal with this, by allowing it to
> allocate as many of these ranges as it wants. In the process of testing
> this, I also ran into another problem: if you load agp.ko, drm.ko
> and i915.ko as modules, and then try to unload them, the kernel will
> panic in agp_i810_detach(). It seems that during unload, the drm/i915
That is fixed correctly on CURRENT but not backported.
Maybe I can track exact svn revision ... I never cared to file PR because I use
only CURRENT.
> code will release the I/O resources allocated by the agp_i810 driver before
> the agp_i810_detach() driver gets to run. That's a shame, because
> agp_i810_detach() needs to use them. When it tries to clear a bit in one
> of the i810's registers, it ends up trying to use a memory mapped I/P
> mapping that's no longer valid. As a workaround, I modified
> agp_i810_detach() to check to see if the resources are still valid, and
> to allocate them again if they're not. This is a hack: the DRM code
> should be sorted out to prevent this from happening, but I'm not really
> eager to dive into it myself.
>
> I put the modified Intel AGP driver code at:
>
> http://www.freebsd.org/~wpaul/7_2_RELEASE/agp
>
> To use it, copy agp_i810.c and agppriv.h to /sys/pci, then recompile
> your kernel and/or agp.ko module.
>
> Once I patched the AGP driver, the X server was willing to enable DRI
> support, but I found that GLX apps still didn't work. In particular,
> things like the GLmatrix screen saver in KDE 4 claimed that the current
> visual did not support the GLX extension. Looking through the log
> file again, I saw that it said: "(==) AIGLX disabled." I considered
> this odd, since I didn't ask to disable it. Apparently it's disabled
> by default. I corrected this by adding:
>
> Option "AIGLX" "on"
>
> to the xorg.conf file. Finally, everything worked correctly. I was
> even able to compile and install the latest Intel video driver (2.7.1).
> One minor nit is that the FreeBSD AGP code doesn't support GEM, which
> the newer X drivers seem to want. This does not appear to be a fatal
> problem (yet).
>
> I put my current xorg.conf file at:
>
> http://www.freebsd.org/~wpaul/7_2_RELEASE/agp
>
> as well.
>
> It was a bit of a shame that I had to fight so much to get this stuff
> to work, though now that I have I'm relatively pleased with the results.
> I was able to get bluetooth tethering to work with my Blackberry fairly
> easily. I still need to confirm that WPA2 works when I get to the office on
> Monday. If it does, I'm going to go through with the update.
>
> -Bill
>
> --
> =============================================================================
> -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu
> wpaul at windriver.com | Wind River Systems
> =============================================================================
> "I put a dollar in a change machine. Nothing changed." - George Carlin
> =============================================================================
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>
--
Paul
More information about the freebsd-stable
mailing list