>Sorry, my report wasn't comlete. I totally forgot to mention that this is not
>a new bug. I saw it with every kernel since about 2.3.14 that I managed to
No surprise. You are just lucky you can boot. If you had two pci buses and
your scsi controller on the second pci bus you would not boot at all (at
least on the tsunami platform). There's some obvious bug but there are
also further troubles. I think I'll have to reject the pci common
interface (assign_unassigned) and to go by hand as before (and as sparc64
is just doing in 2.3.22) to make it to work completly.
This because I think the size of the pci resouce is not detected correctly
by the common pci_scan_bus. The alpha want to detect the size of the io
resource this way:
write(0xffffffff);
read(&size);
size &= PCI_BASE_ADDRESS_IO_MASK;
mask = (~size << 1) | 0x1;
size = (mask & size) & 0xffffffff;
while the pci code is detecting it this way:
write(~0);
read(&size);
size = ~(sz & PCI_BASE_ADDRESS_IO_MASK) & 0xffff;
and there's also some magic alignment to respect while choosing the base
address.
Note: I don't have the specs. All I know about pci it's what I read on the
2.2.x and 2.3.x sources so don't blame me if the above disagree with the
specs. But as I have under my hands the 2.2.x sources that works, I also
basically understood what I have to do to make 2.3.22 to boot as well 8).
>In 2.3.10 this all works fine.
It's the arch/alpha/kernel pci stuff that is buggy in the late 2.3.x. When
I'll boot I'll send you the diff (you may want to give it a try as well
on your hardware ;).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/