ROS testing on real hardware

[Webunny]

Was a while before I could fire up the old, former hardware I described here (http://www.reactos.org/forum/viewtopic.php?f=2&t=11189) on which I successfully tested 3.14, but I finally managed it.

Alas, I have bad news; while it was one of the few machines that actually successfully managed to run ROS 3.14, when I now test it with 3.15 (trunk 61142) it DOES NOT work anymore. The first time, I got a BSOD, and the second time, it just 'hangs' when the window appears 'Installing Devices'. It's exactly the same configuration as I described in my earlier test (see link), so I think it has somehow incurred a regression, at least in this real-life hardware test.

I must say, it's a bit of a disillusion for me; I was looking forward to the progress being made, but something must have happened that it now does not run anymore, while it use to run fine on it with the 3.14 branch...

[EmuandCo]

Some Debug -> Screen photos could help us to fix it. Or Debug over Serial Port ^^

[Webunny]

Some Debug -> Screen photos could help us to fix it. Or Debug over Serial Port ^^

Screen photos? Well, obviously printscreen doesn't work neither. But maybe you meant with a third-party device? I'll see if I can do that. As far as debugging over Serial port is concerned; I think somebody talked about that when I was testing 3.14 too, but I never got around to it. It wasn't as simple to do it neither, as I recall. (you'd need the right cable and another box, no?)

When I get a BSOD (mostly when I'm moving my mouse when the window 'Installing Devices' appear), I get this:

*** STOP: 0x0000001E (0xc0000005, 0xF715A007, 0xF739881C, 0x00000000)

*** cmipci.sys - Address F71A007 base at F715A000, Datestamp 52980dbb

Does that help?

Edit: does anyone else experience difficulties on real hardware testing with the latest trunk/build?

[Webunny]

Holy baloney!

I just downloaded the iso of the 3.15 original release candidate, burned it, and installed it...and that one works!! Well...it got passed the 'Installing devices' at least. The first time, it sort of got stuck later on, while showing the window 'registering'. It didn't freeze up, though (mouse still worked), but it sat there for ages, doing nothing.

However, I recalled from earlier testing, where I had a similar problem, that maybe I shouldn't have localised it with my language, keyboardlayout and time. So the second time, I went with the default US setting. And lo and behold, now it went through, and everything works. (apart from the automatic driver instalments, which didn't amount to any succes. Which is strange, in fact, since I recall that at least my ethernetcard worked and was supported; wasn't that driver added to the 3.15, so it could auto-install it correctly?

But anyway: since that one works, and the latest in trunk doesn't (61142 borks on my real HW), it DOES seem indeed that there is some kind of regression.



Edit: Further testing; driver for ethernetcard (realtek RTL8139C) does not seem to auto-install, even though it's supposed to be a supported card (and I got it to work in the 3.14 testing). I tried to download it, place it on usb and via that way get it on ROS, but it seems ROS, even in the 3.15 version, does not recognise USB.

Tried it to place it on a CD, but - apart from being unstable and sometimes recognising there is a CD-RW in it, and other times not, it had some difficulties finding stuff that wasn't explicitly burned onto it, and even then the instalment of the realtec drivers didn't go as planned.I had an exe which installed it, and that seemed to work as it should, but even after a reboot, I still don't get netwerkconnection. And...it STILL does not seem possible to reinstall a driver?? When I go to 'system', 'hardware', in Windows, you have the possibility to reinstall, but not in ROS. You can't even delete it, and then do a successful search for new hardware, as one can in Windows. I've noted this before, and I repeat this is a seriously annoying thing for real hardware-testing. And it only needs a trivial (for a coder) amount in recoding this; one just has to provide a button that re-enacts the window you get when first installing ROS, where it DOES ask for (to search for) a driver. So it doesn't need some grand recoding, just something that relaunches that particular code (which already exists in ROS). Can't a developer *please* look at this? Pretty please?

Also: tried out FF12; still borks, just as in 3.14. Tried out installing FF3.6; still works, just as with 3.14.

Anyway, it seems, if I want netwerkconnection, I *still* have to do it the long and tedious way of reinstalling ROS, and then search for the right driver that I now burned on a disc when ROS starts up for the first time. It's *really* annoying to have to do a complete reinstall everytime you want to test out a driver on real HW, guys.



Edit2:re-installed ROS, manually selected the driver from my CD, reinstalled FF3.6, and... it worked! Have networkconnection. Installed old version of standalone flash (otherwise, FF didn't perform all to well when visualising things) Started up FF again, and am currently downloading Ur-Quan masters (though this time the HD version), to redo the exact things I tested with 3.14.

[oldman]

I have been testing Ros in real hardware for years. And I am currently running Rev 61103 and I have had no problems installing it. So that should narrow down the search for the regression.
The Search for New Hardware has never worked for me, whenever I have tried it.
In recent revision, my 'hp' usb stick is found and is accessible, but I have not yet tried it with this revision.

[hbelusca]

As far as I could see until now, ReactOS' USB works on some PCs and don't on some others....

[EmuandCo]

cmipci.sys is from a installed audio driver I guess?
Seems like thats your problem.

[Webunny]

cmipci.sys is from a installed audio driver I guess?
Seems like thats your problem.

I think the problem rather is that there ISN'T any audio driver installed (at least, when trying to get UQM to run, which succeeded in 3.14, but not now).

Anyway, it has little to do with the instalment of ROS itself, I think. And even then: why wouldn't it be a problem for the original 3.15, but it is with the latest (when I started the topic) build?

Edit: I finally managed to get another driver working on ROS (cmedia), and now it has sound, and the error when starting up UQM has gone too. Doesn't seem all that stable (the second time I clicked on it, it still gave me the error, but after a restart it seems to be doing ok). SO I guess it's at about the same level as 3.14 (from the perspective of testing applications on real hardware). I don't see a notable improvement nor a degression (apart from the fact the daily build yesterday which DID borked on me; I'm talking about the original 3.15 here, thus). Ofcourse, I'm not talking about improvements under the hood - which I assume are plentiful - just from the stance of comparing which applications worked and which not, on real HW.


The major obstacle to get anything worthwhile out of it, is the driver issue, me thinks. I know there are some licensing issues with some, but can't we port some over from linux, and implement them by default when ROS starts up and asks for it (the auto-search never amounts to anything, as it is now). I know we can't put in ALL drivers, but what about, say, the ten most commonly used ethernetcard-drivers, and the ten most commonly used sounddrivers? With that alone, one could already drastically improve the overall userfriendliness for endusers, me thinks.

[milon]

Try with a recent build. There's been some good changes lately, including driver installation ability (see the change log). If you don't want to burn a CD, you can try it from USB (keep your fingers crossed!): http://www.reactos.org/wiki/LiveUSB

[Webunny]

Try with a recent build. There's been some good changes lately, including driver installation ability (see the change log). If you don't want to burn a CD, you can try it from USB (keep your fingers crossed!): http://www.reactos.org/wiki/LiveUSB

You mean since the build of yesterday? Because I tried that one, and my system borked on it.

And with the 3.15 I have now, usb does not seem to work.

Edit: tried the latest build (61156), with the supposed driver-support, but...it borked again. It can't reach that far, even. As with the former daily build I tried (61142); I get the exact same error as I've described earlier (see above). Searching devices, and than it borks.

The original 3.15 worked perfectly (well...), though, so it must be something that happened in between.

Edit2: Well, I have been going on with further testing. IMPORTANT!

Since it's real HW testing, and I don't have serial or anything, there is no way to get a decent bug-output. Therefore some helpful person in irc has helped me, nay, gently pushed me to test, and test, and test one build after another. going from 61156 to 60000 to 59444 to 59333, etc. Now, according to him, the 3.15 install download was (based of) 59303. But since I was already down to 59333, I found that a bit strange, so I actually tried 59303 out, and...it borked. Like all the rest.

Was it a fluke? A sign of god? The hand of the devil?

Who knows, but then I reinstalled the original 3.15 back and IT STILL WORKED. It got passed the 'searching devices', just as it used to, so that one clearly worked, while even the 59303 didn't!

Now, I was told something about how it's the same, but yet not, etc. I'll quote: " yes, the iso 59303 you download from the getbuilds is not 0.3.15 strictly speaking: it's a build of trunk revision 59303, whereas the 0.3.15 official download is the one in the branch which was tagged in revision 59303."

So a trunk-branch thingy, where the difference lays. If people can already guess where, or something, that would help. (because I'll not be able to test for a while any further tomorrow).

And note to self: if no-one suggests something better, I have to go for build 58487, apparently.


Needless to say, though, this kind of testing is rather demanding and not efficient. Been busy hours with d/l, burning and installing build after build. If it weren't so annoying since I can't use any daily builds anymore...

anyway, this concludes the testing for now.

[oldman]

Post by Webunny » 30 Nov 2013
Now, according to him, the 3.15 install download was (based of) 59303. But since I was already down to 59333, I found that a bit fishy, so I actually tried 59303 out, and...it borked. Like all the rest.
............................
Who knows, but then I reinstalled the original 3.15 back and IT STILL WORKED. It got passed the 'searching devices', just as it used to, so that one clearly worked, while even the 59303 didn't!

Webunny, I don't know if you are aware, but, when they branch trunk for a release, they do a lot of bug fixing before they make the release. So I would guess that the bug in R59303 which stops you from installing it, was fixed for the release of 3.15.

[Webunny]

Post by Webunny » 30 Nov 2013
Now, according to him, the 3.15 install download was (based of) 59303. But since I was already down to 59333, I found that a bit fishy, so I actually tried 59303 out, and...it borked. Like all the rest.
............................
Who knows, but then I reinstalled the original 3.15 back and IT STILL WORKED. It got passed the 'searching devices', just as it used to, so that one clearly worked, while even the 59303 didn't!

Webunny, I don't know if you are aware, but, when they branch trunk for a release, they do a lot of bug fixing before they make the release. So I would guess that the bug in R59303 which stops you from installing it, was fixed for the release of 3.15.

Ok, I'll give an oversight of the regression, pinpointing the range.

Build:

61142: borked
0.3.15-REL: worked
61156: borked
60192: borked
60000: borked
59444: borked
59333: borked

At that point, I started to have doubts that the 59303 build (which the 3.15 was based on), would be any good either, so:

59303: borked

Thus, the trunk vs branch thingy.

Retried the original 3.15, to make sure it wasn't a fluke:

0.3.15-REL: worked

Then, continuing:

59222: borked
58488: worked

This gave me the first range; between 58488 and 59222. Still a long way to go!

58888: borked
58666: borked
58554: worked

New range: 58554 - 58666

58600: worked
58619: borked, but with something entirely else as usual. It didn't gave a typical bsod, rather it went "importing binary hive failed".

At that point, some flashdude on irc suggested that that could be just a bad build, unrelated to the issue. The same person also noted my day(s)-long regression-search for the first time, apparently, AND he looked at my BSOD here, AND he found out what it was about, and where the probable cause lays, namely in build 58644. It was modified by jgardou;

[CMIDriver]
* Update the C-Media 8738/8768 driver to 1.2.6
* Add it to build

Man...I wish someone else (or flash) could have pointed or looked at this a bit sooner - would have saved me hours/days. But anyway, I'm glad that a probable cause was found.

Now, to be sure, I'll check further.

Edit:

58643: worked
58644:.....worked

(!???)

Seems it wasn't that, after all.

New range: 58644 - 58666

But it's getting REAAAALLYYY late, so further testing is going to have to wait.


If any other person has any good idea where the fault/regression may be, lemme now.

Edit2:

Ok, continuing.

First an update: after I tried that latest build out, Theflash noted something else:

Namely that 58644 changed nothing due to:


[CMAKE]
* Fix an embarrassing mistake.


Thus, because of the "embarrassing mistake" by jgardou one could expect things to NOT go as assumed (aka, that the build would bork on that issue). Seems the UNIX build of 58645 was also broken. Then it was suggested to try 58645, but there was no iso file of that. According to Flash, one should go to 58652 then (quite far, but it doesn't matter since there were no changes to CMIDriver).

So, currently, I'm trying this out.

58652:...borked

As expected. So I think we can safely assume it is, indeed, due to the changes made by jgardou on the CMIDriver on build 58652. (Or at least between 58644 and 58652.)

[hbelusca]

Ok, let's clarify the story a bit:

The 0.3.15 branch was created in revision 58636 (in a humoristic way by Ziliang, see: http://svn.reactos.org/svn/reactos?view ... sion=58636 )
Then, some fixes from the trunk were added: see the 0.3.15 branch log here: http://svn.reactos.org/svn/reactos/bran ... hrev=59302

Now, the question is: what was added in the meantime that made ReactOS BSOD in your PC.

According to the CMIDriver commit of Jérôme: yes this revision range 58644-58657 looks suspicious, in the sense that after the commit of 58644 that added/updated the CMI lib, files were not compiled hence their adding into the CMakeLists.txt file in revision 58645. This triggered build problems (since now those files were built!) that were fixed one after the other in the subsequent revisions, until 58652. After, the revision 58653 fixes the warning levels fix of revision 58652, and then revisions 58654 to 58657 compensate each other (the author thought that he needed to fix something, but in fact it was already fixed so that he reverted in revision N+1 what he committed in revision N).

To conclude, I (and others) strongly suspect that this update of the CMIDriver introduced a bug which was revealed only in your HW configuration.
Try to get in touch with Jérôme when he'll appear on IRC.

[Webunny]

Bsod with latest build (61208):




Bit unclear, so:


*** STOP: 0x0000001E (0xc0000005, 0xF72C8007, 0xF737481c, 0x00000000)


*** cmipci.sys - Address F72C8007 base at F72C8000, Datestamp 529dc5bb

[EmuandCo]

Maybe you should photograph the hang with active "Debug to screen" @ boot loader