From owner-freebsd-sparc64@FreeBSD.ORG Tue Sep 30 00:42:37 2008 Return-Path: <owner-freebsd-sparc64@FreeBSD.ORG> Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 379F61065690 for <freebsd-sparc64@freebsd.org>; Tue, 30 Sep 2008 00:42:37 +0000 (UTC) (envelope-from scaron@umich.edu) Received: from heartbreakers.mr.itd.umich.edu (heartbreakers.mr.itd.umich.edu [141.211.93.154]) by mx1.freebsd.org (Postfix) with ESMTP id D7BC68FC2F for <freebsd-sparc64@freebsd.org>; Tue, 30 Sep 2008 00:42:36 +0000 (UTC) (envelope-from scaron@umich.edu) Received: FROM chipewa.web.itd.umich.edu (chipewa.web.itd.umich.edu [141.211.144.147]) BY heartbreakers.mr.itd.umich.edu ID 48E170A4.CF1AC.18785 ; 29 Sep 2008 20:19:48 -0400 Received: (from www@localhost) by chipewa.web.itd.umich.edu () id m8U0JlF0006423; Mon, 29 Sep 2008 20:19:47 -0400 Received: from arbo-1-core-1.diablonet.net (arbo-1-core-1.diablonet.net [75.144.70.41]) by web.mail.umich.edu (Horde Framework) with HTTP; Mon, 29 Sep 2008 20:19:47 -0400 Message-ID: <20080929201947.86701vp3bs8vcatc@web.mail.umich.edu> Date: Mon, 29 Sep 2008 20:19:47 -0400 From: Sean Thomas Caron <scaron@umich.edu> To: freebsd-sparc64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.2) X-Remote-Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 X-IMP-Server: 141.211.144.229 (chipewa) X-Originating-IP: 75.144.70.41 X-Originating-User: scaron Cc: Subject: Kernel panic in 7.0-RELEASE with fatm driver X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc <freebsd-sparc64.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64>, <mailto:freebsd-sparc64-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-sparc64> List-Post: <mailto:freebsd-sparc64@freebsd.org> List-Help: <mailto:freebsd-sparc64-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64>, <mailto:freebsd-sparc64-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 30 Sep 2008 00:42:37 -0000 Hi folks, I've been running FreeBSD 6.x on a number of Ultrasparc based systems =20 using the Cranor NATM driver with a bunch of Fore PCA-200E cards. It =20 generally worked but as the machines got hit with higher and higher =20 network load I would get kernel panics at fairly random intervals on =20 "sbdrop" and "sbflush". Sometimes I would get two per day, sometimes I =20 wouldn't get any for two weeks. So after a while at this I decided to try 7.0-RELEASE out hoping =20 whatever bug was causing these random kernel panics might have gotten =20 fixed. Test system is Sun Fire v120, 550 MHz, 1 GB RAM, PCA-200e installed in =20 PCI slot. I pruned a bunch of stuff from GENERIC and added the usual Cranor NATM =20 stuff that I was using in 6.x. In particular - # ATM options NATM device atm device fatm device utopia Kernel does have multiprocessing enabled (as GENERIC did) even though =20 it's a uniprocessor machine. I built the new kernel then reboot and it panics immediately after =20 touching the ATM card - fatm0: <FORE PCA200E> mem 0x200000-0x3fffff at device 5.0 on pci2 panic: bus_dma_tag_create: parent DMA tag NULL cpuid =3D 0 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. I'm hoping maybe someone has seen this before and has a patch laying =20 around somewhere, or if nothing else, it might get passed along to the =20 fatm maintainer eventually? If anyone wants to see any further information e.g. full kernel =20 configuration file, I will be happy to pass along. I can also procure =20 a backtrace if someone can tell me how to hardcode a dump path into =20 the kernel; I can't find a procedure documented anywhere. Thanks! -Sean