[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debugging von IO-Zugriffen



On 2007-07-20, Andreas Pakulat <apaku@gmx.de> wrote:
> On 20.07.07 13:10:53, Thomas Walter wrote:
>> On 2007-07-20, Wolf Wiegand <wolf@kondancemilch.de> wrote:
>> > Andreas Pakulat wrote:
>> >
>> >> [Festplattenzugriffe]
>> >> 
>> >> Die Frage ist: Wie kriege ich raus wer diese Zugriffe startet um dann zu
>> >> schauen wie ich das abgestellt bekomme.
>> >
>> > # echo 1 > /proc/sys/vm/block_dump
>> >
>> > und dann /var/log/syslog beobachten.
>> >
>> Gute Idee, leider kann man sich damit ganz schön ins Knie schießen:
>> 
>> ,----[aus: /usr/src/linux/Documentation/laptop-mode.txt]
>> | When you use block_dump and your kernel logging level also includes
>> | kernel debugging messages, you probably want to turn off klogd,
>> | otherwise the output of block_dump will be logged, causing disk
>> | activity that is not normally there.
>> `----
>
> Wie kriege ich raus ob mein Kernel log level debug messages
> enthaelt? 

Ich verstehe das anders. So wird KERN_DEBUG definiert:

,----[/usr/src/linux/include/linux/kernel.h]
| #define KERN_DEBUG      "<7>"   /* debug-level messages */
`----

Wenn ich mir mal ein beliebiges Kernelsourcefile anschaue, was
KERN_DEBUG verwendet,

,----[/usr/src/linux/drivers/serial/8250_pci.c]
| pci_read_config_dword(dev, 0x44, (void*) &oldval); 
| if (oldval == 0x00001000L) { /* RESET value */ 
| 	printk(KERN_DEBUG "Local i960 firmware missing");
| 	return -ENODEV;
| }
`----

dann sehe ich keine Möglichkeit, wie dieser Output aufgrund von
Konfigurationen verhindert werden könnte. Ich gehe also davon aus, daß
der Kernel immer auch debug Meldungen schreibt. Du mußt dann mit Hilfe
der syslog.conf entscheiden, ob du die auch haben willst (*.* oder
kern.*) oder nicht (kern.!=debug).

Soetwas wie /proc/sys/kernel/printk (siehe
/usr/src/linux/Documentation/sysctl/kernel.txt) für die Console ist
mir für /proc/kmsg nicht bekannt.

> CONFIG_DEBUG_KERNEL ist auf Y gesetzt, reicht das schon aus?

Nein. Bei mir diese Option "not set" und mein System frisst sich
selbst, wenn ich die syslog.conf nicht anpasse oder den syslogd
während des Test nicht abschalte, wie von Markus vorgeschlagen.


Tom



Reply to: