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
