In message <199903071859.NAA12572@x15-cruise-basselope>, Dan Winship writes:
>When I try to boot a -current GENERIC kernel, I get:
[snip]
>CMD Technology PCI0646 (IDE mass storage, interface 0x8f, revision 0x05) at pc
>i1 dev 1 function 0 not configured
>trap type 200 at 253008
>Stopped in  at  0x223dd8:    lwz r0, r1, 0x14,
>db>
>
>Is this one of the problems you mentioned? I couldn't get a stack
>trace because it wasn't listening to my keyboard.

	Yup.  I have a PowerBook G3 as well, so I was able to do compiles and look at 
assembler output and such on it and keep throwing kernels at my Blue&White to 
see what changed (hence the #33 in the kernel header, I'm over 100 now I 
think..  =)

	Basically what's happening is that when it starts to probe for devices on the 
PCI-PCI bridge it seems that the probe fails with the trap 200 if there is not 
actually a device at the number it tries.  On the first pci_conf_read() it 
does an out32rb(), then fails on the in32rb(), and I get the same trap if I 
try to dereference r->data between these two calls.  IIRC a trap 200 is like a 
bus error, it seems that the address is not set up to return data.  I do not 
know enough about PCI to know what is actually going wrong here, or how to fix 
it.  Presumably NetBSD's code works for other architectures, it certainly 
works for the MPC106 itself.  "dev / ls" indicates that (at least on my 
system) the devices on the bridge are at device slots 0, 1, 5 and 6.  So I 
added this code to pci.c (at the top of the for loop in pci_probe_bus() and it 
got me past the trap above:

 if ((bus == 1) && !((device == 0) ||
                     (device == 1) ||
                     (device == 5) ||
                     (device == 6))) {
   continue;
 }

	This is definitely not the correct fix.  But I do not know what that would 
be.  I'll defer this to someone who knows more about what's going on here (but 
would be happy to test any code / kernels anybody wants to throw my way)  In 
general I think it's probably a problem with how NetBSD/macppc currently 
handles (or doesn't handle) bridges.  There is no pci_bridges[] entry set up 
for the 21154 (as far as I can tell), since bandit.c:scan_pci_devs() only 
looks at the top level of the OFW tree.  I tried forcing it to look at 
/pci/pci-bridge, and filled out the entry for pci_bridges[1], but I am not 
sure if the information is correct (iot == 6800?  The rest seems sane compared 
to the values in pci_bridges[0]), and it still gives trap 200's on bus 1 
device 2 when it uses pci_bridges[1].  I think it's safe to say this is out of 
my league, I've just been trying to feed it some numbers that make more sense, 
and I'm running out of ideas.

	And thanks to the diff Tsubai pointed out, I can now type at the root device prompt.  I'll try to take a look at what's going wrong with bm0 so that I can actually NFS boot this machine.


                                                          Will Ferry

-----------------
woferry@iname.com