Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753299AbbBMOld (ORCPT ); Fri, 13 Feb 2015 09:41:33 -0500 Received: from lists.s-osg.org ([54.187.51.154]:49476 "EHLO lists.s-osg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753248AbbBMOlb convert rfc822-to-8bit (ORCPT ); Fri, 13 Feb 2015 09:41:31 -0500 Date: Fri, 13 Feb 2015 12:41:25 -0200 From: Mauro Carvalho Chehab To: Takashi Iwai Cc: Hans Verkuil , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: DVB suspend/resume regression on 3.19 Message-ID: <20150213124125.67a67e04@recife.lan> In-Reply-To: References:

Organization: Samsung X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5324 Lines: 129 Em Fri, 13 Feb 2015 15:02:42 +0100 Takashi Iwai escreveu: > At Mon, 09 Feb 2015 11:59:07 +0100, > Takashi Iwai wrote: > > > > Hi, > > > > we've got a bug report about the suspend/resume regression of DVB > > device with 3.19. The symptom is VLC doesn't work after S3 or S4 > > resume. strace shows that /dev/dvb/adaptor0/dvr returns -ENODEV. > > > > The reporter confirmed that 3.18 works fine, so the regression must be > > in 3.19. > > > > There is a relevant kernel warning while suspending: > > > > WARNING: CPU: 1 PID: 3603 at ../kernel/module.c:1001 module_put+0xc7/0xd0() > > Workqueue: events_unbound async_run_entry_fn > > 0000000000000000 ffffffff81a45779 ffffffff81664f12 0000000000000000 > > ffffffff81062381 0000000000000000 ffffffffa051eea0 ffff8800ca369278 > > ffffffffa051a068 ffff8800c0a18090 ffffffff810dfb47 0000000000000000 > > Call Trace: > > [] dump_trace+0x8c/0x340 > > [] show_stack_log_lvl+0xa3/0x190 > > [] show_stack+0x21/0x50 > > [] dump_stack+0x47/0x67 > > [] warn_slowpath_common+0x81/0xb0 > > [] module_put+0xc7/0xd0 > > [] dvb_usb_adapter_frontend_exit+0x41/0x60 [dvb_usb] > > [] dvb_usb_exit+0x31/0xa0 [dvb_usb] > > [] dvb_usb_device_exit+0x3b/0x50 [dvb_usb] > > [] usb_unbind_interface+0x1ed/0x2c0 > > [] __device_release_driver+0x7e/0x100 > > [] device_release_driver+0x22/0x30 > > [] usb_forced_unbind_intf+0x2d/0x60 > > [] usb_suspend+0x73/0x130 > > [] usb_dev_freeze+0x13/0x20 > > [] dpm_run_callback+0x4a/0x150 > > [] __device_suspend+0x121/0x350 > > [] async_suspend+0x1e/0xa0 > > [] async_run_entry_fn+0x43/0x150 > > [] process_one_work+0x142/0x3f0 > > [] worker_thread+0x114/0x460 > > [] kthread+0xc1/0xe0 > > [] ret_from_fork+0x7c/0xb0 > > > > So something went wrong in module refcount, which likely leads to > > disabling the device and returning -ENODEV in the end. > > > > Does this ring a bell to you guys? > > > > The hardware details and logs are found in the URL below: > > https://bugzilla.novell.com/show_bug.cgi?id=916577 > > I wonder whether no one hits the same problem...? Hi Takashi, There were no recent changes at dvb-usb core or at the dtt200u.c driver. So, I don't think that the regression was caused by a change at the media subsystem. Yet, we've added some patches to fix suspend/resume at the DVB core, but they basically add a new set of optional callbacks. So, it should not cause any regression. The changeset in question is 59d7889ae49f6e3e9d9cff8c0de7ad95d9ca068b. >From those messages: 2015-02-06T15:30:47.468258+01:00 linux-z24t kernel: [ 150.552119] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-fc03.fw' 2015-02-06T15:30:47.468827+01:00 linux-z24t mtp-probe: checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4" 2015-02-06T15:30:47.879878+01:00 linux-z24t mtp-probe: bus: 1, device: 5 was not an MTP device 2015-02-06T15:30:47.880192+01:00 linux-z24t kernel: [ 151.992993] usb 1-4: USB disconnect, device number 5 2015-02-06T15:30:47.880839+01:00 linux-z24t kernel: [ 151.993076] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. I _suspect_ that dvb_usb_download_firmware() failed to load the firmware file. That problem actually looks like a recently discovered issue:t request_firmware() fails during resume on some systems. What seems to happen in this case is that the media drivers are resumed _before_ mounting the partition where the firmware file is hosted. Yet, in this case, it should be printing: "did not find the firmware file." I would add a test patch in order to print the return code from dvb_usb_download_firmware(), in order to see if it succeeds or not, e. g. something like the patch below, and then try to narrow down where it is failing, assuming that the new message will be printed. If nothing gets printed, then I would try to discover why the USB stack disconnected the device. Perhaps an ehci/xhci bug? Regards, Mauro diff --git a/drivers/media/usb/dvb-usb/dvb-usb-firmware.c b/drivers/media/usb/dvb-usb/dvb-usb-firmware.c index 733a7ff..184d0290 100644 --- a/drivers/media/usb/dvb-usb/dvb-usb-firmware.c +++ b/drivers/media/usb/dvb-usb/dvb-usb-firmware.c @@ -109,6 +109,10 @@ int dvb_usb_download_firmware(struct usb_device *udev, struct dvb_usb_device_pro } release_firmware(fw); + + if (ret) + err("firmware load failed with %d error code", ret); + return ret; } > > > Takashi > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/