Bugzilla – Bug 977027
SLOF keyboard regression on xhci
Last modified: 2017-03-16 17:11:04 UTC
Due to ohci is slow for openQA, we are switching to xhci, but I see type speed in xhci keyboard in SLOF. Which blocks Tumbleweed NET install testing. As reported on ML: https://lists.ozlabs.org/pipermail/slof/2016-April/000982.html
Dinar, could you please update the bug as soon as there is a conclusion upstream? We can then integrate it back into our QEMU package's SLOF binary.
------- Comment From nikunj.dadhania@in.ibm.com 2016-04-29 01:31 EDT------- Sent fix to the mailing list https://patchwork.ozlabs.org/patch/616396/
Fix is in master now.
http://git.qemu.org/?p=SLOF.git;a=commit;h=ca8fb51e05feca057721d72cb194cd0636c73847
(In reply to Michal Marek from comment #4) > http://git.qemu.org/?p=SLOF.git;a=commit; > h=ca8fb51e05feca057721d72cb194cd0636c73847 How is this SLOF patch supposed to be pulled for qemu rebuild for openSUSE ? Does it need an update of the qemu-2.7.0.tar.bz2 ? The used SLOF source tree seems to be dated 20160223 === $strings /usr/share/qemu/slof.bin |grep -i "FW version" FW Version = abuild@obs-power8-03 release 20160223 FW Version = abuild@obs-power8-03 release 20160223 [michel@abanc:~] $rpm -qf /usr/share/qemu/slof.bin qemu-ppc-2.7.0-354.1.ppc64le ===
proposed change in github openSUSE/qemu: https://github.com/openSUSE/qemu/pull/13
SLOF is built from source so you can just add the patch in the qemu package spec as well.
(In reply to Michal Suchanek from comment #7) > SLOF is built from source so you can just add the patch in the qemu package > spec as well. In fact that is needed here. Please list which SLOF commits are needed for cherry-picking to v2.7.0's submodule.
(In reply to Andreas Färber from comment #8) > (In reply to Michal Suchanek from comment #7) > > SLOF is built from source so you can just add the patch in the qemu package > > spec as well. > > In fact that is needed here. Please list which SLOF commits are needed for > cherry-picking to v2.7.0's submodule. The required slof patch was already referenced in comment #4 of this bug. Nevertheless it seems that qemu source tarball in OBS was previously updated with SLOF source tag between what is defined in github (tag qemu-slof-20121018) and the source files in roms/SLOF that match content of tag qemu-slof-20160223 So the maintainer in OBS Virtualization already previously accepted slof tag updates and not only one patch. This is the reason why I suggested the PR of comment #6 * the SLOF source code referenced in github openSUSE/qemu is https://github.com/openSUSE/qemu/commit/4fd50339c0b55fa6387fa3c28f755c306997064c which is pointing to slof commit 0ad10f2: https://github.com/aik/SLOF/releases/tag/qemu-slof-20121018 * in OBS Virtualization qemu the qemu-2.7.0.tar.bz2 is timestamped September 10th but there are no comment in qemu.changes what was the purpose of the change. === [michel@twppc64le:~/workViirtualization/qemu] $lr *bz2 -rw-r--r-- 1 michel users 26M sept. 10 11:32 qemu-2.7.0.tar.bz2 === * in this qemu-2.7.0.tar.bz2 tarball the SLOF version is dated 2016223 and the few files are checked match content of qemu-slof-20160223 tag === $grep -Hnr 20160223 qemu-2.7.0/roms/SLOF/ qemu-2.7.0/roms/SLOF/VERSION:1:20160223 ===
(In reply to Michel Normand from comment #9) > (In reply to Andreas Färber from comment #8) > > (In reply to Michal Suchanek from comment #7) > > > SLOF is built from source so you can just add the patch in the qemu package > > > spec as well. > > > > In fact that is needed here. Please list which SLOF commits are needed for > > cherry-picking to v2.7.0's submodule. > > The required slof patch was already referenced in comment #4 of this bug. Thanks for the pointer. > Nevertheless it seems that qemu source tarball in OBS was previously updated > with SLOF source tag between what is defined in github (tag > qemu-slof-20121018) and the source files in roms/SLOF that match content of > tag qemu-slof-20160223 > > So the maintainer in OBS Virtualization already previously accepted slof tag > updates and not only one patch. As maintainer, I certainly did not, because as I explained to you it would not work. We take whatever SLOF code is in the official QEMU tarball on qemu-project.org. We once applied local SLOF patches on top in our package. (S/390 once had a temporary firmware update workaround in SLES11, therefore I know our scripts don't handle such binary updates.) Dinar previously requested that we replace SLOF with some newer version and that request was rejected by our team. If other SLOF versions are desired for testing, they need to be packaged separately, SRs to Virtualization or Virtualization:Staging welcome. Any patches for SLOF in qemu are maintained old-style (without Git queue), so ultimately I need to make/get an SR with named .patch files being applied. > This is the reason why I suggested the PR of comment #6 > > * the SLOF source code referenced in github openSUSE/qemu > is > https://github.com/openSUSE/qemu/commit/ > 4fd50339c0b55fa6387fa3c28f755c306997064c > which is pointing to slof commit 0ad10f2: > https://github.com/aik/SLOF/releases/tag/qemu-slof-20121018 > > * in OBS Virtualization qemu the qemu-2.7.0.tar.bz2 is timestamped September > 10th but there are no comment in qemu.changes what was the purpose of the > change. [snip] I honestly don't understand what you're claiming here... a) I already said on GitHub that master branch is the wrong branch. It is not updated or used, so a 2012 tag is irrelevant. We are on opensuse-2.7 branch, as can be seen in update_git.sh. b) I personally downloaded the tarball from the official QEMU website and I am certain you will find some "- Updated to v2.7.0" qemu.changes entry for that. You should be able to verify the tarball with qemu-2.7.0.tar.bz2.sig that was downloaded alongside the tarball. Whatever tags you find inside the tarball is not my fault! c) If there is something wrong with the upstream tarball you will need to discuss that with the upstream QEMU maintainer, Peter Maydell.
(In reply to Michal Marek from comment #4) > http://git.qemu.org/?p=SLOF.git;a=commit; > h=ca8fb51e05feca057721d72cb194cd0636c73847 Thanks, applied: https://build.opensuse.org/request/show/442479
Is there a bug reference to track the status of same correction for SLES12-SP2 ?
Seems the patch was submitted to SLE12 and then pulled again for unstated reason.
SUSE-SU-2017:0625-1: An update that solves 15 vulnerabilities and has four fixes is now available. Category: security (important) Bug References: 1014702,1015169,1016779,1017081,1017084,1020491,1020589,1020928,1021129,1021195,1021481,1022541,1023004,1023053,1023073,1023907,1024972,1026583,977027 CVE References: CVE-2016-10028,CVE-2016-10029,CVE-2016-10155,CVE-2016-9921,CVE-2016-9922,CVE-2017-2615,CVE-2017-2620,CVE-2017-5525,CVE-2017-5526,CVE-2017-5552,CVE-2017-5578,CVE-2017-5667,CVE-2017-5856,CVE-2017-5857,CVE-2017-5898 Sources used: SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src): qemu-2.6.2-41.9.1 SUSE Linux Enterprise Server 12-SP2 (src): qemu-2.6.2-41.9.1 SUSE Linux Enterprise Desktop 12-SP2 (src): qemu-2.6.2-41.9.1
openSUSE-SU-2017:0707-1: An update that solves 15 vulnerabilities and has four fixes is now available. Category: security (important) Bug References: 1014702,1015169,1016779,1017081,1017084,1020491,1020589,1020928,1021129,1021195,1021481,1022541,1023004,1023053,1023073,1023907,1024972,1026583,977027 CVE References: CVE-2016-10028,CVE-2016-10029,CVE-2016-10155,CVE-2016-9921,CVE-2016-9922,CVE-2017-2615,CVE-2017-2620,CVE-2017-5525,CVE-2017-5526,CVE-2017-5552,CVE-2017-5578,CVE-2017-5667,CVE-2017-5856,CVE-2017-5857,CVE-2017-5898 Sources used: openSUSE Leap 42.2 (src): qemu-2.6.2-29.4, qemu-linux-user-2.6.2-29.1, qemu-testsuite-2.6.2-29.8