> I'm not sure what to do, but here's a start.
> 
> Can you get these error in r/o mode? That way you can
> test w/o damaging stuff..

Well, they don't seem to cause damage since they are only unexpected
phase errors. The ncr code resynchronizes the bus when it happens.
It just prints alot of stuff and makes things very slow.

> The other thing is we need some big-guns help w/ kernel memory layout.
> Basically the only thing I can think of is for us (well, you)
> to figure out where things are in the kernel image, and try adding
> extra padding in various places. Like figure out what moved
> between kernels, and then try hacks to bload code further on
> in the kernel.

Well, I'm sort of doing that by adding and subtracting code. I think it
may have to do with link ordering. This may be a compiler or linker bug
and it may also be a strangity of the IIvx since I have heard no other
reports of this occuring.

I *want* to work on this problem in a more thorough and serious manner but
I have serious time constraints. I'm trying to get an alpha intvid kernel out
the door as soon as possible while dealing with a Parallaxis program I
have to crank out by Tuesday. I sure wish I knew Parallaxis as well as
I did kernel hacking :-)

> The idea is to bracket the problem (if possable), If bloating
> something at 32% of the kernel has problems and bloat at 50%
> doesn't, moving things inbetween is the problem..

True. I'll have to check where SCSI is getting linked in, in relation
to the grf driver. If it's after then the problem is obvious. If it is
getting linked in before then all bets are off as to what is going on.

> I think we might be in for learning something really weird about Apple
> hardware.

This may have something to do with the fact that we're still inheriting most
of our memory map from MacOS. In a perfect world we would write some bootstrap
code that would absolutely size the RAM (or ask the ROMS to), find device
and NuBus space and then zap in our own memory mapping cleanly. This would
cause all kinds of problems with devices but if we convert all the drivers
to use bus spaces then we can move memory about practically at will.

I already feel the pain of this since I will *need* to write a VRAM sizer
to give people with advanced internal video access to multiple frame buffers
(can you say a much faster X server?). People complain about the aliasing
problem but I think I have a way to get around it. But that's for intvid
alpha 2. :-) Right now I think people just want color.