From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 04:49:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40636106566B; Thu, 25 Aug 2011 04:49:11 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id DE6CA8FC08; Thu, 25 Aug 2011 04:49:10 +0000 (UTC) Received: by vxh11 with SMTP id 11so1800266vxh.13 for ; Wed, 24 Aug 2011 21:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=gLxXKwQAS9vXAaANtbgALVtCafTMwM4VwmDRwT8Dt1A=; b=MaM/SsqIbqoCzljGblZviV+KVxG8IIxN4OGHATAOLryxCJm8ijuROiIJ+b4ESOaB4k UszqAsbR3aNdHqK5AFqwZL4MiACLUHcUrDYn9cgvFkJx/YObbXBG3MjYEUNJ50d1QgjR 2nF6meRQereCA9KJrU9S7+mcFsvTyQX9Xgdxc= MIME-Version: 1.0 Received: by 10.52.173.111 with SMTP id bj15mr5357293vdc.46.1314247750019; Wed, 24 Aug 2011 21:49:10 -0700 (PDT) Received: by 10.224.19.131 with HTTP; Wed, 24 Aug 2011 21:49:09 -0700 (PDT) Date: Wed, 24 Aug 2011 21:49:09 -0700 Message-ID: From: Garrett Cooper To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: if_ath - should it be compiled without ath_hal support? 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: Thu, 25 Aug 2011 04:49:11 -0000 I ran into the panic shown below because it appears that some array indexing went off into the weeds. I haven't seen this happen but once though when running a buildworld last night using r225089 on i386. This begs the question - is it wise to compile if_ath without ath_hal support today? I've been doing this recently because ath_hal isn't available under /sys/modules , and unless I unload the module, things like suspend and resume don't work because if_ath doesn't support suspend/resume yet). There are a lot of references to the ath_hal APIs in if_ath.c now that don't have #ifdefs guarding them as well which concern me.. TIA! -Garrett Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc5ec97f0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0c58968 stack pointer = 0x28:0xd87e2bfc frame pointer = 0x28:0xd87e2c78 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (ath0 taskq) Physical memory: 1001 MB Dumping 103 MB: 88 72 56 40 24 8 ... (kgdb) list 3659 m->m_pkthdr.rcvif = ifp; 3660 m->m_pkthdr.len = len; 3661 } 3662 3663 ifp->if_ipackets++; 3664 sc->sc_stats.ast_ant_rx[rs->rs_antenna]++; 3665 3666 /* 3667 * Populate the rx status block. When there are bpf 3668 * listeners we do the additional work to provide (kgdb) p sc->sc_stats.ast_ant_rx $6 = {0, 3458, 0, 0, 0, 0, 0, 0} (kgdb) p rs->rs_antenna $7 = 8399232 (kgdb)