| 1 | <?xml version="1.0" encoding="UTF-8"?> |
1 | <?xml version="1.0" encoding="UTF-8"?> |
| 2 | <!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
2 | <!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 3 | <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v 1.1 2005/07/13 05:55:39 fox2mike Exp $ --> |
3 | <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v 1.2 2005/07/13 18:58:31 fox2mike Exp $ --> |
| 4 | |
4 | |
| 5 | <guide link="/doc/en/debugging-howto.xml"> |
5 | <guide link="/doc/en/debugging-howto.xml"> |
| 6 | <title>Gentoo Linux Debugging Guide</title> |
6 | <title>Gentoo Linux Debugging Guide</title> |
| 7 | |
7 | |
| 8 | <author title="Author"> |
8 | <author title="Author"> |
| … | |
… | |
| 404 | <section> |
404 | <section> |
| 405 | <title>Conclusion</title> |
405 | <title>Conclusion</title> |
| 406 | <body> |
406 | <body> |
| 407 | |
407 | |
| 408 | <p> |
408 | <p> |
| 409 | Now we've taken care of finding run time bugs. These bugs prove to be |
409 | <c>strace</c> is a great way at seeing what the kernel is doing to with the filesystem. |
| 410 | problematic when you try and run your programs. However, run time errors are |
410 | Another program exists to help users see what the kernel is doing, and help with |
| 411 | the least of your concerns if your program won't compile at all. Let's take a |
411 | kernel debugging. This program is called <c>dmesg</c> |
| 412 | look at how to address <c>emerge</c> compile errors. |
412 | </p> |
|
|
413 | |
|
|
414 | </body> |
|
|
415 | </section> |
|
|
416 | </chapter> |
|
|
417 | |
|
|
418 | <chapter> |
|
|
419 | <title>Kernel Debugging With dmesg</title> |
|
|
420 | <section> |
|
|
421 | <title>dmesg Introduction</title> |
|
|
422 | <body> |
|
|
423 | |
|
|
424 | <p> |
|
|
425 | <c>dmesg</c> is a system program created with debugging kernel operation. It |
|
|
426 | basically reads the kernel messages and keeps them in buffer, letting the user |
|
|
427 | see them later on. Here's an example of what a dmesg output looks like: |
|
|
428 | </p> |
|
|
429 | |
|
|
430 | <pre caption="dmesg sample output"> |
|
|
431 | SIS5513: IDE controller at PCI slot 0000:00:02.5 |
|
|
432 | SIS5513: chipset revision 208 |
|
|
433 | SIS5513: not 100% native mode: will probe irqs later |
|
|
434 | SIS5513: SiS 961 MuTIOL IDE UDMA100 controller |
|
|
435 | ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:DMA, hdb:DMA |
|
|
436 | ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:DMA, hdd:DMA |
|
|
437 | Probing IDE interface ide0... |
|
|
438 | input: ImPS/2 Generic Wheel Mouse on isa0060/serio1 |
|
|
439 | hda: WDC WD800BB-60CJA0, ATA DISK drive |
|
|
440 | hdb: CD-RW 52X24, ATAPI CD/DVD-ROM drive |
|
|
441 | ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 |
|
|
442 | Probing IDE interface ide1... |
|
|
443 | hdc: SAMSUNG DVD-ROM SD-616T, ATAPI CD/DVD-ROM drive |
|
|
444 | hdd: Maxtor 92049U6, ATA DISK drive |
|
|
445 | ide1 at 0x170-0x177,0x376 on irq 15 |
|
|
446 | hda: max request size: 128KiB |
|
|
447 | hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63, |
|
|
448 | UDMA(100) |
|
|
449 | hda: cache flushes not supported |
|
|
450 | hda: hda1 |
|
|
451 | hdd: max request size: 128KiB |
|
|
452 | hdd: 39882528 sectors (20419 MB) w/2048KiB Cache, CHS=39566/16/63, |
|
|
453 | UDMA(66) |
|
|
454 | hdd: cache flushes not supported |
|
|
455 | hdd: unknown partition table |
|
|
456 | hdb: ATAPI 52X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) |
|
|
457 | Uniform CD-ROM driver Revision: 3.20 |
|
|
458 | hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33) |
|
|
459 | ide-floppy driver 0.99.newide |
|
|
460 | libata version 1.11 loaded. |
|
|
461 | usbmon: debugs is not available |
|
|
462 | </pre> |
|
|
463 | |
|
|
464 | <p> |
|
|
465 | The dmesg displayed here is my machine's bootup. You can see harddrives and |
|
|
466 | input devices being initialized. While what you see here seems relatively |
|
|
467 | harmless, <c>dmesg</c> is also good at showing when things go wrong. Let's take |
|
|
468 | for example an IPAQ 1945 I have. After a couple of minutes of inactivity, the |
|
|
469 | device powers off. Now, I have the device connected into the USB port in the |
|
|
470 | front of my system. Now, I want to copy over some files using libsynCE, so I go |
|
|
471 | ahead and initiate a connection: |
|
|
472 | </p> |
|
|
473 | |
|
|
474 | <pre caption="IPAQ connection attempt"> |
|
|
475 | # <i>synce-serial-start</i> |
|
|
476 | /usr/sbin/pppd: In file /etc/ppp/peers/synce-device: unrecognized option |
|
|
477 | '/dev/tts/USB0' |
|
|
478 | |
|
|
479 | synce-serial-start was unable to start the PPP daemon! |
|
|
480 | </pre> |
|
|
481 | |
|
|
482 | <p> |
|
|
483 | The connection fails, as we see here, and we assume that only the screen is in |
|
|
484 | powersave mode, and that maybe the connection is faulty. In order to see what |
|
|
485 | truly happened, we can use <c>dmesg</c>. Now, <c>dmesg</c> tends to give a |
|
|
486 | rather large ammount of output. One can use the <c>tail</c> command to help |
|
|
487 | keep the output down: |
|
|
488 | </p> |
|
|
489 | |
|
|
490 | <pre caption="Adjusting the output ammount with tail"> |
|
|
491 | $ <i>dmesg | tail -n 4</i> |
|
|
492 | usb 1-1.2: PocketPC PDA converter now attached to ttyUSB0 |
|
|
493 | usb 1-1.2: USB disconnect, address 11 |
|
|
494 | PocketPC PDA ttyUSB0: PocketPC PDA converter now disconnected from ttyUSB0 |
|
|
495 | ipaq 1-1.2:1.0: device disconnected |
|
|
496 | </pre> |
|
|
497 | |
|
|
498 | <p> |
|
|
499 | This gives us the last 4 lines of the dmesg output. Now, this is enough to give |
|
|
500 | us some information on the situation. It seems that in the first 2 lines, the |
|
|
501 | pocketpc is recognized as connected. However, in the last 2 lines, it appears |
|
|
502 | to have been disconnected. With this information we check the pocketpc again, |
|
|
503 | and find out it is powered off, and now know about the powersave mode. We can |
|
|
504 | use this information to turn the feature off, or be aware of it next time. |
|
|
505 | While this is a somewhat simple example, it does go to show how well dmesg can |
|
|
506 | work. However, in more complex examples (such as kernel bugs), the entire dmesg |
|
|
507 | output may be required. To obtain that, simple redirect to a log file as such: |
|
|
508 | </p> |
|
|
509 | |
|
|
510 | <pre caption="Saving dmesg output to a log"> |
|
|
511 | $ <i>dmesg > dmesg.log</i> |
|
|
512 | </pre> |
|
|
513 | |
|
|
514 | <p> |
|
|
515 | You can then attach this to a bug report, or post it online somewhere for |
|
|
516 | collaborative debugging sessions. |
|
|
517 | </p> |
|
|
518 | |
|
|
519 | </body> |
|
|
520 | </section> |
|
|
521 | <section> |
|
|
522 | <title>Conclusion</title> |
|
|
523 | <body> |
|
|
524 | |
|
|
525 | <p> |
|
|
526 | Now that we've taken a look at a few ways to debug runtime and kernel errors, |
|
|
527 | let's take a look at how to handle emerge errors. |
| 413 | </p> |
528 | </p> |
| 414 | |
529 | |
| 415 | </body> |
530 | </body> |
| 416 | </section> |
531 | </section> |
| 417 | </chapter> |
532 | </chapter> |
Parent Directory
| 
Revision Log
| 
Patch