linux-kernel - Re: [linux-pm] Crash when suspending Lenovo T510 laptop (2.6.39.3)

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 5 Aug 2011 22:13:40 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Jesper Juhl <jj@...osbits.net>, Len Brown <len.brown@...el.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [linux-pm] Crash when suspending Lenovo T510 laptop (2.6.39.3)

On Friday, August 05, 2011, Alan Stern wrote:
> On Fri, 5 Aug 2011, Rafael J. Wysocki wrote:
> 
> > On Friday, August 05, 2011, Jesper Juhl wrote:
> > > Hi
> > > 
> > > I just experienced a kernel crash when trying to suspend my Lenovo 
> > > Thinkpad T510 (model 4384-GJG) laptop.
> > > 
> > > Normally I just shut the lid and the little moon icon lights up telling me 
> > > that the laptop has suspended. This time was different; the moon icon 
> > > didn't light up as it usually does, so I opened the lid again and found a 
> > > kernel crash dump on the screen. The machine was completely dead at this 
> > > point, so all I could do was take a photo of the screen - nothing had made 
> > > it to the log files either (checked after a reboot).
> > > 
> > > The image I took of the screen with the crash info is available here:
> > >  http://personal.chaosbits.net/suspend-crash.jpg
> > > 
> > > The kernel version is 2.6.39.3
> > > The kernel config is attached as '2.6.39.3-config.gz'
> > > The distribution is Arch Linux 64bit.
> > > 
> > > Here is a partial transcript of the image (typed in manually, so check the 
> > > image if you suspect an error - I also left out function addresses/offsets 
> > > and other details before/after the backtrace to save me some typing, so 
> > > check the image for the full details) :
> > > 
> > > Call Trace:
> > >   ? wq_worker_sleeping
> > >   schedule
> > >   ? cfq_put_queue
> > >   ? cic_free_func
> > >   ? kmem_cache_free
> > >   ? put_io_context
> > >   do_exit
> > >   oops_end
> > >   die
> > >   do_trap
> > >   do_invalid_op
> > >   ? free_msi_irqs
> > >   ? find_busiest_group
> > >   ? pci_conf1_write
> > >   pci_disable_msi
> > >   e1000e_reset_interrupt_capabillity
> > >   __e1000_runtime_suspend
> > >   ? __switch_to
> > >   pci_pm_runtime_suspend
> > >   ? pci_legacy_suspend_late
> > >   rpm_callback
> > >   ? schedule
> > >   rpm_suspend
> > >   ? linkwatch_do_dev
> > >   ? pm_schedule_suspend
> > >   pm_runtime_work
> > >   process_one_work
> > >   worker_thread
> > >   ? manage_workers.isra.29
> > >   kthread
> > >   kernel_thread_helper
> > >   ? kthread_worker
> > >   ? gs_change
> > > 
> > > I've not experienced this before with this kernel, nor with earlier or 
> > > newer ones, so it's not exactely reproducible on demand, so it's anyones 
> > > guess when this was introduced (or if it's been there for ages, just 
> > > triggers rarely)...
> > > 
> > > One detail that may be relevant; normally when I suspend the laptop I do 
> > > so before unplugging any cables or suspend after not having anything 
> > > plugged in for ages (or at all). This time I was in a hurry, so I quickly 
> > > unplugged the power, 3 usb cables and the ethernet cable and then quickly 
> > > slammed the lid shut. Not sure if that has an impact on triggering this 
> > > though. I tried reproducing that scenario 4-5 times, but the laptop 
> > > suspended fine when I did that.
> > > 
> > > If you require further information then please let me know and I'll be 
> > > happy to provide it. 
> > > 
> > > I'll of course try to submit more details if it happens again, but if 
> > > someone has a good guess as to how to provoke it or an idea for a fix I'd 
> > > sure like to know.
> > 
> > I don't know how to fix it yet, but I think I know what the problem is.
> > Namely, a runtime suspend of the Ethernet adapter as occured in parallel with
> > the system-wide suspend and they clashed.  The runtime suspend has probably
> > been provoked by detaching the Ethernet cable from the box.
> 
> For them to clash in that way would mean that the PM workqueue didn't
> get frozen.

Not necessarily, I think.  It's sufficient that system suspend is started
while the runtime PM operation is in progress.

> Is that possible?

Shouldn't be.

Thanks,
Rafael
--
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/