Re: TEST: Sleep patch #7 [imap problem]
On Tue, 2005-01-18 at 00:10 +0100, Guillaume Florey wrote: Sleep patch #7 from benh works fine, but after resuming, I always lost my connection to a imap server, If the sleep is longer than 20 minutes or so, TCP connections will time out. the only way to solve it, is to restart kde and networking... Sounds like a kmail/KDE issue. Kmail gives me also an interesting progress bar when I wanted to check my mail after resume: http://n.ethz.ch/student/floreyg/download/powerbook/kmail.png = -1% (woaw, that mean I'm going to download emails, that are not yet written, or what ?? :-) No, it means it's eating your mail. ;) -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: TEST: Sleep patch #7
Benjamin Herrenschmidt wrote: So my configuration is: iBookG4 800 Mhz running on 600 Mhz, cpufreqd disabled. Firewire is enabled ( no devices attached ) Sound is enabled ( no audio streams open ) USB is enabled ( no devices attached ) This seems to run rather stable. So it seems that enabling cpufreqd causes memory corruption when the frequency changes. What are the boot messages displayed by the cpufreq stuff when it's enabled ? (does it use gpio-based switching or pmu based switching ?) Hmm, this is strange. I was not able to spot such a message and it is not in the dmesg output. Am I missing something? /Arne
Re: TEST: Sleep patch #7
Michael Schmitz wrote: Let me just add that powernowd works fine with sleep patch #7 here Be cautious! It seemed to work fine for me. Only when I do a large compile immediately after reboot, the system gets instable. Can you try this: Start a Linux kernel compile; suspend the compile with Ctrl-Z; suspend the computer; recover the computer; continue the compile. This causes erratic behavious on my system ( with cpufreq installed ). /Arne
Re: TEST: Sleep patch #7
Let me just add that powernowd works fine with sleep patch #7 here Be cautious! It seemed to work fine for me. Only when I do a large compile immediately after reboot, the system gets instable. Can you try this: Start a Linux kernel compile; suspend the compile with Ctrl-Z; suspend the computer; recover the computer; continue the compile. This causes erratic behavious on my system ( with cpufreq installed ). IIRC I put the system to sleep right in the middle of a batch compile. Survived just fine (again, powernowd not cpufreqd). sleep7 is rock solid, by my standard (and I've tested a few other versions before that I had crash a lot more often, mostly in the middle of some longish scroll operation in X). About the only issue I have with sleep7 is firewire - disks connected over sleep need to be replugged after wakeup. If I remember that, fine, otherwise I can only reboot. I don't do crazy stuff like unplugging mice before wakeup, mind you. And USB/firewire sleep support is being worked on by the respective maintainers, and not really an issue with Ben's patch. Michael
Re: TEST: Sleep patch #7
So my configuration is: iBookG4 800 Mhz running on 600 Mhz, cpufreqd disabled. Firewire is enabled ( no devices attached ) Sound is enabled ( no audio streams open ) USB is enabled ( no devices attached ) This seems to run rather stable. So it seems that enabling cpufreqd causes memory corruption when the frequency changes. What are the boot messages displayed by the cpufreq stuff when it's enabled ? (does it use gpio-based switching or pmu based switching ?) Ben.
Re: TEST: Sleep patch #7
I know :) The point of the exercice is to test wether the problem originates from the firewire drivers ... I finally came around to repeat the test with CPUfreq disabled: No crash so far. So my configuration is: iBookG4 800 Mhz running on 600 Mhz, cpufreqd disabled. Firewire is enabled ( no devices attached ) Sound is enabled ( no audio streams open ) USB is enabled ( no devices attached ) This seems to run rather stable. So it seems that enabling cpufreqd causes memory corruption when the frequency changes. Let me just add that powernowd works fine with sleep patch #7 here (AlBook). USB attached devices survive resume with no problem, ieee1394 attached devices need replugging after resume. Michael
Re: TEST: Sleep patch #7
Benjamin Herrenschmidt wrote: I do not have any USB device ( only firewire ). But I will disable CPUfreq again. I had it always disabled with the old patches and only enabled it as you said it should be save now with #7 ;-) Hrm... try without firewire too, just in case ... I can not, I am a firewire developer ;-) I know :) The point of the exercice is to test wether the problem originates from the firewire drivers ... I finally came around to repeat the test with CPUfreq disabled: No crash so far. So my configuration is: iBookG4 800 Mhz running on 600 Mhz, cpufreqd disabled. Firewire is enabled ( no devices attached ) Sound is enabled ( no audio streams open ) USB is enabled ( no devices attached ) This seems to run rather stable. So it seems that enabling cpufreqd causes memory corruption when the frequency changes. /Arne
Re: TEST: Sleep patch #7
On Mon, 2004-12-20 at 11:10 +0100, Benjamin Herrenschmidt wrote: I never tried with XFS, it would be related. At this point, it's very stable for me except some occasional video related lockups on wakeup which I'm investigating. I've been running with XFS since the moment patch1 came out (have stayed with patch1 though). No problems (maybe one crash in the whole time). -- Stewart Smith ([EMAIL PROTECTED]) http://www.flamingspork.com/ signature.asc Description: This is a digitally signed message part
Re: TEST: Sleep patch #7
Benjamin Herrenschmidt wrote: On Mon, 2004-12-20 at 12:27 +0100, Arne Caspari wrote: Benjamin Herrenschmidt wrote: Can you try not plugging any USB device (in case you have any), does that make any difference ? also not building the USB OHCI driver at all... Also, can you try not using cpufreq (or not building it) Let me know if any of these makes any difference. Ben. I do not have any USB device ( only firewire ). But I will disable CPUfreq again. I had it always disabled with the old patches and only enabled it as you said it should be save now with #7 ;-) Hrm... try without firewire too, just in case ... I can not, I am a firewire developer ;-) /Arne
Re: TEST: Sleep patch #7
Arne Caspari wrote: Benjamin Herrenschmidt wrote: Hrm... try without firewire too, just in case ... I can not, I am a firewire developer ;-) I can't believe that you can't cooperate just compiling for a few moments a new kernel without firewire support. It would serve just to rule out some variables. You know, you won't have to run this experimental kernel for the rest of your life. Surprisedly yours, Rogério Brito. -- Learn to quote e-mails decently at: http://pub.tsn.dk/how-to-quote.php http://learn.to/quote http://www.xs4all.nl/~sbpoley/toppost.htm
Re: TEST: Sleep patch #7
I do not have any USB device ( only firewire ). But I will disable CPUfreq again. I had it always disabled with the old patches and only enabled it as you said it should be save now with #7 ;-) Hrm... try without firewire too, just in case ... I can not, I am a firewire developer ;-) I know :) The point of the exercice is to test wether the problem originates from the firewire drivers ... Ben.
Re: TEST: Sleep patch #7
Benjamin Herrenschmidt schrieb: I do not have any USB device ( only firewire ). But I will disable CPUfreq again. I had it always disabled with the old patches and only enabled it as you said it should be save now with #7 ;-) Hrm... try without firewire too, just in case ... I can not, I am a firewire developer ;-) I know :) The point of the exercice is to test wether the problem originates from the firewire drivers ... Sure, but I doubt that it is the IEEE-1394 drivers since I did not have problems with the previous patches and CPUfreq disabled. I will try again with CPUfreq disabled and let you know my results. Unfortunately I am ill at home now and have not taken my power cord with me so it will have to wait a little bit more. BTW.: Are you able to unload IEEE-1394 modules on your machine, ie. rmmod eth1394 does not block? -Arne
Re: TEST: Sleep patch #7
On Mon, 2004-12-20 at 10:41 +0100, Arne Caspari wrote: Hi, I ran a big compile, suspended this compile, put the device to sleep, resumed and then continued the compile. After a while, the machine rebooted. Below is what I found in the kernel log. This happens frequently if I do a compile after sleep. Sometimes the X Server crashes and sometimes the whole machine crashes. Remind me the machine model ? I never tried with XFS, it would be related. At this point, it's very stable for me except some occasional video related lockups on wakeup which I'm investigating. Ben.
Re: TEST: Sleep patch #7
Benjamin Herrenschmidt wrote: On Mon, 2004-12-20 at 10:41 +0100, Arne Caspari wrote: Hi, I ran a big compile, suspended this compile, put the device to sleep, resumed and then continued the compile. After a while, the machine rebooted. Below is what I found in the kernel log. This happens frequently if I do a compile after sleep. Sometimes the X Server crashes and sometimes the whole machine crashes. Remind me the machine model ? Oh sure, sorry. iBook G4 800 Mhz processor : 0 cpu : 7455, altivec supported clock : 798MHz revision: 3.3 (pvr 8001 0303) bogomips: 804.39 machine : PowerBook6,3 motherboard : PowerBook6,3 MacRISC3 Power Macintosh detected as : 287 (iBook G4) pmac flags : 001b L2 cache: 256K unified memory : 256MB pmac-generation : NewWorld I never tried with XFS, it would be related. At this point, it's very stable for me except some occasional video related lockups on wakeup which I'm investigating. I regret that I installed XFS but back the time I installed Linux, the best HOWTO was for XFS. Nowadays I would install Ubuntu on ext3. /Arne Ben.
Re: TEST: Sleep patch #7
iBook G4 800 Mhz processor : 0 cpu : 7455, altivec supported clock : 798MHz revision: 3.3 (pvr 8001 0303) bogomips: 804.39 machine : PowerBook6,3 motherboard : PowerBook6,3 MacRISC3 Power Macintosh detected as : 287 (iBook G4) pmac flags : 001b L2 cache: 256K unified memory : 256MB pmac-generation : NewWorld I never tried with XFS, it would be related. At this point, it's very stable for me except some occasional video related lockups on wakeup which I'm investigating. I regret that I installed XFS but back the time I installed Linux, the best HOWTO was for XFS. Nowadays I would install Ubuntu on ext3. Can you try not plugging any USB device (in case you have any), does that make any difference ? also not building the USB OHCI driver at all... Also, can you try not using cpufreq (or not building it) Let me know if any of these makes any difference. Ben.
Re: TEST: Sleep patch #7
Benjamin Herrenschmidt wrote: Can you try not plugging any USB device (in case you have any), does that make any difference ? also not building the USB OHCI driver at all... Also, can you try not using cpufreq (or not building it) Let me know if any of these makes any difference. Ben. I do not have any USB device ( only firewire ). But I will disable CPUfreq again. I had it always disabled with the old patches and only enabled it as you said it should be save now with #7 ;-) /Arne
Re: TEST: Sleep patch #7
On Mon, 2004-12-20 at 12:27 +0100, Arne Caspari wrote: Benjamin Herrenschmidt wrote: Can you try not plugging any USB device (in case you have any), does that make any difference ? also not building the USB OHCI driver at all... Also, can you try not using cpufreq (or not building it) Let me know if any of these makes any difference. Ben. I do not have any USB device ( only firewire ). But I will disable CPUfreq again. I had it always disabled with the old patches and only enabled it as you said it should be save now with #7 ;-) Hrm... try without firewire too, just in case ... Ben.
Re: TEST: Sleep patch #7
On 21:34, Sun 05 Dec 04, Benjamin Herrenschmidt wrote: Ok, here's the 7th version of the sleep patch for ATI based albooks iBook G4. Other machine users, please test too as it may cause regressions (or improvements) as well. http://gate.crashing.org/~benh/albook-ibookg4-sleep-7.diff Ben, Just wanted to say I've tested the patch on a vanilla 2.6.9 kernel running on a 2004 ibook G4 1Ghz. Everything works nicely, on AC power I can close the lid and the machine sleeps, this is with a USB mouse and ethernet cable plugged in. When I open the lid the machine wakes up and everything seems to work fine, including the mouse :) I get the same results using the battery. I've tested long periods of sleep, about eight hours at a time and the machine wakes up with no problems. The only kernel panic I got was when I unplugged the mouse during sleep. The machine paniced when it work up but I expected this behaviour. I'm gonna go give it a go with the debian 2.6.9 source. Thanks for all the hard work, it's nice to have a sleeping ppc machine. Gavin [EMAIL PROTECTED]:proc[0]$ cat cpuinfo processor : 0 cpu : 7447A, altivec supported clock : 1066MHz revision: 1.1 (pvr 8003 0101) bogomips: 1060.86 machine : PowerBook6,5 motherboard : PowerBook6,5 MacRISC3 Power Macintosh detected as : 287 (iBook G4) pmac flags : 001b L2 cache: 512K unified memory : 1280MB pmac-generation : NewWorld [EMAIL PROTECTED]:proc[0]$ -- Gavin Sandie public pgp key: http://q3a.co.uk/pgp.key signature.asc Description: Digital signature
Re: TEST: Sleep patch #7
Rogério Brito [EMAIL PROTECTED] writes: If the his e-mails in the past are still relevant, Ben is against having CONFIG_PREEMPT enabled (for powerpc, at least). oh, i see. i'll dig the archives. just for the record, i've been using ben's patches 4 to 6 on a new ibook g4 with preempt enabled without a glitch [1] so far (kudos to him for his excellent work!). thanks, jao Footnotes: [1] well, except for problems with alsa/gtkpbbuttons, but i don't think they're related with the sleep patchs.
Re: TEST: Sleep patch #7
X crashed after a few suspend/resume cycle on my ibook g4 Note that I put it to sleep during a compilation (I pushed my luck too far) kernel: Oops: kernel access of bad area, sig: 11 [#1] kernel: NIP: C005C798 LR: C005C944 SP: D6FFBEE0 REGS: d6ffbe30 TRAP: 0300 Not tainted kernel: MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 kernel: DAR: 0034, DSISR: 4000 kernel: TASK = cb848090[25535] 'ope' THREAD: d6ffa000Last syscall: 4 kernel: GPR00: C02C8594 D6FFBEE0 CB848090 FFF7 C0C22D00 002D D6FFBF20 kernel: GPR08: 0002 100812E0 1006 7FFFC7E8 kernel: GPR16: 1008 100B3128 1008 7FFFA070 0FE41798 7FFF9760 kernel: GPR24: 002D 002D 7FFF7050 002D D6FFBF20 DCEE8F00 DCEE8F00 kernel: NIP [c005c798] vfs_write+0x8c/0x154 kernel: LR [c005c944] sys_write+0x50/0x94 kernel: Call trace: kernel: [c005c944] sys_write+0x50/0x94 kernel: [c0007d40] ret_from_syscall+0x0/0x44 cat /proc/cpuinfo processor : 0 cpu : 7455, altivec supported clock : 606MHz revision: 3.3 (pvr 8001 0303) bogomips: 610.30 machine : PowerBook6,3 motherboard : PowerBook6,3 MacRISC3 Power Macintosh detected as : 287 (iBook G4) pmac flags : 001b L2 cache: 256K unified memory : 640MB pmac-generation : NewWorld I have apm_bios with apm emulation enabled, and AGPMode 4 in X11 config -- Sylvain Joyeux
Re: TEST: Sleep patch #7
Benjamin Herrenschmidt wrote: On Mon, 2004-12-06 at 20:04 -0200, Federico Gamio wrote: On Sun, 2004-12-05 at 21:34 +1100, Benjamin Herrenschmidt wrote: (As usual, I'm cross posting several lists, please don't reply to all of them, and CC me as I'm not subscribed to all of them neither) Ok, here's the 7th version of the sleep patch for ATI based albooks iBook G4. Other machine users, please test too as it may cause regressions (or improvements) as well. My 15 PowerBook (1.25Ghz, ATI 9600, PowerBook5.2) has the same problem with suspend to ram patch. I can suspend closing the lid or pushing the power button (I use pbbuttonsd) and all works perfect. I can repeat this for several times, but in some cases they don't want to go sleep and the LCD remains active. If I try to shutdown with init 0, then X become corrupt and the system freeze, so I believe that there is a bug in radeon suspend/resume. I can't reproduce the bug, it shows when he want :( can you try in console mode without X using snooze -f repeately, does it ever happen ? Ben, The problem triggers when you keep in sleep mode for 6 hours (I wlll try shorter periods). With snooze -f and console makes no difference. Right now I have my PB displaying (sorry if I make some mistake, but I will copy all debug information by hand): HID1, before: 80002c80 radeonfb (:00:10.0): resuming from state: 0 . . . PCI: Enabling device :00:10.0 ( - 0003) H1D1, after: 80002c80 cpufreq: resume failed to assert current frequency is what timing core things it is Apple USB OHCI 0001:10:18.0 disabled by firmware Apple USB OHCI 0001:10:19.0 disabled by firmware eth0 resuming PHY ID: 1410cc1, addr 0 hda: Enabling Ultra DMA 5 hdc: MDMA, cycleTime: 120, accessTime: 90, recTime: 30 hdc: Enabling MultiWord DMA 2 usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd hid2hci rqt 64 rq 0 len 0 ret -110 usb 1-1: USB disconect, address 2 drivers/usb/input/hid-core.c: can't resubmit intr, 0001:10:1a.0-1/input1, status -19 ehci_hcd 0001:10:1b.2 Unlink after no-IRQ? Different ACPI or APIC settings may help ohci_hcd 0001:10:1b.1 Unlink after no-IRQ? Different ACPI or APIC settings may help ohci_hcd 0001:10:1b.0 Unlink after no-IRQ? Different ACPI or APIC settings may help usb 1-1: new full speed USB device using address 3 Could not suspend device 1-1: error = -108 hub 1-0:1.0: hub_port_status failed (err = -108) hub 1-0:1.0: cannot disable port 1 (err = -108) hub 1-0:1.0: hub_port_status failed (err = -108) hub 1-0:1.0: reactivate -- -108 Bluetooth: HCI USB driver ver 2.7 hci_usb_probe: Can't set isoc interface setting Oops: kernel access of bad area, sig: 11 [#1] PREEMPT NIP: E26BFA88 LR: E26C0E78 SP: D79EDD40 REGS: d79edc90 TRAP: 0300 Not tainted MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: 011C, DSISR: 4000 TASK = d7d98c90[10660] 'modprobe' THREAD: d79ec000Last syscall: 128 GPR00: 0014 D79EDD40 D7D98C90 DE44DC00 0083 C045 GPR08: C0A94A0C 0004 D79EC000 82992424 1001E284 100013A4 GPR16: 100013A4 10018B30 10018BA0 DFFF7BF4 GPR24: 0002 C0A94A00 C0A9B1E0 DFFF7BE0 DFFEF2C0 E26C18B4 Call trace: [e26c0e78] [e2528124] [c0253598] [e2528434] [e26c0d88] [e252807c] [c0253354] [c02534d4] [c0253aa4] [c02540a8] [e2528184] [e26b7030] [c003a004] [c0006060] eth0: Link is up at 100 Mbps, full-duplex eth0: Pause is disabled eth0: no IPv6 routers present I have no USB device attached to my PB, and the suspend cycles do not restore the console to previus state, it stays displaying the debug information. I tried to log in by network and no sshd present. I tried to change console, and nothing happens. If you need more data, please tell me. Also make sure you have APM emulation built into the kernel and that /dev/apm_bios exists. Yes and yes. I have apm emulation and /dev/apm_bios exists Thanks for all your work. Federico Ben.
Re: TEST: Sleep patch #7
On Tue, 2004-12-07 at 15:52 -0200, Federico Gamio wrote: I have no USB device attached to my PB, and the suspend cycles do not restore the console to previus state, it stays displaying the debug information. You do have a USB device: the internal bluetooth adapter. This looks very much like some USB problems. 2.6.9 isn't very friendly with sleep USB. Hopefully, that will get better with 2.6.10. Also, try not using CONFIG_PREEMPT, it may not be very safe with sleep at the moment.
Re: TEST: Sleep patch #7
Benjamin Herrenschmidt [EMAIL PROTECTED] writes: Also, try not using CONFIG_PREEMPT, it may not be very safe with sleep at the moment. does this advice apply also to ibooks?
Re: TEST: Sleep patch #7
On Dec 07 2004, Jose A. Ortega Ruiz wrote: does this advice apply also to ibooks? If the his e-mails in the past are still relevant, Ben is against having CONFIG_PREEMPT enabled (for powerpc, at least). So, I don't have it enabled in my kernels for my iBook G3 (well, in fact, I'm momentarily not using Linux right now on my iBook G3). Hope this helps, Rogério. -- Learn to quote e-mails decently at: http://pub.tsn.dk/how-to-quote.php http://learn.to/quote http://www.xs4all.nl/~sbpoley/toppost.htm
Re: TEST: Sleep patch #7
Benjamin Herrenschmidt wrote: (As usual, I'm cross posting several lists, please don't reply to all of them, and CC me as I'm not subscribed to all of them neither) Ok, here's the 7th version of the sleep patch for ATI based albooks iBook G4. Other machine users, please test too as it may cause regressions (or improvements) as well. The cache flush problem happens to not be completely fixed yet :( There is something going on that I don't completely explain yet, might be related to an errata of some CPU revisions. This version of the patch adds a load/flush loop before the L2 HW flush on the 745x that appear to make the thing stable on the machines I've tested on. It's a good enough workaround for now, I'm working with freescale to find out what's really going on though. With patch #7, is it safe now to re-enable cpufreqd? Or should it still remain deactivated ( this is currently the only issue I have with the sleep patches ). Thanks, /Arne http://gate.crashing.org/~benh/albook-ibookg4-sleep-7.diff Ben.
Re: TEST: Sleep patch #7
On Mon, 2004-12-06 at 08:07 +1100, Benjamin Herrenschmidt wrote: On Sun, 2004-12-05 at 12:18 +0100, eric.bachard wrote: Hi Ben, Not really the time, I am always using patch #1 on alubook 1,25GHz SD / Debian sid :-)) ... Just a question : is your patch only for 2.6.9 or is it both usable for 2.6.10* ? It's not easily applied to 2.6.10* as-is, but I have a 2.6.10-rc* patch set locally, I should post it soon. Ben. Weird thing: my build kernel panics on resume. I'll try Alex's kernel-image to see if I optimized something. Will be back later. thx ben!
Re: TEST: Sleep patch #7
On Mon, 2004-12-06 at 09:24 +0100, Alexander Wirt wrote: Benjamin Herrenschmidt wrote: I provided some kernel debs at: http://people.debian.org/~formorer/ppc. Patch #7 is working fine here, thanks Benjamin. Alex Downloaded, intalled, working smoothly. And I like the trick with the brightness-control from further down in the list by Holger Levsen. This is beginning to be really smooth. It has not been crashing on suspend/resume ever since I started unplugging the usb-mouse before going to sleep and pluggin it in AFTER the computer woke up. However: There are really disturbing sounds during resume. It will stop after the computer has complete woken up but till then one has to cover his ears. :/ Any hint on that? Greetings and many thanks to you hard working people! Timo Reimerdes
Re: TEST: Sleep patch #7
On Sun, 2004-12-05 at 21:34 +1100, Benjamin Herrenschmidt wrote: (As usual, I'm cross posting several lists, please don't reply to all of them, and CC me as I'm not subscribed to all of them neither) Ok, here's the 7th version of the sleep patch for ATI based albooks iBook G4. Other machine users, please test too as it may cause regressions (or improvements) as well. My 15 PowerBook (1.25Ghz, ATI 9600, PowerBook5.2) has the same problem with suspend to ram patch. I can suspend closing the lid or pushing the power button (I use pbbuttonsd) and all works perfect. I can repeat this for several times, but in some cases they don't want to go sleep and the LCD remains active. If I try to shutdown with init 0, then X become corrupt and the system freeze, so I believe that there is a bug in radeon suspend/resume. I can't reproduce the bug, it shows when he want :( Federico Ben. -- My software never has bugs. | ASCII Ribbon Campaign /\ It just develops random features. | For Standards-Complaint Email \ / Public GnuPG key available at: http://www.keyserver.netX 1024D/203E154B 2003-10-03 Federico Gamio [EMAIL PROTECTED] / \ Key fingerprint = 0B9E 3A19 C88B EBAC 5422 C05F 76B5 B922 203E 154B sub 2048g/32D2F465 2003-10-03 signature.asc Description: This is a digitally signed message part
Re: TEST: Sleep patch #7
On Mon, 2004-12-06 at 20:04 -0200, Federico Gamio wrote: On Sun, 2004-12-05 at 21:34 +1100, Benjamin Herrenschmidt wrote: (As usual, I'm cross posting several lists, please don't reply to all of them, and CC me as I'm not subscribed to all of them neither) Ok, here's the 7th version of the sleep patch for ATI based albooks iBook G4. Other machine users, please test too as it may cause regressions (or improvements) as well. My 15 PowerBook (1.25Ghz, ATI 9600, PowerBook5.2) has the same problem with suspend to ram patch. I can suspend closing the lid or pushing the power button (I use pbbuttonsd) and all works perfect. I can repeat this for several times, but in some cases they don't want to go sleep and the LCD remains active. If I try to shutdown with init 0, then X become corrupt and the system freeze, so I believe that there is a bug in radeon suspend/resume. I can't reproduce the bug, it shows when he want :( can you try in console mode without X using snooze -f repeately, does it ever happen ? Also make sure you have APM emulation built into the kernel and that /dev/apm_bios exists. Ben.
Re: TEST: Sleep patch #7 -- not falling asleep?
Hi, I reported about my powerbook not falling asleep sometimes. I figured it could be usb (after a hint from ben) and tried unplugging it before sleep and plugging it in after wakeup. That fooled me for being the reason. It's not. My next guess is pbbuttonsd or gtkpbbuttonsd. I sense something like: using the adjust volume keys sometimes keeps the thing from falling asleep? or something other. But it does happen when I use the buttons for sound-adjustment and it does not happen as long as I use the gnome-panel thing. Weird. I'll spend some more attention to that issue. Or can someone confirm similar Problems? I am getting really confused about this. greetz Timo
TEST: Sleep patch #7
(As usual, I'm cross posting several lists, please don't reply to all of them, and CC me as I'm not subscribed to all of them neither) Ok, here's the 7th version of the sleep patch for ATI based albooks iBook G4. Other machine users, please test too as it may cause regressions (or improvements) as well. The cache flush problem happens to not be completely fixed yet :( There is something going on that I don't completely explain yet, might be related to an errata of some CPU revisions. This version of the patch adds a load/flush loop before the L2 HW flush on the 745x that appear to make the thing stable on the machines I've tested on. It's a good enough workaround for now, I'm working with freescale to find out what's really going on though. http://gate.crashing.org/~benh/albook-ibookg4-sleep-7.diff Ben.
Re: TEST: Sleep patch #7
Hi Ben, Not really the time, I am always using patch #1 on alubook 1,25GHz SD / Debian sid :-)) ... Just a question : is your patch only for 2.6.9 or is it both usable for 2.6.10* ? Benjamin Herrenschmidt a écrit : Ok, here's the 7th version of the sleep patch for ATI based albooks iBook G4. Other machine users, please test too as it may cause regressions (or improvements) as well. I have planed to test your #7 ASAP, and will answer to give you feedback when it will work. The cache flush problem happens to not be completely fixed yet :( There is something going on that I don't completely explain yet, might be related to an errata of some CPU revisions. This version of the patch adds a load/flush loop before the L2 HW flush on the 745x that appear to make the thing stable on the machines I've tested on. FYI, I have a 7457, and patch#1 works 2 times over 3 (but it works :-) ) It's a good enough workaround for now, I'm working with freescale to find out what's really going on though. http://gate.crashing.org/~benh/albook-ibookg4-sleep-7.diff Noticed, And again, thank you very much fro all your impressive work !! Regards, eric bachard -- eric bachard[EMAIL PROTECTED] French OpenOffice.org Community contributor (build of french releases for Linux PPC and Mac OS X / X11) See : http://fr.openoffice.org
Re: TEST: Sleep patch #7
On Sun, 05 Dec 2004 11:18:29 +, eric.bachard wrote: [...] Just a question : is your patch only for 2.6.9 or is it both usable for 2.6.10* ? well, it does not apply to 2.6.10-rcX ... Soeren
Re: TEST: Sleep patch #7
On 05 Dec 2004 at 21h12, Benjamin Herrenschmidt wrote: Hi, Ok, here's the 7th version of the sleep patch for ATI based albooks iBook G4. Other machine users, please test too as it may cause regressions (or improvements) as well. Still working fine :) -- Colin
Re: TEST: Sleep patch #7
On Sun, 2004-12-05 at 12:18 +0100, eric.bachard wrote: Hi Ben, Not really the time, I am always using patch #1 on alubook 1,25GHz SD / Debian sid :-)) ... Just a question : is your patch only for 2.6.9 or is it both usable for 2.6.10* ? It's not easily applied to 2.6.10* as-is, but I have a 2.6.10-rc* patch set locally, I should post it soon. Ben.
