Date: Sat, 06 Jan 2001 14:31:12 -0800 From: Peter Wemm <peter@netplex.com.au> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Wilko Bulte <wkb@freebie.demon.nl>, freebsd-alpha@FreeBSD.ORG Subject: Re: debugging fpa / FDDI panic Message-ID: <200101062231.f06MVCq68942@mobile.wemm.org> In-Reply-To: <14935.34600.806565.787237@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Gallatin wrote:
>
> Wilko Bulte writes:
> > Now that I have -current running on my Miata I'm trying to find out why th
e
> > fpa driver causes a panic on boot:
> >
> > isp0: interrupting at CIA irq 16
> > pci1: <network, ethernet> at 10.0 (no driver attached)
> > fpa0: <Digital DEFPA PCI FDDI Controller> port 0x9000-0x907f mem
> > 0x80950000-0x8095ffff,0x80960000-0x8096007f irq 4 at device 11.0 on pci0
> >
> > fatal kernel trap:
> >
> > trap entry = 0x2 (memory management fault)
> > a0 = 0x80960014
>
> This is a bus address, not a virtual address.
>
> Change the bus_alloc_resource call in pdq_pci_attach() to
>
> memres = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0, ~0, 1,
> RF_ACTIVE|PCI_RF_DENSE);
>
> We should either have pci_alloc_resource default to RF_DENSE or panic
> if neither PCI_RF_DENSE nor PCI_RF_BWX are specified. The current
> state of affairs makes no sense..
Actually, what I think we should be doing is the same as how the interrupt
resources are handled... ie: seperate allocation and activation.
ie: res = bus_alloc_resource(dev, SYS_RES_IRQ, ....)
bus_setup_intr(dev, res, flags, irqhandler, handlerargs, &irqhandle);
IMHO, we should do the same with memory and IO space.
we presently have:
res = bus_alloc_resource(dev, SYS_RES_MEMORY, ...., RF_ACTIVE|magic_flags);
va = rman_get_virtual(res);
IMHO, this is wrong. We are allocating space within the scope of the bus
and expecting it to silently appear in CPU addressable space and then use
backdoor methods to grab it.
I think it would be better like this:
res = bus_alloc_resource(dev, SYS_RES_MEMORY, .... RF_ACTIVE)
bus_map_space(dev, res, magicflags, &bushandle, &bustag, &mappinghandle);
or something along those lines.
The allocation would be to reserve the space in the bus, and the
bus_map_space() would be to arrange for it to appear into CPU addressable
space, get the handles, choose convenient mapping modes (dense or sparse -
this is a CPU/core chipset *mapping* property, not a "pci bus resource"
property). The pci space on the alphas appears in several forms in the CPU
space.
Things like rman_get_virtual(), rman_get_bushandle(), rman_get_bustag() etc
are abominations and layering violations IMHO. NetBSD did not make this
mistake - they had seperate bus level allocation and cpu level mapping
calls pretty much right from the start. (This was particularly important
for things like the Amiga bridge cards where there was an ISA bus on the
far side of a seperate PC emulator bridge card and mapping the ISA bus was
not as simple as finding the physical address "appeared" in CPU space)
The fact that we have to do pmap_mapdev(), pmap_unmapdev() etc in the i386
code *regardless* of whether virtual access is even required is a bad sign.
Suppose we wanted to just get handles for busdma? We are wasting KVM in
that scenario.
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101062231.f06MVCq68942>