On Fri, 2005-09-02 at 18:35 +, Joerg Sommer wrote:
Hello Otavio,
Otavio Salvador [EMAIL PROTECTED] wrote:
Joerg Sommer [EMAIL PROTECTED] writes:
Hello Matteo,
Matteo Bigoi - Bigo! [EMAIL PROTECTED] wrote:
See http://forums.gentoo.org/viewtopic-t-365647.html
You have to run
there already seems to be *heaps* of reversed engineered information
about programming its chipset (from decompiled AP firmware).
could be off assistance also.
Dean
What we can do is also spy all IOs to the chip and use that to
understand how it works, eventually writing a linux driver...
Michael Schmitz wrote:
Do we have a clear picture of the hardware/software combination this bug
is triggered by?
In particular:
- only tibook? What about iBook or later (Al-) PowerBooks?
- running pbbuttonsd (version?), no pmud present?
- running pmud (version?), no pbbuttonsd present?
-
reassign 326220 apt
Your system looks older than a testing from April 2005. libc6 version
2.2.5-11.8 is a libc6 from Woody, an Debian does not support direct
Woody - Etch upgrade.
So please reassign the bug to whatever seems appropriate. Not being able
to upgrade from woody to current
Michael Schmitz wrote:
Do you use cpudyn to control CPU speed? Michel Dänzer brought this up, and
that's another known cause of lockups.
No, but I use cpufreqd. All my power loss events have occurred while the
machine was on AC power, and have occurred while using both
'performance' and
So far, I've not been able to get a clear picture from the reports. ISTR
one user reported that problems went away after using pmud/mouseemu
instead of pbbuttonsd, that's why I suggest testing the above
configurations.
TiBook IV here, running pmud, no pbbuttonsd, no mouseemu.
I got the
Aluminium Powerbook 12 rev. B (2003, powerbook 6,2)
pbbuttonsd 0.7.1
no pmud
mouseemu 0.15
mouseemu blocks the trackpad
pbbuttonsd does not block the trackpad
I've had the power-loss issue happen only three or four times over two
weeks of use, so it's hard to describe behaviour causing
On Sat, Sep 03, 2005 at 10:30:22AM +0200, Michael Schmitz wrote:
reassign 326220 apt
Your system looks older than a testing from April 2005. libc6 version
2.2.5-11.8 is a libc6 from Woody, an Debian does not support direct
Woody - Etch upgrade.
So please reassign the bug to whatever
hi all,
i compiled kernel 2.6.13 on my 12 powerbook (newest model).
/sys/power/state looks like: standby mem disk
i tried:
echo -n mem /sys/power/state
and
echo -n standby /sys/power/state
the suspend-process starts and falls back to console with no errors.
i disabled sound support in the
hi all,
i compiled kernel 2.6.13 on my 12 powerbook (newest model).
/sys/power/state looks like: standby mem disk
i tried:
echo -n mem /sys/power/state
and
echo -n standby /sys/power/state
the suspend-process starts and falls back to console with no errors.
Just curious - did it
Do you use cpudyn to control CPU speed? Michel Dänzer brought this up, and
that's another known cause of lockups.
No, but I use cpufreqd. All my power loss events have occurred while the
machine was on AC power, and have occurred while using both
'performance' and 'powersave' cpu profiles
On 9/2/05, Michael Tautschnig [EMAIL PROTECTED] wrote:
hi michael,
i struggeled with the same problem - the patch works fine!
is it possible to setup a minimum speed as default?
so the temperature would not rise up that fast.
One possible approach would be the change of this line
Well, apt or dpkg should have figured that out, and warned me off to not
attempt the upgrade, right? Yet another bug.
The system is booted using a floppy, I'm not sure I can even fit a 2.4 or
2.6 kernel on there. Either way, 'you should not try that' is not an
The 2.6.8 sarge kernel
On 9/2/05, Michael Tautschnig [EMAIL PROTECTED] wrote:
hi michael,
i struggeled with the same problem - the patch works fine!
is it possible to setup a minimum speed as default?
so the temperature would not rise up that fast.
One possible approach would be the change of
i compiled kernel 2.6.13 on my 12 powerbook (newest model).
/sys/power/state looks like: standby mem disk
i tried:
echo -n mem /sys/power/state
and
echo -n standby /sys/power/state
the suspend-process starts and falls back to console with no errors.
Just curious - did it ever work? I
On Sat, Sep 03, 2005 at 11:50:09AM +0200, Michael Schmitz wrote:
Well, apt or dpkg should have figured that out, and warned me off to not
attempt the upgrade, right? Yet another bug.
The system is booted using a floppy, I'm not sure I can even fit a 2.4 or
2.6 kernel on there.
According to Michael Tautschnig, on Sat, 3 Sep 2005
Did you mean the above change by this approach - if so, what else would you
suggest? IMHO one could then easily change this by unloading the module and
loading
it again with fan_speed=0 .
better to make an entry fan_speed in /sys IMO...
Michael Schmitz a écrit :
reassign 326220 apt
Your system looks older than a testing from April 2005. libc6 version
2.2.5-11.8 is a libc6 from Woody, an Debian does not support direct
Woody - Etch upgrade.
So please reassign the bug to whatever seems appropriate. Not being able
to upgrade
[...]
so the only possibility is to work with spuspend-to-disk (swsusp2)?
Yes, at least
http://lists.debian.org/debian-powerpc/2005/05/msg00356.html
says so.
HTH,
Michael
signature.asc
Description: Digital signature
According to Michael Tautschnig, on Sat, 3 Sep 2005
Did you mean the above change by this approach - if so, what else would you
suggest? IMHO one could then easily change this by unloading the module and
loading
it again with fan_speed=0 .
better to make an entry fan_speed in /sys
So please reassign the bug to whatever seems appropriate. Not being able
to upgrade from woody to current testing/unstable is what I'd consider a
bug in its own right.
It's seems you are not aware that Sarge is out and is now the stable
I'm well aware of that, thank you very much.
better to make an entry fan_speed in /sys IMO...
There is
/sys/devices/temperatures/specified_fan_speed
but I don't know whether it works the way you'd probably like to use it.
IIRC this only reads out the speed set by the module parameter. I'll have
a look at how your patch behaves on my
Michael Schmitz wrote:
Heh, that might just be Michel's probem. Try powernowd instead of
cpufreqd, or maybe just without cpufreqd.
I've told mouseemu -typing-block 0 - is that the same as disabling it?
All this does is tell mouseemu to pass through any key event it gets to
see. Which isn't
On Sat, 2005-09-03 at 10:36 +0200, Michael Schmitz wrote:
So far, I've not been able to get a clear picture from the reports. ISTR
one user reported that problems went away after using pmud/mouseemu
instead of pbbuttonsd, that's why I suggest testing the above
configurations.
Michel Dänzer wrote:
My assumption is that the sudden shutdowns are triggered by some kind of
race condition when switching CPU speed. If powernowd switches less
often than cpudyn, it may indeed be significantly less likely to
trigger. Of course, cpudyn could be configured to switch less often
Can you try booting the daily builds ? These are at :
http://people.debian.org/~luther/d-i/images/daily/powerpc64/netboot64/
or :
http://people.debian.org/~luther/d-i/images/daily/powerpc64/cdrom64/
Get the initrd.gz and vmlinux on a cd or tftp boot server, write the adequate
On Sat, Sep 03, 2005 at 04:09:55PM -0300, Eduardo Trápani wrote:
Can you try booting the daily builds ? These are at :
http://people.debian.org/~luther/d-i/images/daily/powerpc64/netboot64/
or :
http://people.debian.org/~luther/d-i/images/daily/powerpc64/cdrom64/
Get the
27 matches
Mail list logo
