Hi,
as we earlier discussed, there is an idea to make 0.3.10 a "hardware-
compatibility" release.
There is a full list of 0.3.10 milestones bugs linked from our
roadmap page, but here are some possible directions for work:
- USB support for keyboard and mouse devices. Right now, it needs
fixing the rare crash during booting (bug is bugzilled, comment
explaining how to solve the problem is attached, some investigation
remains), and more testing on real hardware.
- Uniata support: it solves many problems at once, such as a stupid
8Gb limit which is a nonsense for a 2009-year operating system, and
Serial ATA support, which greatly enhances possible ReactOS usability
(along with the first item of this list). I use it in my builds
everyday for more than a month, it works very good. Problems:
VirtualBox CDROM support (it doesn't recognize it), on my
realhardware it also experiences similar problems. Bug is also
bugzilled, a lot of debug logs attached, so everyone can participate.
- Common NICs support: Cameron is doing great work, testers too.
There are some outstanding problems, which you can see from http://
www.reactos.org/wiki/index.php/Supported_Hardware/Network_cards
- Sound support: Johannes knows best, but getting any progress with
sound by 0.3.10 release date is greatly appreciated.
- Videocards support: Olaf performs some tesitng and bugreporting.
Third party drivers support is rather weak, http://www.reactos.org/
wiki/index.php/Supported_Hardware/Video_cards , and usually is
limited by VMWare's video driver which is being one of the most
supported through the ReactOS development history.
Besides of that, Olaf is organizing the Golden Apps testing, so that
we won't discover regressions occasionally or by the time the release
is branched and everyone is awaiting, but instead that's going to
happen on a periodical basis, and he's going to manage this process
with help of our fellow testers.
Target 0.3.10 release date is month from now on - that means,
somewhere in the end of May. Certainly, if our goals aren't met, the
release is going to be rescheduled and that's it, but, I'd like to
ask to concentrate on the above problems first. They are hard to
solve when every problem is being approached by one person, but with
a common effort they aren't going to be a problem.
Any new developers - welcome! There are very definite goals, enough
of information, so please feel free to join and help.
With the best regards,
Aleksey Bragin.
Hi Clemens,
I wonder if you still maintain this code ?
Qemu has recently changed the way to manage network devices,
and I had to do changes to keep it working.
This worked like an charm until today, and is still interesting me as Im beginning tests for wireless nics in ReactOS.
CCing ros-dev mailing list in case someone has it already built it in.
Kind regards,
Sylvain Petreolle
----- Message d'origine ----
> De : Clemens Kolbitsch <clemens.kol(a)gmx.at>
> À : qemu-devel(a)nongnu.org
> Envoyé le : Jeudi, 28 Février 2008, 15h12mn 09s
> Objet : [Qemu-devel] Atheros Wireless Device Emulation
>
> Hi!
> This patch adds virtual wireless networking support to qemu-0.9.1.
> Besides being funny having a wireless LAN in Qemu, I guess wireless driver
> developers could use this a lot.
>
> I have 3 screenshots here:
> http://stud4.tuwien.ac.at/~e0126605/qemu_atheros/atheros_wlan_hardware.jpg
> http://stud4.tuwien.ac.at/~e0126605/qemu_atheros/atheros_wlan_connecting.jpg
> http://stud4.tuwien.ac.at/~e0126605/qemu_atheros/atheros_wlan_connected.jpg
>
>
> Some infos about the emulation:
> - We simulate an Atheros AR5212 NIC
> - Additionally, we have a virutal access point that can
> be used to connect to Qemu
> - The code is based on ath5k reverse engineering from
> about 10 months ago. I did not check what these guys
> did since then.
> - I added tons of hours doing reverse engineering.. but the
> code is still a MESS! I'm sorry, but at least it works ;-)
> - We can simulate different network card vendors. I.e.
> through an additional model-name, we can specify if the
> network card is identified as "Atheros XXXX" or "HP W400", etc.
> ---> different drivers are installed automatically by guest system
> - The hardware reverse engineering still lacks some stuff. Known
> problems:
> * Depending on the driver, you have to use a different model
> ---> official windows drivers VS. madwifi Linux driver
> * Newest madwifi code probably does not work
> ---> Use Madwifi 0.9.3. Works just fine ;-)
> - The networking-code is still a *little* ugly. Outbound connections
> work, but there seem to be problems for inbound connections (e.g.
> tcp-redirection, etc.)
> - VM Snapshots supported
>
> Some infos about the patch:
> - 2 lines added to pci.c
> - added function declaration to pci.h
> - patched Makefile.target (2 lines)
> - added files qemu/hw/atheros_wlan_.*.[ch]
> - took 2 files from wireshark to generate CRC32 checksums
> - took 3 files from ath5k
> ---> licence people, please have a look if that is ok!!
>
> Enabling emulation:
>
> As I wrote above, there are still problems when using the same code for
> windows and linux guests. The model parameter helps here. Using the NIC on
> windows (that's how I tested):
>
> qemu ... -net user -net nic,model=atheros_wlan_winxp_HPW400 ...
>
> and
>
> qemu ... -net user -net nic,model=atheros_wlan_linux_HPW400 ...
>
> for Linux systems.
>
> The "atheros_wlan" is the device itself, "_linux" / "_windows" is necessary
> because the reverse engineering is still buggy and "_HPW400" gives the NIC
> identification for the guest. HPW400 is the Hewlett-Packard W400 device, but
> there are some more (see the atheros_wlan_eeprom.h for details).
>
> I have used the device on Debian (Kubuntu) Linux. The guests were WinXP-SP2
> and Kubuntu Linux, Kernel 2.6.20, MadWifi 0.9.3. My system is x86, so there
> might be problems with big/little endian I am not aware of!!
>
> Please try the patch and let me know what you think of it!!
>
> Greets,
> Clemens
Isn't that actually the same?
It also ignores the number of full descriptors, which I guess is wrong.
And it looks like the whole parsing code is broken. It ignores the
number of partial descriptors and does FullList++
Timo
janderwald(a)svn.reactos.org schrieb:
> Author: janderwald
> Date: Sat Apr 25 16:05:08 2009
> New Revision: 40694
>
> URL: http://svn.reactos.org/svn/reactos?rev=40694&view=rev
> Log:
> - Fix allocation of CM_RESOURCE_LIST
> - Might fix bug 4354
> See issue #4354 for more details.
>
> Modified:
> trunk/reactos/drivers/video/videoprt/dispatch.c
>
> Modified: trunk/reactos/drivers/video/videoprt/dispatch.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/video/videoprt/dis…
> ==============================================================================
> --- trunk/reactos/drivers/video/videoprt/dispatch.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/video/videoprt/dispatch.c [iso-8859-1] Sat Apr 25 16:05:08 2009
> @@ -340,9 +340,11 @@
>
> /* Save the resource list */
> ResourceCount = AllocatedResources->List[0].PartialResourceList.Count;
> - ResourceListSize =
> - FIELD_OFFSET(CM_RESOURCE_LIST, List[0].PartialResourceList.
> - PartialDescriptors[ResourceCount]);
> + ResourceListSize = sizeof(CM_RESOURCE_LIST);
> +
> + if (ResourceCount > 1)
> + ResourceListSize += (ResourceCount-1) * sizeof(CM_PARTIAL_RESOURCE_DESCRIPTOR);
> +
> DeviceExtension->AllocatedResources = ExAllocatePool(PagedPool, ResourceListSize);
> if (DeviceExtension->AllocatedResources == NULL)
> {
>
>
>
I feel that some things really need to be clearly explained, regarding apps
being use to test releases with.
At the moment, despite numerous attempts, i failed to find who (if anyone)
is responsible for compiling and maintaining the list of apps used for
release version testing. Especially, the non-downloader stuff section is
basically changing completely with every release, making those tests
virtually pointless, if we cant keep any consistency. On the other hand,
looks like no one is responsible for maintaining Downloader app list.
Without such responsibilites set, we are slipping into disorganisation,
which is both confusing and uproductive. Clear policies should be set and
observed in this matter, taking care of such basic thing as
adding/linking/opening a bug report for an app that failed in release Test.
I feel that testers have more productive things to do, than cleaning
up/sorting test entries, incorrectly made up by first timers.
Sorry if anyone feels this post to sound harsh, but its still really gentle
and kind, compared to obscenities, curses and swears others have to put up,
when i vent out after seeing the current state of Release testing wiki.
HI!
I was wondering if you people were interested in a new ISO/QUEMU/VMWARE
download mirror, I got space and on my server and I would like to help this
wonder full project.
If the service I'm offering you for free please answer back with the
information for starting "mirroring"
Here's my server's information:
Conection speed: VLAN on 100Mbits
Mirroring protocol: HTTP
Space reserved for ReactOS: 7GB,
Bandwith: Unlimited Bandwith
Waiting your answer,
Jorge Guerra
Kernel Error Administrator
Will Rogers <http://www.brainyquote.com/quotes/authors/w/will_rogers.html>
- "I don't make jokes. I just watch the government and report the
facts."
Hi,
by today most of the bugs which were having 0.3.9 as a milestone are
fixed - including fixing 4-months old bug with richedit control,
properly trimming DLL names during PE loading so that apps now can
find their DLLs (previously that failed in some cases), newest
downloader problem introduced yesterday and fixed today (not to speak
about yesterday's fixes too!).
This is a very good example of team collaboration, team effort aimed
at a narrow set of problems. It worked very well, and I think we
would utilise such bugfixing sessions in future too.
Branching date is now set to tomorrow, 17th of April, 2009 and is not
going to be changed anymore. As soon as the 0.3.9 branch is created,
feature freeze is considered to be finished.
After the release is branched, usual testing will be conducted,
actual packages built and released as usual.
Thank you for your efforts and for being patient with regards to the
feature freeze.
WBR,
Aleksey Bragin.