linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: benh@kernel.crashing.org
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Powerbook shuts down hard when hot, patch found
Date: Sun, 30 Sep 2007 12:16:54 +0200	[thread overview]
Message-ID: <200709301216.55123.mb@bu3sch.de> (raw)
In-Reply-To: <200709301213.36821.mb@bu3sch.de>

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 0000:00:10.0 (0006 -> 0007)
> [    0.649319] radeonfb (0000: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 0x00000060 IS 0x00000303
> [    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 0x0000006C IS 0x00000000
> [    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 (0000: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.777739] 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.

  reply	other threads:[~2007-09-30 10:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-28 21:32 Powerbook shuts down hard when hot, patch found Michael Buesch
2007-09-28 23:04 ` Benjamin Herrenschmidt
2007-09-29 11:06   ` Michael Buesch
2007-09-29 11:22     ` Michael Buesch
2007-09-29 21:51       ` Benjamin Herrenschmidt
2007-09-29 21:53         ` Michael Buesch
2007-09-29 22:19           ` Benjamin Herrenschmidt
2007-09-29 22:26             ` Michael Buesch
2007-09-29 22:49               ` Benjamin Herrenschmidt
2007-09-30 10:13                 ` Michael Buesch
2007-09-30 10:16                   ` Michael Buesch [this message]
2007-10-01  8:00                     ` Michel Dänzer
2007-10-01 20:58                       ` Michael Buesch
2007-10-02  6:43                         ` Michel Dänzer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200709301216.55123.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).