On Tue, Jun 30, 2020 at 04:01:45PM +0200, Maximilian Heyne wrote:
> On 6/30/20 3:36 PM, Christoph Hellwig wrote:
> > And actually - 1.0 did not have the concept of a subsystem. So having
> > a duplicate serial number for a 1.0 controller actually is a pretty
> > nasty bug. Can you point me to
On 6/30/20 3:36 PM, Christoph Hellwig wrote:
On Tue, Jun 30, 2020 at 03:33:58PM +0200, Christoph Hellwig wrote:
On Tue, Jun 30, 2020 at 12:29:23PM +, Maximilian Heyne wrote:
Controller ID's (cntlid) for NVMe devices were introduced in version
1.1.0 of the specification. Controllers that
On Tue, Jun 30, 2020 at 03:33:58PM +0200, Christoph Hellwig wrote:
> On Tue, Jun 30, 2020 at 12:29:23PM +, Maximilian Heyne wrote:
> > Controller ID's (cntlid) for NVMe devices were introduced in version
> > 1.1.0 of the specification. Controllers that follow the older 1.0.0 spec
> > don't set
On Tue, Jun 30, 2020 at 12:29:23PM +, Maximilian Heyne wrote:
> Controller ID's (cntlid) for NVMe devices were introduced in version
> 1.1.0 of the specification. Controllers that follow the older 1.0.0 spec
> don't set this field so it doesn't make sense to validate it. On the
> contrary,
Controller ID's (cntlid) for NVMe devices were introduced in version
1.1.0 of the specification. Controllers that follow the older 1.0.0 spec
don't set this field so it doesn't make sense to validate it. On the
contrary, when using SR-IOV this check breaks VFs as they are all part
of the same NVMe
5 matches
Mail list logo
