From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 23:20:57 2004 Return-Path: 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 642F716A4CE for ; Fri, 20 Aug 2004 23:20:57 +0000 (GMT) Received: from mimoza.pantel.net (mimoza.PANTEL.NET [212.24.191.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 203CF43D48 for ; Fri, 20 Aug 2004 23:20:57 +0000 (GMT) (envelope-from arutz@mimoza.pantel.net) Received: by mimoza.pantel.net (Postfix, from userid 1000) id 9A84B112EC; Sat, 21 Aug 2004 01:20:55 +0200 (CEST) Date: Sat, 21 Aug 2004 01:20:55 +0200 From: Antal Rutz To: current@freebsd.org Message-ID: <20040820232055.GA64448@mimoza.pantel.net> References: <4113EB2A.7060401@root.org> <20040812225838.GB10869@werd> <411D1C52.7050501@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411D1C52.7050501@root.org> User-Agent: Mutt/1.4.2i Subject: Re: Panic on boot with today's CURRENT, ata related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 20 Aug 2004 23:20:57 -0000 This bug is fixed for me with today's current (paniced a week ago, though). ad0 is udma100, cdrw is pio4. acpi enabled. If interested I can track down the change what made my notebook to work. the machine is an HP/compaq nx9005 On Fri, Aug 13, Nate Lawson wrote: > Radek Kozlowski wrote: > >On Fri, Aug 06, 2004 at 01:33:46PM -0700, Nate Lawson wrote: > > > >>I took a quick look at this ATA panic. The exact same one occurs for > >>Ceri. A quick dissassemble shows that the testb is the check for the > >>DMA flag at the very end of ata_generic_transaction(). The bug appears > >>to be that this may be a PIO request (since the DMA check is outside the > >>switch() statement). The fix is to make sure it's a DMA request before > >>dereferencing an element of the DMA struct. Try the attached patch. > > > > > >Another panic on boot with fresh -CURRENT, however this time ad0 is in > >UDMA100 mode: > > > > > >ad0: 38154MB [77520/16/63] at ata0-master > >UDMA100 > > > >Fatal trap 12: page fault while in kernel mode > >fault virtual address = 0x24 > >fault code = supervisor read, page not present > >instruction pointer = 0x8 :0xc0544896 > >stack pointer = 0x10 :0xd302db70 > >frame pointer = 0x10 :0xd302db70 > >code segment = base 0x0, limit 0xffffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > >processor eflags = interrupt enabled, resume, IOPL = 0 > >current process = 4 (g_down) > >[thread 100033] > >Stopped at rman_get_bustag+0x6: movl 0x24(%eax),%eax > >db> trace > >rman_get_bustag(0,d302db84,0,c1a33000,c8000000) at rman_get_bustag+0x6 > >ata_pci_dmastart(c1854200,c8,0,0,1) at ata_pci_dmastart+0x17 > >ata_generic_transaction(c1b3ea8c,c1b3ea8c,1f4,c0537399,0) at > >ata_generic_transaction+0x2e3 > >ata_start(c1854200,0,c1b3ea8c,c1854200,c1b42dec) at ata_start+0x279 > >ata_queue_request(c1b3ea8c,0,101,0,d302dc44,d302dc58,0,0,0,efd88083,2be897c,c1b42dec,c1aadd80) at ata_queue_request+0x1fc > >ad_start(c18542a8,c053e221,c1aaddc8,c1b42dec,c1aadd80) at ad_start+0x398 > >ata_start(c1854200,c1b42dec,0,0,c1b42dec) at ata_start+0xc8 > >adstrategy(c1b42dec,0,200,0,200) at adstrategy+0xce > >g_disk_start(c1b42e70,c0736028,24c,c06deea3,a) at g_disk_start+0x1b6 > >g_io_schedule_down(c188f000,c189e534,d302dd34,c0508650,0) at > >g_io_schedule_down+0x150 > >g_down_procbody(0,d302dd48,0,0,0) at g_down_procbody+0x1e > >fork_exit(c04e4f80,0,d302dd48) at fork_exit+0x80 > >fork_trampoline() at fork_trampoline+0x8 > >--- trap 0x1, eip = 0, esp = 0xd302dd7c, ebp = 0 --- > > > >-Radek > > ctlr->r_res1 is NULL but a DMA transaction is being started. This > results in a NULL pointer being passed to rman_get_bustag(). > ata_pci_attach() should not be setting the dmainit routine to > ata_pci_dmainit() if it can't enable busmastering. There are a myriad > of places to address this so I'm not sure where Soeren will want to fix > this. > > I'm still working with you privately on why r_res1 can't be allocated. > > -Nate > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- --rutz