ROS testing on real hardware
Moderator: Moderator Team
Re: ROS testing on real hardware
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 - debugging - bug reporting - compiling - ISO remaster.
They may help you with a problem, so do have a look at them.
The layman's guides - debugging - bug reporting - compiling - ISO remaster.
They may help you with a problem, so do have a look at them.
Re: ROS testing on real hardware
Second that, and the same for the video card and its memory.oldman wrote:Bios version and company, motherboard chipset and chips used in sound cards, Ethernet cards.
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.
Re: ROS testing on real hardware
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.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.
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?)
Re: ROS testing on real hardware
"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.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.
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: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.)
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):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.
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
The more unstructured data you have, the harder it will be to extract it later to put in the database, for one thing.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?)
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.
Re: ROS testing on real hardware
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)?fred02 wrote:"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.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.
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?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: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.)
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.
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.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):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.
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
The more unstructured data you have, the harder it will be to extract it later to put in the database, for one thing.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?)
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.
Re: ROS testing on real hardware
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: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)?
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: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?
And I agree with you.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.
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: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),
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: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.
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.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.
Also, have you checked these threads?
Overview: ReactOS Testing on Real Hardware
Real Hardware Test on laptops
Re: ROS testing on real hardware
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.Webunny wrote:Ok, I'll give an oversight of the regression, pinpointing the range.oldman wrote: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.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!
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.)
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).
Re: ROS testing on real hardware
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.
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.
Re: ROS testing on real hardware
The real bug: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).
" - 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 ).
-
- Posts: 32
- Joined: Thu Aug 01, 2013 6:39 am
Re: ROS testing on real hardware
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?).
[ external 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:
[ external image ]
[ external 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:
[ external image ]
Re: ROS testing on real hardware
@milon: feel free to add your rig there as wellmilon 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.
@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
Re: ROS testing on real hardware
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!
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 - debugging - bug reporting - compiling - ISO remaster.
They may help you with a problem, so do have a look at them.
The layman's guides - debugging - bug reporting - compiling - ISO remaster.
They may help you with a problem, so do have a look at them.
Re: ROS testing on real hardware
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.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!
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.
Re: ROS testing on real hardware
happy new year to all
tester.. users.. coders...
tester.. users.. coders...
Re: ROS testing on real hardware
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).Webunny wrote:@milon: feel free to add your rig there as well
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?
Who is online
Users browsing this forum: Bing [Bot] and 63 guests