| 2019-02-08 15:57:36 |
Eric Desrochers |
bug |
|
|
added bug |
| 2019-02-08 15:58:17 |
Eric Desrochers |
nominated for series |
|
Ubuntu Xenial |
|
| 2019-02-08 15:58:17 |
Eric Desrochers |
bug task added |
|
pciutils (Ubuntu Xenial) |
|
| 2019-02-08 15:59:59 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time he was updated.
Some user are observe that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to more or less represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
upstream repository : https://github.com/pciutils/pciutils.git
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | cosmic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | disco | source, amd64, arm64, armhf, i386, ppc64el, s390x
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observe that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to more or less represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
upstream repository : https://github.com/pciutils/pciutils.git
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | cosmic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | disco | source, amd64, arm64, armhf, i386, ppc64el, s390x
-- |
|
| 2019-02-08 16:00:05 |
Eric Desrochers |
pciutils (Ubuntu): status |
New |
Fix Released |
|
| 2019-02-08 16:00:42 |
Eric Desrochers |
tags |
|
sts |
|
| 2019-02-08 16:01:25 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observe that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to more or less represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
upstream repository : https://github.com/pciutils/pciutils.git
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | cosmic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | disco | source, amd64, arm64, armhf, i386, ppc64el, s390x
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observe that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to more or less represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
upstream repository : https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | cosmic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | disco | source, amd64, arm64, armhf, i386, ppc64el, s390x
-- |
|
| 2019-02-08 16:01:35 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observe that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to more or less represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
upstream repository : https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | cosmic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | disco | source, amd64, arm64, armhf, i386, ppc64el, s390x
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observe that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to more or less represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | cosmic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | disco | source, amd64, arm64, armhf, i386, ppc64el, s390x
-- |
|
| 2019-02-08 16:05:25 |
Eric Desrochers |
summary |
Update pci.ids for pciutils (xenial) |
[Xenial][SRU] Update pci.ids for pciutils |
|
| 2019-02-08 16:05:34 |
Eric Desrochers |
pciutils (Ubuntu Xenial): status |
New |
In Progress |
|
| 2019-02-08 16:05:38 |
Eric Desrochers |
pciutils (Ubuntu Xenial): assignee |
|
Eric Desrochers (slashd) |
|
| 2019-02-08 16:06:37 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observe that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to more or less represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | cosmic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | disco | source, amd64, arm64, armhf, i386, ppc64el, s390x
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to more or less represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | cosmic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | disco | source, amd64, arm64, armhf, i386, ppc64el, s390x
-- |
|
| 2019-02-08 16:07:32 |
Eric Desrochers |
bug |
|
|
added subscriber Szilard Cserey |
| 2019-02-08 16:08:17 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to more or less represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | cosmic | source, amd64, arm64, armhf, i386, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | disco | source, amd64, arm64, armhf, i386, ppc64el, s390x
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
|
| 2019-02-08 16:23:17 |
Eric Desrochers |
pciutils (Ubuntu Xenial): importance |
Undecided |
Wishlist |
|
| 2019-02-08 16:37:14 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
|
| 2019-02-08 16:41:55 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
If we apply commit [701fdd1e], there is some device id renaming, which I guess can impact some possible customer script expecting a certain type of device output, maybe ?
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
|
| 2019-02-08 16:42:31 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
If we apply commit [701fdd1e], there is some device id renaming, which I guess can impact some possible customer script expecting a certain type of device output, maybe ?
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
If we apply commit [701fdd1e], there is some device id renaming, which I guess can impact some potential users' in-house script expecting a certain type of device output, maybe ?
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
|
| 2019-02-08 16:44:37 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
If we apply commit [701fdd1e], there is some device id renaming, which I guess can impact some potential users' in-house script expecting a certain type of device output, maybe ?
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
If we apply commit [701fdd1e], there is some device id renaming, which I guess can impact some potential users' in-house script expecting a certain type of device output, maybe ?
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
If we decide to go with the renaming as well, we could also simply decide to only add what is missing/
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
|
| 2019-02-08 17:17:02 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
If we apply commit [701fdd1e], there is some device id renaming, which I guess can impact some potential users' in-house script expecting a certain type of device output, maybe ?
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
If we decide to go with the renaming as well, we could also simply decide to only add what is missing/
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
If we apply commit [701fdd1e], there is some device id renaming, which I guess can "possibly" impact some user using in-house script expecting a certain type of device id output, maybe ?
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
If we decide to go with the renaming as well, we could also simply decide to only add what is missing/
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
|
| 2019-02-08 17:17:32 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
If we apply commit [701fdd1e], there is some device id renaming, which I guess can "possibly" impact some user using in-house script expecting a certain type of device id output, maybe ?
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
If we decide to go with the renaming as well, we could also simply decide to only add what is missing/
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
If we apply commit [701fdd1e], there is some device id renaming, which I guess can "possibly" impact some user using in-house script expecting a certain type of device id output, maybe ?
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
|
| 2019-02-08 17:21:03 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
If we apply commit [701fdd1e], there is some device id renaming, which I guess can "possibly" impact some user using in-house script expecting a certain type of device id output, maybe ?
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
If we apply commit [701fdd1e], there is some device id renaming, which I guess can "possibly" impact some user using in-house script (that gather HW inventory for instance) expecting a certain type of device id output, maybe ?
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
|
| 2019-02-08 17:26:14 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
If we apply commit [701fdd1e], there is some device id renaming, which I guess can "possibly" impact some user using in-house script (that gather HW inventory for instance) expecting a certain type of device id output, maybe ?
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
If we apply commit [701fdd1e], there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
|
| 2019-02-08 18:12:18 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
If we apply commit [701fdd1e], there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commits:
# git log --oneline v3.3.1..v3.5.2 pci.ids ## Update done betwwen Xenial and Bionic
701fdd1 Updated pci.ids to today's snapshot
8c2d87f Updated pci.ids to today's snapshot
07a250f pci.ids updated to today's snapshot
73debb0 Updated pci.ids to today's snapshot
# From the example in the [Test Case]:
# git show 701fdd1
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
|
| 2019-02-08 18:20:49 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commits:
# git log --oneline v3.3.1..v3.5.2 pci.ids ## Update done betwwen Xenial and Bionic
701fdd1 Updated pci.ids to today's snapshot
8c2d87f Updated pci.ids to today's snapshot
07a250f pci.ids updated to today's snapshot
73debb0 Updated pci.ids to today's snapshot
# From the example in the [Test Case]:
# git show 701fdd1
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commits:
# git log --oneline v3.3.1..v3.5.2 pci.ids ## Update done between Xenial and Bionic
701fdd1 Updated pci.ids to today's snapshot
8c2d87f Updated pci.ids to today's snapshot
07a250f pci.ids updated to today's snapshot
73debb0 Updated pci.ids to today's snapshot
# From the example in the [Test Case]:
# git show 701fdd1
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
|
| 2019-02-10 17:25:20 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commits:
# git log --oneline v3.3.1..v3.5.2 pci.ids ## Update done between Xenial and Bionic
701fdd1 Updated pci.ids to today's snapshot
8c2d87f Updated pci.ids to today's snapshot
07a250f pci.ids updated to today's snapshot
73debb0 Updated pci.ids to today's snapshot
# From the example in the [Test Case]:
# git show 701fdd1
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that the correct raid controller is not present, if the user doesn't read the PCI bus address.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commits:
# git log --oneline v3.3.1..v3.5.2 pci.ids ## Update done between Xenial and Bionic
701fdd1 Updated pci.ids to today's snapshot
8c2d87f Updated pci.ids to today's snapshot
07a250f pci.ids updated to today's snapshot
73debb0 Updated pci.ids to today's snapshot
# From the example in the [Test Case]:
# git show 701fdd1
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
|
| 2019-02-10 18:13:43 |
Eric Desrochers |
pciutils (Ubuntu Xenial): importance |
Wishlist |
Low |
|
| 2019-02-10 18:20:51 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that the correct raid controller is not present, if the user doesn't read the PCI bus address.
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change. The intention is to only update pci.ids table list.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
Upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commits:
# git log --oneline v3.3.1..v3.5.2 pci.ids ## Update done between Xenial and Bionic
701fdd1 Updated pci.ids to today's snapshot
8c2d87f Updated pci.ids to today's snapshot
07a250f pci.ids updated to today's snapshot
73debb0 Updated pci.ids to today's snapshot
# From the example in the [Test Case]:
# git show 701fdd1
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
-- |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognize new pci vendor list/hw.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information] |
|
| 2019-02-10 18:20:56 |
Eric Desrochers |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-02-10 18:20:56 |
Eric Desrochers |
bug task added |
|
pciutils (Ubuntu Bionic) |
|
| 2019-02-10 18:21:04 |
Eric Desrochers |
pciutils (Ubuntu Bionic): status |
New |
In Progress |
|
| 2019-02-10 18:21:06 |
Eric Desrochers |
pciutils (Ubuntu Bionic): importance |
Undecided |
Low |
|
| 2019-02-10 18:21:08 |
Eric Desrochers |
pciutils (Ubuntu Bionic): assignee |
|
Eric Desrochers (slashd) |
|
| 2019-02-10 18:32:16 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognize new pci vendor list/hw.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information] |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognize new pci vendor list/hw.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output, but I don't expect this impact to be high, should be consider low and easy to fix IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information] |
|
| 2019-02-10 19:05:46 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognize new pci vendor list/hw.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output, but I don't expect this impact to be high, should be consider low and easy to fix IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information] |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognize new pci vendor list/hw.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output, but I don't expect this impact to be high, should be consider low and easy to fix IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
|
| 2019-02-10 19:07:31 |
Eric Desrochers |
summary |
[Xenial][SRU] Update pci.ids for pciutils |
[Xenial][SRU] Update pci.ids to version 2018.07.21 |
|
| 2019-02-10 19:07:50 |
Eric Desrochers |
summary |
[Xenial][SRU] Update pci.ids to version 2018.07.21 |
[Xenial][Bionic][SRU] Update pci.ids to version 2018.07.21 |
|
| 2019-02-11 02:34:36 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognize new pci vendor list/hw.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output, but I don't expect this impact to be high, should be consider low and easy to fix IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognize new pci vendor list/hw.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
|
| 2019-02-11 02:35:50 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognize new pci vendor list/hw.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognize new pci vendor list/ids, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
|
| 2019-02-11 02:38:03 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognize new pci vendor list/ids, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
|
| 2019-02-11 13:03:52 |
Łukasz Zemczak |
pciutils (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2019-02-11 13:03:54 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-02-11 13:03:55 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2019-02-11 13:03:58 |
Łukasz Zemczak |
tags |
sts |
sts verification-needed verification-needed-bionic |
|
| 2019-02-11 13:11:45 |
Łukasz Zemczak |
pciutils (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2019-02-11 13:11:49 |
Łukasz Zemczak |
tags |
sts verification-needed verification-needed-bionic |
sts verification-needed verification-needed-bionic verification-needed-xenial |
|
| 2019-02-11 16:29:53 |
Eric Desrochers |
tags |
sts verification-needed verification-needed-bionic verification-needed-xenial |
sts verification-done-bionic verification-needed verification-needed-xenial |
|
| 2019-02-11 17:01:02 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
lspci on Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
lspci on Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Pending SRU status]
* Regression in autopkgtest for linux (ppc64el): test log ## Xenial
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/ppc64el/l/linux/20190211_161758_29cc4@/log.gz
This start failing before this current SRU on 2019-02-05 ... so far 3 same exact failure occurred, meaning this is a recurrent ADT failure.
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
|
| 2019-02-11 17:01:36 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
lspci on Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
lspci on Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Pending SRU status]
* Regression in autopkgtest for linux (ppc64el): test log ## Xenial
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/ppc64el/l/linux/20190211_161758_29cc4@/log.gz
This start failing before this current SRU on 2019-02-05 ... so far 3 same exact failure occurred, meaning this is a recurrent ADT failure.
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
lspci on Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
lspci on Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Pending SRU status]
* Regression in autopkgtest for linux (ppc64el): test log ## Xenial
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/ppc64el/l/linux/20190211_161758_29cc4@/log.gz
This start failing before this current SRU on 2019-02-05 ... so far 3 same exact failure occurred, meaning this is a recurrent ADT failure, nothing to do with the ongoing SRU.
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
|
| 2019-02-12 14:30:42 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
lspci on Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
lspci on Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Pending SRU status]
* Regression in autopkgtest for linux (ppc64el): test log ## Xenial
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/ppc64el/l/linux/20190211_161758_29cc4@/log.gz
This start failing before this current SRU on 2019-02-05 ... so far 3 same exact failure occurred, meaning this is a recurrent ADT failure, nothing to do with the ongoing SRU.
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
lspci on Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
lspci on Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Pending SRU status]
* XENIAL
- Regression in autopkgtest for linux-oracle
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/linux-oracle/20190211_192705_fa550@/log.gz
ERROR: running version does not match source package
Source Package Version: 4.15.0-1008.10~16.04.1
Running Kernel Version: 4.4.0-142.168
==> https://launchpad.net/bugs/1723223
* BIONIC
- Regression in autopkgtest for linux-oracle (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-oracle/20190211_163710_b6f0a@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux-gcp-edge (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-gcp-edge/20190211_163830_8dce2@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
|
| 2019-02-13 21:15:39 |
Eric Desrochers |
tags |
sts verification-done-bionic verification-needed verification-needed-xenial |
sts verification-done-bionic verification-done-xenial verification-needed |
|
| 2019-02-13 21:16:09 |
Eric Desrochers |
tags |
sts verification-done-bionic verification-done-xenial verification-needed |
sts verification-done verification-done-bionic verification-done-xenial |
|
| 2019-02-15 03:24:05 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
lspci on Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
lspci on Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Pending SRU status]
* XENIAL
- Regression in autopkgtest for linux-oracle
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/linux-oracle/20190211_192705_fa550@/log.gz
ERROR: running version does not match source package
Source Package Version: 4.15.0-1008.10~16.04.1
Running Kernel Version: 4.4.0-142.168
==> https://launchpad.net/bugs/1723223
* BIONIC
- Regression in autopkgtest for linux-oracle (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-oracle/20190211_163710_b6f0a@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux-gcp-edge (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-gcp-edge/20190211_163830_8dce2@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
* Deploy Xenial and/or Bionic system.
* Run 'lspci' command took from the pciutils package found in the Ubuntu archive
* Look all listed devices are recognised with the proper device name/vendor/...
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
lspci on Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
lspci on Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Pending SRU status]
* XENIAL
- Regression in autopkgtest for linux-oracle
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/linux-oracle/20190211_192705_fa550@/log.gz
ERROR: running version does not match source package
Source Package Version: 4.15.0-1008.10~16.04.1
Running Kernel Version: 4.4.0-142.168
==> https://launchpad.net/bugs/1723223
* BIONIC
- Regression in autopkgtest for linux-oracle (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-oracle/20190211_163710_b6f0a@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux-gcp-edge (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-gcp-edge/20190211_163830_8dce2@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
|
| 2019-02-18 08:18:43 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
* Deploy Xenial and/or Bionic system.
* Run 'lspci' command took from the pciutils package found in the Ubuntu archive
* Look all listed devices are recognised with the proper device name/vendor/...
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
lspci on Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
lspci on Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Pending SRU status]
* XENIAL
- Regression in autopkgtest for linux-oracle
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/linux-oracle/20190211_192705_fa550@/log.gz
ERROR: running version does not match source package
Source Package Version: 4.15.0-1008.10~16.04.1
Running Kernel Version: 4.4.0-142.168
==> https://launchpad.net/bugs/1723223
* BIONIC
- Regression in autopkgtest for linux-oracle (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-oracle/20190211_163710_b6f0a@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux-gcp-edge (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-gcp-edge/20190211_163830_8dce2@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
* Deploy Xenial and/or Bionic system.
* Run 'lspci' command took from the pciutils package found in the Ubuntu archive
* Look all listed devices are recognised with the proper device name/vendor/...
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
lspci on Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
lspci on Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Pending SRU status]
* XENIAL
- Regression in autopkgtest for linux-oracle
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/linux-oracle/20190211_192705_fa550@/log.gz
ERROR: running version does not match source package
Source Package Version: 4.15.0-1008.10~16.04.1
Running Kernel Version: 4.4.0-142.168
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux (i386): test log
Recurrent failure from various trigger
(not introduced by this ongoing SRU)
http://autopkgtest.ubuntu.com/packages/l/linux/xenial/i386
* BIONIC
- Regression in autopkgtest for linux-oracle (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-oracle/20190211_163710_b6f0a@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux-gcp-edge (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-gcp-edge/20190211_163830_8dce2@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
|
| 2019-02-18 08:19:31 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
* Deploy Xenial and/or Bionic system.
* Run 'lspci' command took from the pciutils package found in the Ubuntu archive
* Look all listed devices are recognised with the proper device name/vendor/...
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
lspci on Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
lspci on Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Pending SRU status]
* XENIAL
- Regression in autopkgtest for linux-oracle
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/linux-oracle/20190211_192705_fa550@/log.gz
ERROR: running version does not match source package
Source Package Version: 4.15.0-1008.10~16.04.1
Running Kernel Version: 4.4.0-142.168
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux (i386): test log
Recurrent failure from various trigger
(not introduced by this ongoing SRU)
http://autopkgtest.ubuntu.com/packages/l/linux/xenial/i386
* BIONIC
- Regression in autopkgtest for linux-oracle (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-oracle/20190211_163710_b6f0a@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux-gcp-edge (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-gcp-edge/20190211_163830_8dce2@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
* Deploy Xenial and/or Bionic system.
* Run 'lspci' command took from the pciutils package found in the Ubuntu archive
* Look all listed devices are recognised with the proper device name/vendor/...
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
lspci on Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
lspci on Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Pending SRU status]
* XENIAL
- Regression in autopkgtest for linux-oracle
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/linux-oracle/20190211_192705_fa550@/log.gz
ERROR: running version does not match source package
Source Package Version: 4.15.0-1008.10~16.04.1
Running Kernel Version: 4.4.0-142.168
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux (i386): test log
Recurrent failure from various trigger
(not introduced by this ongoing SRU)
http://autopkgtest.ubuntu.com/packages/l/linux/xenial/i386
* BIONIC
- Regression in autopkgtest for linux-oracle (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-oracle/20190211_163710_b6f0a@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux-gcp-edge (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-gcp-edge/20190211_163830_8dce2@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
|
| 2019-02-18 08:21:01 |
Eric Desrochers |
description |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
* Deploy Xenial and/or Bionic system.
* Run 'lspci' command took from the pciutils package found in the Ubuntu archive
* Look all listed devices are recognised with the proper device name/vendor/...
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
lspci on Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
lspci on Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Pending SRU status]
* XENIAL
- Regression in autopkgtest for linux-oracle
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/linux-oracle/20190211_192705_fa550@/log.gz
ERROR: running version does not match source package
Source Package Version: 4.15.0-1008.10~16.04.1
Running Kernel Version: 4.4.0-142.168
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux (i386): test log
Recurrent failure from various trigger
(not introduced by this ongoing SRU)
http://autopkgtest.ubuntu.com/packages/l/linux/xenial/i386
* BIONIC
- Regression in autopkgtest for linux-oracle (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-oracle/20190211_163710_b6f0a@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux-gcp-edge (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-gcp-edge/20190211_163830_8dce2@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated.
Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet.
User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address.
While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch.
x/pciutils-3.3.1/pci.ids:# Version: 2016.01.02
b/pciutils-3.5.2/pci.ids:# Version: 2017.03.16
c/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
d/pciutils-3.5.2/pci.ids:# Version: 2018.07.21
upstream/pciutils/pci.ids:# Version: 2018.08.12
[Test case]
* Deploy Xenial and/or Bionic system.
* Run 'lspci' command took from the pciutils package found in the Ubuntu archive
* Look all listed devices are recognised with the proper device name/vendor/...
Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table:
lspci on Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
lspci on Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01)
[Pending SRU status]
* XENIAL
- Regression in autopkgtest for linux-oracle
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/linux-oracle/20190211_192705_fa550@/log.gz
ERROR: running version does not match source package
Source Package Version: 4.15.0-1008.10~16.04.1
Running Kernel Version: 4.4.0-142.168
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux (i386): test log
Recurrent failure from various trigger
(not introduced by this ongoing SRU)
http://autopkgtest.ubuntu.com/packages/l/linux/xenial/i386
* BIONIC
- Regression in autopkgtest for linux-oracle (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-oracle/20190211_163710_b6f0a@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux-gcp-edge (amd64): test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/linux-gcp-edge/20190211_163830_8dce2@/log.gz
Source Package Version: 4.15.0-1008.10
Running Kernel Version: 4.15.0-45.48
ERROR: running version does not match source package
==> https://launchpad.net/bugs/1723223
- Regression in autopkgtest for linux (ppc64el): test log
- Regression in autopkgtest for linux (i386): test log
Recurrent failure from various trigger
(not introduced by this ongoing SRU)
http://autopkgtest.ubuntu.com/packages/l/linux/bionic/ppc64el
http://autopkgtest.ubuntu.com/packages/l/linux/bionic/i386
[Regression Potential]
Low, no core functionality change.
The intention is to only update pci.ids table list to recognise new PCI vendor/product list, by updating it to the same version level as Cosmic and Disco has as of today.
The only thing I can think of ...
In some cases there is some device id renaming, which I guess can "possibly" impact some user script and/or HW inventory solution. If this happens to certain users, I don't expect it to have a major impact and this should can be consider low and easy to fix by the user or admin of the HW inventory solution ... IMHO.
Example:
- 67df Ellesmere [Polaris10]
+ 67df Ellesmere [Radeon RX 470/480]
[Other information]
Confirmed w/ vorlon (SRU verification team) on #ubuntu-release
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. |
|
| 2019-02-18 14:39:07 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-02-18 14:39:36 |
Launchpad Janitor |
pciutils (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2019-02-18 14:49:10 |
Launchpad Janitor |
pciutils (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
