ibook doesn't "wake up"

I'm fairly certain that some folks have this working on iBooks, CCing some
powerpc folk

When I close the lid on my iBook G4 (800 MHz, dual USB), I have the feeling that
it does not really go to sleep; the TFT backlight goes off, but it _immediately_
works again after I reopen the lid. So I suppose that this thing did not power
down CPU, HD, and other peripherals.

But at least it does not crash...

Yep, confirmed. The powerprefs settings are correct, the thing is supposed to
sleep when the lid closes, and I deactivated all "do not sleep when X" options.
I can still ssh into the iBook when the lid is closed.

mine doesn't even turn off the backlight. Doesn't seem to want to sleep at all.

(In reply to comment #4)
> mine doesn't even turn off the backlight. Doesn't seem to want to sleep at all.

OK, other things were confused, too. After rebooting, it sleeps when I close
the lid, but it doesn't wake up.

I get the same output as comment 0 on the screen when it hangs (except it's in a
different order, but all the same things)

My PowerBook doesn't sleep at all. This is a well-known problem with PowerBooks
using recent ATI cards; ATI haven't provided the specifications necessary for
the ppc kernel maintainers to implement sleep.

It seems worse for the system to crash after closing the lid, than to not sleep
at all.

Derek, could you try commenting out the chvt commands in /etc/acpi/lid.sh?

There is no /etc/acpi on mine...

(In reply to comment #8)
> There is no /etc/acpi on mine...

No /etc/acpi/ folder.

As far as looking in places these seem to be more likely:

/etc/pbbuttons/
or
/etc/apm/

In terms of hardware, my ibook model has been reported to work by many people.
The Edd Dumbill's article:
http://www.macdevcenter.com/pub/a/mac/2002/03/29/ibook_linux.html

Suggests that PMU should be used rather than APM for power management. However,
I imagine there has been some changes since that article was written.

So, I tracked down some more info:

1. PMU and pmud aren't required with a 2.6 based kernel
2. Looking at some of the kernel news updates (although I don't understand them
all), it seems some cpu_freq fixes for the ibook 2 have been merged into the
2.6.9-mm series

http://kerneltrap.org/node/view/3846

It looks like the ppc kernel may need some looking into.

Maybe people could cat /proc/cpuinfo to see if the clock or CPU speed is
reporting properly. I know mine isn't. The clock should be 500mhz.

dkinakin@Channi ~ $ cat /proc/cpuinfo
processor : 0
cpu : 745/755
temperature : 18-20 C (uncalibrated)
clock : 400MHz
revision : 51.17 (pvr 0008 3311)
bogomips : 796.26
machine : PowerBook4,1
motherboard : PowerBook4,1 PowerBook2,2 MacRISC2 MacRISC Power Macintosh
detected as : 257 (iBook 2)
pmac flags : 0000000b
L2 cache : 256K unified
memory : 384MB
pmac-generation : NewWorld

Can you test suspend while X is not running? Log in on a text console and run
/etc/init.d/gdm stop, then close the lid, open it and see if it recovers any better.

(In reply to comment #12)
> Can you test suspend while X is not running? Log in on a text console and run
> /etc/init.d/gdm stop, then close the lid, open it and see if it recovers any
better.

Same failure on mine.

eth1: Airport enterinng sleep mode
eth0: suspending, wakeonlan disabled
aty128fb: suspending....
cpufreq: resume failed to assert current frequency is what timing core thinks it is
aty128fb: resumed!
enable_irq(27) unbalanced
enable_irq(28) unbalanced
eth0: resuming
eth1: Airport waking up
eth1: New link status: Connected (0001)

and there it hangs.

Testing 'sleep' without X makes no difference. The result is the same hung
system and screen message mentioned.

Since this is apparently not a regression, and merely hardware which isn't fully
supported yet, downgrading to normal

I'm not sure about this. I have an ibook also, and same problem here. But before
I was using Gentoo on my ibook, and with gentoo-sources-2.6.8 (linux kernel
2.6.8 with some patches), it got suspended perfectly when I closed the lid.

Why kernel-source-2.6.8 is not in Ubuntu repository, when the kernel-image
package that it's installed is 2.6.8.1? I saw this when I tried to patch the
source with gentoo patches, to test if then the ibook wakes up without problems.

With kernel 2.6.8 and this patches it was working on my ibook with Gentoo Linux:

http://ftp.caliu.info/pub/gentoo/distfiles/genpatches-2.6-8.55-base.tar.bz2
http://ftp.caliu.info/pub/gentoo/distfiles/genpatches-2.6-8.55-extras.tar.bz2

So probably one of them on the tarballs will fix the problem (sorry, I still
didn't check it, and still don't know about which of all is appropiate).

(In reply to comment #17)
> Why kernel-source-2.6.8 is not in Ubuntu repository, when the kernel-image
> package that it's installed is 2.6.8.1? I saw this when I tried to patch the
> source with gentoo patches, to test if then the ibook wakes up without problems.

The source for the Ubuntu kernel is in the package "linux-source-2.6.8.1".

I have an 800 MHz G3 dual USB ibook with the exact same problem noted in the
original bug report; suspend works fine, but resume/wake never finishes, and I
have to force a hard reboot. This has happened every time I suspend the laptop.

As a workaround, I have found that killing hald before suspending allows the
laptop to resume correctly. So far, after more than a dozen sleep-wake cycles,
this workaround has been 100% successful for me.

Ok, I test it and it seems that the problem was that. Hal service must be
stopped before entering suspend mode. I created a patch to fix it.

Created an attachment (id=507)
Fix ibook wake up problem

What particular actions are being executed by hald which cause problems with
resume? We should try to fix the root of the problem if we can, rather than
working around it by stopping hal.

Sure, but... I really don't know so much about hald, so at first I don't have
any idea about which action is the cause of the problem. Anyway, I think this
solution maybe ok at least while the problem was detected.

(In reply to comment #4)
> mine doesn't even turn off the backlight. Doesn't seem to want to sleep at all.

I have a clamshell ibook, 300mhz. It used to sleep just fine with debian's
2.4.25 kernel. After updating to ubuntu 2.6.7 it seems to sleep just fine except
for the backlight which doesn't go off. Using fblevel from the command line
doesnt have any effect either.

(In reply to comment #11)
> Maybe people could cat /proc/cpuinfo to see if the clock or CPU speed is
> reporting properly. I know mine isn't. The clock should be 500mhz.

Mine looks fine, its a clamshell ibook 300mhz.

sidnei@pita:~ $ cat /proc/cpuinfo
processor : 0
cpu : 740/750
temperature : 43-45 C (uncalibrated)
clock : 299MHz
revision : 131.0 (pvr 0008 8300)
bogomips : 595.96
machine : PowerBook2,1
motherboard : PowerBook2,1 MacRISC2 MacRISC Power Macintosh
detected as : 64 (iBook (first generation))
pmac flags : 0000000d
L2 cache : 512K unified
memory : 160MB
pmac-generation : NewWorld

Does removing the 'airport' module before you sleep make any difference?

I don't have an airport card and this module loaded, but I stopped all services
and unloaded most of the modules. Still the iBook does not sleep, if I close the
lid or press the power button shortly, just the display light goes out.

(In reply to comment #28)
> I don't have an airport card and this module loaded, but I stopped all services
> and unloaded most of the modules. Still the iBook does not sleep, if I close the
> lid or press the power button shortly, just the display light goes out.

I'm almost 100% certain that g4 ibooks (which we both have) will not
suspend-to-ram, for the reason Colin mentioned. g3 ibooks should work; David
Allouche has one, but iirc it was flakey for him. BenH would be the person to
ask to be sure.

(In reply to comment #27)
> Does removing the 'airport' module before you sleep make any difference?

No. Not on my system (800 MHz G3 dual USB ibook) -- it will only 'wake up' if
I kill hald before suspending.

grover@sleek:~ $ cat /proc/cpuinfo
processor : 0
cpu : 750FX
temperature : 4-7 C (uncalibrated)

clock : 800MHz
revision : 2.3 (pvr 7000 0203)
bogomips : 1585.15
machine : PowerBook4,3
motherboard : PowerBook4,3 MacRISC2 MacRISC Power Macintosh
detected as : 257 (iBook 2 rev. 2)
pmac flags : 0000000b
L2 cache : 512K unified
memory : 384MB
pmac-generation : NewWorld

BenH has sleep working on g4 ibooks and modern (ati-based) powerbooks with this
patch: http://gate.crashing.org/~benh/albook-ibookg4-sleep-4.diff, he's planning
to get it merged into 2.6.11. I still don't really know what sort of machine
the original person was using, tho.

Hi Herbert, could you include BenH's patch in your 2.6.9 kernels? (re-assigning
at Martin's request).

I run Debian and just started having this problem (precisely) in the 2.6.8
series. I have been suspending my iBook2 (dual USB 600MHz) for years without a
problem. I posted to debian-powerpc and got the following reply which may help
target the HAL problem. The solution works.

http://lists.debian.org/debian-powerpc/2005/01/msg00389.html

<<
I remember this being something to do with HAL polling the IDE CD-ROM.
See http://bugs.debian.org/286820 . To work around it, you can save the
following snippet as /etc/hal/fdi/local_disablecdrom.fdi (I guess you
can name it whatever you want as long as it goes into that directory).
This worked on my iBook G3:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
 <device>
  <match key="block.device" string="/dev/hdb">
   <merge key="storage.media_check_enabled" type="bool">false</merge>
  </match>
 </device>
</deviceinfo>

>>

Indeed, the system was polling the CD/DVD when it froze. Note: this workaround
doesn't fix the problem in HAL, it merely turns off autopolling of the CD/DVD.
I'll see if I can post a bug report to the HAL folks.

(I've marked this bug "upstream". That might be wrong, but it's clearly not
"New" anymore.)

(In reply to comment #33)

Actually this workaround is inferior to Carlos' patch (see attachments, above),
because this disables all CD/DVD polling, but the patch only disables it at
sleep. However I hope it helps someone resolve the real problem.

Could someone test whether this bug is still present with the current 2.6.10-2
kernel in Hoary?

(In reply to comment #35)
> Could someone test whether this bug is still present with the current 2.6.10-2
> kernel in Hoary?

My iBook (G3 800 MHz) is is running up to date hoary, and it is still affected
by this bug. I am running the 2.6.10-3-powerpc kernel.

(In reply to comment #35)
> Could someone test whether this bug is still present with the current 2.6.10-2
> kernel in Hoary?

Bug is still present on my iBook G3 900MHz running hoary with
kernel-2.6.10-2-powerpc :-(

Here, ibook G3 700Mhz with Hoary and same kernel. If I try to suspend with
airport interface down, then it works perfectly. But if I activate it, then
ibook doesn't wake up. Last messages are:

cpufreq: resume failed to assert current frequency is what timing core thinks it is
radeonfb: switching to D0 state...
eth1: no IPv6 routers present
radeonfb: resumed !
eth0: resuming
eth1: Airport waking up
eth1: New link status: Connected (0001)

Again, it seems to be a HAL problem. If I stop dbus-1 service before suspend,
then ibook go to sleep without problems. Putting the following script into
/etc/power/scripts.d/hal, and creating a link to it on /etc/power/event.d/hal,
did the trick. I know, as before, that this is not the greatest way to fix this,
but at least it works :-)

#!/bin/sh

# name : hal
# author : Carlos A. Paramio <email address hidden>
# description : Stops/starts hal service before/after suspend
# requirements:
# limitations :
#
# --- end of public part -- don't change below this line ---

PATH=/bin:/sbin:/usr/bin:/usr/sbin

case "$1" in
  powersave|custom)
    ;;
  performance)
    ;;
  suspend)
    /etc/init.d/dbus-1 stop
    ;;
  resume)
    /etc/init.d/dbus-1 start
    ;;
esac

Can somebody check what is hald doing with the kernel that causes this ?

Before the CD is woken up, the request queue is blocked, so it's normal that a
request issued
from hald blocks until the CD is woken up. But it's not normal that the kernel
stops, it should
proceed to the resume, and hald should unlock when the CD is ready again.

I need to know what is hald doing to check the cdrom (what kind of ioctl etc...)
so I can have a
look at what's going on in the kernel.

Yes, confirming I am still having issues with an iBook G3 800MHz. iBook hangs
while trying to wake up. Running Breezy. Last update 25/09/05

Confirming issues identical to Description on an iBook 700Mhz as of 10/2/2005 --
G3 bug has not been fixed.

Ok, that problem is really eluding me. Is there anybody in australia
(preferrably in Canberra) with such a machine that can lend it to me for a few
days ? I need physical access to properly experiment on that stuff...

Created an attachment (id=4305)
kernel logs of crash

Unfortunately, I'm far from Australia. But you asked for some debug info and
that I can provide.
I didn't think it useful to follow particular ioctls, since I get this error
just by opening the device. I removed
the debugging ifdefs from ide-io.c start_request, as you asked. I dumped the
dmesg of a functional sleep/resume
cycle, then made a bash script that did cat /dev/hdb in a loop. There was no cd
in the drive so it would return:
cat: /dev/hdb: No medium found
over and over. I then closed the lid.
The output doesn't seem all that useful to me (see attachments), but tell me
what else you need.

danny

Well, the machine starts waking up but it's not clear when it stops... If you
add printk's to generic_ide_resume() in drivers/ide/ide.c, is it called on
wakeup and does it return ? Maybe also add a printk to resume_device() in
drivers/base/power/resume.c (or replace the dev_dbg in there with a dev_printk)

Created an attachment (id=4323)
debug log of resuming from sleep

Ok, here is the logs you asked for. When it fails it does indeed not return
from generic_ide_resume. So it hangs somewhere during ide_do_drive_cmd. Since
in the working cycle it enables DMA for hda here I assume this is what makes it
stop.
Interestingly, it seems enabling dma on hda makes it stop, while the problem is
triggered by opening hdb.....

I will see if I can add further debug stuff in ide_do_drive_cmd

danny

I wonder if we are getting any interrupt at all on wakeup when the problem
happens... Can you try adding a printk to arch/ppc/kernel/irq.c -> do_IRQ()...
actually, best is probably to define a global "have_slept" that default to 0,
and that you set to 1 somewhere in ide suspend code or some other place in the
suspend path and test it before doing the printk so your boot dmesg doesn't get
completely swamped with irq messages.

I think do_IRQ is called. If I do as you suggest, when the machine freezes, do_IRQ is called over and over again,
indefinitely.

Some printk in ide_do_request suggests that it does not reach this line:
if (drive->blocked && !blk_pm_request(rq) && !(rq->flags & REQ_PREEMPT)) {
on a failed wakeup, it backs out of that function it seems because i do seem to reach wait_for_completion in
ide_do_drive_cmd

I continue adding printks...

That last message was a bit wrong:

hda: generic_ide_resume called
ide_do_request: at start
ide_do_request: while not busy (just after while (!hwgroup->busy) { )
ide_do_request: before check if rq is empty (before rq = elv_next_request(drive->queue); )
ide_do_request: before the test if request is accepted (before if (drive->blocked && !blk_pm_req.......... )
ide_do_request: before start_request (I think this is absent when it crashes!)
ide_do_drive_cmd: request done, waiting for completion (before waiting_for_completion)
(here it freezes)
ide_do_request: at start
ide_do_request: while not busy
ide_do_request: before check if rq is empty
ide_do_request: before the test if request is accepted
ide_do_request: before start_request
hda: Enabling Ultra DMA 2
ide_do_request: at start
ide_do_request: while not busy
ide_do_request: before return
generic_ide_resume returns 0

Interestingly, there is a line absent when it crashes. If I've got that correctly this means it breaks out of
ide_do_request here:

                if (drive->blocked && !blk_pm_request(rq) && !(rq->flags & REQ_PREEMPT)) {
                        /* We clear busy, there should be no pending ATA command at this point. */
                        hwgroup->busy = 0;
                        break;
                }

No idea why that should be a problem though.
I'm going to double check if the line was really missing now.

danny

I added:
printk("%s: breaking out\n",drive->name);
before the break statement.
indeed, it says: hdb: breaking out.

I assume this is because the queue for hdb is filled with my requests to open the cdrom.

Could it be that it doesn't want to process the PM requests because these other requests are still in the list?

It looks like your request for opening the CD-ROM is getting ahead of the wakeup
request... that is pretty bad indeed. The wakeup request should be inserted at
the head of the queue and thus should be the first request to be processed. I'll
have a look to the code later today again and try to see why that happens, this
is definitely bothering me.

hmm, since you didn't reply yet I was looking at it again. I may be wrong here, but it seems to be that it only called
ide_resume for hda, but when processing this request, it is waiting for all drives, including hdb, but there is no
REQ_PM_RESUME issued yet!

I could have misunderstood how this is supposed to work though.

if what i said it correct, it will never be able to wake up hda. Why is there a break statement instead of continuing
with the next drive? Perhaps I will try changing this.

Created an attachment (id=4375)
patch to fix wakeup on ibook g3

This patch fixes the problem for me. However; it is very ugly, and it may even
cause other bugs due to my limited understanding of all this code.

Ben, you wrote part of this stuff i think, I hope you can find a cleaner fix:)

Good catch ! In fact, this uncovers more problems with the logic in that
function, not only the PM case. Your fix will probably work though you may also
hit a couple of nasty cases if the other drive's queue is plugged for example.
I'm discussing the problem with the IDE maintainers and will come back when I
have a proper fix.

Created an attachment (id=4376)
Temporary fix

In the meantime, here's a slightly more correct version of your fix, please let
me know if it works

Bumping to P1 so I can get this into the next release for breezy.

for me, your patch works fine. For the hal case, but also when stressing hda/hdb in other ways.

I've read your lkml post. You were right in assuming changing break in continue does not work, I tried that before trying
the goto, but with a 'continue', choose_drive keeps on returning hdb, even when entering sleep, so hda never gets
suspended, and it hangs on sleep.
I think some thinking is needed about choose_drive though. It seems wrong that flooding the slave can prevent requests to
the master getting through. Currently, it is not looking at the respective queues at all.

I've added the patch to my mandriva cooker contrib kernel (sorry for the blasphemy on ubuntu bugzilla) to give it some
broader testing. Will report here as well in case of problems.

i have a 600Mhz snow ibook (dual usb) running fully upto date breezy and i still
have this problem

Does this latest breezy have the patch ? Also, when you say "same problem",
please be more precise as there are at least 3 different problems that have been
sort-of throwed under the same bug here :) So define precisely what happens on
wakeup, do you get video back or not at all ? etc...

yes ben, my ibook it totally upto date (latest breezy).

the problem that i get is the one described in this bug
(ibook sleeps fine, but hangs when waking up displaying something about eth1:
but seemingly unrelated to it).

there has been some talk it is caused by hald (and the cdrom) and if i kill hald
before sleeping, it works fine.

this bug is still not fixed.

then i think breezy doesn't have the patch Ben posted. Recompile your kernel with the patch?

This bug has been flagged because it is old and possibly inactive. It may or may
not be fixed in the latest release (Breezy Badger 5.10). It is being marked as
"NEEDSINFO". In two weeks time, if the bug is not updated back to "NEW" and
validated against Breezy, it will be closed.

This is needed in order to help manage the current bug list for the kernel. We
would like to fix all bugs, but need users to test and help with debugging.

If this change was in error for this bug, please respond and make the
appropriate change (or email <email address hidden> if you cannot make the
change).

Thanks for your help.

I'm not sure how kernel updates with Ubuntu work, but I'm running an iBook
G3/900 and i'm having the freeze-on-resume problem discussed here.
Disabling/restarting hald/dbus fixes it. I'm running an up-to-date breezy
install, so I'm guessing Ben's patch hasn't made it into the Breezy kernel? I
just downloaded linux-tree and checked both the kernel sources and the patch and
I don't see Ben's fix in there.

Any chance we can get this fix into the next ppc kernel update for breezy so
that things just work for us ibook g3 users? when would the next breezy ppc
kernel update happen?

This bug continues to be present in Ubuntu released kernels (I'm running a fully
up-to-date breezy install).

I applied Ben's patch to the Ubuntu kernel source and compiled a new kernel
about one month ago. I can confirm that the patch does fix the problem, and it
doesn't appear to introduce any new problems, at least, it's been rock solid on
my iBook.

Can we get this patch into the official Ubuntu kernel, please? There are quite
a few people who are using these laptops and experiencing this bug.

(In reply to comment #39)
> I know, as before, that this is not the greatest way to fix this,
> but at least it works :-)

yes, it does fix the problem in breezy, after slight modification:
/etc/init.d/dbus-1 must be replaced with /etc/init.d/dbus.

(In reply to comment #87)
Ben, the problem is still present in the lates breezy. Resuming iBook G3/900
would stop with messages about my NIC. Please, use Ben's patch when compiling
the next kernel update for Breezy, or, alternatively, supply an updated hal
script desribed in comment #39 for PPC users. Without that, Ubuntu experience is
quite bad on G3 iBooks.

(In reply to comment #90)
> (In reply to comment #39)
> > I know, as before, that this is not the greatest way to fix this,
> > but at least it works :-)
>
> yes, it does fix the problem in breezy, after slight modification:
> /etc/init.d/dbus-1 must be replaced with /etc/init.d/dbus.

I've just noticed a problem with this script - after sleeping/resuming, USB and
CD disks are no longer automounted... :(

Could we please, PLEASE get this in the next Breezy kernel? I'm on the latest
and this problem is *really* annoying. The scripts are finicky at best, but
I've got the kernel patch up and running (4 hours later). Please?

This may just be my ignorance, but I don't think this issue occurs in the latest
Vanilla kernel.

Patch is integrated upstream, so is in dapper 2.6.15.

(In reply to comment #93)
> Patch is integrated upstream, so is in dapper 2.6.15.

And what should people with Breezy do? Go Dapper???? Yeah, I have it on my PC. I
don't even get a good image onscreen. So I believe dapper is much too immature
for "an average user".

Would you PLEASE PLEASE PLEASE integrate that into a breezy stock kernel too? As
a user of Ubuntu, i'm severly pissed off by the fact that I cannot get my
computer back after each and every suspend forced by battery runout, and
randomly, after normal suspends.

Of course, I can compile myself a patched kernel, or use one from Dapper, but is
it so damn impossible to fix a REALLY BIG problem in your ultra-stable release
version of OS?

Mr. Collins, I promise to buy you a beer if you intergrate this patch into a
default kernel of Breezy. ;)

(In reply to comment #94)
> (In reply to comment #93)
> > Patch is integrated upstream, so is in dapper 2.6.15.
>
> And what should people with Breezy do? Go Dapper????

That or simply wait. The kernel team is busy enough, Breezy will only receive
security updates.

(In reply to comment #95)

> That or simply wait. The kernel team is busy enough, Breezy will only receive
> security updates.

Oh,

And don't you think a situation potentially leading to loss of data even on a
single-user system not connected to internet, and even without him (the user)
executing some arbitrary code IS a security issue?

> Oh,
>
> And don't you think a situation potentially leading to loss of data even on a
> single-user system not connected to internet, and even without him (the user)
> executing some arbitrary code IS a security issue?

I've never heard of losing data as being a security issue. Unless of course you
lost it to someone else.

(In reply to comment #97)
> > Oh,
> >
> > And don't you think a situation potentially leading to loss of data even on a
> > single-user system not connected to internet, and even without him (the user)
> > executing some arbitrary code IS a security issue?
>
> I've never heard of losing data as being a security issue. Unless of course you
> lost it to someone else.

Here's a similar entry in the kernel changelog:
  * [SECURITY]: Fix a typo with the overtemp code in the g5 thermal driver can
    cause abrupt shutdowns on some machines. Theoretically a user could perform
    a local DoS abusing the CPU to the point where the machine will shutdown:
    - Add patch drivers-macintosh-thermpm72_CVE-2005-XXXX.dpatch.

Not much difference from our situation, except that you don't need to heat up
the CPU to trigger this bug, just closing the lid is enough.
I still don't get it - why can't a patch that is ready be incorporated into your
kernel along with (other) security patches?..

(In reply to comment #98)
> Here's a similar entry in the kernel changelog:
> * [SECURITY]: Fix a typo with the overtemp code in the g5 thermal driver can
> cause abrupt shutdowns on some machines. Theoretically a user could perform
> a local DoS abusing the CPU to the point where the machine will shutdown:
> - Add patch drivers-macintosh-thermpm72_CVE-2005-XXXX.dpatch.
>
> Not much difference from our situation, except that you don't need to heat up
> the CPU to trigger this bug, just closing the lid is enough.
> I still don't get it - why can't a patch that is ready be incorporated into your
> kernel along with (other) security patches?..

You're comparing a DoS to this bug? These are quite different things. First off,
you can work around this problem by disabling the suspend/resume. Second, the
person who "closes your lid" has to have physical access to your machine, so
that kind of negates any security expectations. The thermal bug could be induced
by a normal user who has remote login. Not the same sort of thing.

(In reply to comment #99)
> (In reply to comment #98)
> > Here's a similar entry in the kernel changelog:
> > * [SECURITY]: Fix a typo with the overtemp code in the g5 thermal driver can
> > cause abrupt shutdowns on some machines. Theoretically a user could perform
> > a local DoS abusing the CPU to the point where the machine will shutdown:
> > - Add patch drivers-macintosh-thermpm72_CVE-2005-XXXX.dpatch.
> >
> > Not much difference from our situation, except that you don't need to heat up
> > the CPU to trigger this bug, just closing the lid is enough.
> > I still don't get it - why can't a patch that is ready be incorporated into your
> > kernel along with (other) security patches?..
>
> You're comparing a DoS to this bug? These are quite different things.

I'm comparing the results. In both cases, machine hangs, someone might loose
data. NOT to anyone else though.

> First off, you can work around this problem by disabling the suspend/resume.

Sure I can. I also have enough knowledge to recompile my kernel. But i don't
think i'm the only person running Breezy on a white iBook in the world.
Furthermore, what I want is a working solution of the problem, not a workaround.
Cuz the best workaround might be simply using OS X.

> Second, the
> person who "closes your lid" has to have physical access to your machine, so
> that kind of negates any security expectations.

As I said, I've resolved the problem with closing the lid. The problem is that
there are cases (like a battery runout) when the laptop goes to sleep without my
explicit actions. And because I have a buggy charger, which somehow randomly
stops charging while i'm at home (while it works perfectly when i'm at work),
this problem hits me even harder - if I leave my laptop on overnight i can be
almost certain that in the morning I'll have to press cmd-ctrl-power to bring it
back from suspended state.

> The thermal bug could be induced by a normal user who has remote login. Not
the same sort of thing.

As I said, for me personally, this bug gets induced without any interference
from me or anyone else. Why do you resist so hard?

FYI. The patch is upstream (been since 2.6.14 afaik, though the later has other
annoying issues with USB I recomment 2.6.15-rc* to powerbook users). Also, it
might be useful to you guys to know that the bug does occasionally trigger on
x86 too. I don't fully understand your distribution policy on taking only
security fixes and no bug fixes though but it's your call. In any cases, you
(users) can just build the kernel yourself, it's not that complicated :)

(In reply to comment #101)
> FYI. The patch is upstream (been since 2.6.14 afaik, though the later has other
> annoying issues with USB I recomment 2.6.15-rc* to powerbook users). Also, it
> might be useful to you guys to know that the bug does occasionally trigger on
> x86 too. I don't fully understand your distribution policy on taking only
> security fixes and no bug fixes though but it's your call. In any cases, you
> (users) can just build the kernel yourself, it's not that complicated :)

Security patches for stable releases is an issue of overhead right not. It's a
lot of work rebuilding the kernel, and testing it.

That will hopefully change for dapper when it is released, but breezy is getting
treated pretty much the same as before.

Not to mention that dapper isn't all that unstable right now. I run it on all of
my machines (including my G4 and G5, and soon my new powerbook). It's not
suggested, but it definitely works well.

(In reply to comment #102)
> (In reply to comment #101)
> Security patches for stable releases is an issue of overhead right not. It's a
> lot of work rebuilding the kernel, and testing it.

You shouldn't call Breezy a STABLE release if you treat it like that. What I'm
facing on my laptop is a huge stability issue, so i'd rather call breezy SECURE
than STABLE, in this case. Go on. Of course, being the sole user of this laptop,
I care about local root exploits much less than about the fact, that I cannot
close a lid of my laptop (or run out of battery charge) without having to cold
reboot my beautiful white notebook with its beautiful and STABLE brown OS. But
sure, that's just me. Who cares. Linux won the desktop already, yeah, sure.

> Not to mention that dapper isn't all that unstable right now. I run it on all of
> my machines (including my G4 and G5, and soon my new powerbook). It's not
> suggested, but it definitely works well.

Yes, I have dapper with Xfce on my DELL Pentium3 desktop at home. No thanks, I
don't yet want it to be my main OS. First, I was facing displaced icons on each
and every GUI widget, regardless of it belonging to Qt or GTK. Now, I cannot
install xterminal which I had to remove during dist-upgrade because of its
broken dependencies. And Xfce Panel keeps crashing. No, thanks, really. What I
want is a stable OS. And what I want is stability updates to be provided along
with security updates. And I believe that for desktops, paranoid security is
often much less important than stability.

And BTW, If I wanted so much to compile and tweak my system a lot, I'd probably
go Gentoo. I use Ubuntu because I like its defaults. And by annoingly asking to
fix this stability bug in a release that is claimed to be stable, I just want
Ubuntu to be better, not more bloated.