ROS testing on real hardware

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

oldman
Posts: 1072
Joined: Sun Dec 20, 2009 1:23 pm

Re: ROS testing on real hardware

Post by oldman » Sun Dec 22, 2013 12:16 pm

Very good Webunny, but if it is going to be useful to the dev's (as Z98 suggested), there needs to be more info, such as, Bios version and company, motherboard chipset and chips used in sound cards, Ethernet cards.
Please keep the Windows classic (9x/2000) look and feel.
The layman's guides to - debugging - bug reporting - compiling - with some complementary scripts.
They may help you with a problem, so do have a look at them.

fred02
Posts: 551
Joined: Thu Nov 22, 2007 5:54 pm

Re: ROS testing on real hardware

Post by fred02 » Sun Dec 22, 2013 6:40 pm

oldman wrote:Bios version and company, motherboard chipset and chips used in sound cards, Ethernet cards.
Second that, and the same for the video card and its memory.
I would also add direct link to the ROS ISO file used for testing. Mere convenience, but will save a needless clicks when someone wants to replicate the bug. And links to the eventual Jira bug reports too.
(Shouldn't we continue this discussion on the talk page of the wiki?)

P.S. Ah, and also add eventual additional drivers used with links to the sources, of course.

Webunny
Posts: 1201
Joined: Sat Apr 28, 2012 1:30 pm

Re: ROS testing on real hardware

Post by Webunny » Sun Dec 22, 2013 7:34 pm

oldman wrote:Very good Webunny, but if it is going to be useful to the dev's (as Z98 suggested), there needs to be more info, such as, Bios version and company, motherboard chipset and chips used in sound cards, Ethernet cards.
Well...it's a balance between having some useful info and making it into a soup of myriads of different variants of the sam thing. I guess ethernetcards could be added, but one has to draw the line somewhere. Are there any examples known where *the same* motherboard exists with a different chipset where one works and the other doesn't? Or when the exact same videocard with 32 MB works, but with 64 Mb doesn't? I think the chances are pretty minute.

Normally, when it works for one class (a cmedia 8738 soundcard for instance) will work for the whole class. It comes as no surprise then, that my 8738-C3DX version also works, because the 8738 as a whole is supported. The same goes for most things that can use generic drivers. It's not that I'm principally against it, but sometimes the usefulness of making an extended list of things and variants isn't that great. I already had a bit doubts with point 2, for instance. Are there any cases where a rig with ROS works with 512 RAM, but not with 1 GB ram, for instance? (below a certain threshold I could imagine, but more ram, if the ram is good, hardly ever leads to suddenly it not working anymore. At least, I've never seen such a thing with ROS testing anywhere.)

Maybe I could make a general point for additional info for those that really want to add to it, but some of it hardly seems worth the clutter.

The ethernetcard and the bios...well, if the devs think it's really wortwhile to have that info, I could make seperate points of it. The rest I would do with a general point (or maybe placing it with 7)comments?)

fred02
Posts: 551
Joined: Thu Nov 22, 2007 5:54 pm

Re: ROS testing on real hardware

Post by fred02 » Sun Dec 22, 2013 9:10 pm

Webunny wrote: Well...it's a balance between having some useful info and making it into a soup of myriads of different variants of the sam thing. I guess ethernetcards could be added, but one has to draw the line somewhere. Are there any examples known where *the same* motherboard exists with a different chipset where one works and the other doesn't? Or when the exact same videocard with 32 MB works, but with 64 Mb doesn't? I think the chances are pretty minute.
Normally, when it works for one class (a cmedia 8738 soundcard for instance) will work for the whole class. It comes as no surprise then, that my 8738-C3DX version also works, because the 8738 as a whole is supported.
"The devil is in the detail." Back in the Athlon and KT133 chipset era, there were motherboards that would support the newer 133MHz CPU bus if there was a . (dot) at the end of the of the PCB revision. Just a dot, all the other numbers/letters identical. :shock: :!:
Webunny wrote:I already had a bit doubts with point 2, for instance. Are there any cases where a rig with ROS works with 512 RAM, but not with 1 GB ram, for instance? (below a certain threshold I could imagine, but more ram, if the ram is good, hardly ever leads to suddenly it not working anymore. At least, I've never seen such a thing with ROS testing anywhere.)
You have seen it. ;) Granted, the bug could not be reliably replicated, but something was fishy. (We can speculate on many more or less plausible "theories" as to why it would stop working with more memory, but considering the fragile state of the current ROS MM should be enough. Same goes for a potential race condition on a faster CPU/bus, i.e. works on P4 1500 but not 3000).
Webunny wrote:Maybe I could make a general point for additional info for those that really want to add to it, but some of it hardly seems worth the clutter.
I think that right now the "formular" is sparse enough, so it can support additional info. I gave a shoot with your config (to the best of my understanding of course):
1) Intel Pentium 4 (shouldn't it be "generic/custom-build PC"? As opposed to some specific manufacturer model?)
2) P4@1,8Ghz(400MHz FSB) potentially an sSpec/id string from Intel CPU id/CPU-Z;
3) Aopen mx4bs (82845/82801BA) 512 Mb RAM (SD or DDR, 1 or 2 modules, which sizes?);
4) NVIDIA Vanta (NV6) AGP 16 MB SDRAM card using build-in SVGA driver
5) CMedia 8738-C3DX soundcard using build-in driver
6) HDD (manufacturer, model?) 40 GB;
7) Network: n/a;
6) REL 0.3.15
Webunny wrote:The ethernetcard and the bios...well, if the devs think it's really wortwhile to have that info, I could make seperate points of it. The rest I would do with a general point (or maybe placing it with 7)comments?)
The more unstructured data you have, the harder it will be to extract it later to put in the database, for one thing.

Also, initially I don't expect more than a douzen hardware testers, so there won't be that much information clutter. And since each one will not test more than 2-3 configs (most likely one), they can afford to spend 5-10 more minutes to have it written down really detailed. Finally, if wiki page space is really such a problem, the detailed info can be put on separate pages in the wiki/forum user profile and linked there. It can then be called simply "Webunny's test rig #1"(2, 3, etc.), but then one will have to click more links to know what hardware was working, and this is counterproductive.
Last edited by fred02 on Sun Dec 22, 2013 9:58 pm, edited 1 time in total.

Webunny
Posts: 1201
Joined: Sat Apr 28, 2012 1:30 pm

Re: ROS testing on real hardware

Post by Webunny » Sun Dec 22, 2013 9:50 pm

fred02 wrote:
Webunny wrote: Well...it's a balance between having some useful info and making it into a soup of myriads of different variants of the same thing. I guess ethernetcards could be added, but one has to draw the line somewhere. Are there any examples known where *the same* motherboard exists with a different chipset where one works and the other doesn't? Or when the exact same videocard with 32 MB works, but with 64 Mb doesn't? I think the chances are pretty minute.
Normally, when it works for one class (a cmedia 8738 soundcard for instance) will work for the whole class. It comes as no surprise then, that my 8738-C3DX version also works, because the 8738 as a whole is supported.
"The devil is in the detail." Back in the Athlon and KT133 chipset era, there were motherboards that would support the newer 133MHz CPU bus if there was a . (dot) at the end of the of the PCB revision. Just a dot, all the other numbers/letters identical. :shock: :!:
I'm not saying it's impossible that it makes a difference, but how many times does it happen, as opposed to the main components (like the motherboard)?
Webunny wrote:I already had a bit doubts with point 2, for instance. Are there any cases where a rig with ROS works with 512 RAM, but not with 1 GB ram, for instance? (below a certain threshold I could imagine, but more ram, if the ram is good, hardly ever leads to suddenly it not working anymore. At least, I've never seen such a thing with ROS testing anywhere.)
You have seen it. ;) Granted, the bug could not be reliably replicated, but "something was fishy". (We can speculate on many more or less plausible "theories" as to why it would stop working with more memory, but considering the fragile state of the current ROS MM should be enough. Same goes for a potential race condition on a faster CPU/bus, i.e. works on P4 1500 but not 3000).
That was VM testing though, not real hardware testing. Did anyone actually test that out in real hardware to see if it worked on 256 Mb but not with 512 Mb?

Ah well, I guess one can keep mentioning the MB RAM, it's not that much of a hassle, and it IS traditionally mentioned when describing a rig. Personally, I doubt it makes much difference (as a show-stopper or not), and the less so the further ROS evolves. There are few cases where windows doesn't work on a PC because there is more RAM (within reason), when the RAM is good and placed as it should. The more ROS gets binary compatible, the less likely it is to be of importance. But, well, as said I guess we can keep it.
Webunny wrote:Maybe I could make a general point for additional info for those that really want to add to it, but some of it hardly seems worth the clutter.
I think that right now the "formular" is sparse enough, so it can support additional info. I gave a shoot with your config (to the best of my understanding of course):
1) Intel Pentium 4 (shouldn't it be "generic/custom-build PC"? As opposed to some specific manufacturer model?)
2) P4@1,8Ghz(400MHz FSB) potentially an sSpec/id string from Intel CPU id/CPU-Z;
3) Aopen mx4bs (82845/82801BA) 512 Mb RAM (SD or DDR, 1 or 2 modules, which sizes?);
4) NVIDIA Vanta (NV6) AGP 16 MB card SDRAM using build-in SVGA driver
5) CMedia 8738-C3DX soundcard using build-in driver
6) HDD (manufacturer, model?) 40 GB;
7) Network: n/a;
6) REL 0.3.15
Webunny wrote:The ethernetcard and the bios...well, if the devs think it's really wortwhile to have that info, I could make seperate points of it. The rest I would do with a general point (or maybe placing it with 7)comments?)
The more unstructured data you have, the harder it will be to extract it later to put in the database, for one thing.
Yes, well, you always have to foresee something that leaves things open when all the rest doesn't fit, or where you simple want to add some info that isn't well defined. So I would keep the comments, though, when (if ever) converting to a database, one can leave it out if one desires, of course.

Your list seems ok (even though I suspect you wanted to end with 8, and not with 6), but it already show some data that is superfluous (imho). For instance, you ask about chipset and SD RAM or DDR ram... but that specific motherboard only had one kind of chipset and could only use SDRAM.

It therefore intrinsically contains that info. Only, one might not know about it. But if you really wanted to incorporate all that info (and even far more), wouldn't it be better to just incorporate a link to the manual of it? Like:

3) Aopen mx4bs

For the rest I think your list is ok, and it didn't clutter with much additional points, so I haven't any real objections to it.
Last edited by Webunny on Mon Dec 23, 2013 12:16 am, edited 1 time in total.

fred02
Posts: 551
Joined: Thu Nov 22, 2007 5:54 pm

Re: ROS testing on real hardware

Post by fred02 » Sun Dec 22, 2013 10:41 pm

Webunny wrote:I'm not saying it's impossible that it makes a difference, but how many times does it happen, as opposed to the main components (like the motherboard)?
I agree with you, this is probably the most extreme case I have ever seen. What is more common is a big company using different components in the same model. I can't vouch for the MB/CPU, but definitely for different HDDs (probably not important) and NIC adapters (more important).
Webunny wrote:That was VM testing though, not real hardware testing. Did anyone actually test that out in real hardware to see if it worked on 256 Mb but not with 512 Mb?
There were not enough hardware testing reports yet to pinpoint it. :) (I also have a vague memory of may be another thread, where problems arise when using more memory in the VM, but I can't find it now.)
Webunny wrote: Personally, I doubt it makes much difference (as a showstopper or not), and the less so the further ROS evolves. There are few cases where windows doesn't work on a PC because there is more RAM (within reason), when the RAM is good and placed as it should. The more ROS gets binary compatible, the less likely it is to be of importance.
And I agree with you.
Webunny wrote:Yes, well, you always have to foresee something that leaves things open when all the rest doesn't fit, or where you simple want to ad some info that isn't well defined. So I would keep the comments, though, when (if ever) converting to a database, one can leave it out if one desires, of course.

You list seems ok (even though I suspect you wantd to end with 8, and not with 6),
Darn "copy-paste" :). I did it in a bit of a hurry, sorry. Also I did not mean to remove the comments. So yes, I agree with you, not everything can be systematised and they should be added.
Webunny wrote:but it already show some data that is superfluous (imho). For instance, you ask about chipset and SD RAM or DDR ram... but that motherboard only had one kind of chipset and could only use SDRAM.
845 is actually a good example, since it acceded both, and there were even some motherboards that had both types of slots. They could not be used at the same time tough.
Webunny wrote:It therefore intrinsically contains that info. Only, one might not know about it. But if you really wanted to incorporate all that info (and even far more), wouldn't it be better to just incorporate a link to the manual of it? Like:

3) Aopen mx4bs

For the rest I think your list is ok, and it didn't clutter with much additional points, so I haven't any real objections to it.
Yes, definitely add it, and also for the video/sound/network, if it is available. Still, having the most important information already on the page will be a time-saver.


Also, have you checked these threads?
Overview: ReactOS Testing on Real Hardware
Real Hardware Test on laptops

Webunny
Posts: 1201
Joined: Sat Apr 28, 2012 1:30 pm

Re: ROS testing on real hardware

Post by Webunny » Mon Dec 23, 2013 9:00 pm

Webunny wrote:
oldman wrote:
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.

:arrow: 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.

:arrow: 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.)
Update: At the request of Jerome I tested it again (build 61357). It seems that he found and fixed the bug that was plaguing my real HW test. I'm glad my hard work (and that of Jerome, obviously) paid off after all, even without a serial cable for debugging.

I set the bugtracker for this issue on 'solved', though I'm quite curious to know what the bug/fix was (in lay-mans' terms).

milon
Posts: 969
Joined: Sat Sep 05, 2009 9:26 pm

Re: ROS testing on real hardware

Post by milon » Mon Dec 23, 2013 9:27 pm

First of all, I think this is awesome. This is one solid way that non-dev's can contribute to ROS. I'd like to start using it right away (well, after the Holidays anyway).

I also suggest that we eventually switch to a sortable table since that will make it simpler to look for trends and find regression causes. Maybe something like this. Obviously, please continue to edit the Talk page until it contains what we need, like NIC cards.

hbelusca
Developer
Posts: 1128
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: ROS testing on real hardware

Post by hbelusca » Mon Dec 23, 2013 10:08 pm

Webunny wrote:I set the bugtracker for this issue on 'solved', though I'm quite curious to know what the bug/fix was (in lay-mans' terms).
The real bug:
" - Use correct calling convention for some callbacks" (http://svn.reactos.org/svn/reactos?view ... sion=61331)
Calling conventions describe how parameters are passed to functions and how they deal with them. If you give to a function parameters in another way it expects them, they can lead to unexpected bugs (and stack corruption for connoisseurs :) ).

ConductiveDielectric
Posts: 32
Joined: Thu Aug 01, 2013 6:39 am

Re: ROS testing on real hardware

Post by ConductiveDielectric » Mon Dec 30, 2013 11:20 pm

Toshiba Terca 8100: ReactOS LiveCD r61342 and r59380 dbg. The boot stops at this screen. After two 'cont' debugger commands, computer becomes unresponsive (falls into BSOD that does not get displayed?).
Image
ReactOS BootCD r61343 and r50000 dbg. The boot stops at blank screen (I'm not able to boot it in Screen mode) and the text-mode setup wizard is not displayed. The computer also becomes unresponsive after two 'cont' commands.

This is the log of the same moment from qemu, where ReactOS boots fine:
Image

Webunny
Posts: 1201
Joined: Sat Apr 28, 2012 1:30 pm

Re: ROS testing on real hardware

Post by Webunny » Tue Dec 31, 2013 2:18 am

milon wrote:First of all, I think this is awesome. This is one solid way that non-dev's can contribute to ROS. I'd like to start using it right away (well, after the Holidays anyway).

I also suggest that we eventually switch to a sortable table since that will make it simpler to look for trends and find regression causes. Maybe something like this. Obviously, please continue to edit the Talk page until it contains what we need, like NIC cards.
@milon: feel free to add your rig there as well

@oldman: I used your info you gave on this thread to put it there myself, but can you fill it in a bit further? Some people would like to see even far more, but I think the info I put there is the bare minimum, and some things are lacking in your info. As for those who want to have even more: I would suggest one can put it under one of these topics, or the comments-section as a direct link to the manual/build/etc. at ones' own leisure. That way, people who want to take the minimal approach can do so, and those who want to provide even more detailed info can as well.

@the two people that tested a laptop with ROS; I've put your info there too, but as with oldman, feel free to fill in the blanks (well, the '??' actually ;-) ); especially the buildnumber - I couldn't find it in that thread.

@ConductiveDielectric: feel free to put your info there too. We're talking about this: https://www.reactos.org/wiki/PC_ROS_Rigs

oldman
Posts: 1072
Joined: Sun Dec 20, 2009 1:23 pm

Re: ROS testing on real hardware

Post by oldman » Tue Dec 31, 2013 10:22 am

I have added my main test computer to the list. Webunny could you check to see if everything is OK, as this is the first time I have ever edited a wiki. I thought that the columns had squashed inwards after that I had saved the page!

I see that all but my main test computer have Intel processors!
Please keep the Windows classic (9x/2000) look and feel.
The layman's guides to - debugging - bug reporting - compiling - with some complementary scripts.
They may help you with a problem, so do have a look at them.

Webunny
Posts: 1201
Joined: Sat Apr 28, 2012 1:30 pm

Re: ROS testing on real hardware

Post by Webunny » Tue Dec 31, 2013 11:20 am

oldman wrote:I have added my main test computer to the list. Webunny could you check to see if everything is OK, as this is the first time I have ever edited a wiki. I thought that the columns had squashed inwards after that I had saved the page!

I see that all but my main test computer have Intel processors!
Thanks. The more, the merrier. At first glance, everything seems ok with your new addition. And it's a wiki, so one can always revert, so mistakes aren't all that important. :-)

Well, I have tested the 0.3.14 with two AMD PC's, but they both borked on ROS, and I don't remember the exact configuration. I actually have a dozen or so PC's, but most are either too old to do anything with anymore, or they're still actively used, so I can't readily keep testing ROS on it. Only 2-3 are not TOO old, nor are they in active use anymore, and those are excellent for testing things out, like ROS.

Funny thing is, I'm actually an AMD-man myself. I almost always buy AMD & Ati radeon stuff. I know that, if you really only care about best performance and not the price, one should go for intel, but I've the tendency to go for the underdog, and also AMD usually has the best bang for the buck (performance/price). My intel vs AMD rigs have a 1 to 10 proportion, but ironically enough, the intel is the only one of the 3 I can use for testing where ROS actually worked on, as of yet. Coincidence, no doubt. I'm sure AMD works as well, as you've proven.

emule01
Posts: 8
Joined: Thu May 13, 2010 12:48 pm

Re: ROS testing on real hardware

Post by emule01 » Wed Jan 01, 2014 2:06 am

happy new year to all

tester.. users.. coders...

milon
Posts: 969
Joined: Sat Sep 05, 2009 9:26 pm

Re: ROS testing on real hardware

Post by milon » Fri Jan 03, 2014 8:12 pm

Webunny wrote:@milon: feel free to add your rig there as well
I was going to wait until it worked on one, but now you've got me asking myself Why wait? I'll put both test machines on there as soon as I get a chance (couple days maybe). :)

EDIT - We should eventually standardize the "Working Builds" column so that sorting by that column results in something useful. Maybe we should put up a template or something?

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest