Bug 186952 - suspend on g4/ppc tibook gives kernel badness
Summary: suspend on g4/ppc tibook gives kernel badness
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard: MassClosed
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-03-27 17:10 UTC by Aldy Hernandez
Modified: 2008-01-20 04:40 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-01-20 04:40:54 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Aldy Hernandez 2006-03-27 17:10:05 UTC
Description of problem:
Running "pm-suspend" does not work and dumps "Badness in wait_for_ready at
drivers/ide/ide-iops.c:516".  Details below.

Version-Release number of selected component (if applicable):


How reproducible:
Every time.

Steps to Reproduce:
1. Run pm-suspend
2. Look at kernel messages.
3.
  
Actual results:
It blanks the screen, but after a few microseconds, returns with the kernel
messages displaying this:

PM: Entering mem sleep
pmac_pm_enter(3)
PM: Finishing wakeup.
radeonfb (0000:00:10.0): resuming from state: 2...
radeonfb (0000:00:10.0): switching to D0 state...
agpgart: Putting AGP V2 device at 0000:00:0b.0 into 1x mode
agpgart: Putting AGP V2 device at 0000:00:10.0 into 1x mode
PM: Writing back config space on device 0001:10:1a.0 at offset 1. (Was 2100003,
writing 2100007)
eth0: resuming
PHY ID: 1410c62, addr: 0
eth1: Airport waking up
eth1: New link status: Connected (0001)
hda: Enabling Ultra DMA 4
Badness in wait_for_ready at drivers/ide/ide-iops.c:516
Call Trace:
[C0393C40] [C0007A50] show_stack+0x54/0x184 (unreliable)
[C0393C60] [C000E564] program_check_exception+0x19c/0x520
[C0393CB0] [C000FC24] ret_from_except_full+0x0/0x4c
--- Exception: 700 at wait_for_ready+0x94/0xec
    LR = wait_for_ready+0x3c/0xec
[C0393D70] [C005A18C] disable_irq_nosync+0x7c/0x90 (unreliable)
[C0393D90] [C01DF410] pmac_ide_do_setfeature+0x108/0x320
[C0393DB0] [C01DF930] pmac_ide_dma_check+0x308/0x490
[C0393DE0] [C01D3740] ide_do_request+0x618/0x8cc
[C0393E50] [C01D3D84] ide_intr+0x204/0x240
[C0393E80] [C0059E28] handle_IRQ_event+0x54/0xa8
[C0393EA0] [C0059F80] __do_IRQ+0x104/0x188
[C0393EC0] [C00057E8] do_IRQ+0x4c/0x7c
[C0393EE0] [C000FC70] ret_from_except+0x0/0x14
--- Exception: 501 at default_idle+0x3c/0x44
    LR = default_idle+0x34/0x44
[C0393FA0] [C00247C0] cpu_idle+0x3c/0x5c (unreliable)
[C0393FB0] [C0003E70] rest_init+0x28/0x38
[C0393FC0] [C0394720] start_kernel+0x19c/0x1b0
[C0393FF0] [000037A0] 0x37a0
hdc: Enabling MultiWord DMA 2
Restarting tasks... done
pmac_pm_finish(3)


Expected results:
It should suspend.

Additional info:

Comment 1 Aldy Hernandez 2006-03-28 15:39:42 UTC
At dwmw2's request, I have installed the apmud package, and run pmud.  This
package appears to be in the extras, but I'm including the info here just in
case it's useful.  (BTW, if this is the only way of getting suspend on the
PowerBooks, we should include "apmud" in the core distribution and enable it on
PowerBook installs.)

With apmud, the laptop goes to sleep, but when it wakes up, the screen turns on
but is blank.  The machine becomes unpingable, but capslock works.

I am trying this from text mode (runlevel 3), as switching back to X doesn't
work even without suspend (see #187083).

I've tried this both with calling "apm" directly, and with closing the lid.  I
have seen it work once or twice, but very rarely.  When I *have* seen it work,
upon return, I see the kernel badness I describe above.

Perhaps 187083 and this issue are related ??


Comment 2 David Woodhouse 2006-03-28 17:18:50 UTC
What if you run 'snooze' or 'snooze -f'? What if you unload various driver
modules before suspending?

Comment 3 Aldy Hernandez 2006-03-28 22:44:19 UTC
Neither work.  Or both work rarely (snooze or snooze -f).

I disabled as many services in /etc/rc.d/init.d/ as was possible, then I removed
as many modules as possible.  Still, calling snooze -f, would not work (actually
it worked the first time, upon returning displayed the kernel badness described,
and the second time it died as usual).  So no difference.

Here are a list of the remaining modules once I purged everything:

Module                  Size  Used by
sunrpc                188488  1
ipv6                  307364  8
dm_mod                 67616  3
ext3                  156808  2
jbd                    78068  1 ext3

I also tried going into single user mode.  No difference.

Comment 4 Aldy Hernandez 2006-03-31 16:52:56 UTC
FWI, this issue is not related to 187083.

Comment 5 Benjamin Herrenschmidt 2006-05-26 07:38:48 UTC
Looks like the IDE layer is now calling the DMA restore code at interrupt time,
which is a bit dodgy for the powermac... I'm surprised it doesn't cause a
problem for me. Then, disable_irq_nosync() should be fine to call at interrupt
time too anyway... not sure what the bug on is about at this point

Comment 6 Dave Jones 2006-10-16 19:13:07 UTC
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Comment 7 Jon Stanley 2008-01-20 04:40:54 UTC
(this is a mass-close to kernel bugs in NEEDINFO state)

As indicated previously there has been no update on the progress of this bug
therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue
still occurs for you and I will try to assist in its resolution. Thank you for
taking the time to report the initial bug.

If you believe that this bug was closed in error, please feel free to reopen
this bug.


Note You need to log in before you can comment on or make changes to this bug.