[PATCH v3] ntdll: Add RtlGetDeviceFamilyInfoEnum and RtlConvertDeviceFamilyInfoToString

[Kacper Rączy]

What’s the status of this patch? Should I send it again to pass the tests, as now known failures has been updated?

> Wiadomość napisana przez Francois Gouget <fgouget at codeweavers.com> w dniu 24.06.2022, o godz. 15:53:
> 
> On Fri, 24 Jun 2022, Kacper rączy wrote:
> 
>> This doesn’t seem right, my changes didn’t touch anything file or 
>> threadpool related. This patch introduced completely new API.
> 
> Only the errors listed in this email are attributed to your patch.
> So you can ignore the file failures.
> 
> [...]
>>> === w1064v1507 (32 bit report) ===
>>> 
>>> ntdll:
>>> threadpool.c:273: Test failed: expected info.userdata = 0x10000, got 0
>>> threadpool.c:278: Test failed: RtlDeregisterWait failed with status 103
> 
> I have no record of these two failures ever happening in the 
> WineTest runs but it makes sense that they are related to bug 53130. 
> Also I managed to reproduce them with and without your patch so it's 
> as if they are more likely to happen outside of WineTest (maybe 
> exclusively on Windows 10 1507?):
> 
> https://testbot.winehq.org/JobDetails.pl?Key=117566#k201
> https://testbot.winehq.org/JobDetails.pl?Key=117569#k201
> 
> Anyway you're in the clear. And I added them to the list of known 
> failures since they are so rare and thus likely to cause false 
> positives.
> 
> 
>>> === w10pro64 (testbot log) ===
>>> 
>>> WineRunTask.pl:error: The previous 1 run(s) terminated abnormally
> 
> The full log is actually:
> | TestBot process got stuck or died unexpectedly
> | WineRunTask.pl:error: The previous 1 run(s) terminated abnormally
> 
> The first line indicates that the server-side process running the 
> task got stuck. So that's not caused by your patch.
> 
> Maybe this should be handled differently (downgraded to a warning?) but 
> there is stuff that I need to figure out first:
> * Did the server-side process get stuck or did it die? Or neither?
>  A better trace would be nice.
> * It may instead be an inconsistency between the Task status and 
>  the VM status. That may suggest there is a race condition somewhere.
> * This task has no start timestamp which is wrong (it has happened 
>  before but is rare). Again this may indicate a race condition of some 
>  sort.
> 
> 
> -- 
> Francois Gouget <fgouget at codeweavers.com>