Bug #1117

fsck coredumps under QEMU-KVM

Added by ahuete.devel almost 6 years ago. Updated almost 6 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:tuxillo% Done:

0%

Category:-
Target version:-

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

fsck.core.gz (13.4 KB) ahuete.devel, 08/11/2008 01:04 PM

History

#1 Updated by ahuete.devel almost 6 years ago

I have noticed that the coredump only occurs if I interrupt the process
(by Ctrl+C):

virtualdragon# ./fsck -f -y /dev/ad2s1a
** /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

#2 Updated by tuxillo almost 6 years ago

There must be some kind of permission issue, because this problem goes away by
running QEMU-KVM as root

#3 Updated by tuxillo almost 6 years ago

This can be closed.

#4 Updated by corecode almost 6 years ago

What's the cause/solution?

cheers
simon

#5 Updated by tuxillo almost 6 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.

Also available in: Atom PDF