Re: Battery-related regression between 2.6.17-git3 and 2.6.17-git6

[Greg KH]

On Mon, Jul 03, 2006 at 10:26:03PM +0200, Rafael J. Wysocki wrote:
> On Monday 03 July 2006 21:44, Greg KH wrote:
> > On Mon, Jul 03, 2006 at 09:39:22PM +0200, Rafael J. Wysocki wrote:
> > > On Monday 03 July 2006 20:00, Greg KH wrote:
> > > > On Mon, Jul 03, 2006 at 01:16:45PM +0200, Rafael J. Wysocki wrote:
> > > > > Hi,
> > > > > 
> > > > > On Sunday 02 July 2006 11:15, Rafael J. Wysocki wrote:
> > > > > > On Sunday 02 July 2006 00:21, Rafael J. Wysocki wrote:
> > > > > > > With the recent -git on my box (Asus L5D, x86_64 SUSE 10) the powersave
> > > > > > > demon is apparently unable to get the battery status, although the data in
> > > > > > > /proc/acpi/battery/BAT0 seem to be correct.  As a result, battery status
> > > > > > > notification via kpowersave doesn't work and it's hard to notice when the
> > > > > > > battery is low/critical.
> > > > > > > 
> > > > > > > So far I have verified that this feature works fine with 2.6.17-git3 and
> > > > > > > doesn't work with 2.6.17-git6 (-git5 doesn't compile here).
> > > > > > > 
> > > > > > > I'll try to get more information tomorrow (unless someone in the know has
> > > > > > > an idea of what's up ;-) ).
> > > > > > 
> > > > > > I've verified that the problem first appeared in 2.6.17-git4.
> > > > > 
> > > > > Apparently this happens because powersaved takes the battery status
> > > > > information from hald and the following kernel changes make hald crash on
> > > > > my system:
> > > > > 
> > > > > http://kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=43104f1da88f5335e9a45695df92a735ad550dda
> > > > > http://kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bd00949647ddcea47ce4ea8bb2cfcfc98ebf9f2a
> > > > > http://kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c182274ffe1277f4e7c564719a696a37cacf74ea
> > > > > http://kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9bde7497e0b54178c317fac47a18be7f948dd471
> > > > > http://kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=36679ea59846d8f34a48f71ca1a37671ca0ad3c5
> > > > > 
> > > > > (ie. after reverting them hald works again).
> > > > 
> > > > Ick, that should not cause any problems, as sysfs should look identical
> > > > to how it was before those patches.  Except that the /sys/class/usb/
> > > > stuff is now symlinks instead of real directories, but HAL has had to
> > > > handle that for a long time now (and it's even documented in
> > > > Documentation/ABI/testing/sysfs-class)
> > > 
> > > Well, apparently one of them happens to trigger a buffer overflow in "my"
> > > version of hal. ;-)
> > > 
> > > > Can you tell me exactly which of the above patches breaks HAL?
> > > 
> > > That would be quite a bit of testing and now I'm sure it's a hal issue.
> > 
> > git bisect would help out a lot.  Or just ask the HAL developers, they
> > might know.
> 
> Anyway I'd have to compile and test at least a couple of kernels.
> [For the record: I'm quite sure that 36679ea59846d8f34a48f71ca1a37671ca0ad3c5
> and 9bde7497e0b54178c317fac47a18be7f948dd471 together break hal on
> my system; this seems to be related to endpoints' paths in sysfs.]

I don't understand why that would break HAL, we are just adding new
devices to the sysfs device tree, which the kernel is free to do at any
time.  HAL should not care about that.

Oh, and 36679ea59846d8f34a48f71ca1a37671ca0ad3c5 is just an internal api
change, it does not affect userspace in any way.  So I don't see how
that would have anything to do with HAL at all.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/