From owner-freebsd-current@FreeBSD.ORG Sat Oct 17 22:23:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E84C81065692; Sat, 17 Oct 2009 22:23:20 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f192.google.com (mail-qy0-f192.google.com [209.85.221.192]) by mx1.freebsd.org (Postfix) with ESMTP id 8538A8FC22; Sat, 17 Oct 2009 22:23:20 +0000 (UTC) Received: by qyk30 with SMTP id 30so2538526qyk.7 for ; Sat, 17 Oct 2009 15:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=2/FiMBK+NMaOYHiGudmKu8lt6iYnPm4P110AQfwLYKk=; b=ZvWVuXklNDwfPMwHT+UHaL4Ycwdbm64HfizV8rovYBoUGdZXDkgBZpLKLfJ/8nlLmF Y9UW1/Ae7lc0srTag4Pf04iWtFoUWLm61D2XGixm4PY3tWXeHbTr2g0eLdvXQom4vopQ 8NYfea19+5SMogngXIysTle9JTdY5zKqdFvC8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Ow0F7ZLmgd9GYKLXsTARwMGEFz8OJQzzQLSxUGU7hxJXGSNnaHbIFnBbSaSmWlrQ5G TBRekGc7tAXwNW1I8qPV1+rhEFVSeqZXgxFXU+ITC54Yhl2pyBPsvKuoEqI8fvYkMalf oUAf4clh0RIQ+shL6QQQsg/gpNYE0VZ7GUxas= Received: by 10.224.90.67 with SMTP id h3mr1821608qam.240.1255818199699; Sat, 17 Oct 2009 15:23:19 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 20sm2142488qyk.9.2009.10.17.15.23.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 17 Oct 2009 15:23:18 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sat, 17 Oct 2009 15:23:14 -0700 From: Pyun YongHyeon Date: Sat, 17 Oct 2009 15:23:14 -0700 To: Mykola Dzham Message-ID: <20091017222314.GB19204@michelle.cdnetworks.com> References: <20091017170351.GZ29771@expo.ukrweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091017170351.GZ29771@expo.ukrweb.net> User-Agent: Mutt/1.4.2.3i Cc: jfv@freebsd.org, current@freebsd.org Subject: Re: page fault in igb driver on 8.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 22:23:21 -0000 On Sat, Oct 17, 2009 at 08:03:51PM +0300, Mykola Dzham wrote: > Hi! > On hight network load system panics: > > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > I believe this type of message should not be in fast path and it should be rate-limited. > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 02 > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff8025e4a5 > stack pointer = 0x28:0xffffff87312f3a60 > frame pointer = 0x28:0xffffff87312f3a80 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (igb0 taskq) > trap number = 12 > panic: page fault > cpuid = 2 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff80185baa = > db_trace_self_wrapper+0x2a > panic() at 0xffffffff8020e992 = panic+0x182 > trap_fatal() at 0xffffffff8040eefd = trap_fatal+0x2ad > trap_pfault() at 0xffffffff8040f27d = trap_pfault+0x22d > trap() at 0xffffffff8040fbff = trap+0x3cf > calltrap() at 0xffffffff803f6e13 = calltrap+0x8 > --- trap 0xc, rip = 0xffffffff8025e4a5, rsp = 0xffffff87312f3a60, rbp = > 0xffffff87312f3a80 --- > mb_free_ext() at 0xffffffff8025e4a5 = mb_free_ext+0x15 > igb_get_buf() at 0xffffffff80a3a6e5 = igb_get_buf+0x2e5 > igb_rxeof() at 0xffffffff80a3abd5 = igb_rxeof+0x425 > igb_handle_rx() at 0xffffffff80a3b14b = igb_handle_rx+0x3b > taskqueue_run() at 0xffffffff80243ec1 = taskqueue_run+0x91 > taskqueue_thread_loop() at 0xffffffff8024404f = > taskqueue_thread_loop+0x3f > fork_exit() at 0xffffffff801ea9b2 = fork_exit+0x112 > fork_trampoline() at 0xffffffff803f72ee = fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff87312f3d30, rbp = 0 --- > Uptime: 1h46m18s > Cannot dump. Device not defined or unavailable. > > System is amd64 8.0-RC1 r197974 Tue Oct 13 23:00:17 EEST 2009 > Hmm, I remember some user already reported similar issues for igb(4). At that time I briefly looked over possible code paths for the issue and saw some questionable handling of mbufs under resource shortage cases and I sent my concerns to Jack but it seems he lost the mail. Unfortunately I don't have igb(4) hardwares so I guess it's somewhat hard for me to fix the issue but I'll try to read the code again if time permit.