> 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? > > > Nilay Vaish wrote: > 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. > >
Since it is very isolated, I would suggest we make the warning a fatal and strictly forbid the double port binding. That makes it less ambiguous and less prone to misunderstandings in the future. Could you maybe shed some light on why it is difficult to prevent it from happening in this case? - Andreas ----------------------------------------------------------- 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
