diff options
Diffstat (limited to 'results/classifier/118/all/1910586')
| -rw-r--r-- | results/classifier/118/all/1910586 | 196 |
1 files changed, 196 insertions, 0 deletions
diff --git a/results/classifier/118/all/1910586 b/results/classifier/118/all/1910586 new file mode 100644 index 000000000..7d86d503f --- /dev/null +++ b/results/classifier/118/all/1910586 @@ -0,0 +1,196 @@ +virtual: 0.987 +semantic: 0.986 +register: 0.984 +permissions: 0.984 +PID: 0.981 +assembly: 0.981 +debug: 0.978 +architecture: 0.978 +socket: 0.977 +network: 0.976 +performance: 0.976 +kernel: 0.975 +files: 0.973 +arm: 0.969 +device: 0.968 +graphic: 0.966 +boot: 0.964 +peripherals: 0.953 +vnc: 0.950 +risc-v: 0.948 +ppc: 0.948 +VMM: 0.935 +TCG: 0.924 +hypervisor: 0.916 +KVM: 0.914 +x86: 0.880 +mistranslation: 0.878 +user-level: 0.841 +i386: 0.756 + +SD card size constraint conceptually wrong + +The patch discussed here: +https://<email address hidden>/msg720833.html +introduces an artificial size constraint for SD cards +that has no relation to reality. + +I'm trying to use an _actual_ **physical** SD card, +and qemu tells me its size is "invalid". + +Something here appears to be conceptually wrong. + +-------------------------------------------------- +# fdisk -l /dev/sdg +Disk /dev/sdg: 14.84 GiB, 15931539456 bytes, 31116288 sectors +Disk model: USB SD Reader +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +Disklabel type: dos +Disk identifier: 0x7a0c8bb0 + +Device Boot Start End Sectors Size Id Type +/dev/sdg1 2048 524287 522240 255M c W95 FAT32 (LBA) +/dev/sdg2 524288 31116287 30592000 14.6G 83 Linux +# qemu-system-aarch64 -M raspi3 -m 1G -kernel vmlinuz-5.4.79-v8 -dtb bcm2837-rpi-3-b-plus.dtb -append console=ttyAMA0\ root=/dev/mmcblk0p2\ rw -nographic -serial mon:stdio -drive file=/dev/sdg,format=raw +qemu-system-aarch64: Invalid SD card size: 14.8 GiB +SD card size has to be a power of 2, e.g. 16 GiB. +You can resize disk images with 'qemu-img resize <imagefile> <new-size>' +(note that this will lose data if you make the image smaller than it currently is). +-------------------------------------------------- + +The same invocation with a dump of the actual image +resized to match qemu's odd expectations works fine. + + +This is on QEMU 5.2.0, as evidenced by the following: +-------------------------------------------------- +# qemu-system-aarch64 -version +QEMU emulator version 5.2.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +-------------------------------------------------- + +Is there a simple workaround that disables this rather +arbitrary constraint? + +On 1/7/21 8:24 PM, - wrote: +> Public bug reported: +> +> The patch discussed here: +> https://<email address hidden>/msg720833.html +> introduces an artificial size constraint for SD cards +> that has no relation to reality. +> +> I'm trying to use an _actual_ **physical** SD card, +> and qemu tells me its size is "invalid". +> +> Something here appears to be conceptually wrong. +> +> -------------------------------------------------- +> # fdisk -l /dev/sdg +> Disk /dev/sdg: 14.84 GiB, 15931539456 bytes, 31116288 sectors +> Disk model: USB SD Reader +> Units: sectors of 1 * 512 = 512 bytes +> Sector size (logical/physical): 512 bytes / 512 bytes +> I/O size (minimum/optimal): 512 bytes / 512 bytes +> Disklabel type: dos +> Disk identifier: 0x7a0c8bb0 +> +> Device Boot Start End Sectors Size Id Type +> /dev/sdg1 2048 524287 522240 255M c W95 FAT32 (LBA) +> /dev/sdg2 524288 31116287 30592000 14.6G 83 Linux +> # qemu-system-aarch64 -M raspi3 -m 1G -kernel vmlinuz-5.4.79-v8 -dtb bcm2837-rpi-3-b-plus.dtb -append console=ttyAMA0\ root=/dev/mmcblk0p2\ rw -nographic -serial mon:stdio -drive file=/dev/sdg,format=raw +> qemu-system-aarch64: Invalid SD card size: 14.8 GiB +> SD card size has to be a power of 2, e.g. 16 GiB. + +Your physical card likely is 16GiB. The firmware running +on it is free to reserve some amount to replace broken +blocks. In your case ~7%. + +We choose to restrict the model to the physical layer to +simplify the design and avoid to deal with security issues. + +Patches to improve the model by better matching the real +world are always welcomed! + +> You can resize disk images with 'qemu-img resize <imagefile> <new-size>' +> (note that this will lose data if you make the image smaller than it currently is). + +Indeed, we can remove this warning for block devices. + +> -------------------------------------------------- +> +> The same invocation with a dump of the actual image +> resized to match qemu's odd expectations works fine. +> +> +> This is on QEMU 5.2.0, as evidenced by the following: +> -------------------------------------------------- +> # qemu-system-aarch64 -version +> QEMU emulator version 5.2.0 +> Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +> -------------------------------------------------- +> +> Is there a simple workaround that disables this rather +> arbitrary constraint? + +No, but you can send a patch :) + +Regards, + +Phil. + + +> Indeed, we can remove this warning for block devices. + +Couldn't you simply remove the entire size check logic for block devices? + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +On Wed, May 12, 2021 at 11:08:09AM -0000, Thomas Huth wrote: +> +> If it is not fixed yet and you think that this bug report here is still +> valid, then you have two options: + +Actually, you seem to have forgotten a third option: I simply don't care +enough, especially after the patronizing response to my original report, +to bother. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/297 + + |