linux-kernel - Why does my driver (drivers/input/misc/winbond-cir.c) break suspend?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20100208101335.GA13907@hardeman.nu>
Date:	Mon, 8 Feb 2010 11:13:35 +0100
From:	David Härdeman <david@...deman.nu>
To:	linux-acpi@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org
Subject: Why does my driver (drivers/input/misc/winbond-cir.c) break
 suspend?

I've been trying to debug a problem with my driver 
(drivers/input/misc/winbond-cir.c) and suspend/resume.

If the driver is loaded, my test computer (Intel DG45FC motherboard) 
survives one suspend/resume cycle but hangs (no pings, no magic sysrq, 
etc) on the second suspend attempt (tested on 2.6.32.X and currently 
testing on a git checkout from yesterday).

After sprinkling a lot of printk's everywhere, it seems that the kernel 
freezes either in the below call, or at a random time soon after it:

drivers/pnp/driver.c:pnp_bus_suspend(), calls
pnp_dev->protocol->suspend()

Since this is a pnpacpi device, that is a call to:

drivers/pnp/pnpacpi/core.c:pnpacpi_disable_resources(), which calls the 
ACPI "_DIS" method for the "UAR3" object.

Now, if I add a hack to my driver to remove the PNP_DISABLE flag from 
device->capabilities (which means, AFAIK, that the above ACPI "_DIS" 
method won't get called during suspend), I can reliably suspend and 
resume, which is why I believe that this has got something to do with 
ACPI even though the crash during suspend doesn't always happen while 
"my" drivers _DIS method is being executed.

I've tried debugging the ACPI method by doing:
echo _DIS   >> /sys/module/acpi/parameters/trace_method_name
echo enable >> /sys/module/acpi/parameters/trace_state

and done a suspend/resume/suspend (i.e. caused the system to crash) 
while capturing the output via netconsole. I can't derive any 
interesting insights from the log though.

The decompiled dsdt table and the log capture from netconsole is 
attached to:
http://bugzilla.kernel.org/show_bug.cgi?id=15257

The first suspend starts at 203.176799 (the first line of the log) and 
ends around 209.083233 (line 2576), the resume starts right after the 
suspend and ends around 211.358430 (line 2712), the second suspend 
starts at 342.876299 (line 2718) and ends where the log file ends (with 
a freeze).

Any suggestions on what to try next?

(Please CC me on any replies)

-- 
David Härdeman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/