Re: config tool + tree enumeration

[YhLu]

Stefan,

Change that to 1 seems no use.

For Tyan S2885, the 8131 and 8111 is connected to CPU0 Link2, and 8151 is
linked to CPU0 link0.

I have to manual to change src/device/hypertransport.c 's
hypertransport_scan_chain the link scan sequence from "0 to 2" to "2 to 0".

I think it works for your case to.

Regards

YH
-----邮件原件-----
发件人: Stefan Reinauer [mailto:[e-mail]] 
发送时间: 2003年9月26日 5:19
收件人: [e-mail]
主题: config tool + tree enumeration

Hi,

I have several non coherent ht devices in a chain, i.e. :

CPU0 -- CPU1    or    CPU2 -- CPU3
   |                     |       |
 8131                  CPU0 -- CPU2
   |                     |       |
 8111                  8111    8131
                                 |
                               8131

The links to the non coherent devices are LDT1 or LDT2, not LDT0.
Do I have to specify the "southbridges with Bus ID 1/2 then, since
it's not on the first Link, or does it have to be 0, since it's the
first south bridge?

northbridge amd/amdk8 "mc0"
        pci 0:18.0
        [..]
        southbridge amd/amd8131 "amd8131"
                pci 1:0.0  
                    ^^^^^
                [..]
        end
        southbridge amd/amd8111 "amd8111"
                pci 1:0.0
                    ^^^^^
                [..]
        end
end

Stefan

config tool + tree enumeration

[Stefan Reinauer]

* YhLu  [030926 18:24]:
> Stefan,
>
> Change that to 1 seems no use.
>
> For Tyan S2885, the 8131 and 8111 is connected to CPU0 Link2, and 8151 is
> linked to CPU0 link0.
>
> I have to manual to change src/device/hypertransport.c 's
> hypertransport_scan_chain the link scan sequence from "0 to 2" to "2 to 0".
>
> I think it works for your case to.

This did help indeed. Is there any good reason not to reverse the
probing per default? Ron, Eric?
If there is, I suggest we make this a config variable

Stefan

config tool + tree enumeration

[ron minnich]

On Sat, 27 Sep 2003, Stefan Reinauer wrote:
> This did help indeed. Is there any good reason not to reverse the
> probing per default? Ron, Eric?

I'm going to defer to Eric on this, as I am not sure.

ron

config tool + tree enumeration

ron minnich  writes:
> On Sat, 27 Sep 2003, Stefan Reinauer wrote:
> > This did help indeed. Is there any good reason not to reverse the
> > probing per default? Ron, Eric?
>
> I'm going to defer to Eric on this, as I am not sure.

I'm running slow in replying.  But I don't see why scanning
busses in any particular order should matter.

And until I have a reason I don't see the point, in making
a change.

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.

Eric

config tool + tree enumeration

[ron minnich]

On 28 Sep 2003, Eric W. Biederman wrote:
> 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.

the PIRQ thing is on my list, and we have all here agreed on most of the 
solution, given me another week.

Yes, papering over is BAD.

ron

config tool + tree enumeration

[Stefan Reinauer]

* Eric W. Biederman  [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? I thought that they are touched
quite a while later in the setup process.
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.

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.

Stefan

config tool + tree enumeration

Stefan Reinauer  writes:
> Eric W. Biederman  [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

config tool + tree enumeration

[Stefan Reinauer]

* Eric W. Biederman  [030929 12:19]:
> > 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?

iirc default_resource_map sets the highest bus number to 0xff, so
it should be above what we ever need. Finding the real highest bus
number is not possible until after the enumeration anyways, is it?
> And what you are hangs.  Very, very weird.  And this is not with
> SST chips?

I've been using an SST 49LF040 (the one that is per default in all
Quartets and Khepris), but I guess it's unrelatet this time. I had no
boot trouble so far with the 040 type, only trouble while flashing.
The boot trouble was solely on the 080 type. But this might be
coincidence.
> 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.

This would be great, especially helping to test the SMP configurations
with the Winbond 256k flash parts I have to see if that changes the
problem.

Stefan

config tool + tree enumeration

[ron minnich]

On Mon, 29 Sep 2003, Stefan Reinauer wrote:
> 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.

well at least now I know it is Linux, and I'm not going nuts.

Really odd problem.

ron

config tool + tree enumeration

[Stefan Reinauer]

* ron minnich  [030929 15:50]:
> On Mon, 29 Sep 2003, Stefan Reinauer wrote:
> > 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.
>
> well at least now I know it is Linux, and I'm not going nuts.
>
> Really odd problem.

Andi Kleen stated that this is a result from wrong pirq- and acpi
tables. Additionally, does Linux parse the mptable to find out about
it's busses? If so, can anybody give a hint how to write a working
mptable.c?

Best regards,
  Stefan Reinauer

config tool + tree enumeration

[ron minnich]

On Mon, 29 Sep 2003, Stefan Reinauer wrote:
> Andi Kleen stated that this is a result from wrong pirq- and acpi
> tables.

OK, what version linux are they using for this statement.

PIRQ doesn't come into the picture for a long time. ACPI I have not seen 
in the PCI parsing on my kernels.

If they have broken PCI direct bus scanning then they have done a bad 
thing. Are you sure Andi knowns how all this stuff works?

ron