Bug 110354 - Confusing Junk in the results: Last errno: 25, Inappropriate ioctl for device
Summary: Confusing Junk in the results: Last errno: 25, Inappropriate ioctl for device
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: IGT (show other bugs)
Version: unspecified
Hardware: Other All
: medium major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-08 11:43 UTC by Arek Hiler
Modified: 2019-08-06 08:30 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Arek Hiler 2019-04-08 11:43:38 UTC
IGT's asserts log the last errno if it's not 0, and it seems like we get this "Inappropriate ioctl for device" quite often polluting the CI results and confusing people. 

We have to locate where is it originating from and set errno to 0 after handling it to stop the pollution.

Some examples:
https://bugs.freedesktop.org/show_bug.cgi?id=109358
https://bugs.freedesktop.org/show_bug.cgi?id=110037
https://bugs.freedesktop.org/show_bug.cgi?id=110279
Comment 1 Arek Hiler 2019-04-08 14:53:33 UTC
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 266aa832..b235b18c 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -984,8 +984,11 @@ void igt_debug_wait_for_keypress(const char *var)
 {
        struct termios oldt, newt;

-       if (!isatty(STDIN_FILENO))
+       if (!isatty(STDIN_FILENO)) {
+               errno = 0; /* otherwise may be ENOTTY */
                return;
+       }
+

        if (!igt_interactive_debug)
                return;

Found the culprit in this particular case. This would suppress most of the weird errno logged in kms tests. 

The questions is now: do we really want to hunt all similar cases down? A round of gdb through a couple of tests with 'watch errno' shows that it gets set to non-zero value about a dozen times every single subtest. Depending when we hit an assert we may get any of those printed out adding to confusion.

I see 3 options:
1. make sure that errno is reset to 0 by everything that touches it and change my nickname to Sisyphus
2. get rid of printing errno in igt_assert(), but then lose valuable information for all those igt_assert(write(...));
3. change igt_assert*(expr,...) macros so that they 'errno = 0;' before evaluating expr

I think that 3 makes the most sense, then we can quickly go through all the 4000-ish of calls we have to make sure that we don't have any weird 'int ret = write(); igt_assert(ret);' for those functions where errno matters.
Comment 2 Arek Hiler 2019-08-06 08:30:38 UTC
There was a patch merged that resets errno in the few places where errno pollution is likely and in the few places where it may require resetting:

commit a558c2e2405473f4157ca71638e5a111ebfa80d1
Author: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Date:   Tue Apr 9 17:21:41 2019 +0300

    lib: Reset errno to 0 after isatty

    Since igt_assert family of functions logs last errno we get a lot of
    those: "Last errno: 25, Inappropriate ioctl for device"

    isatty() seems to be the biggest offender in that area, so this patch
    should limit amount of confusing messages significantly.

    Cc: Martin Peres <martin.peres@linux.intel.com>
    Cc: Petri Latvala <petri.latvala@intel.com>
    Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
    Reviewed-by: Petri Latvala <petri.latvala@intel.com>

commit 02b1706e8b1ca93a53d4ef0f9c484a6f1a0d18f2
Author: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Date:   Thu Apr 4 16:17:40 2019 +0300

    lib/igt_kms: Be more verbose about failure in kmstest_wait_for_pageflip

    First, we set errno to 0 before doing select() to avoid random pollution
    of the assert message with things like:
    "Last errno: 25, Inappropriate ioctl for device"

    Second, we log explicitly if we exceeded the timeout (ret == 0).

    Third, if we fail the select() we log that with some explanation.

    Cc: Petri Latvala <petri.latvala@intel.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
    Reviewed-by: Petri Latvala <petri.latvala@intel.com>


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.