Re: Powerbook shuts down hard when hot, patch found
On Mon, 2007-10-01 at 22:58 +0200, Michael Buesch wrote: On Monday 01 October 2007 10:00:02 Michel Dänzer wrote: On Sun, 2007-09-30 at 12:16 +0200, Michael Buesch wrote: Ah, forgot to say. It does not crash immediately when the register is written. It takes about two seconds to crash. And when the machine is colder to begin with, it takes slightly longer to trigger. That _might_ support your overheating theory. Though, it does not trigger when it's up and running, no matter how hot you drive it. Maybe the thermal control module prevents it from overheating. Have you tried unloading it or loading it ASAP on bootup to see if that makes any difference either way? I'm not sure how that works. Can I unload the framebuffer module? I'm talking about the thermal control module (therm_adt746x in my case), not radeonfb. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Powerbook shuts down hard when hot, patch found
On Sunday 30 September 2007 12:13:36 Michael Buesch wrote: On Sunday 30 September 2007 00:49:05 Benjamin Herrenschmidt wrote: Well, it's possible that they have a too weak pull-up resistor on those lines, and thus when asserted to 0, a significant current goes through causing the whole thing to heat up. That heat added to the residual heat of a hot boot becomes then enough to trigger the temperature sensor threshold... just one possible explanation. Possible, yes. That's why I thought about some silicon bug. Why only when it's hot? :) Also, the other change I made you do turns these into inputs, thus the The _EN bits are already all cleared, as you can see in my printk dump. So clearing them has no effect, of course. So the ports are Inputs as default on boot. Hrm, that's weird then, because in that case, changing the output bits shouldn't have any effect, unless maybe on some chips, the EN bits are flipped. I don't have anything specific about the rv350 tho. Can you print which specific DDC register is doing that (it's called twice right ?) and maybe do a patch preventing that write only for one of them and let me know if it makes a difference. Here's the log of a working kernel. As you can see, I only removed the write for register 0x60 here. So it only crashes when I clear the bits in this register. (makes sense, as there's nothing to clear in the other one). [0.453703] PCI: Enabling device :00:10.0 (0006 - 0007) [0.649319] radeonfb (:00:10.0): Invalid ROM signature 303 should be 0xaa55 [0.649329] radeonfb: Retrieved PLL infos from Open Firmware [0.649340] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=203.00 Mhz, System=392.00 MHz [0.649350] radeonfb: PLL min 12000 max 35000 [0.650146] DDC REG 0x0060 IS 0x0303 [0.793754] i2c-adapter i2c-2: unable to read EDID block. [1.013748] i2c-adapter i2c-2: unable to read EDID block. [1.233748] i2c-adapter i2c-2: unable to read EDID block. [1.310002] DDC REG 0x006C IS 0x [1.310007] WRITING [1.650506] ieee1394: Host added: ID:BUS[0-00:1023] GUID[001124fffed98036] [1.700986] radeonfb: Monitor 1 type LCD found [1.700995] radeonfb: EDID probed [1.701001] radeonfb: Monitor 2 type no found [1.701015] radeonfb: Using Firmware dividers 0x0002008e from PPLL 0 [1.701130] radeonfb: Dynamic Clock Power Management enabled [1.742608] Console: switching to colour frame buffer device 160x53 [1.765577] radeonfb: Backlight initialized (radeonbl0) [1.765767] radeonfb (:00:10.0): ATI Radeon NP [1.776757] Generic RTC Driver v1.07 [1.777085] Macintosh non-volatile memory driver v1.1 [1.777429] Linux agpgart interface v0.102 [1.39] agpgart: Detected Apple UniNorth 2 chipset Ah, forgot to say. It does not crash immediately when the register is written. It takes about two seconds to crash. And when the machine is colder to begin with, it takes slightly longer to trigger. That _might_ support your overheating theory. Though, it does not trigger when it's up and running, no matter how hot you drive it. -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Powerbook shuts down hard when hot, patch found
On Saturday 29 September 2007 13:06:59 Michael Buesch wrote: This is very strange... Can you try also clearing VGA_DDC_CLK_OUT_EN and VGA_DDC_DATA_OUT_EN and the same time and see if that helps ? It still triggers the bug then. I tried something else. I removed the write and only added a printk with a register read to print the contents (DDC REG IS 0x...) . This is the result: [0.431304] PCI: Enabling device :00:10.0 (0006 - 0007) [0.626866] radeonfb (:00:10.0): Invalid ROM signature 303 should be 0xaa55 [0.626877] radeonfb: Retrieved PLL infos from Open Firmware [0.626887] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=203.00 Mhz, System=392.00 MHz [0.626897] radeonfb: PLL min 12000 max 35000 [0.627194] DDC REG IS 0x0303 [0.763751] i2c-adapter i2c-2: unable to read EDID block. [0.983746] i2c-adapter i2c-2: unable to read EDID block. [1.203745] i2c-adapter i2c-2: unable to read EDID block. [1.280001] DDC REG IS 0x [1.620189] ieee1394: Host added: ID:BUS[0-00:1023] GUID[001124fffed98036] [1.670984] radeonfb: Monitor 1 type LCD found [1.670992] radeonfb: EDID probed [1.670997] radeonfb: Monitor 2 type no found [1.671012] radeonfb: Using Firmware dividers 0x0002008e from PPLL 0 [1.671075] radeonfb: Dynamic Clock Power Management enabled [1.712658] Console: switching to colour frame buffer device 160x53 [1.73] radeonfb: Backlight initialized (radeonbl0) [1.735746] radeonfb (:00:10.0): ATI Radeon NP [1.738776] Generic RTC Driver v1.07 [1.738995] Macintosh non-volatile memory driver v1.1 ... Note that the function is called twice. Is that correct? -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Powerbook shuts down hard when hot, patch found
On Sat, 2007-09-29 at 13:22 +0200, Michael Buesch wrote: On Saturday 29 September 2007 13:06:59 Michael Buesch wrote: This is very strange... Can you try also clearing VGA_DDC_CLK_OUT_EN and VGA_DDC_DATA_OUT_EN and the same time and see if that helps ? It still triggers the bug then. I tried something else. I removed the write and only added a printk with a register read to print the contents (DDC REG IS 0x...) . This is the result: [0.431304] PCI: Enabling device :00:10.0 (0006 - 0007) [0.626866] radeonfb (:00:10.0): Invalid ROM signature 303 should be 0xaa55 [0.626877] radeonfb: Retrieved PLL infos from Open Firmware [0.626887] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=203.00 Mhz, System=392.00 MHz [0.626897] radeonfb: PLL min 12000 max 35000 [0.627194] DDC REG IS 0x0303 [0.763751] i2c-adapter i2c-2: unable to read EDID block. [0.983746] i2c-adapter i2c-2: unable to read EDID block. [1.203745] i2c-adapter i2c-2: unable to read EDID block. [1.280001] DDC REG IS 0x [1.620189] ieee1394: Host added: ID:BUS[0-00:1023] GUID[001124fffed98036] [1.670984] radeonfb: Monitor 1 type LCD found [1.670992] radeonfb: EDID probed [1.670997] radeonfb: Monitor 2 type no found [1.671012] radeonfb: Using Firmware dividers 0x0002008e from PPLL 0 [1.671075] radeonfb: Dynamic Clock Power Management enabled [1.712658] Console: switching to colour frame buffer device 160x53 [1.73] radeonfb: Backlight initialized (radeonbl0) [1.735746] radeonfb (:00:10.0): ATI Radeon NP [1.738776] Generic RTC Driver v1.07 [1.738995] Macintosh non-volatile memory driver v1.1 ... Note that the function is called twice. Is that correct? Yes. That's expected, with different registers though. I don't quite get what's going on. I'll have to figure that out with ATI if they bother helping... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Powerbook shuts down hard when hot, patch found
This all smells to me like a silicon bug, so I'd start searching in the silicon erratas. But I'm not sure, of course. It's also strange that it depends on temperature. (That's why I first expected the PMU would cause this). Thanks for your help. Could be that we are creating a short by driving the output low, thus causing the silicon to heat up, but that's strange. Also, the other change I made you do turns these into inputs, thus the DDL lines should be pulled up, unless ... the board doesn't have pullups. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Powerbook shuts down hard when hot, patch found
On Sunday 30 September 2007 00:19:53 Benjamin Herrenschmidt wrote: This all smells to me like a silicon bug, so I'd start searching in the silicon erratas. But I'm not sure, of course. It's also strange that it depends on temperature. (That's why I first expected the PMU would cause this). Thanks for your help. Could be that we are creating a short by driving the output low, thus causing the silicon to heat up, but that's strange. Well. The machine needs to be hot in the first place to trigger it. If it's cold it boots and runs fine even with that patch. Even if I run it hot after boot it does not shutdown. It only shuts down on boot when this register is written and when it's hot at this point. That's why I thought about some silicon bug. Why only when it's hot? :) Also, the other change I made you do turns these into inputs, thus the The _EN bits are already all cleared, as you can see in my printk dump. So clearing them has no effect, of course. So the ports are Inputs as default on boot. DDL lines should be pulled up, unless ... the board doesn't have pullups. Well, I can't tell you :) -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Powerbook shuts down hard when hot, patch found
On Fri, 2007-09-28 at 23:32 +0200, Michael Buesch wrote:
Hi,
some time ago I already mailed you about this problem.
I will quickly describe what's going on, again:
My powerbook boots fine when it's cold. You can work with
it and you can also run it hot (compile something, etc...).
But when you try to boot it while it is hot, it will
automatically shutdown hard inside of the boot process.
Some part of the hardware is shutting it down.
This does not happen when it's getting hot _after_ boot.
Only while boot when it's hot.
I bisected the problem and found out that the following patch
is responsible for this. Yeah, this sounds a little bit
crazy, as this patch does not seem to be related to
this at all. But I confirmed it by booting kernel
4f71c5de19c27f2198105d3b26b398494d5c353b
That kernel triggered the bug. Then I patch -R the patch below
and it booted properly, even when hot. I also rechecked
that it really was hot enough to trigger the event by
immediately rebooting into a known bad kernel, that immediately
shut down the pbook, as expected.
So I'm pretty sure it's the patch below causing this weird
behaviour. Any idea why?
This is very strange... Can you try also clearing VGA_DDC_CLK_OUT_EN and
VGA_DDC_DATA_OUT_EN and the same time and see if that helps ?
commit 4f71c5de19c27f2198105d3b26b398494d5c353b
Author: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Fri Nov 17 15:35:00 2006 +1100
[PATCH] Fix radeon DDC regression
When radeonfb was changed to use the new generic ddc, a bit of
code initializing the GPIO lines was lost, causing it to not work
if the firmware didn't configure them properly, which seems to
happen on some cards.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
diff --git a/drivers/video/aty/radeon_i2c.c b/drivers/video/aty/radeon_i2c.c
index 6767545..869725a 100644
--- a/drivers/video/aty/radeon_i2c.c
+++ b/drivers/video/aty/radeon_i2c.c
@@ -139,7 +139,13 @@ void radeon_delete_i2c_busses(struct rad
int radeon_probe_i2c_connector(struct radeonfb_info *rinfo, int conn,
u8 **out_edid)
{
- u8 *edid = fb_ddc_read(rinfo-i2c[conn-1].adapter);
+ u32 reg = rinfo-i2c[conn-1].ddc_reg;
+ u8 *edid;
+
+ OUTREG(reg, INREG(reg)
+ ~(VGA_DDC_DATA_OUTPUT | VGA_DDC_CLK_OUTPUT));
+
+ edid = fb_ddc_read(rinfo-i2c[conn-1].adapter);
if (out_edid)
*out_edid = edid;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
