Bug #1117
closedfsck coredumps under QEMU-KVM
0%
Description
Hi all,
When trying to fsck to a qemu-kvm disk (it's a physical disk partition
on host system), I get several DMA errors and later it coredumps.
I think this might be a hardware problem on the host disk but as I am
not sure I wanted to consult here. I also attach the core file.
ad2: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=93
ad2: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=93
ad2: FAILURE - WRITE_DMA timed out LBA=93
ad2: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=94
ad2: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=94
ad2: FAILURE - WRITE_DMA timed out LBA=94
ad2: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=4223
ad2: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=4223
ad2: FAILURE - WRITE_DMA timed out LBA=4223
pid 835 (fsck), uid 0: exited on signal 6 (core dumped)
Regards,
Antonio Huete
Files
Updated by ahuete.devel over 16 years ago
I have noticed that the coredump only occurs if I interrupt the process
(by Ctrl+C):
- /dev/ad2s1a
- Last Mounted on /mnt/test
- Phase 1 - Check Blocks and Sizes
- Phase 2 - Check Pathnames
- Phase 3 - Check Connectivity
- Phase 4 - Check Reference Counts
- Phase 5 - Check Cyl groups
3076 files, 56890 used, 136613 free (61 frags, 17069 blocks, 0.0%
fragmentation)
ad2: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=79
^Cad2: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=79
ad2: FAILURE - WRITE_DMA timed out LBA=79
fsck in free(): error: free_pages: pointer to wrong pageAbort (core dumped)
virtualdragon# Aug 11 16:45:30 virtualdragon kernel: pid 995 (fsck), uid
0: exit
ed on signal 6 (core dumped)
Now I include a backtrace:
(gdb) bt
#0 0x080773ac in kill ()
#1 0x0807509e in abort ()
#2 0x0805e611 in ?? ()
#3 0x0805e63b in ?? ()
#4 0x0805ef75 in ?? ()
#5 0x0805f7ca in free ()
#6 0x08053ba3 in ckfini (markclean=0) at utilities.c:266
#7 0x08054701 in catch (sig=2) at utilities.c:487
#8 <signal handler called>
#9 0x08055e9c in write ()
#10 0x08054009 in bwrite (fd=4, buf=0x28085000 "", blk=16, size=8192) at
utilities.c:350
#11 0x08053996 in flush (fd=4, bp=0x808baa0) at utilities.c:226
#12 0x08053c80 in ckfini (markclean=1) at utilities.c:281
#13 0x0804c3b3 in checkfilesys (filesys=0xbfbff9b9 "/dev/ad2s1a",
mntpt=0x0, auxdata=0, child=0) at main.c:339
#14 0x0804bc1d in main (argc=0, argv=0xbfbff8d4) at main.c:148
Hope this helps a bit more.
Regards,
Antonio Huete
Updated by tuxillo about 16 years ago
There must be some kind of permission issue, because this problem goes away by
running QEMU-KVM as root
Updated by tuxillo about 16 years ago
The problem was on the host (Linux) and not in the guest (DF). It seems that
although running QEMU-KVM with a user in kvm group, there are some problems
accessing the disk images (or something else). This is solved by running
QEMU-KVM as root.