Bugs item #2067179, was opened at 2008-08-22 12:25 Message generated for change (Comment added) made by jessorensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2067179&group_id=180599
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Truschnigg (c0l0) Assigned to: Nobody/Anonymous (nobody) Summary: Possible Bug in ATA Emulation Code Initial Comment: CPU: Intel Core 2 Quad Q6600 (4 cores) Distro, kernel: Gentoo GNU/Linux ~amd64, Kernel 2.6.26.3 Bitness, compiler: x86_64, GCC 4.3.1 KVM versions: kvm-72 Before going on vacation, I decided to stress-test a KVM Guest running Ubuntu 8.04.1 (x86) on my Gentoo x86_84 host - it ran the `stress`-program ( http://weather.ou.edu/~apw/projects/stress ) with all hardware components tested for about 10 days. After 178338 seconds of guest-uptime, something in the emulated disk subsystem bombed: [178338.511058] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen [178338.511080] ata1.00: cmd 35/00:00:9f:96:0d/00:04:01:00:00/e0 tag 0 dma 524288 out [178338.511082] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [178338.511085] ata1.00: status: { DRDY } [178343.540203] ata1: port is slow to respond, please be patient (Status 0xd8) [178348.513648] ata1: device not ready (errno=-16), forcing hardreset [178348.513655] ata1: soft resetting link [178348.670875] ata1.00: configured for MWDMA2 [178348.670889] ata1: EH complete The full guest dmesg output is available at http://pasted.at/e548758180.html and as an attachment to this report. This problem lead to the guest OS remounting the filesystem residing on the disk/partition in question read-only, and `stress` killing itself - it did not crash the system completely. The filesystem on the host storing the RAW image containing the guest-OS was perfectly OK when the error occurred. The host's dmesg output remained unchanged all the time, with no errors or info regarding kvm (or anything else, for that matter) whatsoever reported. ---------------------------------------------------------------------- >Comment By: Jes Sorensen (jessorensen) Date: 2010-08-19 12:29 Message: Hi, Going through old bugs trying to clean up the queue. Are you still seeing this problem with recent KVM or can we close the bug? Thanks, Jes ---------------------------------------------------------------------- Comment By: Peter A. Peterson II (unclepedro) Date: 2009-02-05 01:41 Message: I just had a very similar issue, and it turned out that I did not have write permission on the image file (because I had copied it from a different UID). I fixed the permissions on the image, fully restarted qemu (this was critical), and then it worked. HTH. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2067179&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
