[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Crashes of qemu-system-mips64 and qemu-system-mips64el
From: |
Aurelien Jarno |
Subject: |
Re: [Qemu-devel] Crashes of qemu-system-mips64 and qemu-system-mips64el |
Date: |
Thu, 23 Oct 2014 00:07:00 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Wed, Oct 22, 2014 at 10:31:45PM +0200, Torbjörn Granlund wrote:
> Aurelien Jarno <address@hidden> writes:
>
> On Fri, Oct 17, 2014 at 08:57:38PM +0200, Torbjörn Granlund wrote:
> > Aurelien Jarno <address@hidden> writes:
> >
> > I am using 2.1.2 under GNU/Linux.
> >
> > Ah, so you're not trying to reproduce the problem!
>
> I do. Well you talked about 2.1.0, the latest stable one is 2.1.2. Now
> if you prefer, we can conclude the problem is solved in 2.1.2.
>
> > Are you passing the -cpu 5Kc argument?
>
> I used:
>
> qemu-system-mips64 -M malta -cpu 5Kc -m 256 \
> -drive file=disk.img,if=virtio,index=0 \
> -net nic,macaddr=52:54:00:13:06:64 -net user,hostfwd=tcp::20008-:22 \
> -kernel boot/vmlinux-3.2.0-4-5kc-malta \
> -initrd boot/initrd.img-3.2.0-4-5kc-malta \
> -append "root=/dev/vda1 console=ttyS0" \
> -nographic -serial null -monitor null
>
> And it's still running the testsuite in a loop.
>
> > I don't think it's irrelevant, that's why I asked. If you don't provide
> > this information, we won't be able to check which code paths are
> > involved
> >
> > Given you are the only one to reproduce the issue, please provide a
> > backtrace of a crash so that we can proceed further.
> >
> > Really? Has anybody tried to reproduce the issue?
>
> At least me, and it doesn't crash here.
>
> > My bug report contains all information for trivially reproducing the
> > issue. I kept the setup around for a long time, but now I have cleaned
>
> Yes, but it doesn't mean it's reproducible.
>
> > it up. I am very busy in this period and cannot afford to set it up
> > again, also considering that the effort on the developer part seems very
> > very limited wrt reported problems. (I am not complaining, I have no
> > opinion on how volunteer hackers use their time!)
>
> Ok fine, let's consider the issue fixed.
>
> You won't like me saying this, but this is not how professional software
> development is done. It is also discouraging to see a detailed bug
> report being treated in such a dismissive manner.
>
> Here is an alternative approach:
Ok, let's do it.
> 1. Is the bug report complete? If not, ask for more information (or
> perhaps chose to ignore it if you conclude it is bogus).
You refused to provide the information I asked.
> 2. Try to reproduce the problem using the information in the bug report.
> This means that you set up an environment as close as possible in all
> relevant aspects. Clearly, do not use a different version of the
> software being investigated.
I later tried to reproduce it with version 2.1.0. I arrived to the same
conclusion that the bug is not reproducible.
> 3. Isolate the bug and fix it. As the reporter for feedback.
The bug is not reproducible, so that's not something possible.
> 4. Make some effort in finding similar bugs in the the software package.
>
> It is not safe to conclude that when a different version of the software
> seems to work, then the bug is gone. Why? There might be some mistake
> in reproducing the bug. There might be a relevant environment
> discrepancy. You might even be running the wrong binary by mistake, or
> use the wrong data file by mistake. (I have been in the game a long
> time now, and I have made all these mistakes at some point.)
In that case, please provide:
- The QEMU binary you have built.
- The image to reproduce the issue.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
address@hidden http://www.aurel32.net