From owner-cvs-src-old@FreeBSD.ORG Fri Dec 10 21:45:21 2010 Return-Path: Delivered-To: cvs-src-old@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0C481065694 for ; Fri, 10 Dec 2010 21:45:21 +0000 (UTC) (envelope-from ken@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 8441D8FC1B for ; Fri, 10 Dec 2010 21:45:21 +0000 (UTC) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.4/8.14.4) with ESMTP id oBALjLL4054719 for ; Fri, 10 Dec 2010 21:45:21 GMT (envelope-from ken@repoman.freebsd.org) Received: (from svn2cvs@localhost) by repoman.freebsd.org (8.14.4/8.14.4/Submit) id oBALjLwH054718 for cvs-src-old@freebsd.org; Fri, 10 Dec 2010 21:45:21 GMT (envelope-from ken@repoman.freebsd.org) Message-Id: <201012102145.oBALjLwH054718@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: svn2cvs set sender to ken@repoman.freebsd.org using -f From: "Kenneth D. Merry" Date: Fri, 10 Dec 2010 21:45:10 +0000 (UTC) To: cvs-src-old@freebsd.org X-FreeBSD-CVS-Branch: HEAD Subject: cvs commit: src/sys/dev/mps mps.c mpsvar.h X-BeenThere: cvs-src-old@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 21:45:21 -0000 ken 2010-12-10 21:45:10 UTC FreeBSD src repository Modified files: sys/dev/mps mps.c mpsvar.h Log: SVN rev 216363 on 2010-12-10 21:45:10Z by ken Fix an event handling bug with the mps(4) driver. This bug manifested itself after repeated device arrivals and departures. The root of the problem was that the last entry in the reply array wasn't initialized/allocated. So every time we got around to that event, we had a bogus address. There were a couple more problems with the code that are also fixed: - The reply mechanism was being treated as sequential (indexed by sc->replycurindex) even though the spec says that the driver should use the ReplyFrameAddress field of the post queue descriptor to figure out where the reply is. There is no guarantee that the reply descriptors will be used in sequential order. - The second word of the reply post queue descriptor wasn't being checked in mps_intr_locked() to make sure that it wasn't 0xffffffff. So the driver could potentially come across a partially DMAed descriptor. - The number of replies allocated was one less than the actual size of the queue. Instead, it was the size of the number of replies that can be used at one time. (Which is one less than the size of the queue.) mps.c: When initializing the entries in the reply free queue, make sure we initialize the full number that we tell the chip we have (sc->fqdepth), not the number that can be used at any one time (sc->num_replies). When allocating replies, make sure we allocate the number of replies that we've told the chip exist, not just the number that can be used simultaneously. Use the ReplyFrameAddress field of the post queue descriptor to figure out which reply is being referenced. This is what the spec says to do, and the spec doesn't guarantee that the replies will be used in order. Put a check in to verify that the reply address passed back from the card is valid. (Panic if it isn't, we'll panic when we try to deference the reply pointer in any case.) In mps_intr_locked(), verify that the second word of the post queue descriptor is not 0xffffffff in addition to verifying that the unused flag is not set, so we can make sure we didn't get a partially DMAed descriptor. Remove references to sc->replycurindex, it isn't needed now. mpsvar.h: Remove replycurindex from the softc, it isn't needed now. Reviewed by: scottl Revision Changes Path 1.9 +51 -10 src/sys/dev/mps/mps.c 1.5 +0 -1 src/sys/dev/mps/mpsvar.h