|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable-smoke bisection] complete test-arm64-arm64-xl-xsm
branch xen-unstable-smoke xenbranch xen-unstable-smoke job test-arm64-arm64-xl-xsm testid xen-boot Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 11911563610786615c2b3a01cdcaaf09a6f9e38d Bug not present: eb63e1225aba04c959eeb68eda99e422939c37de Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/138293/ commit 11911563610786615c2b3a01cdcaaf09a6f9e38d Author: Stefano Stabellini <sstabellini@xxxxxxxxxx> Date: Fri Jun 21 13:20:25 2019 -0700 xen/arm: fix mask calculation in pdx_init_mask The mask calculation in pdx_init_mask is wrong when the first bank starts at address 0x0. The reason is that pdx_init_mask will do '0 - 1' causing an underflow. As a result, the mask becomes 0xffffffffffffffff which is the biggest possible mask and ends up causing a significant memory waste in the frametable size computation. For instance, on platforms that have a low memory bank starting at 0x0 and a high memory bank, the frametable will end up covering all the holes in between. The purpose of the mask is to be passed as a parameter to pfn_pdx_hole_setup, which based on the mask parameter calculates pfn_pdx_hole_shift, pfn_pdx_bottom_mask, etc. which are actually the important masks for frametable initialization later on. pfn_pdx_hole_setup never compresses addresses below MAX_ORDER bits (1GB on ARM). Thus, it is safe to initialize mask passing 1ULL << (MAX_ORDER + PAGE_SHIFT) as start address to pdx_init_mask. Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx> Reviewed-by: Julien Grall <julien.grall@xxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/test-arm64-arm64-xl-xsm.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. ---------------------------------------- Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/test-arm64-arm64-xl-xsm.xen-boot --summary-out=tmp/138312.bisection-summary --basis-template=138228 --blessings=real,real-bisect xen-unstable-smoke test-arm64-arm64-xl-xsm xen-boot Searching for failure / basis pass: 138295 fail [host=laxton0] / 138228 [host=rochester0] 138205 ok. Failure / basis pass flights: 138295 / 138205 Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 11911563610786615c2b3a01cdcaaf09a6f9e38d Basis pass e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 5a82d598d2d25cff223687b9948473a733a81ffd Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#e64ac26749dc2c0f390caccd04274608ab31c8cf-e64ac26749dc2c0f390caccd04274608ab31c8cf git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-9cca02d8ffc23e9688a971d858e4ffdff5389b11 git://xenbits.xen.org/xen.git#5a82d598d2d25cff223687b9948473a733a81ffd-1191156\ 3610786615c2b3a01cdcaaf09a6f9e38d Loaded 1001 nodes in revision graph Searching for test results: 138205 pass e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 5a82d598d2d25cff223687b9948473a733a81ffd 138293 fail e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 11911563610786615c2b3a01cdcaaf09a6f9e38d 138262 fail e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 11911563610786615c2b3a01cdcaaf09a6f9e38d 138259 pass e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 5a82d598d2d25cff223687b9948473a733a81ffd 138228 [host=rochester0] 138257 fail e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 11911563610786615c2b3a01cdcaaf09a6f9e38d 138242 fail e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 11911563610786615c2b3a01cdcaaf09a6f9e38d 138268 pass e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 f3d8eef9091747e70c505094f63514b43329a922 138271 pass e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 eb63e1225aba04c959eeb68eda99e422939c37de 138276 fail e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 11911563610786615c2b3a01cdcaaf09a6f9e38d 138280 pass e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 eb63e1225aba04c959eeb68eda99e422939c37de 138287 fail e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 11911563610786615c2b3a01cdcaaf09a6f9e38d 138277 [host=laxton1] 138290 pass e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 eb63e1225aba04c959eeb68eda99e422939c37de 138294 [host=laxton1] 138295 fail e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 11911563610786615c2b3a01cdcaaf09a6f9e38d 138299 [host=laxton1] 138302 [host=laxton1] 138306 [host=laxton1] 138309 [host=laxton1] 138312 [host=laxton1] Searching for interesting versions Result found: flight 138205 (pass), for basis pass Result found: flight 138242 (fail), for basis failure Repro found: flight 138259 (pass), for basis pass Repro found: flight 138262 (fail), for basis failure 0 revisions at e64ac26749dc2c0f390caccd04274608ab31c8cf c530a75c1e6a472b0eb9558310b518f0dfcd8860 9cca02d8ffc23e9688a971d858e4ffdff5389b11 eb63e1225aba04c959eeb68eda99e422939c37de No revisions left to test, checking graph state. Result found: flight 138271 (pass), for last pass Result found: flight 138276 (fail), for first failure Repro found: flight 138280 (pass), for last pass Repro found: flight 138287 (fail), for first failure Repro found: flight 138290 (pass), for last pass Repro found: flight 138293 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 11911563610786615c2b3a01cdcaaf09a6f9e38d Bug not present: eb63e1225aba04c959eeb68eda99e422939c37de Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/138293/ commit 11911563610786615c2b3a01cdcaaf09a6f9e38d Author: Stefano Stabellini <sstabellini@xxxxxxxxxx> Date: Fri Jun 21 13:20:25 2019 -0700 xen/arm: fix mask calculation in pdx_init_mask The mask calculation in pdx_init_mask is wrong when the first bank starts at address 0x0. The reason is that pdx_init_mask will do '0 - 1' causing an underflow. As a result, the mask becomes 0xffffffffffffffff which is the biggest possible mask and ends up causing a significant memory waste in the frametable size computation. For instance, on platforms that have a low memory bank starting at 0x0 and a high memory bank, the frametable will end up covering all the holes in between. The purpose of the mask is to be passed as a parameter to pfn_pdx_hole_setup, which based on the mask parameter calculates pfn_pdx_hole_shift, pfn_pdx_bottom_mask, etc. which are actually the important masks for frametable initialization later on. pfn_pdx_hole_setup never compresses addresses below MAX_ORDER bits (1GB on ARM). Thus, it is safe to initialize mask passing 1ULL << (MAX_ORDER + PAGE_SHIFT) as start address to pdx_init_mask. Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx> Reviewed-by: Julien Grall <julien.grall@xxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> Revision graph left in /home/logs/results/bisect/xen-unstable-smoke/test-arm64-arm64-xl-xsm.xen-boot.{dot,ps,png,html,svg}. ---------------------------------------- 138312: truncated flight 138312 xen-unstable-smoke real-bisect [real] http://logs.test-lab.xenproject.org/osstest/logs/138312/ Perfect :-) All tests in this flight passed as required jobs: test-arm64-arm64-xl-xsm truncated ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary _______________________________________________ osstest-output mailing list osstest-output@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/osstest-output
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |