On Tue, Feb 13, 2018 at 10:52 AM, Pavel Dovgalyuk <dovga...@ispras.ru> wrote:
> > From: Peter Maydell [mailto:peter.mayd...@linaro.org] > > On 13 February 2018 at 10:26, Pavel Dovgalyuk <dovga...@ispras.ru> > wrote: > > > Then I added SCSI adapter with the option –device lsi,id=scsi0 and QEMU > > > failed with the following error: > > > > > > qemu: fatal: IO on conditional branch instruction > > > > > Seems, that your kernel is incomatible with QEMU, which ARM emulation > is not > > > good enough. > Just to clarify, this is my working ARM command that works without record / replay: ./buildroot/output.arm~/host/usr/bin/qemu-system-arm -m 128M -monitor telnet::45454,server,nowait -netdev user,hostfwd=tcp::45455-:45455,id=net0 -smp 1 -M versatilepb -append 'root=/dev/sda nokaslr norandmaps printk.devkmsg=on printk.time=y' -device rtl8139,netdev=net0 -drive file=./buildroot/output.arm~/images/rootfs.ext2,if=scsi,format=raw -dtb ./buildroot/output.arm~/images/versatile-pb.dtb -kernel ./buildroot/output.arm~/images/zImage -serial stdio I then tried to modify it for record / replay to use similar options to the x86 version. The only non-trivial change was what to use for the drive. So I tried to replace them with: -drive file=./buildroot/output.arm~/images/rootfs.ext2,if=scsi,id=img-direct,format=raw \ -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \ -device scsi-hd,drive=img-blkreplay \ and some other variations, but this is just guesswork and likely to be wrong, since I don't understand those options very well. I don't need to use SCSI if that is not supported, I'd be happy with any record / replay QEMU command that works with the image I uploaded on the .zip. > > > > It seems fairly unlikely to me that the Linux driver for this > > SCSI adaptor is using weirdo self-modifying code of the kind > > that would trip up that cpu_abort(). I would suggest a bit > > more investigation into what's actually happening... > > It happens for any SCSI adapter (i.e., for every system able to run). > And the log is not very big. Therefore the problem is in early boot code. > > Pavel Dovgalyuk > >