|| ||Linus Torvalds <torvalds-AT-osdl.org>|
|| ||Benjamin Herrenschmidt <benh-AT-kernel.crashing.org>|
|| ||Re: [PATCH 1/2] Add some basic resume trace facilities|
|| ||Thu, 15 Jun 2006 20:08:06 -0700 (PDT)|
|| ||linux-pm-AT-lists.osdl.org, Nigel Cunningham <ncunningham-AT-linuxmail.org>|
On Fri, 16 Jun 2006, Benjamin Herrenschmidt wrote:
> On Tue, 2006-06-13 at 15:59 -0700, Linus Torvalds wrote:
> > The Apple Mac Mini I can't even get to _beep_, which is really annoying.
> > It's a wonderful debug sequence ("oh, I head 15 beeps, it got to point
> > X"). Or rather, it's "wonderful" compared to something that gives you just
> > one single piece of data after the reboot ;)
> No magic GPIO or ACPU command you can use to tweak the front led ?
There's a magic bit that can make it flash. I considered doing that, but
decided that I'm better off with the "almost 24 bits of data" and a
reboot, than trying to desperately look at how the led flashes.
That's especially true since resume on that machine is sometimes delayed
by a SATA problem - so it actually _does_ come back, but it has a
30-second timeout because the SATA controller didn't resume. It seems to
be very timing-dependent: fixing the irq#9 issue on that box actually
exposed it, because it no longer gets 10,000 spurious interrupts to slow
it down ;)
An audible beep is actually _much_ better than a visual LED flash, because
you hear it even if you're not looking at the box intently for half a
Trust me, if I had to watch the LED all the time, I'd just go even crazier
than I am already ;^p
> > The real-time clock was literally the only thing I could find that didn't
> > get cleared, and that obviously has some serious limitations size-wise.
> What about vram ? the entire of it gets cleared or only the displayed
> part ?
There's no VRAM. It's all system RAM. This is integrated video.
So I bet that it's all cleared (before it's even marked for the integrated
graphics chip - which is done by the firmware by writing a magic
register for "top or RAM").
And perhaps more importantly, accessing that hidden memory is actually
pretty hard. Since it's past the "top of RAM" register, you can't do it
from the CPU directly, you have to do it through the AGP bridge.
So I didn't verify it all. I did verify that random memory locations were
cleared (actually, not cleared - it looks like the firmware wrote a
test-pattern to it), and I also verified that at least part of the "ACPI
NVS" are was also cleared (it's called "Non Volatile Storage", which is
why I tried it, but in ACPI terms that seems to mean that it's nonvolatile
as far as the ACPI stuff is concerned: the OS isn't supposed to change it,
not non-volatile in the OS kind of sense).
The RTC has the added advantage that it literally exists in every single
PC out there, ie it's a piece of hardware that has absolutely _zero_
firmware or hardware dependencies. That particular code will most likely
run on everything.
The thing is, I don't actually enjoy debugging my own machines. I _much_
prefer having other people debug _their_ machines, and fixing my machine
in the process. So I didn't want just something that worked on the Mac
Mini, I wanted something that works _universally_, so that hopefully
people who are even crazier than me will waste _their_ time trying to get
these machines working.
I say that with a smile, but I'm serious. There's simply no _point_ for me
to write code that just fixes one machine. If I don't believe it can help
fix a bigger problem, it's not worth doing.
Sometimes fixing just one machine tends to mean that a lot of other
machines also suddenly start working. That has historically clearly not
been the case wrt suspend-to-RAM, which is why I wanted something
to post comments)