[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: I2O on sparc64 [Also on alpha] (Was: Re: mlx on sparc?)
On Thu, 5 Jun 2008, Jan-Hinrich Fessel wrote:
Am 05.06.2008 um 16:31 schrieb Andrew Doran:
Didn't help much - now it waits longer (actually until the KITT phase), but
still reset rejected. Could this be an endian issue despite the
Anyway, since the exit code is 0x0 and not IOP_RESET_REJECTED, I changed
iop.c to ignore the status if it's 0...
It looks like the board actually did reset OK. Can you give this patch
Now I get:
Distributed Processing Technology Memory Controller (miscellaneous memory,
revision 0x02) at pci2 dev 3 function 0 not configured
iop0 at pci2 dev 4 function 0: I2O adapteriop0: reset rejected, status 0x0
iop0: STATUS_GET timed out
iop0: not responding (get status)
which doesn't really bring us that much progress.
What next - and I already exchanged the controller for a known good unit...
Was there any further progress with this?
I have an AlphaServer ES40 and an AlphaServer ES45 with an I2O
controller. Back when I was playing on the ES40, I had added iop(4) to
the alpha kernel config, only to have it fail. I don't remember the
details at the time, and didn't spend too much time trying to debug it.
I had an mlx(4) controller that I had added to the ES40 since OpenVMS
didn't support the I2O controller.
I am now playing around with an ES45, which wasn't supported at all, but
I have gotten it to boot up and probe all the pci hose now. It has a
couple of Emulex fiber interfaces, which again have no driver available.
I added the iop(4) to the kernel configuration and had it fail in the same
manner as described in this thread.
It looked like it should be working, but as Andy mentioned in a later
message, the reset status and the status_get data never show up in memory.
After digging into the alpha busdma trying to re-familiarize myself with
alpha DMA again, I realized that the 'physical address' used by the
iop_reset() and iop_status_get() functions was a 'real' physical memory
address. However, the alpha uses a different address space for the DMA
addresses. The first 1G (I think) of physical memory is "direct-mapped',
but at an address base of 0x80000000, and the remaining memory is access
through the alpha sgmap address space (at a different address base).
I.e., the physical address 0x2f4000 is addressed at 0x802f4000 in the DMA
After hacking the iop(4) driver to convert the physical address to a
DMA address, I was able to get the iop(4) driver to work on the
AlphaServer ES45 quite nicely.
I'm not all the familiar with the bus_dma routines, but it appears that
the problem is due to using bus_dmamem_alloc() to allocate the scratch and
reply memory, and doing bus_dmamem_map() and bus_dmamap_load() on them.
On the alpha, this results in a "real" physical memory address in the dma
segments, which doesn't work. I'm in the process of trying to figure out
if the current method is incorrect and if so, how to fix it.
I'm even less familiar with the sparc64 DMA, but I'm wondering the the
same type of thing is happening there (i.e., the DMA addressing is not
real physical memory, but mapped through DMA mappings).
Michael L. Hitch mhitch%montana.edu@localhost
Information Technology Center
Montana State University Bozeman, MT USA
Main Index |
Thread Index |