Re: [Qemu-devel] x86, nops settings result in kernel crash

[Tomas Racek]

> On 20.08.2012 21:13, Tomas Racek wrote:
> []
> Can we trim the old, large and now not-so-relevant discussion please?
> ;)
> 
> > I can provide you with more different traces if it can help. But I
> > thought that maybe it will be more useful for you to try it on
> > your own. So I've prepared some minimal debian installation which
> > you could download here (apx 163M bzipped):
> > 
> > http://fi.muni.cz/~xracek/debian.img.bz2
> > 
> > Password:
> > root/asdfgh
> > 
> > Here is my config for guest kernel:
> > 
> > http://fi.muni.cz/~xracek/config
> > 
> > I use
> > 
> > qemu-kvm -m 1500 -hda debian.img -kernel
> > linux/arch/x86/boot/bzImage -append "root=/dev/sda1"
> 
> Um.  I'd expect the image to be self-contained, no external kernel.
> I wanted to do a quick test to see if it fails on my machine too,
> d/loaded debian.img.bz2 but there's no kernel.  So.. no quick test
> for you ;)

Well, the point was to use the latest sources instead of some image which can be obsolete tomorrow. However I created a new image with today's kernel which you can use:

http://fi.muni.cz/~xracek/debian2.img.bz2

Other things are the same.

The runtest.sh sets environment for xfstests and runs test 285 which I wrote and and which should test if FS sends discard requests only on free sectors:
285:
1. Create loop device and FS on it.
2. Populate it with some garbage.
3. Get free sectors from FS.
4. Run fstrim and look for discard requests via blk tracer.
5. Compare free sectors to discard requests.

The test itself can have some issues but I'm pretty sure it shouldn't crash the system. ;-)

Regards,
Tom

> 
> > After logging in just run "sh runtest.sh". This leads to crash in
> > my case (host: Intel Core i5-2540M, kernel 3.5.2-1.fc17.x86_64,
> > qemu 1.0.1).
> 
> With all the above, this "runtest.sh" is informationally equal to
> your disk image.
> 
> /mjt
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/