On Wed, Oct 22, 2014 at 10:31:45PM +0200, Torbjörn Granlund wrote: > Aurelien Jarno <aurel...@aurel32.net> writes: > > On Fri, Oct 17, 2014 at 08:57:38PM +0200, Torbjörn Granlund wrote: > > Aurelien Jarno <aurel...@aurel32.net> 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 aurel...@aurel32.net http://www.aurel32.net
