> But I'm still wondering what the effect of this bug will be. > The first order (not setting U-bit) should only affect ZX1 (pa8800/pa8900) > machines. Those have uncacheable IO space between 2GB-4GB physical address. > My guess is the machines should HPMC since the CPU would attempt to access > those ranges as a cacheline read/write instead of sub-cacheline transactions. I think the depdi change may fix the random memory corruption that I have been complaining about. My rp3440 has got through a full build of GCC with 2.6.30.1. Previous two attempts failed with segmentation faults in the dynamic loader, one of which I reported on. It will take a few more builds to be sure. Your comment would explain why I don't see this on c3750. Could this affect PA8700? I installed the change on my rp3440, c3750 and gsyprf11 last night. At some point, I need to test the change with an SMP build on the rp3440. There is one other issue that I see on the rp3440 which I don't see on the c3750 or gsyprf11. I get occassional testsuite timeouts during compilation on compilations that shouldn't timeout. I had always thought this to be a tcl/expect issue, but now I think this is likely a kernel issue. I need to change the timeout value in the testsuite to something big so I can see what's happening. Dave -- J. David Anglin dave.anglin@xxxxxxxxxxxxxx National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
