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: <1227576051.15014.305.camel@rzhang-dt>
Date:	Tue, 25 Nov 2008 09:20:51 +0800
From:	Zhang Rui <rui.zhang@...el.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	"Zhao, Yakui" <yakui.zhao@...el.com>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Alexey Starikovskiy <astarikovskiy@...e.de>,
	Len Brown <lenb@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>, walken <walken@....org>
Subject: Re: Regression: ACPI AC driver doesn't work on Toshiba Portege
	R500 (bisected)

On Mon, 2008-11-24 at 21:30 +0800, Rafael J. Wysocki wrote:
> On Monday, 24 of November 2008, Zhang Rui wrote:
> > On Mon, 2008-11-24 at 09:21 +0800, Rafael J. Wysocki wrote:
> > > On Monday, 24 of November 2008, Zhao Yakui wrote:
> > > > On Mon, 2008-11-24 at 07:37 +0800, Rafael J. Wysocki wrote:
> > > > > On Sunday, 23 of November 2008, Rafael J. Wysocki wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > With current mainline (2.6.28-rc6-git1 as of today) on Toshiba Portege R500 the
> > > > > > status of the AC adapter is not updated when the adapter is unplugged and
> > > > > > plugged in.  Evidently, /sys/class/power_supply/ADP1/online always contains the
> > > > > > same value.  Interestingly enough, though, if the box is suspended to RAM and
> > > > > > resumed, the status of the AC adapter is correctly updated, but the value read
> > > > > > at that time remains in /sys/class/power_supply/ADP1/online until the next
> > > > > > suspend/resume cycle regardless of what's going on with the AC adapter.
> > > > > > 
> > > > > > 2.6.27.7 works correctly on this box so the recent EC patches don't seem to
> > > > > > cause this regression to happen.
> > > > > > 
> > > > > > Any other ideas?
> > > > Hi, Rafael
> > > >     Will you please open a new bug at
> > > > http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI and attach the
> > > > output of acpidump, dmesg, lspci -vxxx?
> > > >     If no ACPI event is reported when AC adapter is unplugged and
> > > > plugged, the /sys/class interface can't display the correct AC status.
> > > > Now Rui is working on this issue and the patch is already finished. But
> > > > it is not sent to Lenb.
> > > 
> > > Can you give me a link to the patch, please?
> 
> Thanks.
> 
> Still, it doesn't seem to be related to the problem at hand.
> 
right, it's another problem.

> > From: Zhang Rui <rui.zhang@...el.com>
> > Subject: power_supply: update ac status before acquiring it.
> > 
> > Update AC status in sysfs I/F.
> > http://bugzilla.kernel.org/show_bug.cgi?id=12035
> > 
> > Signed-off-by: Zhang Rui <rui.zhang@...el.com>
> > ---
> >  drivers/acpi/ac.c |    6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > Index: linux-2.6/drivers/acpi/ac.c
> > ===================================================================
> > --- linux-2.6.orig/drivers/acpi/ac.c
> > +++ linux-2.6/drivers/acpi/ac.c
> > @@ -87,6 +87,7 @@ struct acpi_ac {
> >  	unsigned long long state;
> >  };
> >  
> > +static int acpi_ac_get_state(struct acpi_ac *ac);
> >  #define to_acpi_ac(x) container_of(x, struct acpi_ac, charger);
> >  
> >  #ifdef CONFIG_ACPI_PROCFS_POWER
> > @@ -103,15 +104,18 @@ static int get_ac_property(struct power_
> >  			   enum power_supply_property psp,
> >  			   union power_supply_propval *val)
> >  {
> > +	int result;
> >  	struct acpi_ac *ac = to_acpi_ac(psy);
> > +
> >  	switch (psp) {
> >  	case POWER_SUPPLY_PROP_ONLINE:
> > +		result = acpi_ac_get_state(ac);
> >  		val->intval = ac->state;
> >  		break;
> >  	default:
> >  		return -EINVAL;
> >  	}
> > -	return 0;
> > +	return result;
> >  }
> >  
> >  static enum power_supply_property ac_props[] = {
> > 
> > >  
> > > >     From the problem description it seems that the problem is related
> > > > with the AC driver. But from the git-bisect it seems that the problem is
> > > > related with the button driver(Fix power button device). 
> > > > 
> > > >     Any-way, please attach the output of dmesg, acpidump, lspci -vxxx.
> > > 
> > > Created http://bugzilla.kernel.org/show_bug.cgi?id=12091 with the information
> > > attached as requested.
> > > 
> > I'll take this bug. :)
> 
> Thanks again.
> 
> Do I understand correctly that you intend to revert commit
> faee816b1502385dc9bc5abf2960d1cc645844d1 and provide an alternative patch
> for walken?
> 
First, I think it's safe to revert
commit faee816b1502385dc9bc5abf2960d1cc645844d1
because bug #10503 can not be reproduced in the upstream kernel as a
result of another commit  49db139955d3392c6c4facf987905d0a9afed581

Second, if we can make sure all the pci devices won't issue any PMEs
when the /sys/devices/.../power/wakeup files are "disabled", then I'd
glad to generate another patch which always enables the PCI root bridge
(PNP0A03) GPE, both at runtime and sleep state, just like what we do for
the buttons.

thanks,
rui

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