Stefan Reinauer <[EMAIL PROTECTED]> writes: > * Eric W. Biederman <[EMAIL PROTECTED]> [030929 00:38]: > > And until I have a reason I don't see the point, in making > > a change. > > Hm. You are right. With some more tests I found out that this > solution only fixes the problem occasionally. It seems that > the chance that it works is higher with the number of tries. > Really weird. > > > Mostly I suspect this is a matter of keeping the irq tables > > in sync, or something similar where hard codes don't match the dynamic > > assignments. And if that is the case we need to dig and do a good fix > > instead of papering over the problem. > > If LinuxBIOS hangs during CPU/Northbridge enumeration, can this > really be a matter of irq tables?
No. My problem is that I don't have a good data point on what the problem is. And the fact that the problem is not even consistent is very peculiar. > I thought that they are touched quite a while later in the setup process. Yes, much later. Hard codes in the irq tables are one of the things that could cause problems if the busses were enumerated in a different order. But not until the kernel has been loaded. > I suspect it might be connected to the highest bus number set in > the default resource map, but I did not try more in this direction > yet. But it is not consistent? And what you are hangs. Very, very weird. And this is not with SST chips? > Additionally I have Linux moaning that the irq table contains entries > for a bus that does not exist. It's bus 1, that LinuxBIOS and OpenBIOS > find really well, only Linux refuses to see it. And that is also very strange. I need to start synchronizing my tree with the public one, now that it seems to be working. And I have some romcc cleanups to do. I finally have the core infrastructure in place for making inline optional, which should help a lot on the size issues. Eric _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
