December 2016 - Wine-Devel - list.winehq.org

Re: TestBot news

by Francois Gouget

On Sun, 4 Dec 2016, Jonas Maebe wrote: > Francois Gouget wrote: > > Indeed during the revert vm1 shows no read traffic (lots of RAM to cache > > that), but a steady 6 MB/s stream of writes ! In contrast on vm2 writes > > quickly ramp up to 80 MB/s, then stop after ~5 seconds and QEMU just > > uses CPU for the last ~4 seconds. > > Maybe vm2 mounts its file systems with noatime? The VM hosts all use relatime which provides essentially all the benefits of noatime. But in this case I expect the writes all go to the qcow2 disk image and I know vm1 is capable of sustaining more than 6 MB/s writes (e.g. when copying >100 GB around). -- Francois Gouget <fgouget(a)codeweavers.com>

Dec. 5, 2016

Re: [PATCH] Updated Readme with Github Markdown

by Alex Henrie

Hello Varunram, and thanks for your interest in contributing to Wine. The patch you submitted is very unlikely to be accepted because we, like the Linux kernel and many other projects, optimize our READMEs for terminal text editors rather than for GitHub. Also, if you submit any more patches in the future, please be sure to use your real name and include a Signed-off-by line. -Alex

Dec. 4, 2016

WineHQ Forums: Slackware multi-lib Wine build issues

by Bob Wya

Hiya, I've gotten really stuck trying to help out a Slackware user (yes they still exist!) on the WineHQ forums... Been bashing away at this problem for over a month now. He's trying to build a Shared WoW64 Wine. The build logs look clean. But the 32-bit half of Wine is segfaulting immediately. The 64-bit half appears to function as normal. I feel like I've hit a brick wall now... Anyone able to help? See: https://forum.winehq.org/viewtopic.php?f=8&t=27879 -- All the best, Robert

Dec. 4, 2016

Re: [PATCH] user32: Handle WM_SYSKEYDOWN in MENU_SuspendPopup.

by Alex Henrie

2016-12-02 11:41 GMT-07:00 Alexandre Julliard <julliard(a)winehq.org>: > Alex Henrie <alexhenrie24(a)gmail.com> writes: > >> Instead of adding WM_SYSKEYDOWN to the switch statement, we could fix >> the bug in one line by moving "pmt->trackFlags |= TF_SKIPREMOVE;" into >> the WM_KEYDOWN case. Or, we could delete MENU_SuspendPopup entirely >> and the if statements that call it. However, we wouldn't be setting >> TF_SKIPREMOVE anymore for unrecognized messages, likely causing a >> return of the bug that d75b0cdc tried to fix. >> >> By the way, I'm not exactly reverting d75b0cdc. I changed PM_REMOVE to >> PM_NOREMOVE to make sure that messages are removed only if they are >> recognized. >> >> I hope that makes sense; I admit that my previous explanation was not >> as well thought out as it could have been. Thanks for the feedback. > > Sorry for the delay in reviewing this. It still doesn't quite make sense > to me. Changing to PM_NOREMOVE now means that the keyboard message won't > get removed if some other message happened in between. I'm not sure > that's a good idea. We definitely do not want to remove the keyboard message if some other message is in line before it. In fact, the PeekMessageW( &msg, 0, 0, 0, PM_NOYIELD | PM_NOREMOVE ) statements later in the function depend on the assumption that they are reading a message that follows the WM_KEYDOWN. They are not supposed to be looking at a message that precedes the WM_KEYDOWN like is possible in the current code. I made the function behave the way that it used to before d75b0cdc, while being careful to not reintroduce the bug where non-keyboard messages were accidentally removed. -Alex

Dec. 4, 2016

Re: Serial port sniffing problem

by Bill Lionheart

Thanks for your reply Henri, I tried socat with a virtual serial port but I could only see what the config program sent and it got no reply. And slsniff ,sltrace and jpnevulator. All prevented the config program seeing the device. Morre details on my post https://forum.winehq.org/viewtopic.php?f=8&t=28031 on Wine-hq forum I also tried usb monitoring with wireshark and it did not stop the program running but I didnt understand the output and I couldnt see anything I expected so maybe I just didnt get it. Just now though Actually just now I tried tshark following exactly this suggestion https://ludovicrousseau.blogspot.co.uk/2014/10/ccid-usb-spy-using-wireshark…, this worked perfectly and did not prevent the two way serial communications. So the moral of this problem is for serial port sniffing of a Windows program running under Wine, tshark. As I understand it tshark is just command line wire shark. Main thing is it just worked and saved all the serial traffic in a file. Thanks for all the help and encouragement (including emails off the list), and for Bob Wye for encouraging me to post on wine-devel. I hope this will also be of some help in the future for wine developers in diagnosing serial communications problems to know that tshark is probably worth trying first (for a USB to serial converter at least) Best wishes Bill On 4 December 2016 at 12:05, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 27 November 2016 at 22:53, Bill Lionheart <billlionheart(a)gmail.com> wrote: >> The bundled GPRS tracker config software installs and runs OK under >> Wine. But my attempts to sniff the serial port traffic fails using all >> the standard Linux methods I know. >> > Which were those, and what happens? > >> I also tried using the Windows program Serial Port Monitor under Wine >> http://www.eltima.com/products/serial-port-monitor/ . This program >> says it cannot detect any serial ports. >> > Without knowing much about the software in question, I think there's a > good chance it works by hooking into the (Windows) kernel driver for > the serial port, or doing something similar. Perhaps that could be > made to work in Wine, but you'll likely have much more success with > intercepting the traffic on the Linux side. -- Professor of Applied Mathematics University of Manchester http://www.maths.manchester.ac.uk/bl

Dec. 4, 2016

Re: [v2 1/2] wined3d: Implement primitive restart index.

by Józef Kucia

On Tue, Nov 22, 2016 at 3:02 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 21 November 2016 at 01:42, Józef Kucia <joseph.kucia(a)gmail.com> wrote: >> Is it really safe to enable the primitive restart for all D3D >> versions? Shouldn't we enable it just for D3D10+? > It's probably "safe" in the sense that if previous versions don't have > primitive restart, and that seems likely at this point, you'd probably > get undefined behaviour instead, and primitive restart is as good of > an undefined behaviour as any other. Unless it's a valid index of > course, which is certainly a possibility with 16-bit indices in > particular, if perhaps not likely. > > But regardless, we want to know for sure. I've written some tests and the results indicate that 0xffff is a valid index in D3D8 and D3D9. I'll submit patches soon.

Dec. 4, 2016

Re: Serial port sniffing problem

by Henri Verbeet

On 27 November 2016 at 22:53, Bill Lionheart <billlionheart(a)gmail.com> wrote: > The bundled GPRS tracker config software installs and runs OK under > Wine. But my attempts to sniff the serial port traffic fails using all > the standard Linux methods I know. > Which were those, and what happens? > I also tried using the Windows program Serial Port Monitor under Wine > http://www.eltima.com/products/serial-port-monitor/ . This program > says it cannot detect any serial ports. > Without knowing much about the software in question, I think there's a good chance it works by hooking into the (Windows) kernel driver for the serial port, or doing something similar. Perhaps that could be made to work in Wine, but you'll likely have much more success with intercepting the traffic on the Linux side.

Dec. 4, 2016

Re: TestBot news

by Lauri Kenttä

On 2016-12-04 05:32, Francois Gouget wrote: > That said I'm not really happy with the state of things on vm1: for > some > reason its reverts are much slower than they should be. > ... > So there is still a mystery there and if anyone has an insight into it > it would be appreciated. Maybe you could simply replace vm1 with a copy of vm2 and then restore only the few relevant pieces (network, hostname, VM snapshot). This should rule out most configuration issues. In general, if those machines are only used for TestBot, you could build a common root partition for all the machines. That would be easier to keep up-to-date and to copy to new machines, if necessary. You could then have another partition where you have the per-machine configuration, VM snapshots etc. -- Lauri Kenttä

Dec. 4, 2016

Re: TestBot news

by Jonas Maebe

Francois Gouget wrote: > Indeed during the revert vm1 shows no read traffic (lots of RAM to cache > that), but a steady 6 MB/s stream of writes ! In contrast on vm2 writes > quickly ramp up to 80 MB/s, then stop after ~5 seconds and QEMU just > uses CPU for the last ~4 seconds. Maybe vm2 mounts its file systems with noatime? (see e.g. http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/ch… ). For vm3 that wouldn't make such a big difference because of its SSD. Jonas

Dec. 4, 2016

TestBot news

by Francois Gouget

I have upgraded Debian on vm1 from 7 to 8.6 and the filesystem from ext3 to ext4. This gets it a non-antique version of the kernel and QEMU which includes Huw's fix for the ntdll:exception test. So there should be one less unfixable failure for VMs being run on vm1. That said I'm not really happy with the state of things on vm1: for some reason its reverts are much slower than they should be. For instance with the wvista VM doing 3 reverts in a row on otherwise idle machines gives me: vm1 56.361s 46.803s 46.569s vm2 10.206s 9.783s 9.912s vm3 9.583s 8.137s 8.004s One could think that vm2 has much better hardware but that's just not the case: PassMark Disk Disk Host CPU MT ST Type Speed vm1 Xeon E3-1230v2 8855 1940 HD 130 MB/s vm2 Opteron 6128 6959 n/a HD Raid0 144 MB/s vm3 Xeon E3-1226v3 7462 2127 SSD 354 MB/s All hosts have 16 GB of RAM. So vm2 has what looks like a somewhat slower processor and a marginally faster disk thanks to Raid0. That should not be sufficient for it to be 4 times faster, particularly given that vm3 has a disk that's over twice as fast is only marginally faster than vm2. Indeed during the revert vm1 shows no read traffic (lots of RAM to cache that), but a steady 6 MB/s stream of writes ! In contrast on vm2 writes quickly ramp up to 80 MB/s, then stop after ~5 seconds and QEMU just uses CPU for the last ~4 seconds. vm3 also shows it's not an AMD vs Intel thing. There may be some missing CPU feature on vm1 but if that's the case I don't see what. So there is still a mystery there and if anyone has an insight into it it would be appreciated. Despite that I have put vm1 back to active duty. But I decided to keep the wvistau64 VM on the vm2 host. This means vm1 essentially only has one VM to take care of and since most of the time it's going to be idle already it should not slow jobs down. I also applied all Windows updates up to 2016/07/25 to the w7u VM. This caused some new failures that Hans started tackling / fixed. Any other new failure on the 3 VMs affected by the upgrade (wvista, wvistau64 and w7u) should be fixable. The configuration of the other two vms, wvista and wvistau64 should be essentially unchanged. Finally I also performed a minor upgrade on vm3: from Debian 8.2 to 8.6. The goal was to see if the minor QEMU upgrade would be sufficient to get Windows 10 to stop crashing when running WineTest. It looks like that's not the case. So the next step will be to grab QEMU 2.7 from the Debian BackPorts but there's a dumb command line incompatibility with libvirt 1.2.9 and there's no easily installable alternative :-( Fortunately I have a qemu wrapper script that should bridge the gap. -- Francois Gouget <fgouget(a)codeweavers.com>

Dec. 4, 2016