linux-kernel - Re: WARNING: at kernel/resource.c:189 __release

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] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 01 Dec 2007 09:12:01 +0100
From:	Jiri Slaby <jirislaby@...il.com>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
CC:	Andrew Morton <akpm@...ux-foundation.org>, matthew@....cx,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-pm@...ts.linux-foundation.org, drzeus@...eus.cx
Subject: Re: WARNING: at kernel/resource.c:189 __release_resource

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