Re: Panic on boot with today's CURRENT, ata related

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:
> >
> ><snip>
> >ad0: 38154MB <IC25N040ATMR04-0/M020AD0A> [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_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 

-- 
 
 
--rutz