Stefan Reinauer stepan@suse.de writes:
- Eric W. Biederman ebiederman@lnxi.com [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