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]
Message-Id: <200711301558.13538.bjorn.helgaas@hp.com>
Date:	Fri, 30 Nov 2007 15:58:13 -0700
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Jiri Slaby <jirislaby@...il.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 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.

Bjorn
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ