Project

General

Profile

Actions

Bug #1117

closed

fsck coredumps under QEMU-KVM

Added by ahuete.devel over 15 years ago. Updated over 15 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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

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

Updated by ahuete.devel over 15 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

Actions #2

Updated by tuxillo over 15 years ago

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

Actions #3

Updated by tuxillo over 15 years ago

This can be closed.

Actions #4

Updated by corecode over 15 years ago

What's the cause/solution?

cheers
simon

Actions #5

Updated by tuxillo over 15 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.

Actions

Also available in: Atom PDF