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

[Jiri Slaby <jirislaby@gmail.com>]

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@gmail.com)
Faculty of Informatics, Masaryk University