1 2config PRINTK_TIME 3 bool "Show timing information on printks" 4 depends on PRINTK 5 help 6 Selecting this option causes timing information to be 7 included in printk output. This allows you to measure 8 the interval between kernel operations, including bootup 9 operations. This is useful for identifying long delays 10 in kernel startup. 11 12config ENABLE_WARN_DEPRECATED 13 bool "Enable __deprecated logic" 14 default y 15 help 16 Enable the __deprecated logic in the kernel build. 17 Disable this to suppress the "warning: 'foo' is deprecated 18 (declared at kernel/power/somefile.c:1234)" messages. 19 20config ENABLE_MUST_CHECK 21 bool "Enable __must_check logic" 22 default y 23 help 24 Enable the __must_check logic in the kernel build. Disable this to 25 suppress the "warning: ignoring return value of 'foo', declared with 26 attribute warn_unused_result" messages. 27 28config FRAME_WARN 29 int "Warn for stack frames larger than (needs gcc 4.4)" 30 range 0 8192 31 default 1024 if !64BIT 32 default 2048 if 64BIT 33 help 34 Tell gcc to warn at build time for stack frames larger than this. 35 Setting this too low will cause a lot of warnings. 36 Setting it to 0 disables the warning. 37 Requires gcc 4.4 38 39config MAGIC_SYSRQ 40 bool "Magic SysRq key" 41 depends on !UML 42 help 43 If you say Y here, you will have some control over the system even 44 if the system crashes for example during kernel debugging (e.g., you 45 will be able to flush the buffer cache to disk, reboot the system 46 immediately or dump some status information). This is accomplished 47 by pressing various keys while holding SysRq (Alt+PrintScreen). It 48 also works on a serial console (on PC hardware at least), if you 49 send a BREAK and then within 5 seconds a command keypress. The 50 keys are documented in <file:Documentation/sysrq.txt>. Don't say Y 51 unless you really know what this hack does. 52 53config UNUSED_SYMBOLS 54 bool "Enable unused/obsolete exported symbols" 55 default y if X86 56 help 57 Unused but exported symbols make the kernel needlessly bigger. For 58 that reason most of these unused exports will soon be removed. This 59 option is provided temporarily to provide a transition period in case 60 some external kernel module needs one of these symbols anyway. If you 61 encounter such a case in your module, consider if you are actually 62 using the right API. (rationale: since nobody in the kernel is using 63 this in a module, there is a pretty good chance it's actually the 64 wrong interface to use). If you really need the symbol, please send a 65 mail to the linux kernel mailing list mentioning the symbol and why 66 you really need it, and what the merge plan to the mainline kernel for 67 your module is. 68 69config DEBUG_FS 70 bool "Debug Filesystem" 71 depends on SYSFS 72 help 73 debugfs is a virtual file system that kernel developers use to put 74 debugging files into. Enable this option to be able to read and 75 write to these files. 76 77 For detailed documentation on the debugfs API, see 78 Documentation/DocBook/filesystems. 79 80 If unsure, say N. 81 82config HEADERS_CHECK 83 bool "Run 'make headers_check' when building vmlinux" 84 depends on !UML 85 help 86 This option will extract the user-visible kernel headers whenever 87 building the kernel, and will run basic sanity checks on them to 88 ensure that exported files do not attempt to include files which 89 were not exported, etc. 90 91 If you're making modifications to header files which are 92 relevant for userspace, say 'Y', and check the headers 93 exported to $(INSTALL_HDR_PATH) (usually 'usr/include' in 94 your build tree), to make sure they're suitable. 95 96config DEBUG_SECTION_MISMATCH 97 bool "Enable full Section mismatch analysis" 98 depends on UNDEFINED 99 # This option is on purpose disabled for now. 100 # It will be enabled when we are down to a resonable number 101 # of section mismatch warnings (< 10 for an allyesconfig build) 102 help 103 The section mismatch analysis checks if there are illegal 104 references from one section to another section. 105 Linux will during link or during runtime drop some sections 106 and any use of code/data previously in these sections will 107 most likely result in an oops. 108 In the code functions and variables are annotated with 109 __init, __devinit etc. (see full list in include/linux/init.h) 110 which results in the code/data being placed in specific sections. 111 The section mismatch analysis is always done after a full 112 kernel build but enabling this option will in addition 113 do the following: 114 - Add the option -fno-inline-functions-called-once to gcc 115 When inlining a function annotated __init in a non-init 116 function we would lose the section information and thus 117 the analysis would not catch the illegal reference. 118 This option tells gcc to inline less but will also 119 result in a larger kernel. 120 - Run the section mismatch analysis for each module/built-in.o 121 When we run the section mismatch analysis on vmlinux.o we 122 lose valueble information about where the mismatch was 123 introduced. 124 Running the analysis for each module/built-in.o file 125 will tell where the mismatch happens much closer to the 126 source. The drawback is that we will report the same 127 mismatch at least twice. 128 - Enable verbose reporting from modpost to help solving 129 the section mismatches reported. 130 131config DEBUG_KERNEL 132 bool "Kernel debugging" 133 help 134 Say Y here if you are developing drivers or trying to debug and 135 identify kernel problems. 136 137config DEBUG_SHIRQ 138 bool "Debug shared IRQ handlers" 139 depends on DEBUG_KERNEL && GENERIC_HARDIRQS 140 help 141 Enable this to generate a spurious interrupt as soon as a shared 142 interrupt handler is registered, and just before one is deregistered. 143 Drivers ought to be able to handle interrupts coming in at those 144 points; some don't and need to be caught. 145 146config DETECT_SOFTLOCKUP 147 bool "Detect Soft Lockups" 148 depends on DEBUG_KERNEL && !S390 149 default y 150 help 151 Say Y here to enable the kernel to detect "soft lockups", 152 which are bugs that cause the kernel to loop in kernel 153 mode for more than 10 seconds, without giving other tasks a 154 chance to run. 155 156 When a soft-lockup is detected, the kernel will print the 157 current stack trace (which you should report), but the 158 system will stay locked up. This feature has negligible 159 overhead. 160 161 (Note that "hard lockups" are separate type of bugs that 162 can be detected via the NMI-watchdog, on platforms that 163 support it.) 164 165config SCHED_DEBUG 166 bool "Collect scheduler debugging info" 167 depends on DEBUG_KERNEL && PROC_FS 168 default y 169 help 170 If you say Y here, the /proc/sched_debug file will be provided 171 that can help debug the scheduler. The runtime overhead of this 172 option is minimal. 173 174config SCHEDSTATS 175 bool "Collect scheduler statistics" 176 depends on DEBUG_KERNEL && PROC_FS 177 help 178 If you say Y here, additional code will be inserted into the 179 scheduler and related routines to collect statistics about 180 scheduler behavior and provide them in /proc/schedstat. These 181 stats may be useful for both tuning and debugging the scheduler 182 If you aren't debugging the scheduler or trying to tune a specific 183 application, you can say N to avoid the very slight overhead 184 this adds. 185 186config TIMER_STATS 187 bool "Collect kernel timers statistics" 188 depends on DEBUG_KERNEL && PROC_FS 189 help 190 If you say Y here, additional code will be inserted into the 191 timer routines to collect statistics about kernel timers being 192 reprogrammed. The statistics can be read from /proc/timer_stats. 193 The statistics collection is started by writing 1 to /proc/timer_stats, 194 writing 0 stops it. This feature is useful to collect information 195 about timer usage patterns in kernel and userspace. This feature 196 is lightweight if enabled in the kernel config but not activated 197 (it defaults to deactivated on bootup and will only be activated 198 if some application like powertop activates it explicitly). 199 200config DEBUG_OBJECTS 201 bool "Debug object operations" 202 depends on DEBUG_KERNEL 203 help 204 If you say Y here, additional code will be inserted into the 205 kernel to track the life time of various objects and validate 206 the operations on those objects. 207 208config DEBUG_OBJECTS_SELFTEST 209 bool "Debug objects selftest" 210 depends on DEBUG_OBJECTS 211 help 212 This enables the selftest of the object debug code. 213 214config DEBUG_OBJECTS_FREE 215 bool "Debug objects in freed memory" 216 depends on DEBUG_OBJECTS 217 help 218 This enables checks whether a k/v free operation frees an area 219 which contains an object which has not been deactivated 220 properly. This can make kmalloc/kfree-intensive workloads 221 much slower. 222 223config DEBUG_OBJECTS_TIMERS 224 bool "Debug timer objects" 225 depends on DEBUG_OBJECTS 226 help 227 If you say Y here, additional code will be inserted into the 228 timer routines to track the life time of timer objects and 229 validate the timer operations. 230 231config DEBUG_SLAB 232 bool "Debug slab memory allocations" 233 depends on DEBUG_KERNEL && SLAB 234 help 235 Say Y here to have the kernel do limited verification on memory 236 allocation as well as poisoning memory on free to catch use of freed 237 memory. This can make kmalloc/kfree-intensive workloads much slower. 238 239config DEBUG_SLAB_LEAK 240 bool "Memory leak debugging" 241 depends on DEBUG_SLAB 242 243config SLUB_DEBUG_ON 244 bool "SLUB debugging on by default" 245 depends on SLUB && SLUB_DEBUG 246 default n 247 help 248 Boot with debugging on by default. SLUB boots by default with 249 the runtime debug capabilities switched off. Enabling this is 250 equivalent to specifying the "slub_debug" parameter on boot. 251 There is no support for more fine grained debug control like 252 possible with slub_debug=xxx. SLUB debugging may be switched 253 off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying 254 "slub_debug=-". 255 256config SLUB_STATS 257 default n 258 bool "Enable SLUB performance statistics" 259 depends on SLUB && SLUB_DEBUG && SYSFS 260 help 261 SLUB statistics are useful to debug SLUBs allocation behavior in 262 order find ways to optimize the allocator. This should never be 263 enabled for production use since keeping statistics slows down 264 the allocator by a few percentage points. The slabinfo command 265 supports the determination of the most active slabs to figure 266 out which slabs are relevant to a particular load. 267 Try running: slabinfo -DA 268 269config DEBUG_PREEMPT 270 bool "Debug preemptible kernel" 271 depends on DEBUG_KERNEL && PREEMPT && (TRACE_IRQFLAGS_SUPPORT || PPC64) 272 default y 273 help 274 If you say Y here then the kernel will use a debug variant of the 275 commonly used smp_processor_id() function and will print warnings 276 if kernel code uses it in a preemption-unsafe way. Also, the kernel 277 will detect preemption count underflows. 278 279config DEBUG_RT_MUTEXES 280 bool "RT Mutex debugging, deadlock detection" 281 depends on DEBUG_KERNEL && RT_MUTEXES 282 help 283 This allows rt mutex semantics violations and rt mutex related 284 deadlocks (lockups) to be detected and reported automatically. 285 286config DEBUG_PI_LIST 287 bool 288 default y 289 depends on DEBUG_RT_MUTEXES 290 291config RT_MUTEX_TESTER 292 bool "Built-in scriptable tester for rt-mutexes" 293 depends on DEBUG_KERNEL && RT_MUTEXES 294 help 295 This option enables a rt-mutex tester. 296 297config DEBUG_SPINLOCK 298 bool "Spinlock and rw-lock debugging: basic checks" 299 depends on DEBUG_KERNEL 300 help 301 Say Y here and build SMP to catch missing spinlock initialization 302 and certain other kinds of spinlock errors commonly made. This is 303 best used in conjunction with the NMI watchdog so that spinlock 304 deadlocks are also debuggable. 305 306config DEBUG_MUTEXES 307 bool "Mutex debugging: basic checks" 308 depends on DEBUG_KERNEL 309 help 310 This feature allows mutex semantics violations to be detected and 311 reported. 312 313config DEBUG_LOCK_ALLOC 314 bool "Lock debugging: detect incorrect freeing of live locks" 315 depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT 316 select DEBUG_SPINLOCK 317 select DEBUG_MUTEXES 318 select LOCKDEP 319 help 320 This feature will check whether any held lock (spinlock, rwlock, 321 mutex or rwsem) is incorrectly freed by the kernel, via any of the 322 memory-freeing routines (kfree(), kmem_cache_free(), free_pages(), 323 vfree(), etc.), whether a live lock is incorrectly reinitialized via 324 spin_lock_init()/mutex_init()/etc., or whether there is any lock 325 held during task exit. 326 327config PROVE_LOCKING 328 bool "Lock debugging: prove locking correctness" 329 depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT 330 select LOCKDEP 331 select DEBUG_SPINLOCK 332 select DEBUG_MUTEXES 333 select DEBUG_LOCK_ALLOC 334 default n 335 help 336 This feature enables the kernel to prove that all locking 337 that occurs in the kernel runtime is mathematically 338 correct: that under no circumstance could an arbitrary (and 339 not yet triggered) combination of observed locking 340 sequences (on an arbitrary number of CPUs, running an 341 arbitrary number of tasks and interrupt contexts) cause a 342 deadlock. 343 344 In short, this feature enables the kernel to report locking 345 related deadlocks before they actually occur. 346 347 The proof does not depend on how hard and complex a 348 deadlock scenario would be to trigger: how many 349 participant CPUs, tasks and irq-contexts would be needed 350 for it to trigger. The proof also does not depend on 351 timing: if a race and a resulting deadlock is possible 352 theoretically (no matter how unlikely the race scenario 353 is), it will be proven so and will immediately be 354 reported by the kernel (once the event is observed that 355 makes the deadlock theoretically possible). 356 357 If a deadlock is impossible (i.e. the locking rules, as 358 observed by the kernel, are mathematically correct), the 359 kernel reports nothing. 360 361 NOTE: this feature can also be enabled for rwlocks, mutexes 362 and rwsems - in which case all dependencies between these 363 different locking variants are observed and mapped too, and 364 the proof of observed correctness is also maintained for an 365 arbitrary combination of these separate locking variants. 366 367 For more details, see Documentation/lockdep-design.txt. 368 369config LOCKDEP 370 bool 371 depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT 372 select STACKTRACE 373 select FRAME_POINTER if !X86 && !MIPS 374 select KALLSYMS 375 select KALLSYMS_ALL 376 377config LOCK_STAT 378 bool "Lock usage statistics" 379 depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT 380 select LOCKDEP 381 select DEBUG_SPINLOCK 382 select DEBUG_MUTEXES 383 select DEBUG_LOCK_ALLOC 384 default n 385 help 386 This feature enables tracking lock contention points 387 388 For more details, see Documentation/lockstat.txt 389 390config DEBUG_LOCKDEP 391 bool "Lock dependency engine debugging" 392 depends on DEBUG_KERNEL && LOCKDEP 393 help 394 If you say Y here, the lock dependency engine will do 395 additional runtime checks to debug itself, at the price 396 of more runtime overhead. 397 398config TRACE_IRQFLAGS 399 depends on DEBUG_KERNEL 400 bool 401 default y 402 depends on TRACE_IRQFLAGS_SUPPORT 403 depends on PROVE_LOCKING 404 405config DEBUG_SPINLOCK_SLEEP 406 bool "Spinlock debugging: sleep-inside-spinlock checking" 407 depends on DEBUG_KERNEL 408 help 409 If you say Y here, various routines which may sleep will become very 410 noisy if they are called with a spinlock held. 411 412config DEBUG_LOCKING_API_SELFTESTS 413 bool "Locking API boot-time self-tests" 414 depends on DEBUG_KERNEL 415 help 416 Say Y here if you want the kernel to run a short self-test during 417 bootup. The self-test checks whether common types of locking bugs 418 are detected by debugging mechanisms or not. (if you disable 419 lock debugging then those bugs wont be detected of course.) 420 The following locking APIs are covered: spinlocks, rwlocks, 421 mutexes and rwsems. 422 423config STACKTRACE 424 bool 425 depends on STACKTRACE_SUPPORT 426 427config DEBUG_KOBJECT 428 bool "kobject debugging" 429 depends on DEBUG_KERNEL 430 help 431 If you say Y here, some extra kobject debugging messages will be sent 432 to the syslog. 433 434config DEBUG_HIGHMEM 435 bool "Highmem debugging" 436 depends on DEBUG_KERNEL && HIGHMEM 437 help 438 This options enables addition error checking for high memory systems. 439 Disable for production systems. 440 441config DEBUG_BUGVERBOSE 442 bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EMBEDDED 443 depends on BUG 444 depends on ARM || AVR32 || M32R || M68K || SPARC32 || SPARC64 || \ 445 FRV || SUPERH || GENERIC_BUG || BLACKFIN || MN10300 446 default !EMBEDDED 447 help 448 Say Y here to make BUG() panics output the file name and line number 449 of the BUG call as well as the EIP and oops trace. This aids 450 debugging but costs about 70-100K of memory. 451 452config DEBUG_INFO 453 bool "Compile the kernel with debug info" 454 depends on DEBUG_KERNEL 455 help 456 If you say Y here the resulting kernel image will include 457 debugging info resulting in a larger kernel image. 458 This adds debug symbols to the kernel and modules (gcc -g), and 459 is needed if you intend to use kernel crashdump or binary object 460 tools like crash, kgdb, LKCD, gdb, etc on the kernel. 461 Say Y here only if you plan to debug the kernel. 462 463 If unsure, say N. 464 465config DEBUG_VM 466 bool "Debug VM" 467 depends on DEBUG_KERNEL 468 help 469 Enable this to turn on extended checks in the virtual-memory system 470 that may impact performance. 471 472 If unsure, say N. 473 474config DEBUG_WRITECOUNT 475 bool "Debug filesystem writers count" 476 depends on DEBUG_KERNEL 477 help 478 Enable this to catch wrong use of the writers count in struct 479 vfsmount. This will increase the size of each file struct by 480 32 bits. 481 482 If unsure, say N. 483 484config DEBUG_LIST 485 bool "Debug linked list manipulation" 486 depends on DEBUG_KERNEL 487 help 488 Enable this to turn on extended checks in the linked-list 489 walking routines. 490 491 If unsure, say N. 492 493config DEBUG_SG 494 bool "Debug SG table operations" 495 depends on DEBUG_KERNEL 496 help 497 Enable this to turn on checks on scatter-gather tables. This can 498 help find problems with drivers that do not properly initialize 499 their sg tables. 500 501 If unsure, say N. 502 503config FRAME_POINTER 504 bool "Compile the kernel with frame pointers" 505 depends on DEBUG_KERNEL && \ 506 (X86 || CRIS || M68K || M68KNOMMU || FRV || UML || S390 || \ 507 AVR32 || SUPERH || BLACKFIN || MN10300) 508 default y if DEBUG_INFO && UML 509 help 510 If you say Y here the resulting kernel image will be slightly larger 511 and slower, but it might give very useful debugging information on 512 some architectures or if you use external debuggers. 513 If you don't debug the kernel, you can say N. 514 515config BOOT_PRINTK_DELAY 516 bool "Delay each boot printk message by N milliseconds" 517 depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY 518 help 519 This build option allows you to read kernel boot messages 520 by inserting a short delay after each one. The delay is 521 specified in milliseconds on the kernel command line, 522 using "boot_delay=N". 523 524 It is likely that you would also need to use "lpj=M" to preset 525 the "loops per jiffie" value. 526 See a previous boot log for the "lpj" value to use for your 527 system, and then set "lpj=M" before setting "boot_delay=N". 528 NOTE: Using this option may adversely affect SMP systems. 529 I.e., processors other than the first one may not boot up. 530 BOOT_PRINTK_DELAY also may cause DETECT_SOFTLOCKUP to detect 531 what it believes to be lockup conditions. 532 533config RCU_TORTURE_TEST 534 tristate "torture tests for RCU" 535 depends on DEBUG_KERNEL 536 default n 537 help 538 This option provides a kernel module that runs torture tests 539 on the RCU infrastructure. The kernel module may be built 540 after the fact on the running kernel to be tested, if desired. 541 542 Say Y here if you want RCU torture tests to be built into 543 the kernel. 544 Say M if you want the RCU torture tests to build as a module. 545 Say N if you are unsure. 546 547config RCU_TORTURE_TEST_RUNNABLE 548 bool "torture tests for RCU runnable by default" 549 depends on RCU_TORTURE_TEST = y 550 default n 551 help 552 This option provides a way to build the RCU torture tests 553 directly into the kernel without them starting up at boot 554 time. You can use /proc/sys/kernel/rcutorture_runnable 555 to manually override this setting. This /proc file is 556 available only when the RCU torture tests have been built 557 into the kernel. 558 559 Say Y here if you want the RCU torture tests to start during 560 boot (you probably don't). 561 Say N here if you want the RCU torture tests to start only 562 after being manually enabled via /proc. 563 564config KPROBES_SANITY_TEST 565 bool "Kprobes sanity tests" 566 depends on DEBUG_KERNEL 567 depends on KPROBES 568 default n 569 help 570 This option provides for testing basic kprobes functionality on 571 boot. A sample kprobe, jprobe and kretprobe are inserted and 572 verified for functionality. 573 574 Say N if you are unsure. 575 576config BACKTRACE_SELF_TEST 577 tristate "Self test for the backtrace code" 578 depends on DEBUG_KERNEL 579 default n 580 help 581 This option provides a kernel module that can be used to test 582 the kernel stack backtrace code. This option is not useful 583 for distributions or general kernels, but only for kernel 584 developers working on architecture code. 585 586 Note that if you want to also test saved backtraces, you will 587 have to enable STACKTRACE as well. 588 589 Say N if you are unsure. 590 591config LKDTM 592 tristate "Linux Kernel Dump Test Tool Module" 593 depends on DEBUG_KERNEL 594 depends on KPROBES 595 depends on BLOCK 596 default n 597 help 598 This module enables testing of the different dumping mechanisms by 599 inducing system failures at predefined crash points. 600 If you don't need it: say N 601 Choose M here to compile this code as a module. The module will be 602 called lkdtm. 603 604 Documentation on how to use the module can be found in 605 drivers/misc/lkdtm.c 606 607config FAULT_INJECTION 608 bool "Fault-injection framework" 609 depends on DEBUG_KERNEL 610 help 611 Provide fault-injection framework. 612 For more details, see Documentation/fault-injection/. 613 614config FAILSLAB 615 bool "Fault-injection capability for kmalloc" 616 depends on FAULT_INJECTION 617 help 618 Provide fault-injection capability for kmalloc. 619 620config FAIL_PAGE_ALLOC 621 bool "Fault-injection capabilitiy for alloc_pages()" 622 depends on FAULT_INJECTION 623 help 624 Provide fault-injection capability for alloc_pages(). 625 626config FAIL_MAKE_REQUEST 627 bool "Fault-injection capability for disk IO" 628 depends on FAULT_INJECTION 629 help 630 Provide fault-injection capability for disk IO. 631 632config FAULT_INJECTION_DEBUG_FS 633 bool "Debugfs entries for fault-injection capabilities" 634 depends on FAULT_INJECTION && SYSFS && DEBUG_FS 635 help 636 Enable configuration of fault-injection capabilities via debugfs. 637 638config FAULT_INJECTION_STACKTRACE_FILTER 639 bool "stacktrace filter for fault-injection capabilities" 640 depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT 641 depends on !X86_64 642 select STACKTRACE 643 select FRAME_POINTER 644 help 645 Provide stacktrace filter for fault-injection capabilities 646 647config LATENCYTOP 648 bool "Latency measuring infrastructure" 649 select FRAME_POINTER if !MIPS 650 select KALLSYMS 651 select KALLSYMS_ALL 652 select STACKTRACE 653 select SCHEDSTATS 654 select SCHED_DEBUG 655 depends on HAVE_LATENCYTOP_SUPPORT 656 help 657 Enable this option if you want to use the LatencyTOP tool 658 to find out which userspace is blocking on what kernel operations. 659 660source kernel/trace/Kconfig 661 662config PROVIDE_OHCI1394_DMA_INIT 663 bool "Remote debugging over FireWire early on boot" 664 depends on PCI && X86 665 help 666 If you want to debug problems which hang or crash the kernel early 667 on boot and the crashing machine has a FireWire port, you can use 668 this feature to remotely access the memory of the crashed machine 669 over FireWire. This employs remote DMA as part of the OHCI1394 670 specification which is now the standard for FireWire controllers. 671 672 With remote DMA, you can monitor the printk buffer remotely using 673 firescope and access all memory below 4GB using fireproxy from gdb. 674 Even controlling a kernel debugger is possible using remote DMA. 675 676 Usage: 677 678 If ohci1394_dma=early is used as boot parameter, it will initialize 679 all OHCI1394 controllers which are found in the PCI config space. 680 681 As all changes to the FireWire bus such as enabling and disabling 682 devices cause a bus reset and thereby disable remote DMA for all 683 devices, be sure to have the cable plugged and FireWire enabled on 684 the debugging host before booting the debug target for debugging. 685 686 This code (~1k) is freed after boot. By then, the firewire stack 687 in charge of the OHCI-1394 controllers should be used instead. 688 689 See Documentation/debugging-via-ohci1394.txt for more information. 690 691config FIREWIRE_OHCI_REMOTE_DMA 692 bool "Remote debugging over FireWire with firewire-ohci" 693 depends on FIREWIRE_OHCI 694 help 695 This option lets you use the FireWire bus for remote debugging 696 with help of the firewire-ohci driver. It enables unfiltered 697 remote DMA in firewire-ohci. 698 See Documentation/debugging-via-ohci1394.txt for more information. 699 700 If unsure, say N. 701 702source "samples/Kconfig" 703 704source "lib/Kconfig.kgdb" 705