Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 May 2009 23:59:52 +0000 (GMT)
From:      wpaul@FreeBSD.ORG (Bill Paul)
To:        freebsd-stable@freebsd.org
Subject:   Fear and loathing in FreeBSD 7.2 (AGP issues and fixes)
Message-ID:  <20090516235952.77D391065670@hub.freebsd.org>

next in thread | raw e-mail | index | archive | help

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.

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@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@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
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@windriver.com | Wind River Systems
=============================================================================
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=============================================================================



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090516235952.77D391065670>