Hello,
I tried to get QEMU running with UEFI and SecureBoot. It sometimes
works, but sometimes I get memory corruption:
- the Debian installer sometimes fails to load the "libata.ko" or
"e1000.ko" modules.
- it it not always the same module
- my guest kernel uses KASLR, which might explain different modules
getting corrupted
- the file size is the same
- md5sums differs
- modules are all loaded from InitRamFS.
- depmod detects a cyclic dependency for "libata" on itelf:
> depmod: ERROR: Cycle detected: libata -> libata
Comparing the corrupted (left) with the supposed (right) driver shows
the following pattern:
> /tmp/uefi.bin [+] 15038,1 Alles /tmp/uefi.ko [+] 15038,1 Alles
> 003ac00: e801 0000 0000 0000 3c00 0000 1700 0000 ........<....... | 003ac00: e801 0000 0000 0000 5e8c 0000 1000 f1ff ........^.......
> 003ac10: 785b 3e8a 0000 0000 3c00 0000 0700 0000 x[>.....<....... | 003ac10: 785b 3e8a 0000 0000 0000 0000 0000 0000 x[>.............
> 003ac20: 778c 0000 1200 0200 3c00 0000 0700 0000 w.......<....... | 003ac20: 778c 0000 1200 0200 f018 0000 0000 0000 w...............
> 003ac30: 1e00 0000 0000 0000 3c00 0000 1700 0000 ........<....... | 003ac30: 1e00 0000 0000 0000 8c8c 0000 1200 0200 ................
> 003ac40: 7007 0000 0000 0000 3c00 0000 0700 0000 p.......<....... | 003ac40: 7007 0000 0000 0000 1400 0000 0000 0000 p...............
> 003ac50: 9c8c 0000 1200 0200 3c00 0000 0700 0000 ........<....... | 003ac50: 9c8c 0000 1200 0200 0022 0000 0000 0000 ........."......
> 003ac60: 4000 0000 0000 0000 3c00 0000 1700 0000 @.......<....... | 003ac60: 4000 0000 0000 0000 ac8c 0000 1000 f1ff @...............
That's the only difference in the 433702 byte sized file. (libata.ko)
I suspect this to be frame-buffer related, as the EFI frame-buffer is
also broken: see attached screen-shot
> # dmesg
> [ 0.980927] efifb: probing for efifb
> [ 0.981656] efifb: framebuffer at 0x80000000, using 1876k, total 1875k
> [ 0.983030] efifb: mode is 800x600x32, linelength=3200, pages=1
> [ 0.984293] efifb: scrolling: redraw
> [ 0.985128] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> [ 0.988296] Console: switching to colour frame buffer device 100x37
> [ 0.990700] fb0: EFI VGA frame buffer device
My host system is a Debian-Jessie system with newer QEMU components:
> $ dpkg-query -W qemu-system-x86 ovmf linux-image-4.9\*
> linux-image-4.9.0-0.bpo.3-amd64 4.9.25-1~bpo8+1
> ovmf 0~20160813.de74668f-2
> qemu-system-x86 1:2.6+dfsg-3.1~bpo8+1
My guest uses linux-4.9.13 self-compiled:
> CONFIG_RANDOMIZE_BASE=y
> CONFIG_RANDOMIZE_MEMORY=y
> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0xa
> CONFIG_FB_EFI=y
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
> CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
Bootloder is GRUB2, which initialized the frame-buffer to 800x600
QEMU is launched through libvirt:
> qemu-system-x86_64 -enable-kvm -name uefi -S -machine pc-i440fx-2.1,accel=kvm,usb=off -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/uefi_VARS.fd,if=pflash,format=raw,unit=1 -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 1d33ad46-5325-4bf0-b87f-e897b8b66946 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/phahn/.config/libvirt/qemu/lib/uefi.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device lsi,id=scsi0,bus=pci.0,addr=0x6 -device ahci,id=ahci0,bus=pci.0,addr=0x7 -drive file=/home/libvirt/ucs_4.2-0-latest-amd64.iso,format=raw,if=none,media=cdrom,id=drive-sata0-0-0,readonly=on -device ide-cd,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 -drive file=/home/libvirt/UEFI.qcow2,format=qcow2,if=none,id=drive-sata0-0-1,cache=unsafe,discard=unmap -device ide-hd,bus=ahci0.1,drive=drive-sata0-0-1,id=sata0-0-1,bootindex=2 -netdev tap,fd=23,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:31:e6:b4,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev file,id=charserial1,path=/tmp/uefi.log -device isa-serial,chardev=charserial1,id=serial1 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -global isa-debugcon.iobase=0x402 -debugcon file:/tmp/ovmf.log -msg timestamp=on
Has someone seen a similar issue or is this even a known issue?
I will try a newer version of QEMU and OVMF next.
Thank you in advance for your input.
Philipp
--
Philipp Hahn
Open Source Software Engineer
Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
[email protected]
http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876
On 06/16/17 19:03, Philipp Hahn wrote:
> Comparing the corrupted (left) with the supposed (right) driver shows
> the following pattern:
>> /tmp/uefi.bin [+] 15038,1 Alles /tmp/uefi.ko [+] 15038,1 Alles
>> 003ac00: e801 0000 0000 0000 3c00 0000 1700 0000 ........<....... | 003ac00: e801 0000 0000 0000 5e8c 0000 1000 f1ff ........^.......
>> 003ac10: 785b 3e8a 0000 0000 3c00 0000 0700 0000 x[>.....<....... | 003ac10: 785b 3e8a 0000 0000 0000 0000 0000 0000 x[>.............
>> 003ac20: 778c 0000 1200 0200 3c00 0000 0700 0000 w.......<....... | 003ac20: 778c 0000 1200 0200 f018 0000 0000 0000 w...............
>> 003ac30: 1e00 0000 0000 0000 3c00 0000 1700 0000 ........<....... | 003ac30: 1e00 0000 0000 0000 8c8c 0000 1200 0200 ................
>> 003ac40: 7007 0000 0000 0000 3c00 0000 0700 0000 p.......<....... | 003ac40: 7007 0000 0000 0000 1400 0000 0000 0000 p...............
>> 003ac50: 9c8c 0000 1200 0200 3c00 0000 0700 0000 ........<....... | 003ac50: 9c8c 0000 1200 0200 0022 0000 0000 0000 ........."......
>> 003ac60: 4000 0000 0000 0000 3c00 0000 1700 0000 @.......<....... | 003ac60: 4000 0000 0000 0000 ac8c 0000 1000 f1ff @...............
Let me give you a different visual representation. First good, then bad.
(I also recommend using the "vbindiff" tool for such problems, it is
great for picking out patterns.)
** ** ** ** ** ** ** ** 8 9 ** ** ** 13 14 15
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
00000000 01 e8 00 00 00 00 00 00 8c 5e 00 00 00 10 ff f1
00000010 5b 78 8a 3e 00 00 00 00 00 00 00 00 00 00 00 00
00000020 8c 77 00 00 00 12 00 02 18 f0 00 00 00 00 00 00
00000030 00 1e 00 00 00 00 00 00 8c 8c 00 00 00 12 00 02
00000040 07 70 00 00 00 00 00 00 00 14 00 00 00 00 00 00
00000050 8c 9c 00 00 00 12 00 02 22 00 00 00 00 00 00 00
00000060 00 40 00 00 00 00 00 00 8c ac 00 00 00 10 ff f1
00000000 01 e8 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
00000010 5b 78 8a 3e 00 00 00 00 00 3c 00 00 00 07 00 00
00000020 8c 77 00 00 00 12 00 02 00 3c 00 00 00 07 00 00
00000030 00 1e 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
00000040 07 70 00 00 00 00 00 00 00 3c 00 00 00 07 00 00
00000050 8c 9c 00 00 00 12 00 02 00 3c 00 00 00 07 00 00
00000060 00 40 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
** ** ** ** ** ** ** ** 8 9 ** ** ** 13 14 15
The columns that I marked with "**" are identical between "good" and
"bad". (These are columns 0-7, 10-12.)
Column 8 is overwritten by zeros (every 16th byte).
Column 9 is overwritten by 0x3c (every 16th byte).
Column 13 is super interesting. The most significant nibble in that
column is not disturbed. And, in the least significant nibble, the least
significant three bits are turned on. Basically, the corruption could be
described, for this column (i.e., every 16th byte), as
bad = good | 0x7
Column 14 is overwritten by zeros (every 16th byte).
Column 15 is overwritten by zeros (every 16th byte).
My take is that your host machine has faulty RAM. Please run memtest86+
or something similar.
Thanks
Laszlo
Hello,
Am 17.06.2017 um 18:51 schrieb Laszlo Ersek:
> (I also recommend using the "vbindiff" tool for such problems, it is
> great for picking out patterns.)
>
> ** ** ** ** ** ** ** ** 8 9 ** ** ** 13 14 15
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 00000000 01 e8 00 00 00 00 00 00 8c 5e 00 00 00 10 ff f1
> 00000010 5b 78 8a 3e 00 00 00 00 00 00 00 00 00 00 00 00
> 00000020 8c 77 00 00 00 12 00 02 18 f0 00 00 00 00 00 00
> 00000030 00 1e 00 00 00 00 00 00 8c 8c 00 00 00 12 00 02
> 00000040 07 70 00 00 00 00 00 00 00 14 00 00 00 00 00 00
> 00000050 8c 9c 00 00 00 12 00 02 22 00 00 00 00 00 00 00
> 00000060 00 40 00 00 00 00 00 00 8c ac 00 00 00 10 ff f1
>
> 00000000 01 e8 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
> 00000010 5b 78 8a 3e 00 00 00 00 00 3c 00 00 00 07 00 00
> 00000020 8c 77 00 00 00 12 00 02 00 3c 00 00 00 07 00 00
> 00000030 00 1e 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
> 00000040 07 70 00 00 00 00 00 00 00 3c 00 00 00 07 00 00
> 00000050 8c 9c 00 00 00 12 00 02 00 3c 00 00 00 07 00 00
> 00000060 00 40 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> ** ** ** ** ** ** ** ** 8 9 ** ** ** 13 14 15
>
> The columns that I marked with "**" are identical between "good" and
> "bad". (These are columns 0-7, 10-12.)
>
> Column 8 is overwritten by zeros (every 16th byte).
>
> Column 9 is overwritten by 0x3c (every 16th byte).
>
> Column 13 is super interesting. The most significant nibble in that
> column is not disturbed. And, in the least significant nibble, the least
> significant three bits are turned on. Basically, the corruption could be
> described, for this column (i.e., every 16th byte), as
>
> bad = good | 0x7
>
> Column 14 is overwritten by zeros (every 16th byte).
>
> Column 15 is overwritten by zeros (every 16th byte).
>
> My take is that your host machine has faulty RAM. Please run memtest86+
> or something similar.
I will do so, but for me very unlikely:
- it never happens with BIOS, only with OVMF
- for each test I start q new QEMU process, which should use a different
memory region
- it repeatedly hits e1000 or libata.ko
After updating from OVMF to 0~20161202.7bbe0b3e-1 from
(0~20160813.de74668f-2 it has not yet happened again.
Anyway, thank you for your help.
Philipp
* Philipp Hahn ([email protected]) wrote:
> Hello,
>
> Am 17.06.2017 um 18:51 schrieb Laszlo Ersek:
> > (I also recommend using the "vbindiff" tool for such problems, it is
> > great for picking out patterns.)
> >
> > ** ** ** ** ** ** ** ** 8 9 ** ** ** 13 14 15
> > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 00000000 01 e8 00 00 00 00 00 00 8c 5e 00 00 00 10 ff f1
> > 00000010 5b 78 8a 3e 00 00 00 00 00 00 00 00 00 00 00 00
> > 00000020 8c 77 00 00 00 12 00 02 18 f0 00 00 00 00 00 00
> > 00000030 00 1e 00 00 00 00 00 00 8c 8c 00 00 00 12 00 02
> > 00000040 07 70 00 00 00 00 00 00 00 14 00 00 00 00 00 00
> > 00000050 8c 9c 00 00 00 12 00 02 22 00 00 00 00 00 00 00
> > 00000060 00 40 00 00 00 00 00 00 8c ac 00 00 00 10 ff f1
> >
> > 00000000 01 e8 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
> > 00000010 5b 78 8a 3e 00 00 00 00 00 3c 00 00 00 07 00 00
> > 00000020 8c 77 00 00 00 12 00 02 00 3c 00 00 00 07 00 00
> > 00000030 00 1e 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
> > 00000040 07 70 00 00 00 00 00 00 00 3c 00 00 00 07 00 00
> > 00000050 8c 9c 00 00 00 12 00 02 00 3c 00 00 00 07 00 00
> > 00000060 00 40 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
> > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > ** ** ** ** ** ** ** ** 8 9 ** ** ** 13 14 15
> >
> > The columns that I marked with "**" are identical between "good" and
> > "bad". (These are columns 0-7, 10-12.)
> >
> > Column 8 is overwritten by zeros (every 16th byte).
> >
> > Column 9 is overwritten by 0x3c (every 16th byte).
> >
> > Column 13 is super interesting. The most significant nibble in that
> > column is not disturbed. And, in the least significant nibble, the least
> > significant three bits are turned on. Basically, the corruption could be
> > described, for this column (i.e., every 16th byte), as
> >
> > bad = good | 0x7
> >
> > Column 14 is overwritten by zeros (every 16th byte).
> >
> > Column 15 is overwritten by zeros (every 16th byte).
> >
> > My take is that your host machine has faulty RAM. Please run memtest86+
> > or something similar.
>
> I will do so, but for me very unlikely:
> - it never happens with BIOS, only with OVMF
> - for each test I start q new QEMU process, which should use a different
> memory region
> - it repeatedly hits e1000 or libata.ko
>
> After updating from OVMF to 0~20161202.7bbe0b3e-1 from
> (0~20160813.de74668f-2 it has not yet happened again.
>
> Anyway, thank you for your help.
What host CPU are you using?
Dave
>
> Philipp
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
Am 18.06.2017 um 20:27 schrieb Dr. David Alan Gilbert:
> * Philipp Hahn ([email protected]) wrote:
>> Hello,
>>
>> Am 17.06.2017 um 18:51 schrieb Laszlo Ersek:
>>> (I also recommend using the "vbindiff" tool for such problems, it is
>>> great for picking out patterns.)
>>>
>>> ** ** ** ** ** ** ** ** 8 9 ** ** ** 13 14 15
>>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 00000000 01 e8 00 00 00 00 00 00 8c 5e 00 00 00 10 ff f1
>>> 00000010 5b 78 8a 3e 00 00 00 00 00 00 00 00 00 00 00 00
>>> 00000020 8c 77 00 00 00 12 00 02 18 f0 00 00 00 00 00 00
>>> 00000030 00 1e 00 00 00 00 00 00 8c 8c 00 00 00 12 00 02
>>> 00000040 07 70 00 00 00 00 00 00 00 14 00 00 00 00 00 00
>>> 00000050 8c 9c 00 00 00 12 00 02 22 00 00 00 00 00 00 00
>>> 00000060 00 40 00 00 00 00 00 00 8c ac 00 00 00 10 ff f1
>>>
>>> 00000000 01 e8 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
>>> 00000010 5b 78 8a 3e 00 00 00 00 00 3c 00 00 00 07 00 00
>>> 00000020 8c 77 00 00 00 12 00 02 00 3c 00 00 00 07 00 00
>>> 00000030 00 1e 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
>>> 00000040 07 70 00 00 00 00 00 00 00 3c 00 00 00 07 00 00
>>> 00000050 8c 9c 00 00 00 12 00 02 00 3c 00 00 00 07 00 00
>>> 00000060 00 40 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
>>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> ** ** ** ** ** ** ** ** 8 9 ** ** ** 13 14 15
>>>
>>> The columns that I marked with "**" are identical between "good" and
>>> "bad". (These are columns 0-7, 10-12.)
>>>
>>> Column 8 is overwritten by zeros (every 16th byte).
>>>
>>> Column 9 is overwritten by 0x3c (every 16th byte).
>>>
>>> Column 13 is super interesting. The most significant nibble in that
>>> column is not disturbed. And, in the least significant nibble, the least
>>> significant three bits are turned on. Basically, the corruption could be
>>> described, for this column (i.e., every 16th byte), as
>>>
>>> bad = good | 0x7
>>>
>>> Column 14 is overwritten by zeros (every 16th byte).
>>>
>>> Column 15 is overwritten by zeros (every 16th byte).
>>>
>>> My take is that your host machine has faulty RAM. Please run memtest86+
>>> or something similar.
>>
>> I will do so, but for me very unlikely:
>> - it never happens with BIOS, only with OVMF
>> - for each test I start q new QEMU process, which should use a different
>> memory region
>> - it repeatedly hits e1000 or libata.ko
>>
>> After updating from OVMF to 0~20161202.7bbe0b3e-1 from
>> (0~20160813.de74668f-2 it has not yet happened again.
>>
>> Anyway, thank you for your help.
>
> What host CPU are you using?
Everything is amd64:
> processor : 3
> vendor_id : GenuineIntel
> cpu family : 6
> model : 58
> model name : Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz
> stepping : 9
> microcode : 0x19
> cpu MHz : 2591.015
> cache size : 3072 KB
> physical id : 0
> siblings : 4
> core id : 1
> cpu cores : 2
> apicid : 3
> initial apicid : 3
> fpu : yes
> fpu_exception : yes
> cpuid level : 13
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts
> bugs :
> bogomips : 3592.75
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
Philipp
Hello,
Am 18.06.2017 um 20:22 schrieb Philipp Hahn:
> Am 17.06.2017 um 18:51 schrieb Laszlo Ersek:
>> (I also recommend using the "vbindiff" tool for such problems, it is
>> great for picking out patterns.)
>>
>> ** ** ** ** ** ** ** ** 8 9 ** ** ** 13 14 15
>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 00000000 01 e8 00 00 00 00 00 00 8c 5e 00 00 00 10 ff f1
>> 00000010 5b 78 8a 3e 00 00 00 00 00 00 00 00 00 00 00 00
>> 00000020 8c 77 00 00 00 12 00 02 18 f0 00 00 00 00 00 00
>> 00000030 00 1e 00 00 00 00 00 00 8c 8c 00 00 00 12 00 02
>> 00000040 07 70 00 00 00 00 00 00 00 14 00 00 00 00 00 00
>> 00000050 8c 9c 00 00 00 12 00 02 22 00 00 00 00 00 00 00
>> 00000060 00 40 00 00 00 00 00 00 8c ac 00 00 00 10 ff f1
>>
>> 00000000 01 e8 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
>> 00000010 5b 78 8a 3e 00 00 00 00 00 3c 00 00 00 07 00 00
>> 00000020 8c 77 00 00 00 12 00 02 00 3c 00 00 00 07 00 00
>> 00000030 00 1e 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
>> 00000040 07 70 00 00 00 00 00 00 00 3c 00 00 00 07 00 00
>> 00000050 8c 9c 00 00 00 12 00 02 00 3c 00 00 00 07 00 00
>> 00000060 00 40 00 00 00 00 00 00 00 3c 00 00 00 17 00 00
>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> ** ** ** ** ** ** ** ** 8 9 ** ** ** 13 14 15
>>
>> The columns that I marked with "**" are identical between "good" and
>> "bad". (These are columns 0-7, 10-12.)
>>
>> Column 8 is overwritten by zeros (every 16th byte).
>>
>> Column 9 is overwritten by 0x3c (every 16th byte).
>>
>> Column 13 is super interesting. The most significant nibble in that
>> column is not disturbed. And, in the least significant nibble, the least
>> significant three bits are turned on. Basically, the corruption could be
>> described, for this column (i.e., every 16th byte), as
>>
>> bad = good | 0x7
>>
>> Column 14 is overwritten by zeros (every 16th byte).
>>
>> Column 15 is overwritten by zeros (every 16th byte).
>>
>> My take is that your host machine has faulty RAM. Please run memtest86+
>> or something similar.
>
> I will do so, but for me very unlikely:
> - it never happens with BIOS, only with OVMF
> - for each test I start q new QEMU process, which should use a different
> memory region
> - it repeatedly hits e1000 or libata.ko
Okay: memtest+-5.01 run for 8h and did not find any errors in those 3
passes.
> After updating from OVMF to 0~20161202.7bbe0b3e-1 from
> (0~20160813.de74668f-2 it has not yet happened again.
Anyway, thank you for your help.
Philipp