> My contribution to kernel bloat ... untested except on Lombard, the 3400
Followup: I forgot the following little patch to pmu.h. Paul, BenH, can we
please get this into the kernel source?
Michael
--- include/asm/pmu.h.org Fri Nov 24 14:25:38 2000
+++ include/asm/pmu.h Fri Nov 2
> >Result: The vanilla gnome battery_applet now works for me (TM).
>
> A better way would be to have the via-pmu driver asynchronously (via
> a timer) poll for state change and update some static status datas.
> This way, on core99, we can just disable the polling timer and rely
> on automatic no
>My contribution to kernel bloat ... untested except on Lombard, the 3400
>code needs testing and perhaps some work. Overall the code looks pretty
>ugly, take it as a proof of concept only and improve as desired. Patch is
>against 2.2.18-stable, the proc_register probably needs changing for 2.4.
>
> It seems this apm-pmud glue library would solve our problem in user space
> entirely (except for apps that directly cat /proc/apm). The battery status
> commands to the PMU are sent via /dev/adb and I'm not sure how this can
> be safely done from kernel code.
My contribution to kernel bloat ...
On Fri, 24 Nov 2000, Benjamin Herrenschmidt wrote:
> >Ok, I don't see very much the point of saving fractions of watt on a
> >desktop but...
>
> It can be more than fraction of watts when you put it all together, especially
> in deep sleep. And multiply that by the number of machines out there.
On 11/24/00 8:23 AM, Gabriel Paubert wrote:
[...]
> BTW: what is the minimum RAM to run Liunx/PPC these days ? My smallest
> (quasi embedded) machines have 16Mb and I hope to keep these running for
> at least 5 to 7 more years.
2.4.x runs reasonably well on a 8Mb machine here.
Takashi Oe
On Fri, 24 Nov 2000, Benjamin Herrenschmidt wrote:
> >Ok, I don't see very much the point of saving fractions of watt on a
> >desktop but...
>
> It can be more than fraction of watts when you put it all together, especially
> in deep sleep. And multiply that by the number of machines out there...
>Ok, I don't see very much the point of saving fractions of watt on a
>desktop but...
It can be more than fraction of watts when you put it all together, especially
in deep sleep. And multiply that by the number of machines out there...
Also, the Cube is sensitive to heat problems, having some po
On Fri, 24 Nov 2000, Benjamin Herrenschmidt wrote:
> Yup. Almost all Apple recent machines can do power management in various
> ways. Some can deep sleep (not only portables), all can switch off power
> to some PCI devices & ASICs, some support turning off the CPU...
Ok, I don't see very much t
>Could the recently added keventd thread be used for this? I don't like the
>idea of adding kernel threads just for one thing. One kernel thread for
>all relatively slow operations which may need a process context is
>reasonable however.
I'll investigate.
>No, I thought the deep sleep modes were
> > using the SuSE rescue disk. No idea how SuSE copes with readonly root fs.
>
> It doesnt work per default, some guys did some hacks to the boot scripts
> to have a readonly root fs.
> Well, but most users want to story something on their hard drives so it
Everybody seems to use hard disks fo
Quoting Benjamin Herrenschmidt <[EMAIL PROTECTED]>:
> >Hi,
> >
> >Seems like I missed a good part of the discussion... First reason I
> >wanted apmd
> >marked as x86 only, is because it is useless _now_ on power-pc. We have
> a PMU,
> >not an APM BIOS (ugh!), we have pmud not apmd. What is the poi
>Hi,
>
>Seems like I missed a good part of the discussion... First reason I
>wanted apmd
>marked as x86 only, is because it is useless _now_ on power-pc. We have
a PMU,
>not an APM BIOS (ugh!), we have pmud not apmd. What is the point compiling it
>for powerpc if it's not working and will probably
On Thu, Nov 23, Michael Schmitz wrote:
> The init scripts of all distributions but SuSE handle this just fine
> (mount -n). At least SuSE seems to mount the root fs rw from the start,
> which causes all sorts of pain if you want to boot into a RedHat system
> using the SuSE rescue disk. No idea ho
On Fri, 24 Nov 2000, Benjamin Herrenschmidt wrote:
> We can "fix" that by either having the PMU driver on core99 continuously
> send those infos via /dev/pmu without explicit request. It may also be
> interesting to replace this by a kernel thread. That would allow more
> flexibility in communic
On Thu, 23 Nov 2000, Michael Schmitz wrote:
> The init scripts of all distributions but SuSE handle this just fine
> (mount -n). At least SuSE seems to mount the root fs rw from the start,
> which causes all sorts of pain if you want to boot into a RedHat system
> using the SuSE rescue disk. No
>> Not APM support exactly... simply support for the same interface.
Just like
>> powermacs have totally different sound systems and still use /dev/dsp.
>> /proc/apm and /dev/apm_bios are so simple that it should be easy to
convince
>> any power management system to provide those API's.
>
>The in
On Thu, 23 Nov 2000, Adrian Cox wrote:
>
> Gabriel Paubert wrote:
> > Because mount stats /etc/mtab and does not touch it if it finds that it is
> > a symlink. But this has still problem, I just can't remember which ones. I
> > know that I thought it would be great and had to go back to the sta
On Thu, Nov 23, 2000 at 11:40:15AM +0100, Michel wrote:
> Avery Pennarun wrote:
>
> > Is this a typo? Why is status information in /etc?
>
> Because it's from pmud, which can't create /proc entries.
I think his problem was with the fact that it's in /etc, when it
should be in /var.
> > It's al
> > Good answer. I'd have used a symlink to some writeable directory on the
> > root fs, mainly because using /proc all over the place tends to confuse
> > Unix admins with no Linux experience. Let's not fall into the Solaris trap
> > (you are in a maze of twisty little config files, all different
Gabriel Paubert wrote:
> Because mount stats /etc/mtab and does not touch it if it finds that it is
> a symlink. But this has still problem, I just can't remember which ones. I
> know that I thought it would be great and had to go back to the standard
> /etc/mtab.
See http://www.xss.co.at/sysinfo/
On Thu, 23 Nov 2000, Michael Schmitz wrote:
>
> > On Thu, Nov 23, 2000 at 12:15:32PM +0100, Michael Schmitz wrote:
> >
> > > Re: mounting /etc readonly: how do you handle /etc/mtab in that case? :-)
> >
> > Symlink it to /proc/mounts, of course. :)
>
> Good answer. I'd have used a symlink to s
On Thu, 23 Nov 2000, Tony Mantler wrote:
> >Now /etc/mtab is also somewhat redundant with /proc/mounts. Actually you
> >should be able to link /etc/mtab to /proc/mounts but it raises a lot of
> >problems and does not work satifactorily in my experience.
> [...]
>
> I think technically the /proc
> We have here a big fat hardware difference. A PMU's a PMU, and an APM BIOS's
> an
> APM BIOS. I'm now working (with help from Joseph Garcia) on an APM library for
> PMUD. It hides PMUD from the libapm-using battery applets. I posted last week
> a
> first "socket" version that uses the TCP socke
> On Thu, Nov 23, 2000 at 12:15:32PM +0100, Michael Schmitz wrote:
>
> > Re: mounting /etc readonly: how do you handle /etc/mtab in that case? :-)
>
> Symlink it to /proc/mounts, of course. :)
Good answer. I'd have used a symlink to some writeable directory on the
root fs, mainly because using /
Quoting Michael Schmitz <[EMAIL PROTECTED]>:
> > > The info logged to /proc/apm is currently logged to /etc/power/apm.
> I have
> >
> > Is this a typo? Why is status information in /etc?
>
> Because user space pmud can't create /proc/ entries?
>
> > > no idea what /dev/apm does aside from pr
At 5:37 AM -0600 11/23/2000, Gabriel Paubert wrote:
[...]
>I agree that power management status/log should go to /var. On the other
>hand /etc has to be on the root fs for several reasons (/etc/inittab among
>others is quite important): IOW you don't use a separate mount point for
>/etc unless you
On Thu, 23 Nov 2000, Avery Pennarun wrote:
> Then it should go in /var, I think. We have standards for this stuff.
> (FSSTND, FHS, Debian policy.) I might want to mount /etc read-only (and
> /usr too, while I'm at it)... and this sounds like it would prevent me from
> doing so.
On Thu, 23 Nov
On Thu, Nov 23, 2000 at 12:15:32PM +0100, Michael Schmitz wrote:
> Re: mounting /etc readonly: how do you handle /etc/mtab in that case? :-)
Symlink it to /proc/mounts, of course. :)
/etc/mtab has always been evil, and not just because it's in the wrong
directory. It's about equivalent to the "
> > > > The info logged to /proc/apm is currently logged to /etc/power/apm. I
> > >
> > > Is this a typo? Why is status information in /etc?
> >
> > Because it's from pmud, which can't create /proc entries.
>
> Then it should go in /var, I think. We have standards for this stuff.
> (FSSTND, FH
> > The info logged to /proc/apm is currently logged to /etc/power/apm. I have
>
> Is this a typo? Why is status information in /etc?
Because user space pmud can't create /proc/ entries?
> > no idea what /dev/apm does aside from providing that log info, and I have
> > no clue what /dev/apm_bi
On Thu, Nov 23, 2000 at 11:40:15AM +0100, Michel Dänzer wrote:
> > > > /proc/apm and /dev/apm_bios are so simple that it should be easy to
> > > > convince any power management system to provide those API's.
> > >
> > > The info logged to /proc/apm is currently logged to /etc/power/apm. I
> >
> >
Avery Pennarun wrote:
> > > Not APM support exactly... simply support for the same interface. Just
> > > like powermacs have totally different sound systems and still use
> > > /dev/dsp.
> > > /proc/apm and /dev/apm_bios are so simple that it should be easy to
> > > convince any power management
On Thu, Nov 23, 2000 at 09:47:13AM +0100, Michael Schmitz wrote:
> > Not APM support exactly... simply support for the same interface. Just
> > like powermacs have totally different sound systems and still use
> > /dev/dsp.
> > /proc/apm and /dev/apm_bios are so simple that it should be easy to c
> > Linux-PPC (basically the Apple computers, any other Linux/PPC-subset
> > using it ?) uses the PMU, and pmud for power management. I don't think
> > that anybody wants to write an APM support for Power Macs (not me
> > anyway).
>
> Not APM support exactly... simply support for the same interfac
On Wed, Nov 22, 2000 at 08:53:43PM +, Hadess wrote:
> Linux-PPC (basically the Apple computers, any other Linux/PPC-subset
> using it ?) uses the PMU, and pmud for power management. I don't think
> that anybody wants to write an APM support for Power Macs (not me
> anyway).
Not APM support ex
Avery Pennarun wrote:
>
> On Wed, Nov 22, 2000 at 04:58:04PM +0100, Hadess wrote:
>
> > I'm writing you to have apmd marked as x86 only. Right now apmd is
> > compiled by the build-daemon (I think) but is 100% useless on PPCs, just
> > to name one arch. Maybe some other architectures (I'm thinkin
On Wed, Nov 22, 2000 at 04:58:04PM +0100, Hadess wrote:
> I'm writing you to have apmd marked as x86 only. Right now apmd is
> compiled by the build-daemon (I think) but is 100% useless on PPCs, just
> to name one arch. Maybe some other architectures (I'm thinking of Alphas)
> use the APM system.
Hi,
I'm writing you to have apmd marked as x86 only. Right now apmd is compiled by
the build-daemon (I think) but is 100% useless on PPCs, just to name one arch.
Maybe some other architectures (I'm thinking of Alphas) use the APM system.
Thanks for your time
/Hadess
39 matches
Mail list logo
