fox2mike 05/07/14 09:54:37 Modified: xml/htdocs/doc/en/draft debugging-howto.xml Log: Coding Style + Doublespace fixes.
Revision Changes Path 1.4 +19 -18 xml/htdocs/doc/en/draft/debugging-howto.xml file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/debugging-howto.xml?rev=1.4&content-type=text/x-cvsweb-markup&cvsroot=gentoo plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/debugging-howto.xml?rev=1.4&content-type=text/plain&cvsroot=gentoo diff : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/debugging-howto.xml.diff?r1=1.3&r2=1.4&cvsroot=gentoo Index: debugging-howto.xml =================================================================== RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- debugging-howto.xml 14 Jul 2005 09:42:27 -0000 1.3 +++ debugging-howto.xml 14 Jul 2005 09:54:37 -0000 1.4 @@ -1,6 +1,6 @@ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v 1.3 2005/07/14 09:42:27 swift Exp $ --> +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v 1.4 2005/07/14 09:54:37 fox2mike Exp $ --> <guide link="/doc/en/debugging-howto.xml"> <title>Gentoo Linux Debugging Guide</title> @@ -423,9 +423,9 @@ <body> <p> -<c>dmesg</c> is a system program created with debugging kernel operation. It +<c>dmesg</c> is a system program created with debugging kernel operation. It basically reads the kernel messages and keeps them in buffer, letting the user -see them later on. Here's an example of what a dmesg output looks like: +see them later on. Here's an example of what a dmesg output looks like: </p> <pre caption="dmesg sample output"> @@ -463,12 +463,12 @@ </pre> <p> -The dmesg displayed here is my machine's bootup. You can see harddrives and +The dmesg displayed here is my machine's bootup. You can see the hard disks and input devices being initialized. While what you see here seems relatively -harmless, <c>dmesg</c> is also good at showing when things go wrong. Let's take -for example an IPAQ 1945 I have. After a couple of minutes of inactivity, the -device powers off. Now, I have the device connected into the USB port in the -front of my system. Now, I want to copy over some files using libsynCE, so I go +harmless, <c>dmesg</c> is also good at showing when things go wrong. Let's take +for example an IPAQ 1945 I have. After a couple of minutes of inactivity, the +device powers off. Now, I have the device connected into the USB port in the +front of my system. Now, I want to copy over some files using libsynCE, so I go ahead and initiate a connection: </p> @@ -484,7 +484,7 @@ The connection fails, as we see here, and we assume that only the screen is in powersave mode, and that maybe the connection is faulty. In order to see what truly happened, we can use <c>dmesg</c>. Now, <c>dmesg</c> tends to give a -rather large ammount of output. One can use the <c>tail</c> command to help +rather large ammount of output. One can use the <c>tail</c> command to help keep the output down: </p> @@ -497,15 +497,16 @@ </pre> <p> -This gives us the last 4 lines of the dmesg output. Now, this is enough to give -us some information on the situation. It seems that in the first 2 lines, the -pocketpc is recognized as connected. However, in the last 2 lines, it appears -to have been disconnected. With this information we check the pocketpc again, -and find out it is powered off, and now know about the powersave mode. We can -use this information to turn the feature off, or be aware of it next time. -While this is a somewhat simple example, it does go to show how well dmesg can -work. However, in more complex examples (such as kernel bugs), the entire dmesg -output may be required. To obtain that, simple redirect to a log file as such: +This gives us the last 4 lines of the <c>dmesg</c> output. Now, this is enough +to give us some information on the situation. It seems that in the first 2 +lines, the pocketpc is recognized as connected. However, in the last 2 lines, it +appears to have been disconnected. With this information we check the pocketpc +again, and find out it is powered off, and now know about the powersave mode. We +can use this information to turn the feature off, or be aware of it next time. +While this is a somewhat simple example, it does go to show how well +<c>dmesg</c> can work. However, in more complex examples (such as kernel bugs), +the entire <c>dmesg</c> output may be required. To obtain that, simple redirect +to a log file as such: </p> <pre caption="Saving dmesg output to a log"> -- [email protected] mailing list
