Re: WARNING: at kernel/resource.c:189 __release_resource

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/30/2007 11:58 PM, Bjorn Helgaas wrote:
> On Friday 30 November 2007 03:49:55 pm Jiri Slaby wrote:
>> On 11/30/2007 10:08 PM, Bjorn Helgaas wrote:
>>> On Thursday 29 November 2007 05:42:07 pm Andrew Morton wrote:
>>>> On Thu, 29 Nov 2007 16:40:37 -0700
>>>>> Maybe we could either remove the pnp_{stop,start}_dev() calls
>>>>> from the suspend/resume path, or move the PNP resource management
>>>>> out of pnp_{start,stop}_dev().
>>>>>
>>>>> Bjorn
>>>>>
>>>>> [1] http://lkml.org/lkml/2005/11/30/39
>>>> So was this particular problem caused/exposed by
>>>> pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch, or is
>>>> it in mainline?
>>> I'm pretty sure this problem is caused by that patch, so we
>>> we shouldn't see this in mainline.
>>>
>>> Jiri, can you try the additional patch below, please?
>>>
>>> Index: linux-mm/drivers/pnp/driver.c
>>> ===================================================================
>>> --- linux-mm.orig/drivers/pnp/driver.c	2007-11-30 13:58:25.000000000 -0700
>>> +++ linux-mm/drivers/pnp/driver.c	2007-11-30 13:59:37.000000000 -0700
>>> @@ -161,13 +161,6 @@
>>>  			return error;
>>>  	}
>>>  
>>> -	if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) &&
>>> -	    pnp_can_disable(pnp_dev)) {
>>> -		error = pnp_stop_dev(pnp_dev);
>>> -		if (error)
>>> -			return error;
>>> -	}
>>> -
>>>  	if (pnp_dev->protocol && pnp_dev->protocol->suspend)
>>>  		pnp_dev->protocol->suspend(pnp_dev, state);
>>>  	return 0;
>>> @@ -185,12 +178,6 @@
>>>  	if (pnp_dev->protocol && pnp_dev->protocol->resume)
>>>  		pnp_dev->protocol->resume(pnp_dev);
>>>  
>>> -	if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) {
>>> -		error = pnp_start_dev(pnp_dev);
>>> -		if (error)
>>> -			return error;
>>> -	}
>>> -
>>>  	if (pnp_drv->resume)
>>>  		return pnp_drv->resume(pnp_dev);
>>>  
>> No, it breaks suspend.
> 
> Thanks for trying it.  What are the symptoms?  I'd like to understand
> why we need to stop the devices before suspend.

Ho hum, it's not so easy, it's kind of nondeterministic now. Maybe some other
issue. If I remove 8250* modules from the kernel, it works. Otherwise it locks
in the middle of suspend after disks and graphics go down no matter if the patch
has been applied or not. Trying to investigate this further...

regards,
-- 
Jiri Slaby (jirislaby@xxxxxxxxx)
Faculty of Informatics, Masaryk University
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux