I finally tracked down the scenario that caused me to make the changes I described:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00919.html Basically I implemented what I proposed in that email (since no one objected) but never got around to pushing it to the public repo. The bad news is that Ali's fix won't work in my code, but the good news is that I believe the restructuring I did got rid of this problem anyway. It'll be a while before I have a chance to test the patch and push it, so if people can hold on a week or two then we don't need to do anything (which I suppose is the case, since no one even noticed this bug for years). If Ali wants to push his current patch as a stopgap that's OK too, but then I'll have to remember to reverse it when I put my change in. Steve On Sun, Nov 30, 2008 at 8:58 PM, Ali Saidi <[EMAIL PROTECTED]> wrote: > You could, but it's such a rare event that it prettier code trumped > performance. > > Ali > > On Nov 30, 2008, at 10:55 PM, Steve Reinhardt wrote: > >> OK, that makes more sense now... I'm confused because I revamped >> things a bit in my tree so that now the cpu side of a cache generally >> is the default port (instead of being the explicit responder to the >> cacheable address range). So while that fix works in the public >> branch it wouldn't work in mine. >> >> There was a reason I did that, but I don't remember it off the top >> of my head. >> >> As far as your patch goes, why not check if the dest port if the >> default port outside of the loop? >> >> Steve >> >> >> On Sun, Nov 30, 2008 at 8:41 PM, Ali Saidi <[EMAIL PROTECTED]> wrote: >>> Yea that is exactly what I'm doing. The default port on all the >>> busses >>> but the I/O bus responds with a BadPacket packet, nothing more. You >>> don't need to be coherent on an address that doesn't exist. >>> >>> Ali >>> >>> On Nov 30, 2008, at 8:56 PM, Steve Reinhardt wrote: >>> >>>> Does this really work? It looks to me like you're never doing any >>>> snooping on any packet that targets the bus's default port, which I >>>> would think would eliminate pretty much all snoops (and thus make >>>> coherence not work). >>>> >>>> I have a changeset locally that I think should fix this problem. It >>>> adds a 'forward_snoops' flag to the cache object that controls >>>> whether >>>> it forwards snoops it receives on its mem port to its cpu-side port. >>>> The default is true but I set it to false for the I/O cache, so the >>>> I/O bus never sees snoops. >>>> >>>> Unfortunately it might be another week until I have time to dig it >>>> out >>>> and apply it to the public repo; if someone feels that it's urgent >>>> enough that they're willing to work with an untested bare patch >>>> let me >>>> know. >>>> >>>> Steve >>>> >>>> On Sun, Nov 30, 2008 at 12:08 PM, Ali Saidi <[EMAIL PROTECTED]> wrote: >>>>> It helps if I include the patch... >>>>> >>>>> Ali >>>>> >>>>> >>>>> On Nov 30, 2008, at 1:40 PM, Ali Saidi wrote: >>>>> >>>>>> Here is a fix (a) that works for booting. However, we need to >>>>>> decide >>>>>> what the correct thing to do is. What about other interconnects? >>>>>> >>>>>> Ali >>>>>> >>>>>> On Nov 28, 2008, at 1:12 AM, Ali Saidi wrote: >>>>>> >>>>>>> I did some digging and figured out the problem. The issue occurs >>>>>>> when >>>>>>> the o3 cpu is miss-speculating and loads from an invalid address. >>>>>>> The >>>>>>> request gets to the dcache which issues a readreq for the block >>>>>>> on the >>>>>>> membus. The membus matches the default responder (which would >>>>>>> return a >>>>>>> response with BadAddress), however the bus also sends the >>>>>>> snoops to >>>>>>> the I/O Cache, which in turn forwards it to the i/o bus. The I/O >>>>>>> bus >>>>>>> already has a default responder (for PCI config space), so the >>>>>>> panic >>>>>>> occurs. >>>>>>> >>>>>>> I don't exactly understand why this doesn't occur when an L2 is >>>>>>> present as well and can't really imagine that we always just get >>>>>>> lucky. >>>>>>> >>>>>>> There are a variety of possible solutions: >>>>>>> a) Don't send accesses to the default responder to the >>>>>>> snoopers. If >>>>>>> you're there the address isn't cacheable so no one should be >>>>>>> supplying >>>>>>> data. >>>>>>> b) Make the I/O cache filter snoop ranges based on the filter >>>>>>> ranges >>>>>>> it already has for range change passing. >>>>>>> c) Have two default options for busses. A default port that is >>>>>>> user- >>>>>>> settable, and a port of last resort that always just returns a >>>>>>> BadAddr >>>>>>> packet. >>>>>>> d) ?? There are probably a couple more options. >>>>>>> >>>>>>> Ali >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Nov 26, 2008, at 3:59 PM, Steve Reinhardt wrote: >>>>>>> >>>>>>>> It runs fine with --l2cache. Interesting... >>>>>>>> >>>>>>>> On Wed, Nov 26, 2008 at 1:48 PM, Steve Reinhardt >>>>>>>> <[EMAIL PROTECTED]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Looks like the main difference is that the regression has an L2 >>>>>>>>> cache >>>>>>>>> where just saying --caches only gives you L1s. I'm rerunning >>>>>>>>> the >>>>>>>>> problematic version with --l2cache to see if that fixes the >>>>>>>>> problem. >>>>>>>>> >>>>>>>>> Steve >>>>>>>>> >>>>>>>>> On Wed, Nov 26, 2008 at 12:59 PM, Ali Saidi <[EMAIL PROTECTED]> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> The o3 regression with caches does successfully run. So, >>>>>>>>>> what us >>>>>>>>>> the >>>>>>>>>> difference between what you're running and what the >>>>>>>>>> regressions >>>>>>>>>> run? >>>>>>>>>> >>>>>>>>>> Ali >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> m5-users mailing list >>>>>>>> [email protected] >>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> m5-users mailing list >>>>>>> [email protected] >>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> m5-users mailing list >>>>>> [email protected] >>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> m5-users mailing list >>>>> [email protected] >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>>> >>>> _______________________________________________ >>>> m5-users mailing list >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>> >>> >>> _______________________________________________ >>> m5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>> >> _______________________________________________ >> m5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
