Thanks! That makes sense. But, off the cuff, it seems odd that there's an instance_id if it can only be zero. But then again, it may be overloaded or be applicable in other cases. I'll dig into the code today.
On 07/01/2016 02:27 AM, Dr. David Alan Gilbert wrote:
> Hi Tom,
> Yeh it's just vmstate_register_with_alias_id printing vmsd->name at entry,
> and then after the char *id = .... printing that as well (that's what I labelled as the dev/id case).
> Then just before the assert I was printing the se->compat and se->instance_id values.
>
> I noticed this bug because one of our test team had hit the same assert
> a few weeks back on x86, but it was on a truly bizarre setup (~50 nested
> PCIe bridges) so I knew where to look for it.
>
> I think the idea is that if you have a se->compat string then it had
> better be unique (that is instance_id == 0); and the compat string is
> formed by concatenation of the qdev path and the name of this device.
> Then we have '0.0.0' as the name of this scsi device (i.e. local to this
> SCSI adapter) but no path that gives a unique string for the adapter
> like we do on the x86.
>
> Dave
>
Thanks! That makes sense. But, off the cuff, it seems odd that there's an instance_id if it can only be zero. But then again, it may be overloaded or be applicable in other cases. I'll dig into the code today.
On 07/01/2016 02:27 AM, Dr. David Alan Gilbert wrote: register_ with_alias_ id printing vmsd->name at entry,
> Hi Tom,
> Yeh it's just vmstate_
> and then after the char *id = .... printing that as well (that's what I labelled as the dev/id case).
> Then just before the assert I was printing the se->compat and se->instance_id values.
>
> I noticed this bug because one of our test team had hit the same assert
> a few weeks back on x86, but it was on a truly bizarre setup (~50 nested
> PCIe bridges) so I knew where to look for it.
>
> I think the idea is that if you have a se->compat string then it had
> better be unique (that is instance_id == 0); and the compat string is
> formed by concatenation of the qdev path and the name of this device.
> Then we have '0.0.0' as the name of this scsi device (i.e. local to this
> SCSI adapter) but no path that gives a unique string for the adapter
> like we do on the x86.
>
> Dave
>