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!
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