Re: [ros-general] ReactOS BSOD / Freeze on large data transfers (and CPU load?)

[Michael Lackner]

Greetings!

I'm having some trouble with my eMail client, it seems the digest mode of the mailing
list confuses it somehow, so I'll quote this part manually, sorry for that. I
switched
digest off now, hopefully the list will now deliver your eMails individually. :)

Copying my test file to ReactOS is not that problematic, I can just boot Knoppix in the
same VM, mount the ReactOS FAT32 filesystem, mount an external USB stick or something
and copy it over, reboot to ReactOS, problem solved.

But generally it would be nice to have stable FTP (or HTTP or SCP) transfers in ReactOS,
so I kept trying different programs etc. I thought that this is such a basic thing that
it just has to work! But yeah, BSOD every time. File size btw. is 668MBytes.

Now the second thing is, I would like to run x264 (a H.264/AVC video encoder linked
against the libav codec library for decoding) to transcode a video stream (that 668MB
file).

That part works for a few minutes and then crashes.

If it helps I can generate logs, maybe you could tell me what exactly I could do that
helps you.

About that VMware Player configuration I just noticed that I gave you wrong info. I was
indeed using the original setting set up by the 0.3.14 VMware image that I had
downloaded. The vmx/vmxf configuration files are attached to this eMail, here are some
settings beforehand:

* Mem: 512MB
* CPUs: 1
* HDD: 8GB
* USB: Present
* Display: Autodetect
* OS Type: XP Pro

I just tried it again a few times, and build #57337 boots into BSOD every single time
using those settings on VMware Player "4.0.1 build-528992". Host OS is CentOS
6.3 Linux
x86_64 in case it matters..

So if you require any specific tests or anything, just let me know. :) I might not be
able to test on weekends though, as the machine I am testing on might not be available
on weekends.

Thanks!

-Michael

>   Hi Michael!
>  Well...We can try several tricks to make it work :)
>  If your main objective is to "copy" the File into ReactOS, then the best option
> is to
>  "Mount" the Virtual HardDisk of your VirtualMachine. Mounting will let you
> place the
>  file inside ReactOS without issues and from your host OS.Then when booting ReactOS you
>  will see the file inside "magically".
>
>  If your main objective is to test the MM and overall ReactOS behavior in Vmware then
>  thanks a lot, because your help could be really really helpful. :)
>  I've to say that lately ReactOS has improved a lot its stability under Vbox but
> seems
>  it didn't do the same under Vmware as your tests shows.
>  It would be really nice if you can share which is your Virtual Machine
>  configuration(Ram, HDD, etc) so maybe we can try to replicate the issue to find
>  something useful in the logs.
>  Or maybe you can create useful Logs for us :) 
>   I have tried Filezilla under VBOX and seems to
> fail.Reason under this line:
>  (Trace cut out)
>
>  If this didnt happen in 0.3.14 then we are in front of a regression. Nice catch!
>  We can try to find the guilty commit via Binary Search.
>  Thanks a lot! 
-- 
Michael Lackner
Lehrstuhl für Informationstechnologie (CiT)
Montanuniversität Leoben
Tel.: [phone] | Mail: michael.lackner(a)unileoben.ac.at
Fax.: [phone] | Web: http://institute.unileoben.ac.at/infotech

[Michael Lackner]

Good morning!

I would like to comment on this issue again, because to my surprise there seem
to have been some significant changes about the problems I was having.

I downloaded another trunk build yesterday to retry my stuff, and this time
several things worked, that would previously cause bluescreens. The test was
to download a ~690MB file from the internet using either ftp.exe on the
commandline or FileZilla2 (both with and without Implicit AND Explicit SSL),
bug was always triggered.

Additionally, I also ran the x264 video transcoder, statically linked against
libav libraries. This thing runs CPU- and memory-intensive computation using
several CPU instruction extensions when present (SSE, SSE2, SSSE3, SSE4.1,
SSE4.2, AVX, FMA4 etc.).

Tested builds:

* 0.3.14 -> NTOSKRNL.EXE BSOD on data transfer and crunching.
* r57415 -> NTOSKRNL.EXE BSOD on data transfer and crunching.
* r57452 -> tcpip.sys BSOD on data transfer, NTOSKRNL.EXE BSOD on crunching.
* r57481 -> everything works!

For those builds which would cause BSOD when tested with x264, the BSOD would
usually arrive around 200-400 completed video frames (out of 15691 which are
processed twice). This time, I completed an entire run of encoding pass 1 + 2,
which took around 8 hours (i7 980X), and I am now running another one, which
also does not seem to cause any problems!!

See here (german version, shouldn't matter):

http://www.xin.at/x264/pics/guide_screenshot_reactos.png

I studied the changelogs since the last version, but I didn't see anything
big that would have said "fix tcpip.sys" or "fix LOTS of bluescreens",
but...

WHATEVER you guys (developers) did, it really, really helped in my case!

Thanks for that!

-- 
Michael Lackner
Lehrstuhl für Informationstechnologie (CiT)
Montanuniversität Leoben
Tel.: [phone] | Mail: michael.lackner(a)unileoben.ac.at
Fax.: [phone] | Web: http://institute.unileoben.ac.at/infotech