https://bugzilla.novell.com/show_bug.cgi?id=228344 bk@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|ak@novell.com | ------- Comment #23 from bk@novell.com 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: http://lkml.org/lkml/2006/11/15/144 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: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.