> On March 15, 2012, 12:57 a.m., Andreas Hansson wrote: > > I'm not sure I understand the context. Do you want to connect the config, > > pio and dma port to different interconnects (bus vs ruby)? If so, why? If > > all the ports of the device, e.g. the ide controller, are connected to the > > same interconnect, then I'd suggest to rely on attachIO and just pass the > > Ruby sequencer in question instead of the bus. > > Nilay Vaish wrote: > Let me ask you a different question. Suppose I write the following > statements > > dma = bus.slave > dma = bus.slave > > Note that the same port is assigned a peer port twice. How many bus ports > will > be created in actual? I think two bus ports will get created and one of > them > will not have a peer port and this would result in a segmentation fault at > run time. This is what is happening right now with ruby full system as > well. > IDE disk's dma port is assigned a peer port twice. > > Is this intentional? > > Andreas Hansson wrote: > There is no convenient way of specifying the number of vector ports up > front, but I am fairly certain we check that the peer is not set when > assigning it, so the second line should cause the Python configuration to > complain. If not, we can easily add it. So in essence, yes it is intentional > that the VectorPorts grow with assignment, but we could call fatal or similar > when a peer is already set in the Python Port class. > > If we do that, your example would terminate at the Python stage as > intended. The problem then becomes to remove the double binding. Why is the > dma port assigned twice? Can we easily remove it? Why is it not done as part > of attachIO? >
Currently a warning gets printed about over writing some port with some thing, and afterwards the simulation ends with a segmentation fault. Is is not possible to nullify the effects of the first statement, and only keep the effects of the second statement around? As of know, I do not think it is straight forward to prevent this double assignment from happening. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1102/#review2314 ----------------------------------------------------------- On March 14, 2012, 8:58 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1102/ > ----------------------------------------------------------- > > (Updated March 14, 2012, 8:58 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 8898:71c9357b9132 > --------------------------- > Ruby X86: problem in setting DMA port, related to changeset 8850. > I think since the dma port is assigned twice (once in SouthBridge.py, > and once by Ruby somewhere) an extra port gets created which has no > peer port. This results in a segmentation fault when a simulation is > started. The posted patch solves the problem, but it is not the > solution I am looking for. Andreas, do you have some idea how to > handle this issue? > > > Diffs > ----- > > configs/common/FSConfig.py 6df06e5975c6 > src/dev/x86/Pc.py 6df06e5975c6 > src/dev/x86/SouthBridge.py 6df06e5975c6 > > Diff: http://reviews.gem5.org/r/1102/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
