Mailinglist Archive: opensuse-bugs (8048 mails)

< Previous Next >
[Bug 228344] Acer Ferrari 1000 resets on resume with CONFIG_MTRR
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Wed, 7 Feb 2007 09:36:57 -0700 (MST)
  • Message-id: <20070207163657.3BB3FFC5@xxxxxxxxxxxxxxxxxxxxxx>

bk@xxxxxxxxxx changed:

What |Removed |Added
Info Provider|ak@xxxxxxxxxx |

------- Comment #23 from bk@xxxxxxxxxx 2007-02-07 09:36 MST -------
Sorry that this comment is a bit long, but I really wanted to give
a complete update:

Andi suggested debugging the MTRR resume function, but while
trying that on the CVS kernel (which otherwise has working
suspend/resume when CONTIG_MTRR is off because it has no bad
interaction between tg3 and sata_sil), I found that MTRR breaks
suspending with the sata_sil driver, but with the CVS kernel only
so far.

While sata_sil should in theory be robust to suspend independently
of MTRR support in the kernel, this itself is a bug, but this
actually helps me a but to hopefully find out what is wrong with
MTRRs on the Ferrari 1000. At least, they should normally not
have such impact, I guess...

While adopting Andi's development patches to switch from MTRR
to PAT would be too bleeding-edge for general adoption just now,
starting to try out his patches for PAT and disabling MTRR on the
brand new Ferrari 1000 (controlled by DMI) would be an option which
I'd be interested in.

During the last release candidates of 2.6.19, a big fix for the
MTRR code was adopted, so I could also try to revert it an see:

While suspending to disk (but not resuming from disk) worked with
CONFIG_MTRR on on plain vanilla 2.6.20-rc5, I do not think that
this is a bug in sata_sil, because sata_sil otherwise suspends
and resumes fine with CONFIG_MTRR is off and it even works with
CONFIG_MTRR enabled on a similar machine (HP nx6325) with the
same CPU stepping (TL-56 stepping 02) and same ATI RS480 chipset.

The only issue which I still saw with sata_sil in the CVS kernel build
was that if using vesafb and with console log level was 8 and PCI_- and
PM_DEBUG on, it still lost it's disk, probably still because the
intense logging on vesafb takes too long to make the driver recover.

So the sata_sil driver in CVS is apparently improved, but still not useful
for suspend debugging with many messages logged over a slow output
like vesafb. Pure VGA Text mode console logging was fine.

Since the machine does not reset itself but hang, that new symptom is
better because at that point, I may still be able to read the Ferrari's
RAM chips over DMA using the thankfully on-board OHCI1394 controller
over Firewire using Andi's x86_64 port of firescope. That would be
harder to do after a complete machine reset and so I could get debugging
information which the CPU does not even have to output somewhere, it
just has to be written to the RAM chips, from where I can read it over
firewire. Thanks to Andi also for some tips on how to set that up.

If reverting the last MTRR fix does not help and Andi's PAT code
is not yet well enough (a small fix would be also preferred if possible),
I'd have to look at the MTRR initialisation routines, reduce MTRR
initialisation to a minimum, see if that works and start setting
more MTRR registers.

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

< Previous Next >