From owner-freebsd-stable@FreeBSD.ORG Sat May 16 23:59:52 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 77D391065670; Sat, 16 May 2009 23:59:52 +0000 (UTC) To: freebsd-stable@freebsd.org Date: Sat, 16 May 2009 23:59:52 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20090516235952.77D391065670@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Subject: Fear and loathing in FreeBSD 7.2 (AGP issues and fixes) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2009 23:59:52 -0000 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 =============================================================================