From owner-freebsd-current@FreeBSD.ORG Tue Jul 11 20:50:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA6CD16A4DE; Tue, 11 Jul 2006 20:50:35 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E630C43D7B; Tue, 11 Jul 2006 20:50:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6BKnTEU046628; Tue, 11 Jul 2006 14:49:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 11 Jul 2006 14:49:29 -0600 (MDT) Message-Id: <20060711.144929.74705658.imp@bsdimp.com> To: wpaul@freebsd.org From: Warner Losh In-Reply-To: <20060711203213.3C7C816A4E1@hub.freebsd.org> References: <20060712.044439.74753790.goto@snowy.to> <20060711203213.3C7C816A4E1@hub.freebsd.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 11 Jul 2006 14:49:30 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: if_re does not work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 20:50:35 -0000 > > > In theory the bus_alloc_resource(.., SYS_RES_IRQ, ...) should route an > > > interrupt for the re0 device but it won't show up in the probe line in that > > > case since the probe line is printed before re_attach() is called. In fact, > > > in the failing case, it wasn't bus_alloc_resource() that failed, but > > > bus_setup_intr(). This is most likely not an re0 issue however. > > > > > > goto-san, can you add printf's to i386/i386/intr_machdep.c:intr_add_handler() > > > and kern/kern_intr.c:intr_event_add_handler() to see which of the EINVAL > > > cases is being triggered? > > > > I added printf() to 2 functions (one in intr_add_handler() and two > > in intr_event_add_handler()) and re-build my kernel and reboot my > > ThinkPad X40. But I could not get any printf's messages. > > > > And I have a question. Why INTR_FAST was added in re_attach()? > > When I deleted it and re-build if_re modules, my card was attached. > > INTR_FAST added because the driver was converted to use 'fast' interrupts. > > I really hope nobody's going to tell me that INTR_FAST isn't supported with > cardbus. INTR_FAST isn't supported with cardbus at the moment. However, that decision dates from a time when you couldn't share fast and non-fast interrupts. Cardbus necessarily shared its function interrupt with its card status change interrupt (since there's only one interrupt pin on the cardbus bridge). I'll investigate what it takes to make this happen given the current new-world order. I have at least one re cardbus card, I think, so I can do testing. Warner