th a new flag to the boot option which
the new init_ohci1394 commit added.
The documentation in the commit also includes a link to firedump, a tool
which can to pull the the contents of all PCI-accessible memory over
FireWire at high speed. But it does not parse the e820 map yet, so it
crashes the r
nhard
PS: This code can be extended to allow to debug panics, suspend and resume
by enabling physical DMA especially on these events, so in incremental
patches, we could add support e.g. for ohci1394_dma={suspend,resume,panic}
Signed-Off-By: Bernhard Kaindl <[EMAIL PROTECTED]>
Tested-By:
Hi,
this mail sums up some discussion about special code for early initialisation
of OHCI-1394 controllers to enable their use for remote debugging over FireWire
using physical DMA. The thread started on linux-kernel and Stefan Richter
asked to Cc also linux1394-devel for the review of ieee1394-r
On Tue, 4 Dec 2007, Stefan Richter wrote:
A quick note to this text from
http://www.suse.de/~bk/firewire/ohci1394_dma_early.diff :
+ As all changes to the FireWire bus such as enabling and disabling
+ devices cause a bus reset and thereby disable remote DMA for all
+ dev
On Tue, 4 Dec 2007, Andi Kleen wrote:
I have just had the guts to explore __fast__ memory dumping over
firewire for full-system dumps [...]
Unfortunately it won't work for >3GB or so AFAIK.
Yes we seem to be limited to 4GB mostly, with 3G mem hole, it's 3GB.
Afterwards, the victim was dea
Hi,
I just wanted to let you know that I'll have picked up the early
firewire patch again and cleaned it up very much so that it should
be ready to submit it and but it on the patch-submission road.
What's left to do is to write some HOWTO like Stefan describes
below, but I'll try to get that
bers are not totally way off (outside of) the child bus range
* remove the reference to pci=assign-busses and the plea to report it
We could add a pure source code-only comment to keep a reference to
pci=assign-busses the in case when this is triggered by someone who
is debugging the cause of
I noticed that I can just use call graphs to make more clear what I want to say.
There is otherwise nothing new in this mail and I'll submit a new patch
which reverts this patch if my review came too late, if in doubt, just
ignore this mail, I may just refer to it later then.
> NACK - obsolete, r
On Mon, 30 Apr 2007, Andi Kleen wrote:
> Subject: [PATCH] [16/34] i386: fix mtrr sections
NACK - obsolete, replaced by:
Jeremy Fitzhardinge - "x86: clean up identify_cpu"
http://lkml.org/lkml/2007/4/7/113 [it's also patch 11/26 in this thread]
It's a leftover of "__init to __cpuinit in mtrr code
ross all processors." as written in the AMD and Intel manuals.
If an WRMSR instruction fails because MtrrFixDramModEn is not
set, I expect that also the Intel-style MTRR bits are not updated.
Signed-off-by: Bernhard Kaindl <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
ation with other patches this allows to fix s2ram
and s2disk on the Acer Ferrari 1000 notebook and at least
s2disk on the Acer Ferrari 5000 notebook.
Signed-off-by: Bernhard Kaindl <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc:
l be
using.
Because mtrr_save_fixed_ranges calls get_fixed_ranges after
kernel initialisation time, __init needs to be removed from
the declaration of get_fixed_ranges().
If CONFIG_MTRR is not set, we define mtrr_save_fixed_ranges
as an empty statement because there is nothing to do.
Signed-off-by: Bernhard Kain
t it might be interesting to syncronize the MTTRs of all
processors before booting. That would be an incremental patch,
but of rather low priority since there is no machine known so
far which would require this.
Signed-off-by: Bernhard Kaindl <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton
Hi,
This is an updated repost of http://lkml.org/lkml/2007/4/3/110 whith the
changes which Andrew Morton added in http://lkml.org/lkml/2007/4/8/88 to fix
'make headers_check' applied to the 2nd patch, which he updated.
The oops of Andrew's Viao on s2ram was caused by a merge error which
was cau
resting to syncronize the MTTRs of all
processors before booting new CPUs. That would be an incremental
patch, of rather low priority since there is no machine known so
far which would require this.
Signed-off-by: Bernhard Kaindl <[EMAIL PROTECTED]>
--- linux-2.6.20.orig/arch/
static struct which stores our current
backup of the fixed-range MTRR values which all CPUs shall be
using.
Because mtrr_save_fixed_ranges calls get_fixed_ranges() after
kernel initialisation time, __init needs to be removed from
the declaration of get_fixed_ranges().
Signed-off-by: Bernhard
he support for "Extended fixed-range
type-field encodings" because the access mode only changes if
these bits are set, otherwise, we do not need to enable them.
Best Regards,
Bernhard Kaindl
PS: I attached a program which uses msr.ko (CONFIG_X86_MSR) from
Processor type and features
, I expect that also the Intel-style MTRR bits are not updated.
Signed-off-by: Bernhard Kaindl <[EMAIL PROTECTED]>
--- linux-2.6.20.orig/arch/i386/kernel/cpu/mtrr/generic.c
+++ linux-2.6.20/arch/i386/kernel/cpu/mtrr/generic.c
@@ -20,12 +20,29 @@ struct mtrr_state {
mtrr_type def_ty
Ferrari 1000 notebook and at least
s2disk on the Acer Ferrari 5000 notebook.
Signed-off-by: Bernhard Kaindl <[EMAIL PROTECTED]>
--- linux-2.6.20/arch/i386/power/cpu.c
+++ linux-2.6.20/arch/i386/power/cpu.c
@@ -21,6 +21,7 @@ unsigned long saved_context_eflags;
void __save_processor_state(
19 matches
Mail list logo
