From: "Shyam Mani" <fox2mike@lark.gentoo.org>
To: gentoo-doc-cvs@lists.gentoo.org
Subject: [gentoo-doc-cvs] cvs commit: debugging-howto.xml
Date: Wed, 13 Jul 2005 18:58:31 +0000 [thread overview]
Message-ID: <200507131857.j6DIvhMx013945@robin.gentoo.org> (raw)
fox2mike 05/07/13 18:58:31
Modified: xml/htdocs/doc/en/draft debugging-howto.xml
Log:
dmesh patch from Chris White aka PUNK ;)
Revision Changes Path
1.2 +120 -5 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.2&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.2&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.1&r2=1.2&cvsroot=gentoo
Index: debugging-howto.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- debugging-howto.xml 13 Jul 2005 05:55:39 -0000 1.1
+++ debugging-howto.xml 13 Jul 2005 18:58:31 -0000 1.2
@@ -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.1 2005/07/13 05:55:39 fox2mike Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v 1.2 2005/07/13 18:58:31 fox2mike Exp $ -->
<guide link="/doc/en/debugging-howto.xml">
<title>Gentoo Linux Debugging Guide</title>
@@ -406,10 +406,125 @@
<body>
<p>
-Now we've taken care of finding run time bugs. These bugs prove to be
-problematic when you try and run your programs. However, run time errors are
-the least of your concerns if your program won't compile at all. Let's take a
-look at how to address <c>emerge</c> compile errors.
+<c>strace</c> is a great way at seeing what the kernel is doing to with the filesystem.
+Another program exists to help users see what the kernel is doing, and help with
+kernel debugging. This program is called <c>dmesg</c>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Kernel Debugging With dmesg</title>
+<section>
+<title>dmesg Introduction</title>
+<body>
+
+<p>
+<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:
+</p>
+
+<pre caption="dmesg sample output">
+SIS5513: IDE controller at PCI slot 0000:00:02.5
+SIS5513: chipset revision 208
+SIS5513: not 100% native mode: will probe irqs later
+SIS5513: SiS 961 MuTIOL IDE UDMA100 controller
+ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:DMA, hdb:DMA
+ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:DMA, hdd:DMA
+Probing IDE interface ide0...
+input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
+hda: WDC WD800BB-60CJA0, ATA DISK drive
+hdb: CD-RW 52X24, ATAPI CD/DVD-ROM drive
+ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
+Probing IDE interface ide1...
+hdc: SAMSUNG DVD-ROM SD-616T, ATAPI CD/DVD-ROM drive
+hdd: Maxtor 92049U6, ATA DISK drive
+ide1 at 0x170-0x177,0x376 on irq 15
+hda: max request size: 128KiB
+hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63,
+UDMA(100)
+hda: cache flushes not supported
+hda: hda1
+hdd: max request size: 128KiB
+hdd: 39882528 sectors (20419 MB) w/2048KiB Cache, CHS=39566/16/63,
+UDMA(66)
+hdd: cache flushes not supported
+hdd: unknown partition table
+hdb: ATAPI 52X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
+Uniform CD-ROM driver Revision: 3.20
+hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
+ide-floppy driver 0.99.newide
+libata version 1.11 loaded.
+usbmon: debugs is not available
+</pre>
+
+<p>
+The dmesg displayed here is my machine's bootup. You can see harddrives 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
+ahead and initiate a connection:
+</p>
+
+<pre caption="IPAQ connection attempt">
+# <i>synce-serial-start</i>
+/usr/sbin/pppd: In file /etc/ppp/peers/synce-device: unrecognized option
+'/dev/tts/USB0'
+
+synce-serial-start was unable to start the PPP daemon!
+</pre>
+
+<p>
+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
+keep the output down:
+</p>
+
+<pre caption="Adjusting the output ammount with tail">
+$ <i>dmesg | tail -n 4</i>
+usb 1-1.2: PocketPC PDA converter now attached to ttyUSB0
+usb 1-1.2: USB disconnect, address 11
+PocketPC PDA ttyUSB0: PocketPC PDA converter now disconnected from ttyUSB0
+ipaq 1-1.2:1.0: device disconnected
+</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:
+</p>
+
+<pre caption="Saving dmesg output to a log">
+$ <i>dmesg > dmesg.log</i>
+</pre>
+
+<p>
+You can then attach this to a bug report, or post it online somewhere for
+collaborative debugging sessions.
+</p>
+
+</body>
+</section>
+<section>
+<title>Conclusion</title>
+<body>
+
+<p>
+Now that we've taken a look at a few ways to debug runtime and kernel errors,
+let's take a look at how to handle emerge errors.
</p>
</body>
--
gentoo-doc-cvs@gentoo.org mailing list
next reply other threads:[~2005-07-13 18:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-13 18:58 Shyam Mani [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-07-14 9:54 [gentoo-doc-cvs] cvs commit: debugging-howto.xml Shyam Mani
2005-07-14 9:42 Sven Vermeulen
2005-07-13 5:55 Shyam Mani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200507131857.j6DIvhMx013945@robin.gentoo.org \
--to=fox2mike@lark.gentoo.org \
--cc=docs-team@lists.gentoo.org \
--cc=gentoo-doc-cvs@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox