/dev/toshiba created chmod 660 root:root

I don't reboot that often (-: so I didn't notice until now, but actually, /dev/toshiba is (of course) recreated each time you load the toshiba module, and removed when it is rmmodded. Every time, you have to go chmod or chgrp it in order for e.g. wmtuxtime to work. I plan to set up a local rc.script to do just that at boot time, but of course, ideally, it should not be necessary.

The workaround turned out to be a textbook example of the modprobe "install" directive. Including here just in case I need to remember what I did ...

The solution hinges on the assumption that a particular group (in this case, admin) corresponds to the users who are granted privilege to run wmtuxtime et al. On a single-user laptop, of course, this is rarely a real issue.

This appears to be a problem in the kernel or a related package, since it manifests even on a system which doesn't have toshutils installed. Feel free to reject against toshutils and reassign ... most likely in accordance with this:

vnix$ dpkg -S /lib/modules/2.6.17-11-generic/kernel/drivers/acpi/toshiba_acpi.ko
linux-image-2.6.17-11-generic: /lib/modules/2.6.17-11-generic/kernel/drivers/acpi/toshiba_acpi.ko

The system where I originally discovered this was running a different kernel, apparently 2.6.15

On second thought, maybe the permissions should remain, and wmtuxtime et al. changed to cope accordingly instead (and then the bug assigned back to toshutils)? Any opinions?

This bug has had no activity for a considerable period. This is a check to see if there is still interest in investigating this bug report.

I still have the hardware where this happened but it cannot really run any recent version of Ubuntu. However, I believe the repro steps should be trivial (try to use the device as a non-root user) and the fix, one way or another, straightforward. If there are newer Toshiba machines with the same facility and software which uses it then they would certainly benefit from this.

The toshutils package's description contains this remark:

 Note that these utilities work with APM features in the Toshiba BIOS.
 If your laptop's BIOS only supports ACPI and not APM, then toshutils will
 probably not work for you. Toshiba's newer models tend to support ACPI
 only, and therefore toshutils will not work with them.

So I guess the whole interface is becoming obsolescent. However, as long as it's being included in kernel builds, shouldn't it be made to work?

I'm not entirely convinced this is sufficient information for you; if you know of a forum where more Toshiba Ubuntu users could comment on this, that would seem like a good idea. Popcon stats for the toshutils could also be a good idea. Maybe the toshutils maintainer would be able to comment?

Also http://ubuntuforums.org/showthread.php?t=16975 looks like coincidental confirmation that others too have bumped into this, but that's a pretty old thread (2005).

Here's what http://popcon.ubuntu.com/by_vote says:

#Format
#
#<name> is the package name;
#<inst> is the number of people who installed this package;
#<vote> is the number of people who use this package regularly;
#<old> is the number of people who installed, but don't use this package
# regularly;
#<recent> is the number of people who upgraded this package recently;
#<no-files> is the number of people whose entry didn't contain enough
# information (atime and ctime were 0).
#rank name inst vote old recent no-files (maintainer)
1 perl-base 452401 134486 303218 14682 15 (Brendan O'dea)
2 debianutils 452415 134414 302214 15779 8 (Clint Adams)
3 grep 452411 134405 304925 13026 55 (Ryan M. Golbeck)
 :
 :
6890 toshutils 896 62 791 43 0 (Drew Parsons)

(Sorry for the screwy formatting.)

I don't understand how the rank is calculated, but it's in the top decile (-: -- the full list has 75594 entries. (Ah, it's simply by vote, apparently. A lot of packages have one or zero votes.)

Judging from the comments in Ubuntuforums, a lot of people installed this only to find out it doesn't work for their BIOS (or many are still puzzling about what it's supposed to do for them). I guess the vote might be inflated somewhat if it has an init script which gets run at every boot, even if it only finds that it can't do anything, and quits. (I don't know if it does, but IIRC it contains a small daemon of some sort.)

Wouldn't in fact group "powerdev" ownership be a good solution? Where are these standard groups documented?

Can you clarify the following:
This issue is the same for every release upto & including Gutsy?
You solve this by changing /dev/toshiba from:[660 root:root] to [660 root:admin]?

I found one link which suggested Debian runs this as [666 root:root] - although not suggesting you run like this as this may create a security issue.

Yes, [660 root:powerdev] maybe good solution.
Kernel Team need to assess this.
Thanks.

To reiterate, I no longer have a Toshiba which uses APM, so I cannot easily assess the effects of this bug any longer. The permissions have not changed but the applications which use this API may have come up with a different workaround. I presently have no way to test that.

The 18 month support period for Edgy Eft 6.10 has reached it's end of life. As a result, we are closing the linux-source-2.6.17 Edgy Eft kernel task. However, please note that this report will remain open against the actively developed kernel. Thank you for your continued support and help as we debug this issue.

Hardy Heron 8.04 was recently released. It would be helpful if you could test the new release and verify if this is still an issue - http://www.ubuntu.com/getubuntu/download . You should be able to test your bug using the LiveCD. Please let us know your results. Thanks.

Like I wrote before, I cannot personally test this, because the hardware is too old to run any recent release of Ubuntu. Anybody else with a Toshiba APM BIOS should be able to try to repro this, though. Is there a tag I could assign to this bug to indicate that testing help from someone with suitable hardware would be appreciated?

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Unfortunately this bug report is being closed because we received no response to the last inquiry for information. However, the Intrepid Ibex 8.10 Beta release was most recently announced - http://www.ubuntu.com/testing/intrepid/beta . If you are able to confirm this is still an issue with this most recent release please feel free to reopen this report. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New".

Thanks,