ROS testing on real hardware

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
Black_Fox
Posts: 1584
Joined: Fri Feb 15, 2008 9:44 pm
Location: Czechia

Re: ROS testing on real hardware

Post by Black_Fox » Wed Jan 08, 2014 11:41 am

Webunny wrote:RH-testing (...) greatest interest lays in finding bugs that don't show up in VM.
Sorry for not being clear, my sentences are meant to say precisely what you said in this quote.

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

Re: ROS testing on real hardware

Post by milon » Wed Jan 08, 2014 8:11 pm

Webunny wrote:Interesting. I had a look at your examples, and I think the red letters are more easily readable then the red block. It's something like that which I envisaged when I talked about using a colour-scheme indeed. What specific suggestion of its usage would you recommend? I don't think it opportune to let everything be coloured in... only (the names/numbers of) the builds, then? Red if they were not working, green if they were? It would make it more easily to see at a glance which worked and which not, indeed.
True, black-on-red isn't terribly readable, but it stands out better at a distance. The font color can easily be switched from black to white or something. (Made an edit to mine - what do you think?) The Template text is red because we haven't defined such a page. I'm not sure yet how to properly define a template page, so what you're seeing is essentially a broken link.

I agree that we shouldn't color everything. I don't see any reason to color anything other than Working Builds, and maybe non-working builds mentioned in the comments field.

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

Re: ROS testing on real hardware

Post by Webunny » Thu Jan 09, 2014 12:12 am

milon wrote:
Webunny wrote:Interesting. I had a look at your examples, and I think the red letters are more easily readable then the red block. It's something like that which I envisaged when I talked about using a colour-scheme indeed. What specific suggestion of its usage would you recommend? I don't think it opportune to let everything be coloured in... only (the names/numbers of) the builds, then? Red if they were not working, green if they were? It would make it more easily to see at a glance which worked and which not, indeed.
True, black-on-red isn't terribly readable, but it stands out better at a distance. The font color can easily be switched from black to white or something. (Made an edit to mine - what do you think?) The Template text is red because we haven't defined such a page. I'm not sure yet how to properly define a template page, so what you're seeing is essentially a broken link.

I agree that we shouldn't color everything. I don't see any reason to color anything other than Working Builds, and maybe non-working builds mentioned in the comments field.
I edited it a bit with the letters as colours (I changed the background colours of Adrian, thus, because I really thought it less suited and more difficult to read the actual numbers.)

As it is now, it seems rather ok. Just maybe one thing: to people who say 'none' int he builds-section, I would prefer if you at least put the first and last build-number of ROS that you tried (and didn't work) in there. That way, it's easier to follow any progression of builds we might see. Just saying 'none' gives little info as to what was tested. Or at least something like: "none up to number xxx" would be a better indication.

For the rest, it seems to be shapin' up rather nicely. It already has more HW-testers in there in such a short time than I expected. I know real hardware testers are a niche anyway with ROS, currently, but a very important one, imho. It's enough if we have a small dedicated team for real hardware testing, and I'm sure others interested in RH-testing will dribble in as well, in the future.

Speaking of which, I asked a collegue of mine who might have a serial/null modem cable, so I don't need to go through such exhausting range-finding research to pinpoint the culprit buold/regression anymore, like last time.


@adrian: good idea. Feel free to do so. Making a wikipage specifically explaining how best to go about with RH-testing might be useful indeed (don't forget to detail how to get info in different ways, and especially with a null modem cable). I'm sure it will be welcomed by would-be novice testers who want to try out ROs on actual hardware as well. In time, I believe this group will be larger than VM-testing, even. Both have their uses (as said, I use virtualbox and putty myself, because it's far easier to repetitively test common factors that way), but in the end, the better ROS gets, the more it should start working on real hardware, and the more use(full) it will become TO use and test it on real HW - where it is, ultimately, meant to be run on. So it's understandable the vast majority of testing right now is done on VM, but it's very useful to have some dedicated real-hardware testers as well, imho. And there are, currently, very few of them, which is why everyone counts. No doubt, other bugs/regressions that can't be noticed on VM, but only on HW-testing, will be discovered, just as in my latest testing-case.

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

Re: ROS testing on real hardware

Post by Webunny » Wed Jan 15, 2014 8:29 pm

Since I'm focussing a bit more on real hardware testing these days, I've decided (and acquired) a nul modem cable.

I'm not sure I have the good one, though. As far as I can see, you have like four different kinds of null modems, all with different 'handshaking'. How do I know what I have (and which do I need anyway?)

Since I don't want to go through the tedious range-finding by burning different builds anymore like last time, I think might need this cable if I turn into bugs/regressions again. No doubt there are others around who already have some experience with this?

middings
Posts: 1009
Joined: Tue May 07, 2013 9:18 pm
Location: California, USA

Re: ROS testing on real hardware

Post by middings » Thu Jan 16, 2014 12:37 am

Webunny wrote:As far as I can see, you have like four different kinds of null modems, all with different 'handshaking'. How do I know what I have (and which do I need anyway?)
The ReactOS wiki article Debugging has a schematic of a null modem cable. Look for the section Real computer: Physical serial cable. The portions of the schematic for the 9-pin connections match the Null Modem Cable Wiring that Microsoft recommends for use with WinDbg.

You may wish to compare that cable to the InterLink cable Microsoft describes for use with its Direct Cable Connection software. It matches the cable sold to me years ago as a LapLink compatible cable that looks like this. (Years ago, desktop PCs and industrial equipment usually had 25-pin connectors but laptops often had the smaller 9-pin ones. The ability to mix and match plug sizes at each end was useful.) Notice that the signals connected by the pair of 9-pin plugs do not completely match the corresponding signal connections on the 25-pin pair. The DCD signal (on pin 8) is left unconnected on the 25-pin plugs but is connected between the 9-pin ones (on pin 1). I expect the 9-pin plugs will work with WinDbg but the 25-pin ones might not. I'll find out when I get my old HP Pavilion desktop PC ready to experiment with.

The two web pages here and here will tell you more about null modem cables than most people even want to know. To make a long story short, the four different styles of null modem cables match four different methods of signal handshaking.

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

Re: ROS testing on real hardware

Post by Webunny » Sat Jan 18, 2014 12:05 pm

Just tested the new ReactOS 0.3.16 RC on real hardware. It installed and worked as expected; no show-stopping bugs/reversions in vanilla ROS/build noticeable.

I will now test some applications, as requested by z98.

Edit: added it to the https://www.reactos.org/wiki/PC_ROS_Rigs page too.

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

Re: ROS testing on real hardware

Post by Webunny » Sat Feb 08, 2014 9:10 pm

Webunny wrote:Just tested the new ReactOS 0.3.16 RC on real hardware. It installed and worked as expected; no show-stopping bugs/reversions in vanilla ROS/build noticeable.

I will now test some applications, as requested by z98.

Edit: added it to the https://www.reactos.org/wiki/PC_ROS_Rigs page too.
Tested out REL 0.3.16 too, of course, and everything worked fine, for an alpha release.

zydon
Posts: 160
Joined: Tue Dec 18, 2007 9:03 am

Re: ROS testing on real hardware

Post by zydon » Fri Feb 14, 2014 10:13 pm

I think boot problems on real hardware is unnecessary because it show similarity with the early win2k glitch. Even WinPE boot better on most of the machine back then.

ROS Developers should considered to develop the OS to make it run on VirtualPC 2007 as a priority of real hardware visualization. Once ROS load without a problem on VPC, the OS almost certainly would run on most of real hardware old and new without a problem. It may also even run on any other virtual machine application without a hiccup too.

I think ROS VESA drivers already done being developed. Dealing with VGA drivers and non-VESA higher resolution display using VPC additions drivers might help improving ROS to support real hardware display department.

I've seem many OS that doesn't run in VPC couldn't run on the real hardware too. So, the question is what is missing?

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: ROS testing on real hardware

Post by Z98 » Fri Feb 14, 2014 10:22 pm

zydon wrote:Once ROS load without a problem on VPC, the OS almost certainly would run on most of real hardware old and new without a problem. It may also even run on any other virtual machine application without a hiccup too.
That's a very strong assertion. What evidence do you have to back it up?

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

Re: ROS testing on real hardware

Post by fred02 » Sat Feb 15, 2014 1:50 pm

zydon wrote:I think boot problems on real hardware is unnecessary because it show similarity with the early win2k glitch.
What glitch? May be the developers should know, as it might be helpful to solve it.
Last edited by fred02 on Tue Feb 18, 2014 12:54 pm, edited 1 time in total.

erkinalp
Posts: 843
Joined: Sat Dec 20, 2008 5:55 pm

Re: ROS testing on real hardware

Post by erkinalp » Sat Feb 15, 2014 7:45 pm

ROS Developers should considered to develop the OS to make it run on VirtualPC 2007 as a priority of real hardware visualization. Once ROS load without a problem on VPC, the OS almost certainly would run on most of real hardware old and new without a problem. It may also even run on any other virtual machine application without a hiccup too.
VirtualPC is not as close as VMWare for full system virtualization, VMWare will give more realistic results for real PC emulation.
-uses Ubuntu+GNOME 3 GNU/Linux
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2

EmuandCo
Developer
Posts: 4348
Joined: Sun Nov 28, 2004 7:52 pm
Location: Germany, Bavaria, Steinfeld
Contact:

Re: ROS testing on real hardware

Post by EmuandCo » Sat Feb 15, 2014 8:03 pm

VirtualPC just behaves so awkward, that many operating systems cant handle it. That has nothing to do with compatibility to old systems
Image
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.

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

Re: ROS testing on real hardware

Post by Webunny » Sat Feb 15, 2014 11:21 pm

Anyway, I tested a bit further with the REL 0.3.16. I don't think it's worth making a jira bugreport of, and I'm sure it's already known in most cases, but as a general comment/critique on the working I would say this:

1) moving windows around is slow, and response time to opening something is slow as well
2) usb doesn't work (on RH)
3) (black) artifacts appear on icons/windows in some instances (sometimes just by browsing over them)
4) sounddriver (and two other drivers) still don't auto-install or even get recognised (manually installing the sounddriver works, though)
5) When closing (shutting down) ROS, I now get a BSOD. This might well be a regression, since - contrary to the above points - I don't recall this happening with former builds.
6) drag&drop doesn't work

For the rest I have little to add, seen it's alpha stage.

zydon
Posts: 160
Joined: Tue Dec 18, 2007 9:03 am

Re: ROS testing on real hardware

Post by zydon » Mon Feb 17, 2014 12:31 pm

Z98 wrote:
zydon wrote:Once ROS load without a problem on VPC, the OS almost certainly would run on most of real hardware old and new without a problem. It may also even run on any other virtual machine application without a hiccup too.
That's a very strong assertion. What evidence do you have to back it up?
Did I the only person logically think Microsoft using VPC to develop their Windows OS?

I don't think Microsoft will use VMWare or VirtualBox or other VM than their very own VPC. That is where the secret lies how their Windows OS running smoothly on almost all x86 hardware.

For me, OS is about Read, Write and Redraw(GUI) frequency handling from/to all the devices on a PC hardware. VPC provide the basic fundamental of x86 performance. Timer, Delay and duration to read/write into devices has to be optimized to satisfy this fundamental x86 VM. Otherwise, you'll noticed how slow the OS you build crawling like hell on the various real hardware.

All the symptoms real hardware having reported for ReactOS is the exact problems to what happened when it tested on VPC.

EmuandCo
Developer
Posts: 4348
Joined: Sun Nov 28, 2004 7:52 pm
Location: Germany, Bavaria, Steinfeld
Contact:

Re: ROS testing on real hardware

Post by EmuandCo » Mon Feb 17, 2014 1:34 pm

VPC is old and nearly unsupported. They test it on Hyper-V and real HW. And yes, I know what I talk about. I call them almost daily at work and that's what they often say when I lament about some stupid problems. And VPC behaves somehow like a PC, yes. Thats what it was made for. But it's just behaving SIMILAR to real HW. Thats not enough for many time critical things many OSes base on.
Image
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.

Post Reply

Who is online

Users browsing this forum: learn_more and 6 guests