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>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+icZUU=SDuMbkCOS8Fafi3NjDxGoY+95LMcP0+C8tebdRRQUg@mail.gmail.com>
Date:	Mon, 14 Jan 2013 15:06:13 +0100
From:	Sedat Dilek <sedat.dilek@...il.com>
To:	Jiri Slaby <jirislaby@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	linux-next <linux-next@...r.kernel.org>,
	Linux PM List <linux-pm@...ts.linux-foundation.org>,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Len Brown <lenb@...nel.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: -next: no resume from suspend

On Mon, Jan 14, 2013 at 2:36 PM, Sedat Dilek <sedat.dilek@...il.com> wrote:
> On Mon, Jan 14, 2013 at 1:53 PM, Sedat Dilek <sedat.dilek@...il.com> wrote:
>> Hi Jiri,
>>
>> [ QUOTE ]
>> since friday's -next (the last known to be working is the last monday's)
>> I cannot resume from suspend. The last thing I see with
>> no_console_suspend is:
>> i915: No ACPI video bus found
>>
>> But I used to see the message always, so this is no difference. Any idea
>> before I start bisecting?
>>
>> It is x86_64, core 2 duo, intel g33 GPU, 6G RAM.
>> [ /QUOTE ]
>>
>> Before starting any git-bisection I would try drm-intel-nightly GIT branch.
>> It includes drm-intel-fixes + drm-intel-next + drm-intel-next-queued
>> and applied here (mostly) cleanly against Linux (upstream) and/or
>> Linux-Next.
>>
>> $ cd linux-next/
>>
>> $ git pull git://people.freedesktop.org/~danvet/drm-intel drm-intel-nightly
>>
>> I remember I had no problems with i915 with next-20130109 (WED) and
>> next-20130110 (THU), so I am curious if I will hit the problem as
>> well.
>>
>
> Looks like I have also problems to do a successfull suspend (see
> call-trace below):
>
> +[   90.220468] wlan0: deauthenticating from 00:04:0e:e4:00:3d by
> local choice (reason=3)
> +[   90.236579] cfg80211: Calling CRDA to update world regulatory domain
> +[   90.247716] cfg80211: World regulatory domain updated:
> +[   90.247729] cfg80211:   (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> +[   90.247738] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz),
> (300 mBi, 2000 mBm)
> +[   90.247745] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz),
> (300 mBi, 2000 mBm)
> +[   90.247751] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz),
> (300 mBi, 2000 mBm)
> +[   90.247757] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz),
> (300 mBi, 2000 mBm)
> +[   90.247762] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz),
> (300 mBi, 2000 mBm)
> +[   92.510591] PM: Syncing filesystems ... done.
> +[   97.583869] Freezing user space processes ...
> +[  117.574599] Freezing of tasks failed after 20.01 seconds (1 tasks
> refusing to freeze, wq_busy=0):
> +[  117.574642] aptd            D 0000000000000000     0  2703   2702 0x00000004
> +[  117.574646]  ffff880071cadab8 0000000000000046 00000000000213da
> ffff88011ac28680
> +[  117.574649]  ffff8800832d1720 ffff880071cadfd8 ffff880071cadfd8
> ffff880071cadfd8
> +[  117.574652]  ffff880119b31720 ffff8800832d1720 ffff880071cadab8
> ffff88011fa547b8
> +[  117.574654] Call Trace:
> +[  117.574662]  [<ffffffff8112e830>] ? sleep_on_page+0x20/0x20
> +[  117.574667]  [<ffffffff816b49d9>] schedule+0x29/0x70
> +[  117.574670]  [<ffffffff816b4aaf>] io_schedule+0x8f/0xd0
> +[  117.574673]  [<ffffffff8112e83e>] sleep_on_page_killable+0xe/0x40
> +[  117.574676]  [<ffffffff816b32df>] __wait_on_bit+0x5f/0x90
> +[  117.574679]  [<ffffffff81130f70>] wait_on_page_bit_killable+0x80/0x90
> +[  117.574683]  [<ffffffff8107eaf0>] ? autoremove_wake_function+0x40/0x40
> +[  117.574685]  [<ffffffff81131026>] __lock_page_or_retry+0xa6/0xd0
> +[  117.574688]  [<ffffffff811314c1>] filemap_fault+0x471/0x4e0
> +[  117.574691]  [<ffffffff81155342>] __do_fault+0x72/0x520
> +[  117.574694]  [<ffffffff811583d6>] handle_pte_fault+0xf6/0xae0
> +[  117.574698]  [<ffffffff81173f5a>] ? alloc_pages_current+0xba/0x170
> +[  117.574702]  [<ffffffff8104c417>] ? pte_alloc_one+0x37/0x50
> +[  117.574705]  [<ffffffff816b58de>] ? _raw_spin_lock+0xe/0x20
> +[  117.574707]  [<ffffffff81156219>] ? __pte_alloc+0xa9/0x160
> +[  117.574709]  [<ffffffff8115a411>] handle_mm_fault+0x271/0x390
> +[  117.574712]  [<ffffffff816b99ae>] __do_page_fault+0x17e/0x540
> +[  117.574715]  [<ffffffff8114bd3c>] ? vm_mmap_pgoff+0xbc/0xe0
> +[  117.574717]  [<ffffffff816b9d9b>] do_page_fault+0x2b/0x50
> +[  117.574719]  [<ffffffff816b61d8>] page_fault+0x28/0x30
> +[  117.574721]
> +[  117.574722] Restarting tasks ... done.
> +[  117.581299] video LNXVIDEO:00: Restoring backlight state
> +[  118.108217] iwlwifi 0000:01:00.0: L1 Enabled; Disabling L0S
> +[  118.114986] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
> +[  118.343161] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> +[  124.674956] wlan0: authenticate with 00:04:0e:e4:00:3d
> +[  124.682933] wlan0: send auth to 00:04:0e:e4:00:3d (try 1/3)
> +[  124.684635] wlan0: authenticated
> +[  124.684780] iwlwifi 0000:01:00.0 wlan0: disabling HT as WMM/QoS is
> not supported by the AP
> +[  124.684785] iwlwifi 0000:01:00.0 wlan0: disabling VHT as WMM/QoS
> is not supported by the AP
> +[  124.685817] wlan0: associate with 00:04:0e:e4:00:3d (try 1/3)
> +[  124.690449] wlan0: RX AssocResp from 00:04:0e:e4:00:3d
> (capab=0x411 status=0 aid=1)
> +[  124.697818] wlan0: associated
> +[  124.697860] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
>

Grrr, damn mei-driver... there is a pending patch and did not hit
char-misc-next!

With drm-intel-nightly (see attached patch) I can sucessfully suspend
+ resume (see attached dmesg-2.diff).

- Sedat -

> - Sedat -
>
>> Kernel-config and some logs (dmesg) or hwinfos (lspci) might be helpful :-).
>>
>> If this does not help, I would recommend to create diffs between
>> latest known (-rcX and next-X.good) and (-rcX and next-X.bad) and
>> compare (i915||acpi||pm) the changes.
>> But this also means you have to know which of the -next releases was
>> good and bad.
>> If you are building Linux-Next daily, this is good.
>> NOTE: Helpful is in this strategy that your -rcX should be the same
>> (here: v3.8-rc3).
>>
>> Hope this helps you (I know bisecting Linux-Next is a bit of a pain).
>>
>> Regards,
>> - Sedat -
>>
>> [1] http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-nightly

Download attachment "dmesg-2.diff" of type "application/octet-stream" (14871 bytes)

Download attachment "3.8.0-rc3-next20130114-2-iniza-generic.patch" of type "application/octet-stream" (184049 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ