linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* What will be in the x86-64/x86 2.6.21 merge
@ 2007-02-10 11:42 Andi Kleen
  2007-02-10 13:43 ` [discuss] " Muli Ben-Yehuda
                   ` (2 more replies)
  0 siblings, 3 replies; 29+ messages in thread
From: Andi Kleen @ 2007-02-10 11:42 UTC (permalink / raw)
  To: linux-kernel; +Cc: discuss


I will post the existing patches in batches for closer review.

Can be already all viewed at ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/

Highlights: 

- Using %fs instead of %gs for PDA register (Jeremy F.)
- Removed the old static rom probing on x86-64. We really trust e820 now.
  This is slightly experimental still. We'll see how it does.
- uncached copy user 
  Not a clear win, but also not a loss. Follow i386.
- Fix 32bit EFI with regparms.
- Fix boot slowdown as VT guest (Zach Amsden) 
- VMI for paravirtualized VMware 
  * first paravirt ops client
  * still some changes missing which need more work
- Various changes in APIC routing setup (Ingo Molnar)  
- Various changes in mmconfig handling (Olivier Galibert, OGAWA Hirofumi, me) 
  * Share code between i386/x86-64
  * Be more aggressive at ignoring bogus MCFG tables 
  * Now supports white lists for some chipsets (currently only Intel 945/915) 
- Some patches for the upcomming AMD Family10 CPUs.
- More init section reference fixes from Vivek
- Some preparation patches for Perfmon
- New NUMA hash function for x86-64 and related changes (Amul Shah) 
- Support a trigger on machine check events on x86-64
- NMI watchdog fixes for Core2 from Venkatesh
- Fix a HPET timer calibration issue on systems with long SMM events at boot (Jack Steiner)
- Fix compat a.out signals on x86-64 
- Lots of small stuff

Not included yet. Might or might not make .21:

- Solution for Nvidia IOMMU corruptions. We could default to iommu=soft for 
  nvidia, but I was still hoping for a workaround from the hardware vendors.
- vDSO support (still trouble with newer toolkits)  
- Xen paravirt ops support from Jeremy/Chris
- Dynamic command line from Bernhard Walle
- Fast getcpu from Dean (requires vDSO) 
- Rewritten RAID XOR functions 
- Fixes for empty nodes from mm
- Fake node improvements for x86-64
- New dynamic IRQ 0 probing to work around all chipset issues
- lguest
  * still seems heavily in development. Not sure it will be ready in time.

Not likely to make .21:
- PAT support (needs some more work and lot more testing) 
- Early firewire support for firescope at early boot

Full list of patches:

Note I will do at least a second review pass before sending them to Linus,
so there might be changes. No guarantee all patches will make it.

defconfig-update
i386-defconfig-update
	Defconfig updates

copy-user-nocache
	Support cache bypassing copy_from_user for file system workloads
	Wasn't a clear win, but also not a clear loss.
#io-apic-reuse
#vdso
	Not yet

#last-branch
	Private Debugging 

make-the-numa-hash-function-nodemap-allocation
convert-i386-pda-code-to-use-%fs
kernel-mode-faults-pollute-current-thead
	Fix for UML

revert-i386-fix-the-verify_quirk_intel_irqbalance
revert-x86_64-mm-add-genapic_force
revert-x86_64-mm-fix-the-irqbalance-quirk-for-e7320-e7520-e7525
optimize-fix-apic-mode-setup
always-use-physical-delivery-mode-on-8-cpus
remove-clustered-apic-mode
default-to-physical-mode-on-hotplug-cpu-kernels
	genapic changes from Ingo

x86_64-make-the-numa-hash-function-nodemap-allocation-fix-fix
fix-a-typo-in-an-irq-handler-name

mmconfig-share
only-call-unreachable_devices-when-type-1-is-available.
detect-and-support-the-e7520-and-the-945g-gz-p-pl
reserve-resources-but-only-when-were-sure-about-them.
mmconfig-ioremap
mmconfig-reject-broken-table
	mmconfig changes

get-rid-of-arch_have_xtime_lock

a-memcpy-that-tries-to-reduce-cache-pressure
use-memcpy_uncached_read-in-rdma-interrupt-handler-to-reduce-packet-loss
	Infiniband uncached copy support

improved-iommu-documentation
do-not-always-end-the-stack-trace-with-ulong_max
e820-include
	Misc fixes

page-allocation-hooks-for-vmi-backend
paravirt-cpu-hypercall-batching-mode
iopl-handling-for-paravirt-guests
smp-boot-hook-for-paravirt
vmi-backend-for-paravirt-ops
vmi-timer
profile-pc-badness
kprobe-rpl-fix
vmi-timer-race
paravirt-debug-defaults-off
	VMI

move-startup_32-in-text.head-section
break-init-in-two-parts-to-avoid-modpost-warnings
	section warning fixes from Vivek

mcheck-include
add-idle-notifier
	Idle notifier for perfmon 
	
improve-sched_clock-on-i686
romsignature-checksum-cleanup
fix-fake-numa-for-x86_64-machines-with-big-io-hole
remove-fastcall-references-in-x86_64-code
use-constant-instead-of-raw-number-in-x86_64-ioperm.c

handle-32-bit-perfmon-counter-writes-cleanly-in-x86_64-nmi_watchdog
handle-32-bit-perfmon-counter-writes-cleanly-in-i386-nmi_watchdog
handle-32-bit-perfmon-counter-writes-cleanly-in-oprofile
	Core2 NMI watchdog fixes

config_physical_align-limited-to-4m
cleanup-doc-x86_64-files
list-x86_64-quilt-tree
simplify-notify_page_fault
	Misc fixes

mce_amd-issues
mce-trigger
	Machine check trigger support

remove-get_pmd
fix-tlbflush-comment
msr-on-cpu
kconfig-typos
msr-scf-single
mtrr-scf-single
fix-preprocessor-condition
mtrr-compat
	MTRR support for 32bit compat clients
apm-seqfile
fix-size_or_mask-and-size_and_mask
	48 bit MTRR support step 1.
ignore-long-smi-interrupts-in-clock-calibration-code-update-1
	Fix HPET calibration problem when SMI interrupts
putreg-check
unexport-supported-pte
aout-no-vdso
	Fix a.out
fs-gs-clear
	VT boot performance fix
iommu-boundary
efi-regparms
	Fix EFI on 32bit
remove-rom-reservation
	Trust e820 completely. Muahaha!
define-dma-noncoherent-api-functions
robustify-bad_dma_address-handling
fix-laptop-bootup-hang-in-init_acpi
all-transmeta-cpus-have-constant-tscs
avoid-gcc-extension
support-classic-mediagxm
	Support for older Cyrix CPUs
entrys-end-endproc-annotations
clean-up-sparsemem-memory_present-call
arch-i386-kernel-alternativec-should-include-asm-bugsh
remove-unused-kernel-config-option-x86_xadd
	Misc cleanups
update-io-apic-dest-field-to-8-bit-for-xapic
	Fix kexec on es7000 with 8 bit APIC IDs
avoid-warning-message-livelock
minor-patch-for-compilation-warning-in-x86_64-signal-code
dont-include-bugsh
add-option-to-show-more-code-in-oops-reports
32-bit-ptrace-mangles-sixth-system-call-argument
geode-configuration-fixes
survive-having-no-irq-mapping-for-a-vector
fix-gcc-check
	Misc changes
paravirt-remove-fastcall
	Small cleanup
fam10-cpuid
fam10-l3cache
fam10-nmi-watchdog
	AMD family10 support

fix-microcode-warning
i386-fix-transmeta-warning
fails-to-detect-mediagx


-Andi

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [discuss] What will be in the x86-64/x86 2.6.21 merge
  2007-02-10 11:42 What will be in the x86-64/x86 2.6.21 merge Andi Kleen
@ 2007-02-10 13:43 ` Muli Ben-Yehuda
  2007-02-10 13:52   ` Andi Kleen
  2007-02-10 13:51 ` remote debugging via FireWire (was What will be in the x86-64/x86 2.6.21 merge) Stefan Richter
  2007-02-12 14:11 ` What will be in the x86-64/x86 2.6.21 merge James Morris
  2 siblings, 1 reply; 29+ messages in thread
From: Muli Ben-Yehuda @ 2007-02-10 13:43 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel, discuss

On Sat, Feb 10, 2007 at 12:42:48PM +0100, Andi Kleen wrote:
> 
> I will post the existing patches in batches for closer review.
> 
> Can be already all viewed at
> ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/

Andi, please make sure to also include this Calgary patch I sent on
Feb 6th.

Thanks,
Muli

Subject: x86-64 Calgary: robustify bad_dma_address handling
From: Muli Ben-Yehuda <muli@il.ibm.com>

- set bad_dma_address explicitly to 0x0
- reserve 32 pages from bad_dma_address and up
- WARN_ON() a driver feeding us bad_dma_address

Thanks to Leo Duran <leo.duran@amd.com> for the suggestion.

Signed-off-by: Muli Ben-Yehuda <muli@il.ibm.com>
Cc: Leo Duran <leo.duran@amd.com>
Cc: Job Mason <jdmason@kudzu.us>
---
 arch/x86_64/kernel/pci-calgary.c |   17 +++++++++++++++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/x86_64/kernel/pci-calgary.c b/arch/x86_64/kernel/pci-calgary.c
index 3d65b1d..04480c3 100644
--- a/arch/x86_64/kernel/pci-calgary.c
+++ b/arch/x86_64/kernel/pci-calgary.c
@@ -138,6 +138,8 @@ static const unsigned long phb_debug_off
 
 #define PHB_DEBUG_STUFF_OFFSET	0x0020
 
+#define EMERGENCY_PAGES 32 /* = 128KB */
+
 unsigned int specified_table_size = TCE_TABLE_SIZE_UNSPECIFIED;
 static int translate_empty_slots __read_mostly = 0;
 static int calgary_detected __read_mostly = 0;
@@ -296,6 +298,16 @@ static void __iommu_free(struct iommu_ta
 {
 	unsigned long entry;
 	unsigned long badbit;
+	unsigned long badend;
+
+	/* were we called with bad_dma_address? */
+	badend = bad_dma_address + (EMERGENCY_PAGES * PAGE_SIZE);
+	if (unlikely((dma_addr >= bad_dma_address) && (dma_addr < badend))) {
+		printk(KERN_ERR "Calgary: driver tried unmapping bad DMA "
+		       "address 0x%Lx\n", dma_addr);
+		WARN_ON(1);
+		return;
+	}
 
 	entry = dma_addr >> PAGE_SHIFT;
 
@@ -656,8 +668,8 @@ static void __init calgary_reserve_regio
 	u64 start;
 	struct iommu_table *tbl = dev->sysdata;
 
-	/* reserve bad_dma_address in case it's a legal address */
-	iommu_range_reserve(tbl, bad_dma_address, 1);
+	/* reserve EMERGENCY_PAGES from bad_dma_address and up */
+	iommu_range_reserve(tbl, bad_dma_address, EMERGENCY_PAGES);
 
 	/* avoid the BIOS/VGA first 640KB-1MB region */
 	start = (640 * 1024);
@@ -1176,6 +1188,7 @@ int __init calgary_iommu_init(void)
 	}
 
 	force_iommu = 1;
+	bad_dma_address = 0x0;
 	dma_ops = &calgary_dma_ops;
 
 	return 0;
-- 
1.4.1

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* remote debugging via FireWire (was What will be in the x86-64/x86 2.6.21 merge)
  2007-02-10 11:42 What will be in the x86-64/x86 2.6.21 merge Andi Kleen
  2007-02-10 13:43 ` [discuss] " Muli Ben-Yehuda
@ 2007-02-10 13:51 ` Stefan Richter
  2007-02-10 14:02   ` Andi Kleen
  2007-12-04  3:45   ` remote debugging via FireWire * __fast__ firedump! Bernhard Kaindl
  2007-02-12 14:11 ` What will be in the x86-64/x86 2.6.21 merge James Morris
  2 siblings, 2 replies; 29+ messages in thread
From: Stefan Richter @ 2007-02-10 13:51 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel, discuss, linux1394-devel, Bernhard Kaindl

Andi Kleen wrote at LKML:
...
> Not likely to make .21:
...
> - Early firewire support for firescope at early boot
...

Was it seen in canonical patch format on a mailinglist before?
Is it Bernhard Kaindl's ohci1394_early?
http://www.suse.de/~bk/firewire/

Would be good to put this on the usual patch-submission road in order to
prep it for 2.6.22. Could be handled via linux1394-2.6.git, although a
different channel where the actual users of this facility watch would
IMO be more appropriate.

I also have suggestions, at least WRT Bernhard's code:
  - The Kconfig option could go into the "Kernel hacking" submenu rather
    than the IEEE 1394 submenu. (The driver source should stay in
    drivers/ieee1394.)
  - Leave a note in the Kconfig help how it is typically used, i.e. what
    is required on the remote terminal side, where to find firescope,
    fireproxy etc. and assorted HOWTOs.
  - Indicate in the Kconfig help that only a 4GB address range is made
    visible this way.

A mostly unrelated note: A simple to set up remote-dmesg utility would
be nice to have on the terminal side. Maybe a small ieee1394 high-level
driver which gives hints on the location of the dmesg buffer via
configuration ROM would be warranted. Or is it feasible to find the
dmesg buffer by plain memory analysis?
-- 
Stefan Richter
-=====-=-=== --=- -=-=-
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [discuss] What will be in the x86-64/x86 2.6.21 merge
  2007-02-10 13:43 ` [discuss] " Muli Ben-Yehuda
@ 2007-02-10 13:52   ` Andi Kleen
  2007-02-10 13:56     ` Muli Ben-Yehuda
  0 siblings, 1 reply; 29+ messages in thread
From: Andi Kleen @ 2007-02-10 13:52 UTC (permalink / raw)
  To: Muli Ben-Yehuda; +Cc: linux-kernel, discuss

On Saturday 10 February 2007 14:43, Muli Ben-Yehuda wrote:
> On Sat, Feb 10, 2007 at 12:42:48PM +0100, Andi Kleen wrote:
> > 
> > I will post the existing patches in batches for closer review.
> > 
> > Can be already all viewed at
> > ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/
> 
> Andi, please make sure to also include this Calgary patch I sent on
> Feb 6th.

It's already included

ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/robustify-bad_dma_address-handling

-Andi

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [discuss] What will be in the x86-64/x86 2.6.21 merge
  2007-02-10 13:52   ` Andi Kleen
@ 2007-02-10 13:56     ` Muli Ben-Yehuda
  2007-02-10 14:03       ` Andi Kleen
  0 siblings, 1 reply; 29+ messages in thread
From: Muli Ben-Yehuda @ 2007-02-10 13:56 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel, discuss

On Sat, Feb 10, 2007 at 02:52:16PM +0100, Andi Kleen wrote:
> On Saturday 10 February 2007 14:43, Muli Ben-Yehuda wrote:
> > On Sat, Feb 10, 2007 at 12:42:48PM +0100, Andi Kleen wrote:
> > > 
> > > I will post the existing patches in batches for closer review.
> > > 
> > > Can be already all viewed at
> > > ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/
> > 
> > Andi, please make sure to also include this Calgary patch I sent on
> > Feb 6th.
> 
> It's already included
> 
>
> ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/robustify-bad_dma_address-handling

Thanks, I scanned the list for 'calgary' and missed it. I'm guessing
the Calgary got dropped because the Subject had 'x86-64 Calgary:' and
your scripts trimmed the prefix?

Cheers,
Muli

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: remote debugging via FireWire (was What will be in the x86-64/x86 2.6.21 merge)
  2007-02-10 13:51 ` remote debugging via FireWire (was What will be in the x86-64/x86 2.6.21 merge) Stefan Richter
@ 2007-02-10 14:02   ` Andi Kleen
  2007-02-10 15:14     ` remote debugging via FireWire Stefan Richter
  2007-12-04  3:45   ` remote debugging via FireWire * __fast__ firedump! Bernhard Kaindl
  1 sibling, 1 reply; 29+ messages in thread
From: Andi Kleen @ 2007-02-10 14:02 UTC (permalink / raw)
  To: Stefan Richter; +Cc: linux-kernel, discuss, linux1394-devel, Bernhard Kaindl

On Saturday 10 February 2007 14:51, Stefan Richter wrote:
> Andi Kleen wrote at LKML:
> ...
> > Not likely to make .21:
> ...
> > - Early firewire support for firescope at early boot
> ...
> 
> Was it seen in canonical patch format on a mailinglist before?

Don't know.

> Is it Bernhard Kaindl's ohci1394_early?
> http://www.suse.de/~bk/firewire/

Yes.
> 
> Would be good to put this on the usual patch-submission road in order to
> prep it for 2.6.22. Could be handled via linux1394-2.6.git, although a
> different channel where the actual users of this facility watch would
> IMO be more appropriate.

It's more related to arch code than firewire, so I thought i would
handle it. But you can too if you want. It definitely needs much
more review anyways.

> A mostly unrelated note: A simple to set up remote-dmesg utility would
> be nice to have on the terminal side.

ftp://ftp.firstfloor.org/pub/ak/firescope/

-Andi

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [discuss] What will be in the x86-64/x86 2.6.21 merge
  2007-02-10 13:56     ` Muli Ben-Yehuda
@ 2007-02-10 14:03       ` Andi Kleen
  0 siblings, 0 replies; 29+ messages in thread
From: Andi Kleen @ 2007-02-10 14:03 UTC (permalink / raw)
  To: discuss; +Cc: Muli Ben-Yehuda, linux-kernel


> Thanks, I scanned the list for 'calgary' and missed it. I'm guessing
> the Calgary got dropped because the Subject had 'x86-64 Calgary:' and
> your scripts trimmed the prefix?

Yes.

-Andi

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: remote debugging via FireWire
  2007-02-10 14:02   ` Andi Kleen
@ 2007-02-10 15:14     ` Stefan Richter
  2007-02-10 15:41       ` Andi Kleen
  0 siblings, 1 reply; 29+ messages in thread
From: Stefan Richter @ 2007-02-10 15:14 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Bernhard Kaindl, discuss, linux1394-devel, linux-kernel

Andi Kleen wrote:
> On Saturday 10 February 2007 14:51, Stefan Richter wrote:
>> Could be handled via linux1394-2.6.git, although a
>> different channel where the actual users of this facility watch would
>> IMO be more appropriate.
> 
> It's more related to arch code than firewire, so I thought i would
> handle it. But you can too if you want. It definitely needs much
> more review anyways.

It's better you do it. I don't know anything about the specifics of
early initialization. Just Cc linux1394-devel on submission so that we
can have a look at the OHCI-1394 related bits.

Using linux1394-2.6.git could only be helpful if more code sharing
between ohci1394.c and ohci1394_early.c would be desired. That's
questionable though, given the rather small size of ohci1394_early.c.

>> A mostly unrelated note: A simple to set up remote-dmesg utility would
>> be nice to have on the terminal side.
> 
> ftp://ftp.firstfloor.org/pub/ak/firescope/

Thanks, I wasn't aware that firescope actually does fill this gap.
-- 
Stefan Richter
-=====-=-=== --=- -=-=-
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: remote debugging via FireWire
  2007-02-10 15:14     ` remote debugging via FireWire Stefan Richter
@ 2007-02-10 15:41       ` Andi Kleen
  2007-02-10 19:16         ` Stefan Richter
  0 siblings, 1 reply; 29+ messages in thread
From: Andi Kleen @ 2007-02-10 15:41 UTC (permalink / raw)
  To: Stefan Richter; +Cc: Bernhard Kaindl, discuss, linux1394-devel, linux-kernel

On Saturday 10 February 2007 16:14, Stefan Richter wrote:
> Andi Kleen wrote:
> > On Saturday 10 February 2007 14:51, Stefan Richter wrote:
> >> Could be handled via linux1394-2.6.git, although a
> >> different channel where the actual users of this facility watch would
> >> IMO be more appropriate.
> > 
> > It's more related to arch code than firewire, so I thought i would
> > handle it. But you can too if you want. It definitely needs much
> > more review anyways.
> 
> It's better you do it. I don't know anything about the specifics of
> early initialization. Just Cc linux1394-devel on submission so that we
> can have a look at the OHCI-1394 related bits.

Ok. I'm sure you know more about 1394 than me so I guess it will be shared
review.

-Andi

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: remote debugging via FireWire
  2007-02-10 15:41       ` Andi Kleen
@ 2007-02-10 19:16         ` Stefan Richter
  2007-02-11 21:35           ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 29+ messages in thread
From: Stefan Richter @ 2007-02-10 19:16 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Stefan Richter, Bernhard Kaindl, discuss, linux1394-devel, linux-kernel

[ohci1394_early]

Some remarks to the September 2006 version at
http://www.suse.de/~bk/firewire/ :

  - Seems its .remove won't work properly if more than one OHCI-1394
    controller is installed.  And it's .probe isn't reentrant, but that
    might be less of a problem.
  - Its functionality will be lost if there is a FireWire bus reset,
    e.g. when something is plugged in or out.  To keep physical DMA
    alive, an interrupt handler had to be installed which writes ~0
    to OHCI1394_PhyReqFilter{Hi,Lo}Set.  Can interrupt handlers be
    registered in an early setup stage?
  - There might be some register accesses in the setup which could be
    omitted; I'd have to look this up.
  - Could be optimized to not use ohci1394.h::struct ti_ohci.
  - PCI_CLASS_FIREWIRE_OHCI can be replaced by
    include/linux/pci_ids.h::PCI_CLASS_SERIAL_FIREWIRE_OHCI which
    was newly added in 2.6.20-git#.
  - I suppose .probe should check for PCI_CLASS_SERIAL_FIREWIRE_OHCI
    instead of PCI_CLASS_SERIAL_FIREWIRE.
  - How about dropping support for configuring this as module, to
    simplify the code?  Unless this would interfere with ohci1394; and
    it probably would if there was an interrupt handler...
  - "depends on X86_64" is missing in Kconfig.
  - Maybe put it into arch/x86_64/drivers/ instead of drivers/ieee1394?
  - Plus what I mentioned earlier in the thread.

I could send code to address some of this at next weekend or later.
-- 
Stefan Richter
-=====-=-=== --=- -=-=-
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: remote debugging via FireWire
  2007-02-10 19:16         ` Stefan Richter
@ 2007-02-11 21:35           ` Benjamin Herrenschmidt
  2007-02-12  6:49             ` Andi Kleen
  0 siblings, 1 reply; 29+ messages in thread
From: Benjamin Herrenschmidt @ 2007-02-11 21:35 UTC (permalink / raw)
  To: Stefan Richter
  Cc: Andi Kleen, Bernhard Kaindl, discuss, linux1394-devel, linux-kernel

On Sat, 2007-02-10 at 20:16 +0100, Stefan Richter wrote:
> [ohci1394_early]
> 
> Some remarks to the September 2006 version at
> http://www.suse.de/~bk/firewire/ :
> 
>   - Seems its .remove won't work properly if more than one OHCI-1394
>     controller is installed.  And it's .probe isn't reentrant, but that
>     might be less of a problem.
>   - Its functionality will be lost if there is a FireWire bus reset,
>     e.g. when something is plugged in or out.  To keep physical DMA
>     alive, an interrupt handler had to be installed which writes ~0
>     to OHCI1394_PhyReqFilter{Hi,Lo}Set.  Can interrupt handlers be
>     registered in an early setup stage?
>   - There might be some register accesses in the setup which could be
>     omitted; I'd have to look this up.
>   - Could be optimized to not use ohci1394.h::struct ti_ohci.
>   - PCI_CLASS_FIREWIRE_OHCI can be replaced by
>     include/linux/pci_ids.h::PCI_CLASS_SERIAL_FIREWIRE_OHCI which
>     was newly added in 2.6.20-git#.
>   - I suppose .probe should check for PCI_CLASS_SERIAL_FIREWIRE_OHCI
>     instead of PCI_CLASS_SERIAL_FIREWIRE.
>   - How about dropping support for configuring this as module, to
>     simplify the code?  Unless this would interfere with ohci1394; and
>     it probably would if there was an interrupt handler...
>   - "depends on X86_64" is missing in Kconfig.
>   - Maybe put it into arch/x86_64/drivers/ instead of drivers/ieee1394?
>   - Plus what I mentioned earlier in the thread.
> 
> I could send code to address some of this at next weekend or later.

I'd like to have that on ppc as well, so I'd rather keep it in drivers/

I agree that it doesn't need to be a module. If you can load modules,
then you can load the full ohci driver. Thus, if it's an early thingy
initialized by arch, it can export a special "takeover" hook that the
proper ohci module can then call to override it (important if we start
having an irq handler).

Andi, also, how do you deal with iommu ? Not at all ? :-)

Ben.



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: remote debugging via FireWire
  2007-02-11 21:35           ` Benjamin Herrenschmidt
@ 2007-02-12  6:49             ` Andi Kleen
  2007-02-12  7:29               ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 29+ messages in thread
From: Andi Kleen @ 2007-02-12  6:49 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Stefan Richter, Bernhard Kaindl, discuss, linux1394-devel, linux-kernel

On Sunday 11 February 2007 22:35, Benjamin Herrenschmidt wrote:

> I'd like to have that on ppc as well, so I'd rather keep it in drivers/

This will need some abstraction at least -- there are some early mapping hacks
that are x86 specific right now.

> I agree that it doesn't need to be a module. If you can load modules,
> then you can load the full ohci driver. Thus, if it's an early thingy
> initialized by arch, it can export a special "takeover" hook that the
> proper ohci module can then call to override it (important if we start
> having an irq handler).
> 
> Andi, also, how do you deal with iommu ? Not at all ? :-)

Yes -- it's really early debugging hack mostly. It's reasonable to 
let the iommu be disabled (or later a special bypass can be added for this) 

-Andi
 

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: remote debugging via FireWire
  2007-02-12  6:49             ` Andi Kleen
@ 2007-02-12  7:29               ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 29+ messages in thread
From: Benjamin Herrenschmidt @ 2007-02-12  7:29 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Stefan Richter, Bernhard Kaindl, discuss, linux1394-devel, linux-kernel

On Mon, 2007-02-12 at 07:49 +0100, Andi Kleen wrote:
> On Sunday 11 February 2007 22:35, Benjamin Herrenschmidt wrote:
> 
> > I'd like to have that on ppc as well, so I'd rather keep it in drivers/
> 
> This will need some abstraction at least -- there are some early mapping hacks
> that are x86 specific right now.

Either abstraction or ifdef's .. we have ioremap working very early on
ppc :-)

> > I agree that it doesn't need to be a module. If you can load modules,
> > then you can load the full ohci driver. Thus, if it's an early thingy
> > initialized by arch, it can export a special "takeover" hook that the
> > proper ohci module can then call to override it (important if we start
> > having an irq handler).
> > 
> > Andi, also, how do you deal with iommu ? Not at all ? :-)
> 
> Yes -- it's really early debugging hack mostly. It's reasonable to 
> let the iommu be disabled (or later a special bypass can be added for this) 

Ok.

Ben.



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: What will be in the x86-64/x86 2.6.21 merge
  2007-02-10 11:42 What will be in the x86-64/x86 2.6.21 merge Andi Kleen
  2007-02-10 13:43 ` [discuss] " Muli Ben-Yehuda
  2007-02-10 13:51 ` remote debugging via FireWire (was What will be in the x86-64/x86 2.6.21 merge) Stefan Richter
@ 2007-02-12 14:11 ` James Morris
  2007-02-12 14:14   ` Andi Kleen
  2 siblings, 1 reply; 29+ messages in thread
From: James Morris @ 2007-02-12 14:11 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel, discuss

On Sat, 10 Feb 2007, Andi Kleen wrote:

> - lguest
>   * still seems heavily in development. Not sure it will be ready in time.

How would you define ready?

It's currently useful and stable, and features a lack of enterprise-class 
complexity.



- James
-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: What will be in the x86-64/x86 2.6.21 merge
  2007-02-12 14:11 ` What will be in the x86-64/x86 2.6.21 merge James Morris
@ 2007-02-12 14:14   ` Andi Kleen
  2007-02-12 14:46     ` James Morris
  2007-02-14  6:53     ` Rusty Russell
  0 siblings, 2 replies; 29+ messages in thread
From: Andi Kleen @ 2007-02-12 14:14 UTC (permalink / raw)
  To: James Morris; +Cc: linux-kernel, discuss

On Monday 12 February 2007 15:11, James Morris wrote:
> On Sat, 10 Feb 2007, Andi Kleen wrote:
> 
> > - lguest
> >   * still seems heavily in development. Not sure it will be ready in time.
> 
> How would you define ready?

Used by at least some people for something, got some real world testing, more review.
 
> It's currently useful and stable, 

How do you know?

-Andi

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: What will be in the x86-64/x86 2.6.21 merge
  2007-02-12 14:14   ` Andi Kleen
@ 2007-02-12 14:46     ` James Morris
  2007-02-14  6:53     ` Rusty Russell
  1 sibling, 0 replies; 29+ messages in thread
From: James Morris @ 2007-02-12 14:46 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel, discuss

On Mon, 12 Feb 2007, Andi Kleen wrote:

> > It's currently useful and stable, 
> 
> How do you know?

I've been working on it for some weeks.  At this stage, it's also useful 
for some simple kernel hacking.



- James
-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: What will be in the x86-64/x86 2.6.21 merge
  2007-02-12 14:14   ` Andi Kleen
  2007-02-12 14:46     ` James Morris
@ 2007-02-14  6:53     ` Rusty Russell
  1 sibling, 0 replies; 29+ messages in thread
From: Rusty Russell @ 2007-02-14  6:53 UTC (permalink / raw)
  To: Andi Kleen; +Cc: James Morris, linux-kernel, discuss

On Mon, 2007-02-12 at 15:14 +0100, Andi Kleen wrote:
> On Monday 12 February 2007 15:11, James Morris wrote:
> > On Sat, 10 Feb 2007, Andi Kleen wrote:
> > 
> > > - lguest
> > >   * still seems heavily in development. Not sure it will be ready in time.
> > 
> > How would you define ready?
> 
> Used by at least some people for something, got some real world testing, more review.

Well, I only have bug reports from around half a dozen people, so I'm
not sure what that says about my userbase (for most people it should
simply work).

lguest.ozlabs.org got 3000 hits in the last 12 hours, and they can't all
be bots 8)  Mind you, in that time only 26 unique IP addresses visited
the patches/ repository, so maybe they are...

As to "insufficient review", the reviews so far have cleaned up some
code (great!) and found 3 actual bugs, none real showstoppers and all
now fixed:

 (1) race of initialization code vs. cpu hotplug.
 (2) block driver being suboptimal
 (3) network driver sending crap for inter-guest sendfile.

In addition, you counted not handling TSC change as a bug, so I tore
that code out, instead of leaving a FIXME.  During the cleanup patches I
did introduce (and then fix) another bug, it is true.

I would not describe it as "heavily in development"; I really think it's
at the stage where it can benefit from being in-tree.

> > It's currently useful and stable, 
> 
> How do you know?

Please don't harass my users.  That's my job!

Cheers!
Rusty.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: remote debugging via FireWire * __fast__ firedump!
  2007-02-10 13:51 ` remote debugging via FireWire (was What will be in the x86-64/x86 2.6.21 merge) Stefan Richter
  2007-02-10 14:02   ` Andi Kleen
@ 2007-12-04  3:45   ` Bernhard Kaindl
  2007-12-04  7:39     ` Andi Kleen
  2007-12-04 22:15     ` Stefan Richter
  1 sibling, 2 replies; 29+ messages in thread
From: Bernhard Kaindl @ 2007-12-04  3:45 UTC (permalink / raw)
  To: Stefan Richter, Benjamin Herrenschmidt
  Cc: Andi Kleen, Bernhard Kaindl, linux-kernel

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 done soon.

I've also started working on the userspace tools and got firescope
to work across the 32/64-bit machines (both directions), there is
one hack (which I should do in a clean way insteat) in that patch
of which I do not know if that works in ppc/ppc64 but I could look
at it if needed or send the patch to Benjamin for adding support
for ppc64, to do it properly, we'll probably need an target architecture
option in firescope and as I do not know if it's needed by Benjamin,
I left out ppc64 for now.

I have just had the guts to explore __fast__ memory dumping over
firewire for full-system dumps (reading quadlets is __painfully__
show if you want to read 2GB of memory over the bus, you only get
about some some kilobytes each second) using raw1394_start_read()
to allow also block reads instead of just quatlet reads.

The biggest block size that worked here was 2048 bytes, which was
enough to get nearly 10MB/s of data transfer rate from the remote
memory to disk. Dumping 2GB of remote memory was just a matter of
about 3 few short minutes which quickly ran by.

Afterwards, the victim was dead (I excluded the low MB of memory,
so something else must have caused this), at least the start of
the dump looked well, but I haven't tested the error handling yet,
but I'll send you the tool (I called it firedump) soon.

Bernhard

On Sat, 10 Feb 2007, Stefan Richter wrote:

> Andi Kleen wrote at LKML:
> ...
>> Not likely to make .21:
> ...
>> - Early firewire support for firescope at early boot
> ...
>
> Was it seen in canonical patch format on a mailinglist before?
> Is it Bernhard Kaindl's ohci1394_early?
> http://www.suse.de/~bk/firewire/
>
> Would be good to put this on the usual patch-submission road in order to
> prep it for 2.6.22. Could be handled via linux1394-2.6.git, although a
> different channel where the actual users of this facility watch would
> IMO be more appropriate.
>
> I also have suggestions, at least WRT Bernhard's code:
>  - The Kconfig option could go into the "Kernel hacking" submenu rather
>    than the IEEE 1394 submenu. (The driver source should stay in
>    drivers/ieee1394.)
>  - Leave a note in the Kconfig help how it is typically used, i.e. what
>    is required on the remote terminal side, where to find firescope,
>    fireproxy etc. and assorted HOWTOs.
>  - Indicate in the Kconfig help that only a 4GB address range is made
>    visible this way.
>
> A mostly unrelated note: A simple to set up remote-dmesg utility would
> be nice to have on the terminal side. Maybe a small ieee1394 high-level
> driver which gives hints on the location of the dmesg buffer via
> configuration ROM would be warranted. Or is it feasible to find the
> dmesg buffer by plain memory analysis?
> --
> Stefan Richter
> -=====-=-=== --=- -=-=-
> http://arcgraph.de/sr/
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> mailing list linux1394-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux1394-devel
>
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: remote debugging via FireWire * __fast__ firedump!
  2007-12-04  3:45   ` remote debugging via FireWire * __fast__ firedump! Bernhard Kaindl
@ 2007-12-04  7:39     ` Andi Kleen
  2007-12-06 16:02       ` Bernhard Kaindl
  2007-12-04 22:15     ` Stefan Richter
  1 sibling, 1 reply; 29+ messages in thread
From: Andi Kleen @ 2007-12-04  7:39 UTC (permalink / raw)
  To: Bernhard Kaindl
  Cc: Stefan Richter, Benjamin Herrenschmidt, Bernhard Kaindl, linux-kernel

On Tuesday 04 December 2007 04:45:22 am Bernhard Kaindl wrote:
>     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.

Nice.

> I have just had the guts to explore __fast__ memory dumping over
> firewire for full-system dumps (reading quadlets is __painfully__
> show if you want to read 2GB of memory over the bus, you only get
> about some some kilobytes each second) using raw1394_start_read()
> to allow also block reads instead of just quatlet reads.

Unfortunately it won't work for >3GB or so AFAIK.

> The biggest block size that worked here was 2048 bytes, which was
> enough to get nearly 10MB/s of data transfer rate from the remote
> memory to disk. Dumping 2GB of remote memory was just a matter of
> about 3 few short minutes which quickly ran by.
>
> Afterwards, the victim was dead (I excluded the low MB of memory,
> so something else must have caused this), at least the start of

Did you run into the PCI memory hole below 4GB? 

I suppose the best way would be to require a System.map and
then read e820.nr_map/e820.map[] and only dump real memory.

-Andi

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: remote debugging via FireWire * __fast__ firedump!
  2007-12-04  3:45   ` remote debugging via FireWire * __fast__ firedump! Bernhard Kaindl
  2007-12-04  7:39     ` Andi Kleen
@ 2007-12-04 22:15     ` Stefan Richter
  2007-12-04 22:34       ` Stefan Richter
  2007-12-06 16:32       ` remote debugging via FireWire * __fast__ firedump! Bernhard Kaindl
  1 sibling, 2 replies; 29+ messages in thread
From: Stefan Richter @ 2007-12-04 22:15 UTC (permalink / raw)
  To: Bernhard Kaindl
  Cc: Benjamin Herrenschmidt, Andi Kleen, Bernhard Kaindl, linux-kernel

Bernhard Kaindl wrote:
> The biggest block size that worked here was 2048 bytes, which was
> enough to get nearly 10MB/s of data transfer rate from the remote
> memory to disk.

The maximum payload size of block requests depends on three things:
1. speed of the connection between the two nodes (debugged machine and
debugging machine), 2. link layer controllers of the two nodes, 3.
software on the debugging machine.

1.) S100: 512 bytes, S200: 1024 bytes, S400: 2048 bytes, S800 and more:
4096 bytes.

2.) Controllers on CardBus cards are limited to 1024 bytes payload of
asynchronous packets, for reasons I don't know.  The other available
controllers only have the above mentioned speed-dependent limit.

3.) The ohci1394 driver has an implementation limitation which requires
that all packets including headers don't exceed PAGE_SIZE.  This does
not affect the packets which go through the physical response unit
(which they do on the debugged machine) but it affects the debugging
machine.

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
> +	  devices, be sure to have FireWire enabled on the debug host (and
> +	  the cable plugged) before booting the debug target for debugging.

Bus resets are also caused by bus managing software, which Linux' old
and new FireWire stacks and the stacks of all other FireWire capable
desktop OSs are to varying degrees.  I wonder if the following could
happen:  The two PCs are directly connected, only the PHY of the
debugging PC is active, then the PHY of the debugged PC is activated,
becomes root node, debugging PC examines the bus, then resets the bus to
force its own PHY to become root node in order to get a working
isochronous resource manager.  This bus reset would switch remote DMA on
the debugged PC off.
-- 
Stefan Richter
-=====-=-=== ==-- --=--
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: remote debugging via FireWire * __fast__ firedump!
  2007-12-04 22:15     ` Stefan Richter
@ 2007-12-04 22:34       ` Stefan Richter
  2007-12-04 22:40         ` Stefan Richter
  2007-12-06 16:32       ` remote debugging via FireWire * __fast__ firedump! Bernhard Kaindl
  1 sibling, 1 reply; 29+ messages in thread
From: Stefan Richter @ 2007-12-04 22:34 UTC (permalink / raw)
  To: Bernhard Kaindl
  Cc: Benjamin Herrenschmidt, Andi Kleen, Bernhard Kaindl, linux-kernel

Stefan Richter wrote:
> Bernhard Kaindl wrote:
>> The biggest block size that worked here was 2048 bytes, which was
>> enough to get nearly 10MB/s of data transfer rate from the remote
>> memory to disk.
> 
> The maximum payload size of block requests depends on three things:
> 1. speed of the connection between the two nodes (debugged machine and
> debugging machine), 2. link layer controllers of the two nodes, 3.
> software on the debugging machine.
> 
> 1.) S100: 512 bytes, S200: 1024 bytes, S400: 2048 bytes, S800 and more:
> 4096 bytes.

PS:
If there are only 1394a nodes, you can read the connection speed from
the speed map registers on the debugging machine.  It becomes difficult
for 1394b nodes and some mixtures of 1394a and b nodes.  But consumer
1394b hardware is always S800 capable.  Consumer 1394a hardware is
always S400 capable.  Except consumer camcorders which are AFAIK
typically limited to S100, but they have only one port and will
therefore never sit between debugging and debugged PC.  So it's not as
difficult in 99.9% of the cases:  You can expect S400, some people might
get S800.  But you can't use the bigger S800 block size if the debugging
machine runs ohci1394.

> 2.) Controllers on CardBus cards are limited to 1024 bytes payload of
> asynchronous packets, for reasons I don't know.  The other available
> controllers only have the above mentioned speed-dependent limit.

This is relevant if the debugging or the debugged PC have a CardBus
card.  Actually this is the limit of all 1394a CardBus card I have seen;
I don't know about 1394b CardBus cards, or Express cards.  (I suppose
Express cards have no limits of this kind, as they are just PCIe cards
in a different formfactor.)

This payload limitation of the link can be read from the bus info blocks
of the debugged and the debugging machine.  Though I am not entirely
sure right now if the ohci1394_earlyinit driven machine will have its
bus info block properly set up.
-- 
Stefan Richter
-=====-=-=== ==-- --=--
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: remote debugging via FireWire * __fast__ firedump!
  2007-12-04 22:34       ` Stefan Richter
@ 2007-12-04 22:40         ` Stefan Richter
  2007-12-06 18:36           ` [feedback discussion] Early boot debugging via FireWire (ohci1394_dma=early) Bernhard Kaindl
  0 siblings, 1 reply; 29+ messages in thread
From: Stefan Richter @ 2007-12-04 22:40 UTC (permalink / raw)
  To: Bernhard Kaindl
  Cc: Benjamin Herrenschmidt, Andi Kleen, Bernhard Kaindl, linux-kernel

PPS:  Today I had a brief look through your current sources.  Look good
so far, except for a curious hunk which patches drivers/Makefile.  And I
can't say anything to the x86 platform related and PCI related aspects
of the driver.
-- 
Stefan Richter
-=====-=-=== ==-- --=--
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: remote debugging via FireWire * __fast__ firedump!
  2007-12-04  7:39     ` Andi Kleen
@ 2007-12-06 16:02       ` Bernhard Kaindl
  0 siblings, 0 replies; 29+ messages in thread
From: Bernhard Kaindl @ 2007-12-06 16:02 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel

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 dead (I excluded the low MB of memory,
>> so something else must have caused this), at least the start of
>
> Did you run into the PCI memory hole below 4GB?

Thanks, that was it most likely. I checked and haw that I did
read a 32MB reserved area just below 2GB.

> I suppose the best way would be to require a System.map and
> then read e820.nr_map/e820.map[] and only dump real memory.

Yes, good idea!
Bernhard

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: remote debugging via FireWire * __fast__ firedump!
  2007-12-04 22:15     ` Stefan Richter
  2007-12-04 22:34       ` Stefan Richter
@ 2007-12-06 16:32       ` Bernhard Kaindl
  1 sibling, 0 replies; 29+ messages in thread
From: Bernhard Kaindl @ 2007-12-06 16:32 UTC (permalink / raw)
  To: Stefan Richter; +Cc: linux-kernel

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
>> +	  devices, be sure to have FireWire enabled on the debug host (and
>> +	  the cable plugged) before booting the debug target for debugging.
>
> Bus resets are also caused by bus managing software, which Linux' old
> and new FireWire stacks and the stacks of all other FireWire capable
> desktop OSs are to varying degrees.

Yes, I can also trigger it raw1394_reset_bus() from libraw1394.

>                                      I wonder if the following could
> happen:  The two PCs are directly connected, only the PHY of the
> debugging PC is active, then the PHY of the debugged PC is activated,
> becomes root node, debugging PC examines the bus, then resets the bus to
> force its own PHY to become root node in order to get a working
> isochronous resource manager.  This bus reset would switch remote DMA on
> the debugged PC off.

Yes, that's the case. The PHY of the debugging PC must be active before the
booting a kernel with the early OHCI-1394 initialisation on the debugged
machine.

I tried to to instruct users to do exactly that in that part of the help
text, but changed the wording now in to hope to make it clearer:

+	  [...] be sure to have the cable plugged and FireWire enabled on
+	  the debugging host before booting the debug target for debugging.

and I added new file, installed as Documentation/debugging-via-ohci1394.txt
to give a more detailed HOWTO with links to all available tools and a step
by step guide on how to create a setup for using firescope.

ftp://ftp.suse.de/private/bk/firewire/kernel/ohci1394_dma_early-v2.diff

I'll submit that patch for full review in my next mail.

Bernhard

^ permalink raw reply	[flat|nested] 29+ messages in thread

* [feedback discussion] Early boot debugging via FireWire (ohci1394_dma=early)
  2007-12-04 22:40         ` Stefan Richter
@ 2007-12-06 18:36           ` Bernhard Kaindl
  2007-12-06 19:23             ` Stefan Richter
  2007-12-06 19:23             ` [PATCH] " Bernhard Kaindl
  0 siblings, 2 replies; 29+ messages in thread
From: Bernhard Kaindl @ 2007-12-06 18:36 UTC (permalink / raw)
  To: Stefan Richter; +Cc: Bernhard Kaindl, linux-kernel, linux1394-devel

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-related parts.

On Tue, 4 Dec 2007, Stefan Richter wrote:
> 
> PPS:  Today I had a brief look through your current sources.  Look good
> so far, except for a curious hunk which patches drivers/Makefile.  And I
> can't say anything to the x86 platform related and PCI related aspects
> of the driver.

Thanks, good catch. The I fixed that hunk now

ftp://ftp.suse.de/private/bk/firewire/kernel/ohci1394_dma_early-v2.diff

to read like this:

linux-2.6.24-rc4/drivers/Makefile:

  obj-$(CONFIG_ATA)		+= ata/
  obj-$(CONFIG_FUSION)		+= message/
  obj-$(CONFIG_FIREWIRE)		+= firewire/
-obj-$(CONFIG_IEEE1394)		+= ieee1394/
+obj-y				+= ieee1394/
  obj-$(CONFIG_UIO)		+= uio/
  obj-y				+= cdrom/
  obj-y				+= auxdisplay/

The reason for adding it was that drivers/ieee1394/init_ohci1394_dma.c
does not get compiled if CONFIG_IEEE1394 is not set, but it's not really
depeding on CONFIG_IEEE1394 being set.

The only effect this hunk has (and only when CONFIG_IEEE1394 is not set)
is that an empty object file is created in drivers/ieee1394 for linking
into vmlinux, but as it does not contain any code or data, it does not
change vmlinux at all.

If you do not approve that change, I'd have to add a "depends IEEE1394"
to the new config entry. I adopted way to have the early firewire debugging
option showing up all times, not only when CONFIG_IEEE1394 is set.

I tried to add "selects IEEE1394", but that causes IEEE1394 to be compiled
into the kernel even if you do not intend that, so I saw the hunk above as
the best way to deal with it.

==========================================================================

I'm commenting on suggestions made in the early part of this thread, it
can be found at http://lkml.org/lkml/2007/2/10/96 :

>   - The Kconfig option could go into the "Kernel hacking" submenu rather
>     than the IEEE 1394 submenu. (The driver source should stay in
>     drivers/ieee1394.)

done.

>   - Leave a note in the Kconfig help how it is typically used, i.e. what
>     is required on the remote terminal side, where to find firescope,
>     fireproxy etc. and assorted HOWTOs.

I have put that to Documentation/debugging-via-ohci1394.txt in the new patch.

>   - Indicate in the Kconfig help that only a 4GB address range is made
>     visible this way.

done.

Andi Kleen said that he would handle to patch-submission process:

> It's more related to arch code than firewire, so I thought i would
> handle it. But you can too if you want. It definitely needs much
> more review anyways.

To which Stefan Richter agreed:

> It's better you do it. I don't know anything about the specifics of
> early initialization. Just Cc linux1394-devel on submission so that we
> can have a look at the OHCI-1394 related bits.

doing that now, Stefan also remarked:

> Using linux1394-2.6.git could only be helpful if more code sharing
> between ohci1394.c and ohci1394_early.c would be desired. That's
> questionable though, given the rather small size of ohci1394_early.c.

Andi agreed:

> Ok. I'm sure you know more about 1394 than me so I guess it will be shared
> review.

Stefan then did a code review and came back with:

>   - Its functionality will be lost if there is a FireWire bus reset,
>     e.g. when something is plugged in or out.  To keep physical DMA
>     alive, an interrupt handler had to be installed which writes ~0
>     to OHCI1394_PhyReqFilter{Hi,Lo}Set.  Can interrupt handlers be
>     registered in an early setup stage?

We didn't go into this further, and while I have further ideas on that,
like polling for bus resets in the Oops and Panic handlers,
I now resorted to documenting that carefully as especially if the issue
to be debugged crashed the machine bady or one wants to run a kernel
debugger over firewire using physical DMA, interrupts would be disabled
anyways.

>   - There might be some register accesses in the setup which could be
>     omitted; I'd have to look this up.

Migth be possible. I didn't give this a major priority because at least
in this version, all code is tagged with __init, so everything is freed
after boot, and even if we keep the init routine, there is not a awful
lot to remove. When linked into vmlinux, I saw about 1k size increase
for the whole initialisation routine.

>   - Could be optimized to not use ohci1394.h::struct ti_ohci.

Indeed, but I didn't see it a big gain to have my own copy of it.
As nothing (except a fixmap per controller) is allocated permanently,
it wouldn't change the compiled code. In a future step, it may share
some source code with fw-ohci to make the source even smaller, the
source code which could be shared is about 84 lines, not very much.

>   - PCI_CLASS_FIREWIRE_OHCI can be replaced by
>     include/linux/pci_ids.h::PCI_CLASS_SERIAL_FIREWIRE_OHCI which
>     was newly added in 2.6.20-git#.

done.

>   - How about dropping support for configuring this as module, to
>     simplify the code?  Unless this would interfere with ohci1394; and
>     it probably would if there was an interrupt handler...

done, no interrupt handler.

>   - "depends on X86_64" is missing in Kconfig.

Added support for X86_32 too, so it has a depends X86 now. It uses a fixmap
currenlty which means that it's X86-only for now, for ppc see below.

>   - Maybe put it into arch/x86_64/drivers/ instead of drivers/ieee1394?

Ben replied to that:

> I'd like to have that on ppc as well, so I'd rather keep it in drivers/

He asked:
> > > Andi, also, how do you deal with iommu ? Not at all ? :-)
Andi:
> > Yes -- it's really early debugging hack mostly. It's reasonable to
> > let the iommu be disabled (or later a special bypass can be added for this)
Ben:
> Ok.

On support for PowerPC and other archtectures:

>> This will need some abstraction at least -- there are some early mapping hacks
>> that are x86 specific right now.
> Either abstraction or ifdef's .. we have ioremap working very early on
> ppc :-)

Either way would be fine with me. I'd like to put it this way:

Everyone is free to extend the code to execute also early on more archtectures,
and I could even look at that myself in January but not now as I'm on vacation
from next week on. I think that support for more architectures can be added
with incremental patches.

I'll submit the patch now in the formal way (next mail) for full review,
Bernhard

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [feedback discussion] Early boot debugging via FireWire (ohci1394_dma=early)
  2007-12-06 18:36           ` [feedback discussion] Early boot debugging via FireWire (ohci1394_dma=early) Bernhard Kaindl
@ 2007-12-06 19:23             ` Stefan Richter
  2007-12-06 19:23             ` [PATCH] " Bernhard Kaindl
  1 sibling, 0 replies; 29+ messages in thread
From: Stefan Richter @ 2007-12-06 19:23 UTC (permalink / raw)
  To: Bernhard Kaindl; +Cc: Bernhard Kaindl, linux-kernel, linux1394-devel

Bernhard Kaindl wrote:
> linux-2.6.24-rc4/drivers/Makefile:
...
> -obj-$(CONFIG_IEEE1394)        += ieee1394/
> +obj-y                += ieee1394/
...
> The reason for adding it was that drivers/ieee1394/init_ohci1394_dma.c
> does not get compiled if CONFIG_IEEE1394 is not set, but it's not really
> depeding on CONFIG_IEEE1394 being set.

>From what I gather from e.g. drivers/usb/Makefile, you could do it also
this way:

 obj-$(CONFIG_IEEE1394)		+= ieee1394/
+obj-$(CONFIG_PROVIDE_OHCI1394_DMA_INIT) += ieee1394/

-- 
Stefan Richter
-=====-=-=== ==-- --==-
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 29+ messages in thread

* [PATCH] Early boot debugging via FireWire (ohci1394_dma=early)
  2007-12-06 18:36           ` [feedback discussion] Early boot debugging via FireWire (ohci1394_dma=early) Bernhard Kaindl
  2007-12-06 19:23             ` Stefan Richter
@ 2007-12-06 19:23             ` Bernhard Kaindl
  2007-12-06 20:23               ` Stefan Richter
  2007-12-17 13:49               ` Ingo Molnar
  1 sibling, 2 replies; 29+ messages in thread
From: Bernhard Kaindl @ 2007-12-06 19:23 UTC (permalink / raw)
  To: Stefan Richter, Andi Kleen
  Cc: Bernhard Kaindl, linux-kernel, linux1394-devel, Thomas Renninger,
	Benjamin Herrenschmidt

Hi,
   after summing up the discussion on previous patches, I'm now submitting the
patch below for formal review and adoption on branches for mainline inclusion.

As this patch is X86-only for now (might be extended for more architectures in
incremental patches tough), initially (that was in February 2007) Andi Kleen
offered to handle the patch submission.

Subject of this patch:

This patch adds a new configuration option, which adds support for a new
early_param which gets checked in arch/x86/kernel/setup_{32,64}.c:setup_arch()
to decide wether OHCI-1394 FireWire controllers should be initialized and
enabled for physical DMA access to allow remote debugging of early problems
like issues ACPI or other subsystems which are executed very early.

If the config option is not enabled, no code is changed, and if the boot
paramenter is not given, no new code is executed, and independent of that,
all new code is freed after boot, so the config option can be even enabled
in standard, non-debug kernels.

With specialized tools, it is then possible to get debugging information
from machines which have no serial ports (notebooks) such as the printk
buffer contents, or any data which can be referenced from global pointers,
if it is stored below the 4GB limit and even memory dumps of of the physical
RAM region below the 4GB limit can be taken without any cooperation from the
CPU of the host, so the machine can be crashed early, it does not matter.

In the extreme, even kernel debuggers can be accessed in this way. I wrote
a small kgdb module and an accompanying gdb stub for FireWire which allows
to gdb to talk to kgdb using remote remory reads and writes over FireWire.

An version of the gdb stub fore FireWire is able to read all global data
from a system which is running a a normal kernel without any kernel debugger,
without any interruption or support of the system's CPU. That way, e.g. the
task struct and so on can be read and even manipulated when the physical DMA
access is granted.

A HOWTO is included in this patch, in Documentation/debugging-via-ohci1394.txt
and I've put a copy online at
ftp://ftp.suse.de/private/bk/firewire/docs/debugging-via-ohci1394.txt

It also has links to all the tools which are available to make use of it
another copy of it is online at:
ftp://ftp.suse.de/private/bk/firewire/kernel/ohci1394_dma_early-v2.diff

Cheers,
Bernhard

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 <bk@suse.de>
Tested-By:     Thomas Renninger <trenn@suse.de>

--- linux-2.6.24-rc4/arch/x86/kernel/setup_32.c
+++ linux-2.6.24-rc4/arch/x86/kernel/setup_32.c
@@ -44,6 +44,7 @@
 #include <linux/crash_dump.h>
 #include <linux/dmi.h>
 #include <linux/pfn.h>
+#include <linux/init_ohci1394_dma.h>
 
 #include <video/edid.h>
 
@@ -636,6 +637,16 @@
 	smp_alloc_memory(); /* AP processor realmode stacks in low memory*/
 #endif
 	paging_init();
+
+	/*
+	 * NOTE: On x86-32, only from this point on, fixmaps are ready for use.
+	 */
+
+#ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
+	if (init_ohci1394_dma_early)
+		init_ohci1394_dma_on_all_controllers();
+#endif
+
 	remapped_pgdat_init();
 	sparse_init();
 	zone_sizes_init();
--- linux-2.6.24-rc4/arch/x86/kernel/setup_64.c
+++ linux-2.6.24-rc4/arch/x86/kernel/setup_64.c
@@ -39,6 +39,7 @@
 #include <linux/dmi.h>
 #include <linux/dma-mapping.h>
 #include <linux/ctype.h>
+#include <linux/init_ohci1394_dma.h>
 
 #include <asm/mtrr.h>
 #include <asm/uaccess.h>
@@ -254,6 +255,11 @@
 		ebda_size = 64*1024;
 }
 
+/*
+ * setup_arch - architecture-specific boot-time initializations
+ *
+ * Note: On x86_64, fixmaps are ready for use even before this is called.
+ */
 void __init setup_arch(char **cmdline_p)
 {
 	printk(KERN_INFO "Command line: %s\n", boot_command_line);
@@ -293,6 +299,11 @@
 
 	parse_early_param();
 
+#ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
+	if (init_ohci1394_dma_early)
+		init_ohci1394_dma_on_all_controllers();
+#endif
+
 	finish_e820_parsing();
 
 	e820_register_active_regions(0, 0, -1UL);
--- linux-2.6.24-rc4/drivers/Makefile
+++ linux-2.6.24-rc4/drivers/Makefile
@@ -38,7 +38,7 @@
 obj-$(CONFIG_ATA)		+= ata/
 obj-$(CONFIG_FUSION)		+= message/
 obj-$(CONFIG_FIREWIRE)		+= firewire/
-obj-$(CONFIG_IEEE1394)		+= ieee1394/
+obj-y				+= ieee1394/
 obj-$(CONFIG_UIO)		+= uio/
 obj-y				+= cdrom/
 obj-y				+= auxdisplay/
--- linux-2.6.24-rc4/drivers/ieee1394/Makefile
+++ linux-2.6.24-rc4/drivers/ieee1394/Makefile
@@ -15,3 +15,4 @@
 obj-$(CONFIG_IEEE1394_DV1394) += dv1394.o
 obj-$(CONFIG_IEEE1394_ETH1394) += eth1394.o
 
+obj-$(CONFIG_PROVIDE_OHCI1394_DMA_INIT) += init_ohci1394_dma.o
--- linux-2.6.24-rc4/drivers/ieee1394/init_ohci1394_dma.c
+++ linux-2.6.24-rc4/drivers/ieee1394/init_ohci1394_dma.c
@@ -0,0 +1,285 @@
+/*
+ * init_ohci1394_dma.c - Initializes physical DMA on all OHCI 1394 controllers
+ *
+ * Copyright (C) 2006-2007      Bernhard Kaindl <bk@suse.de>
+ *
+ * Derived from drivers/ieee1394/ohci1394.c and arch/x86/kernel/early-quirks.c
+ * this file has functions to:
+ * - scan the PCI very early on boot for all OHCI 1394-compliant controllers
+ * - reset and initialize them and make them join the IEEE1394 bus and
+ * - enable physical DMA on them to allow remote debugging
+ *
+ * All code and data is marked as __init and __initdata, respective as
+ * during boot, all OHCI1394 controllers may be claimed by the firewire
+ * stack and at this point, this code should not touch them anymore.
+ *
+ * To use physical DMA after the initialization of the firewire stack,
+ * be sure that the stack enables it and (re-)attach after the bus reset
+ * which may be caused by the firewire stack initialization.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include <linux/interrupt.h>	/* for ohci1394.h */
+#include <linux/delay.h>
+#include <linux/pci.h>		/* for PCI defines */
+#include <linux/init_ohci1394_dma.h>
+#include <asm/pci-direct.h>	/* for direct PCI config space access */
+#include <asm/fixmap.h>
+
+#include "ieee1394_types.h"
+#include "ohci1394.h"
+
+int __initdata init_ohci1394_dma_early;
+
+/* Reads a PHY register of an OHCI-1394 controller */
+static inline u8 __init get_phy_reg(struct ti_ohci *ohci, u8 addr)
+{
+	int i;
+	quadlet_t r;
+
+	reg_write(ohci, OHCI1394_PhyControl, (addr << 8) | 0x00008000);
+
+	for (i = 0; i < OHCI_LOOP_COUNT; i++) {
+		if (reg_read(ohci, OHCI1394_PhyControl) & 0x80000000)
+			break;
+		mdelay(1);
+	}
+	r = reg_read(ohci, OHCI1394_PhyControl);
+
+	return (r & 0x00ff0000) >> 16;
+}
+
+/* Writes to a PHY register of an OHCI-1394 controller */
+static inline void __init set_phy_reg(struct ti_ohci *ohci, u8 addr, u8 data)
+{
+	int i;
+
+	reg_write(ohci, OHCI1394_PhyControl, (addr << 8) | data | 0x00004000);
+
+	for (i = 0; i < OHCI_LOOP_COUNT; i++) {
+		u32 r = reg_read(ohci, OHCI1394_PhyControl);
+		if (!(r & 0x00004000))
+			break;
+		mdelay(1);
+	}
+}
+
+/* Resets an OHCI-1394 controller (for sane state before initialization) */
+static inline void __init init_ohci1394_soft_reset(struct ti_ohci *ohci) {
+	int i;
+
+	reg_write(ohci, OHCI1394_HCControlSet, OHCI1394_HCControl_softReset);
+
+	for (i = 0; i < OHCI_LOOP_COUNT; i++) {
+		if (!(reg_read(ohci, OHCI1394_HCControlSet)
+				   & OHCI1394_HCControl_softReset))
+			break;
+		mdelay(1);
+	}
+}
+
+/* Basic OHCI-1394 register and port inititalization */
+static inline void __init init_ohci1394_initialize(struct ti_ohci *ohci)
+{
+	quadlet_t bus_options;
+	int num_ports, i;
+
+	/* Put some defaults to these undefined bus options */
+	bus_options = reg_read(ohci, OHCI1394_BusOptions);
+	bus_options |=  0x60000000; /* Enable CMC and ISC */
+	bus_options &= ~0x00ff0000; /* XXX: Set cyc_clk_acc to zero for now */
+	bus_options &= ~0x18000000; /* Disable PMC and BMC */
+	reg_write(ohci, OHCI1394_BusOptions, bus_options);
+
+	/* Set the bus number */
+	reg_write(ohci, OHCI1394_NodeID, 0x0000ffc0);
+
+	/* Enable posted writes */
+	reg_write(ohci, OHCI1394_HCControlSet,
+			OHCI1394_HCControl_postedWriteEnable);
+
+	/* Clear link control register */
+	reg_write(ohci, OHCI1394_LinkControlClear, 0xffffffff);
+
+	/* enable phys */
+	reg_write(ohci, OHCI1394_LinkControlSet,
+			OHCI1394_LinkControl_RcvPhyPkt);
+
+	/* Don't accept phy packets into AR request context */
+	reg_write(ohci, OHCI1394_LinkControlClear, 0x00000400);
+
+	/* Clear the Isochonouys interrupt masks */
+	reg_write(ohci, OHCI1394_IsoRecvIntMaskClear, 0xffffffff);
+	reg_write(ohci, OHCI1394_IsoRecvIntEventClear, 0xffffffff);
+	reg_write(ohci, OHCI1394_IsoXmitIntMaskClear, 0xffffffff);
+	reg_write(ohci, OHCI1394_IsoXmitIntEventClear, 0xffffffff);
+
+	/* Accept asyncronous transfer requests from all nodes for now */
+	reg_write(ohci,OHCI1394_AsReqFilterHiSet, 0x80000000);
+
+	/* Specify asyncronous transfer retries */
+	reg_write(ohci, OHCI1394_ATRetries,
+		  OHCI1394_MAX_AT_REQ_RETRIES |
+		  (OHCI1394_MAX_AT_RESP_RETRIES<<4) |
+		  (OHCI1394_MAX_PHYS_RESP_RETRIES<<8));
+
+	/* We don't want hardware swapping */
+	reg_write(ohci, OHCI1394_HCControlClear, OHCI1394_HCControl_noByteSwap);
+
+	/* Enable link */
+	reg_write(ohci, OHCI1394_HCControlSet, OHCI1394_HCControl_linkEnable);
+
+	/* If anything is connected to a port, make sure it is enabled */
+	num_ports = get_phy_reg(ohci, 2) & 0xf;
+	for (i = 0; i < num_ports; i++) {
+		unsigned int status;
+
+		set_phy_reg(ohci, 7, i);
+		status = get_phy_reg(ohci, 8);
+
+		if (status & 0x20)
+			set_phy_reg(ohci, 8, status & ~1);
+	}
+}
+
+/**
+ * init_ohci1394_wait_for_busresets - wait until bus resets are completed
+ *
+ * OHCI1394 initialization itself and any device going on- or offline
+ * and any cable issue cause a IEEE1394 bus reset. The OHCI1394 spec
+ * specifies that physical DMA is disabled on each bus reset and it
+ * has to be enabled after each bus reset when needed. We resort
+ * to polling here because on early boot, we have no interrupts.
+ */
+static inline void __init init_ohci1394_wait_for_busresets(struct ti_ohci *ohci)
+{
+	int i, events;
+
+	for (i=0; i < 9; i++) {
+		mdelay(200);
+		events = reg_read(ohci, OHCI1394_IntEventSet);
+		if (events & OHCI1394_busReset)
+			reg_write(ohci, OHCI1394_IntEventClear,
+					OHCI1394_busReset);
+	}
+}
+
+/**
+ * init_ohci1394_enable_physical_dma - Enable physical DMA for remote debugging
+ * This enables remote DMA access over IEEE1394 from every host for the low
+ * 4GB of address space. DMA accesses above 4GB are not available currently.
+ */
+static inline void __init init_ohci1394_enable_physical_dma(struct ti_ohci *hci)
+{
+	reg_write(hci, OHCI1394_PhyReqFilterHiSet, 0xffffffff);
+	reg_write(hci, OHCI1394_PhyReqFilterLoSet, 0xffffffff);
+	reg_write(hci, OHCI1394_PhyUpperBound, 0xffff0000);
+}
+
+/**
+ * init_ohci1394_reset_and_init_dma - init controller and enable DMA
+ * This initializes the given controller and enables physical DMA engine in it.
+ */
+static inline void __init init_ohci1394_reset_and_init_dma(struct ti_ohci *ohci)
+{
+	/* Start off with a soft reset, clears everything to a sane state. */
+	init_ohci1394_soft_reset(ohci);
+
+	/* Accessing some registers without LPS enabled may cause lock up */
+	reg_write(ohci, OHCI1394_HCControlSet, OHCI1394_HCControl_LPS);
+
+	/* Disable and clear interrupts */
+	reg_write(ohci, OHCI1394_IntEventClear, 0xffffffff);
+	reg_write(ohci, OHCI1394_IntMaskClear, 0xffffffff);
+
+	mdelay(50); /* Wait 50msec to make sure we have full link enabled */
+
+	init_ohci1394_initialize(ohci);
+	/*
+	 * The initialization causes at least one IEEE1394 bus reset. Enabling
+	 * physical DMA only works *after* *all* bus resets have calmed down:
+	 */
+	init_ohci1394_wait_for_busresets(ohci);
+
+	/* We had to wait and do this now if we want to debug early problems */
+	init_ohci1394_enable_physical_dma(ohci);
+}
+
+/**
+ * init_ohci1394_controller - Map the registers of the controller and init DMA
+ * This maps the registers of the specified controller and initializes it
+ */
+static inline void __init init_ohci1394_controller(int num, int slot, int func)
+{
+	unsigned long ohci_base;
+	struct ti_ohci ohci;
+
+	printk(KERN_INFO "init_ohci1394_dma: initializing OHCI-1394"
+			 " at %02x:%02x.%x\n", num, slot, func);
+
+	ohci_base = read_pci_config(num, slot, func, PCI_BASE_ADDRESS_0+(0<<2))
+						   & PCI_BASE_ADDRESS_MEM_MASK;
+
+	set_fixmap_nocache(FIX_OHCI1394_BASE, ohci_base);
+
+	ohci.registers = (void *)fix_to_virt(FIX_OHCI1394_BASE);
+
+	init_ohci1394_reset_and_init_dma(&ohci);
+}
+
+/**
+ * debug_init_ohci1394_dma - scan for OHCI1394 controllers and init DMA on them
+ * Scans the whole PCI space for OHCI1394 controllers and inits DMA on them
+ */
+void __init init_ohci1394_dma_on_all_controllers(void)
+{
+	int num, slot, func;
+
+	if (!early_pci_allowed())
+		return;
+
+	/* Poor man's PCI discovery, the only thing we can do at early boot */
+	for (num = 0; num < 32; num++) {
+		for (slot = 0; slot < 32; slot++) {
+			for (func = 0; func < 8; func++) {
+				u32 class = read_pci_config(num,slot,func,
+							PCI_CLASS_REVISION);
+				if ((class == 0xffffffff))
+					continue; /* No device at this func */
+
+				if (class>>8 != PCI_CLASS_SERIAL_FIREWIRE_OHCI)
+					continue; /* Not an OHCI-1394 device */
+
+				init_ohci1394_controller(num, slot, func);
+				break; /* Assume one controller per device */
+			}
+		}
+	}
+	printk(KERN_INFO "init_ohci1394_dma: finished initializing OHCI DMA\n");
+}
+
+/**
+ * setup_init_ohci1394_early - enables early OHCI1394 DMA initialization
+ */
+static int __init setup_ohci1394_dma(char *opt)
+{
+	if (!strcmp(opt, "early"))
+		init_ohci1394_dma_early = 1;
+	return 0;
+}
+
+/* passing ohci1394_dma=early on boot causes early OHCI1394 DMA initialization */
+early_param("ohci1394_dma", setup_ohci1394_dma);
--- linux-2.6.24-rc4/include/asm-x86/fixmap_32.h
+++ linux-2.6.24-rc4/include/asm-x86/fixmap_32.h
@@ -95,6 +95,9 @@
 	FIX_BTMAP_END = __end_of_permanent_fixed_addresses,
 	FIX_BTMAP_BEGIN = FIX_BTMAP_END + NR_FIX_BTMAPS - 1,
 	FIX_WP_TEST,
+#ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
+	FIX_OHCI1394_BASE,
+#endif
 	__end_of_fixed_addresses
 };
 
--- linux-2.6.24-rc4/include/asm-x86/fixmap_64.h
+++ linux-2.6.24-rc4/include/asm-x86/fixmap_64.h
@@ -41,6 +41,9 @@
 	FIX_APIC_BASE,	/* local (CPU) APIC) -- required for SMP or not */
 	FIX_IO_APIC_BASE_0,
 	FIX_IO_APIC_BASE_END = FIX_IO_APIC_BASE_0 + MAX_IO_APICS-1,
+#ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
+	FIX_OHCI1394_BASE,
+#endif
 	__end_of_fixed_addresses
 };
 
--- linux-2.6.24-rc4/include/linux/init_ohci1394_dma.h
+++ linux-2.6.24-rc4/include/linux/init_ohci1394_dma.h
@@ -0,0 +1,4 @@
+#ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
+extern int __initdata init_ohci1394_dma_early;
+extern void __init init_ohci1394_dma_on_all_controllers(void);
+#endif
--- linux-2.6.24-rc4/lib/Kconfig.debug
+++ linux-2.6.24-rc4/lib/Kconfig.debug
@@ -517,4 +517,33 @@
 	help
 	  Provide stacktrace filter for fault-injection capabilities
 
+config PROVIDE_OHCI1394_DMA_INIT
+	bool "Provide code for enabling DMA over FireWire early on boot"
+	depends on PCI && X86
+	help
+	  If you want to debug problems which hang or crash the kernel early
+	  on boot and the crashing machine has a FireWire port, you can use
+	  this feature to remotely access the memory of the crashed machine
+	  over FireWire. This employs remote DMA as part of the OHCI1394
+	  specification which is now the standard for FireWire controllers.
+
+	  With remote DMA, you can monitor the printk buffer remotely using
+	  firescope and access all memory below 4GB using fireproxy from gdb.
+	  Even controlling a kernel debugger is possible using remote DMA.
+
+	  Usage:
+
+	  If ohci1394_dma=early is used as boot parameter, it will initialize
+	  all OHCI1394 controllers which are found in the PCI config space.
+
+	  As all changes to the FireWire bus such as enabling and disabling
+	  devices cause a bus reset and thereby disable remote DMA for all
+	  devices, be sure to have the cable plugged and FireWire enabled on
+	  the debugging host before booting the debug target for debugging.
+
+	  This code (~1k) is freed after boot. By then, the firewire stack
+	  in charge of the OHCI-1394 controllers should be used instead.
+
+	  See Documentation/debugging-via-ohci1394.txt for more information. 
+
 source "samples/Kconfig"
--- linux-2.6.24-rc4/Documentation/debugging-via-ohci1394.txt
+++ linux-2.6.24-rc4/Documentation/debugging-via-ohci1394.txt
@@ -0,0 +1,179 @@
+
+  Using physical DMA provided by OHCI-1394 FireWire controllers for debugging
+  ---------------------------------------------------------------------------
+
+Introduction
+------------
+
+Basically all FireWire controllers which are in use today are compliant
+to the OHCI-1394 specification which defines the controller to be a PCI
+bus master which uses DMA to offload data transfers from the CPU and has
+a "Physical Response Unit" which executes specific requests by employing
+PCI-Bus master DMA after applying filters defined by the OHCI-1394 driver.
+
+Once properly configured, remote machines can send these requests to
+ask the OHCI-1394 controller to perform read and write requests on
+physical system memory and, for read requests, send the result of
+the physical memory read back to the requester.
+
+With that, it is possible to debug issues by reading interesting memory
+locations such as buffers like the printk buffer or the process table.
+
+Retrieving a full system memory dump is also possible over the FireWire,
+using data transfer rates in the order of 10MB/s or more.
+
+Memory access is currently limited to the low 4G of physical address
+space which can be a problem on IA64 machines where memory is located
+mostly above that limit, but it is rarely a problem on more common
+hardware such as hardware based on x86, x86-64 and PowerPC.
+
+Together with a early initialization of the OHCI-1394 controller for debugging,
+this facility proved most useful for examining long debugs logs in the printk
+buffer on to debug early boot problems in areas like ACPI where the system
+fails to boot and other means for debugging (serial port) are either not
+available (notebooks) or too slow for extensive debug information (like ACPI).
+
+Drivers
+-------
+
+The OHCI-1394 drivers in drivers/firewire and drivers/ieee1394 initialize
+the OHCI-1394 controllers to a working state and can be used to enable
+physical DMA. By default you only have to load the driver, and physical
+DMA access will be granted to all remote nodes, but it can be turned off
+when using the ohci1394 driver.
+
+Because these drivers depend on the PCI enumeration to be completed, an
+initialization routine which can runs pretty early (long before console_init(),
+which makes the printk buffer appear on the console can be called) was written.
+
+To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu:
+Provide code for enabling DMA over FireWire early on boot) and pass the
+parameter "ohci1394_dma=early" to the recompiled kernel on boot.
+
+Tools
+-----
+
+firescope - Originally developed by Benjamin Herrenschmidt, Andi Kleen ported
+it from PowerPC to x86 and x86_64 and added functionality, firescope can now
+be used to view the printk buffer of a remote machine, even with live update.
+
+Bernhard Kaindl enhanced firescope to support accessing 64-bit machines
+from 32-bit firescope and vice versa:
+- ftp://ftp.suse.de/private/bk/firewire/tools/firescope-0.2.2.tar.bz2
+
+and he implemented fast system dump (alpha version - read README.txt):
+- ftp://ftp.suse.de/private/bk/firewire/tools/firedump-0.1.tar.bz2
+
+There is also a gdb proxy for firewire which allows to use gdb to access
+data which can be referenced from symbols found by gdb in vmlinux:
+- ftp://ftp.suse.de/private/bk/firewire/tools/fireproxy-0.33.tar.bz2
+
+The latest version of this gdb proxy (fireproxy-0.34) can communicate (not
+yet stable) with kgdb over an memory-based communication module (kgdbom).
+
+Getting Started
+---------------
+
+The OHCI-1394 specification regulates that the OHCI-1394 controller must
+disable all physical DMA on each bus reset.
+
+This means that if you want to debug an issue in a system state where
+interrupts are disabled and where no polling of the OHCI-1394 controller
+for bus resets takes place, you have to establish any FireWire cable
+connections and fully initialize all FireWire hardware __before__ the
+system enters such state.
+
+Step-by-step instructions for using firescope with early OHCI initialization:
+
+1) Verify that your hardware is supported:
+
+   Load the ohci1394 or the fw-ohci module and check your kernel logs.
+   You should see a line similar to
+
+   ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18]  MMIO=[fe9ff800-fe9fffff]
+   ... Max Packet=[2048]  IR/IT contexts=[4/8]
+
+   when loading the driver. If you have no supported controller, many PCI,
+   CardBus and even some Express cards which are fully compliant to OHCI-1394
+   specification are available. If it requires no driver for Windows operating
+   systems, it most likely is. Only specialized shops have cards which are not
+   compliant, they are based on TI PCILynx chips and require drivers for Win-
+   dows operating systems.
+
+2) Establish a working FireWire cable connection:
+
+   Any FireWire cable, as long at it provides electrically and mechanically
+   stable connection and has matching connectors (there are small 4-pin and
+   large 6-pin FireWire ports) will do.
+
+   If an driver is running on both machines you should see a line like
+
+   ieee1394: Node added: ID:BUS[0-01:1023]  GUID[0090270001b84bba]
+
+   on both machines in the kernel log when the cable is plugged in
+   and connects the two machines.
+
+3) Test physical DMA using firescope:
+
+   On the debug host,
+	- load the raw1394 module,
+	- make sure that /dev/raw1394 is accessible,
+   then start firescope:
+
+	$ firescope
+	Port 0 (ohci1394) opened, 2 nodes detected
+
+	FireScope
+	---------
+	Target : <unspecified>
+	Gen    : 1
+	[Ctrl-T] choose target
+	[Ctrl-H] this menu
+	[Ctrl-Q] quit
+
+    ------> Press Ctrl-T now, the output should be similar to:
+
+	2 nodes available, local node is: 0
+	 0: ffc0, uuid: 00000000 00000000 [LOCAL]
+	 1: ffc1, uuid: 00279000 ba4bb801
+
+   Besides the [LOCAL] node, it must show another node without error message.
+
+4) Prepare for debugging with early OHCI-1394 initialization:
+
+   4.1) Kernel compilation and installation on debug target
+
+   Compile the kernel to be debugged with CONFIG_PROVIDE_OHCI1394_DMA_INIT
+   (Kernel hacking: Provide code for enabling DMA over FireWire early on boot)
+   enabled and install it on the machine to be debugged (debug target).
+
+   4.2) Transfer the System.map of the debugged kernel to the debug host
+
+   Copy the System.map of the kernel be debugged to the debug host (the host
+   which is connected to the debugged machine over the FireWire cable).
+
+5) Retrieving the printk buffer contents:
+
+   With the FireWire cable connected, the OHCI-1394 driver on the debugging
+   host loaded, reboot the debugged machine, booting the kernel which has
+   CONFIG_PROVIDE_OHCI1394_DMA_INIT enabled, with the option ohci1394_dma=early.
+
+   Then, on the debugging host, run firescope, for example by using -A:
+
+	firescope -A System.map-of-debug-target-kernel
+
+   Note: -A automatically attaches to the first non-local node. It only works
+   reliably if only connected two machines are connected using FireWire.
+
+   After having attached to the debug target, press Ctrl-D to view the
+   complete printk buffer or Ctrl-U to enter auto update mode and get an
+   updated live view of recent kernel messages logged on the debug target.
+
+   Call "firescope -h" to get more information on firescope's options.
+
+Notes
+-----
+Documentation and specifications: ftp://ftp.suse.de/private/bk/firewire/docs
+
+FireWire is a trademark of Apple Inc. - for more information please refer to:
+http://en.wikipedia.org/wiki/FireWire

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH] Early boot debugging via FireWire (ohci1394_dma=early)
  2007-12-06 19:23             ` [PATCH] " Bernhard Kaindl
@ 2007-12-06 20:23               ` Stefan Richter
  2007-12-17 13:49               ` Ingo Molnar
  1 sibling, 0 replies; 29+ messages in thread
From: Stefan Richter @ 2007-12-06 20:23 UTC (permalink / raw)
  To: Bernhard Kaindl
  Cc: Andi Kleen, Bernhard Kaindl, linux-kernel, linux1394-devel,
	Thomas Renninger, Benjamin Herrenschmidt

Bernhard Kaindl wrote:
>    after summing up the discussion on previous patches, I'm now submitting the
> patch below for formal review and adoption on branches for mainline inclusion.

I will look a bit more into the details later; for now I have just a
quick comment on the documentation.

> --- linux-2.6.24-rc4/Documentation/debugging-via-ohci1394.txt
> +++ linux-2.6.24-rc4/Documentation/debugging-via-ohci1394.txt
> @@ -0,0 +1,179 @@
> +
> +  Using physical DMA provided by OHCI-1394 FireWire controllers for debugging
> +  ---------------------------------------------------------------------------
> +
> +Introduction
> +------------

There are some really long sentences in it.
Try to use the "." character more often.  :-)

> +Basically all FireWire controllers which are in use today are compliant
> +to the OHCI-1394 specification which defines the controller to be a PCI
> +bus master which uses DMA to offload data transfers from the CPU and has
> +a "Physical Response Unit" which executes specific requests by employing
> +PCI-Bus master DMA after applying filters defined by the OHCI-1394 driver.
> +
> +Once properly configured, remote machines can send these requests to
> +ask the OHCI-1394 controller to perform read and write requests on
> +physical system memory and, for read requests, send the result of
> +the physical memory read back to the requester.

In other words, the FireWire controller can be configured to work as a
bus bridge between FireWire bus and local bus (PCI or PCIe).

And yes, there are security implications.

[...]
> +The OHCI-1394 drivers in drivers/firewire and drivers/ieee1394 initialize
> +the OHCI-1394 controllers to a working state and can be used to enable
> +physical DMA. By default you only have to load the driver, and physical
> +DMA access will be granted to all remote nodes, but it can be turned off
> +when using the ohci1394 driver.

This is correct for ohci1394, and it's a bug.
http://bugzilla.kernel.org/show_bug.cgi?id=7794

firewire-ohci however implements filtered physical DMA.  The only user
of that is the firewire-sbp2 driver which grants SBP-2 targets access
through the physical response unit.  firewire-ohci has at the moment no
option for either unfiltered physical DMA (as needed by firescope at al,
tracked at http://wiki.linux1394.org/ToDo) nor to completely disable
physical DMA.
-- 
Stefan Richter
-=====-=-=== ==-- --==-
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH] Early boot debugging via FireWire (ohci1394_dma=early)
  2007-12-06 19:23             ` [PATCH] " Bernhard Kaindl
  2007-12-06 20:23               ` Stefan Richter
@ 2007-12-17 13:49               ` Ingo Molnar
  1 sibling, 0 replies; 29+ messages in thread
From: Ingo Molnar @ 2007-12-17 13:49 UTC (permalink / raw)
  To: Bernhard Kaindl
  Cc: Stefan Richter, Andi Kleen, Bernhard Kaindl, linux-kernel,
	linux1394-devel, Thomas Renninger, Benjamin Herrenschmidt,
	Thomas Gleixner, H. Peter Anvin


* Bernhard Kaindl <bk@suse.de> wrote:

> Subject of this patch:
> 
> This patch adds a new configuration option, which adds support for a 
> new early_param which gets checked in 
> arch/x86/kernel/setup_{32,64}.c:setup_arch() to decide wether 
> OHCI-1394 FireWire controllers should be initialized and enabled for 
> physical DMA access to allow remote debugging of early problems like 
> issues ACPI or other subsystems which are executed very early.
> 
> If the config option is not enabled, no code is changed, and if the 
> boot paramenter is not given, no new code is executed, and independent 
> of that, all new code is freed after boot, so the config option can be 
> even enabled in standard, non-debug kernels.
> 
> With specialized tools, it is then possible to get debugging 
> information from machines which have no serial ports (notebooks) such 
> as the printk buffer contents, or any data which can be referenced 
> from global pointers, if it is stored below the 4GB limit and even 
> memory dumps of of the physical RAM region below the 4GB limit can be 
> taken without any cooperation from the CPU of the host, so the machine 
> can be crashed early, it does not matter.

cool stuff! I've tentatively added your patch to x86.git (pending more 
review feedback from others), but it already looks quite nice to me.

	Ingo

^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2007-12-17 13:50 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-10 11:42 What will be in the x86-64/x86 2.6.21 merge Andi Kleen
2007-02-10 13:43 ` [discuss] " Muli Ben-Yehuda
2007-02-10 13:52   ` Andi Kleen
2007-02-10 13:56     ` Muli Ben-Yehuda
2007-02-10 14:03       ` Andi Kleen
2007-02-10 13:51 ` remote debugging via FireWire (was What will be in the x86-64/x86 2.6.21 merge) Stefan Richter
2007-02-10 14:02   ` Andi Kleen
2007-02-10 15:14     ` remote debugging via FireWire Stefan Richter
2007-02-10 15:41       ` Andi Kleen
2007-02-10 19:16         ` Stefan Richter
2007-02-11 21:35           ` Benjamin Herrenschmidt
2007-02-12  6:49             ` Andi Kleen
2007-02-12  7:29               ` Benjamin Herrenschmidt
2007-12-04  3:45   ` remote debugging via FireWire * __fast__ firedump! Bernhard Kaindl
2007-12-04  7:39     ` Andi Kleen
2007-12-06 16:02       ` Bernhard Kaindl
2007-12-04 22:15     ` Stefan Richter
2007-12-04 22:34       ` Stefan Richter
2007-12-04 22:40         ` Stefan Richter
2007-12-06 18:36           ` [feedback discussion] Early boot debugging via FireWire (ohci1394_dma=early) Bernhard Kaindl
2007-12-06 19:23             ` Stefan Richter
2007-12-06 19:23             ` [PATCH] " Bernhard Kaindl
2007-12-06 20:23               ` Stefan Richter
2007-12-17 13:49               ` Ingo Molnar
2007-12-06 16:32       ` remote debugging via FireWire * __fast__ firedump! Bernhard Kaindl
2007-02-12 14:11 ` What will be in the x86-64/x86 2.6.21 merge James Morris
2007-02-12 14:14   ` Andi Kleen
2007-02-12 14:46     ` James Morris
2007-02-14  6:53     ` Rusty Russell

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).