> > Do you know off-hand whether the mapping registers say that the region
> > is prefetchable or not?  (I'm just wondering for my own curiosity; it
> > doesn't affect anything i've said here.)
> 
> How can I tell? Is this the PCI_MAPREG_MEM_CACHEABLE bit from pcireg.h? If
> so, no, it's not set on my 53c875 (ASUS SC875 card).

OK, right, that's what I was thinking of.

Given your reply, I can tell you that there are alpha systems on which
that card could not have its memory accessed linearly.  8-)


> So, I've got everything using the bus_space_* stuff, and it seems to be
> working just fine... except I tried using bus_space_write_multi_4 to
> copy the microcode over to the card, and it made my machine reboot. So,
> I'm currently using bus_space_write_4 in a loop, which works okay.

Are you sure you want to be using bus_space_write_multi_* rather than
bus_space_write_region_*?

i assume that your copy loop looks something like:

	u_int32_t script[];

	while (script left to copy) {
		bus_space_write_4(t, h, byteoffset, script[instoffset]);
		instoffset++;
		byteoffset += 4;
	}

bus_space_write_multi_* writes the contents of a region of memory to a
_single_ bus space location (i.e. writes the same location in bus
space multiple times), while bus_space_write_region_* writes the
contents of a region of memory to a region of bus space. 


> I think it's a gcc optimizer bug, but I'm not sure... it looks like gcc
> isn't paying attention to the list of registers that are used by the
> __asm() code in bus_space_write_multi_4. The following demonstrates the
> bug when compiled with -O or -O2:
> [ ... ]

This is interesting, but it may be unrelated to your problem (if
you're using the wrong function 8-)

I wonder if anybody is still seeing reboot problems with the lpt
driver...


chris