[Crash-utility] unsubscribe

Brown, Phillip (Linux/Virtualization) Phillip.Brown at hp.com
Fri Jul 6 21:14:52 UTC 2012



-----Original Message-----
From: crash-utility-bounces at redhat.com [mailto:crash-utility-bounces at redhat.com] On Behalf Of crash-utility-request at redhat.com
Sent: Friday, July 06, 2012 10:00 AM
To: crash-utility at redhat.com
Subject: Crash-utility Digest, Vol 82, Issue 10

Send Crash-utility mailing list submissions to
	crash-utility at redhat.com

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.redhat.com/mailman/listinfo/crash-utility
or, via email, send a message with subject or body 'help' to
	crash-utility-request at redhat.com

You can reach the person managing the list at
	crash-utility-owner at redhat.com

When replying, please edit your Subject line so it is more specific than "Re: Contents of Crash-utility digest..."


Today's Topics:

   1. Re: Crash-utility Digest, Vol 82, Issue 6 (Dave Anderson)
   2. Re: ptov command (Dave Anderson)


----------------------------------------------------------------------

Message: 1
Date: Fri, 06 Jul 2012 09:19:17 -0400 (EDT)
From: Dave Anderson <anderson at redhat.com>
To: "Discussion list for crash utility usage,	maintenance and
	development" <crash-utility at redhat.com>
Subject: Re: [Crash-utility] Crash-utility Digest, Vol 82, Issue 6
Message-ID:
	<570e1143-fa63-47f7-8eba-77cc60c4e034 at zmail15.collab.prod.int.phx2.redhat.com>
	
Content-Type: text/plain; charset=utf-8



----- Original Message -----
> 
> Dear ,
> The place is at value_search in symbols.c line 4252,I must apologize 
> for my careless.

OK -- but the same question still applies: 

  struct syment *
  value_search(ulong value, ulong *offset)
  {
          struct syment *sp, *spnext;

          if (!in_ksymbol_range(value))
                  return((struct syment *)NULL);


How does it get past in_ksymbol_range()?  What is the value of st->symtable[0].value and the passed-in "value"?

Dave



------------------------------

Message: 2
Date: Fri, 06 Jul 2012 11:39:52 -0400 (EDT)
From: Dave Anderson <anderson at redhat.com>
To: "Discussion list for crash utility usage,	maintenance and
	development" <crash-utility at redhat.com>
Subject: Re: [Crash-utility] ptov command
Message-ID:
	<d81a6bfc-4ee7-4b5f-b1b8-b40d66e5898c at zmail15.collab.prod.int.phx2.redhat.com>
	
Content-Type: text/plain; charset="utf-8"



----- Original Message -----
> Below you find my version of the ptov function. I have just added a 
> few lines and placed them under "#if defined(ARM)". The test is 
> reasonable for ARM so I would appreciate if you include it. For other 
> platforms please do whatever you like.
> 
> Jan
> 
> 
> void
> cmd_ptov(void)
> {
> 	int c;
> 	ulong vaddr;
> 	physaddr_t paddr;
> #if defined(ARM)
> 	physaddr_t paddr_tst;
> #endif
> 	char buf1[BUFSIZE];
> 	char buf2[BUFSIZE];
> 	int others;
> 
> 	while ((c = getopt(argcnt, args, "")) != EOF) {
> 		switch(c)
> 		{
> 		default:
> 			argerrs++;
> 			break;
> 		}
> 	}
> 
> 	if (argerrs || !args[optind])
> 		cmd_usage(pc->curcmd, SYNOPSIS);
> 
> 	others = 0;
> 	while (args[optind]) {
> 		paddr = htoll(args[optind], FAULT_ON_ERROR, NULL);
> 		vaddr = PTOV(paddr);
> 
> #if defined(ARM)
> 		if (kvtop(0, vaddr, &paddr_tst, 0) && paddr_tst==paddr) { #endif
> 		fprintf(fp, "%s%s  %s\n", others++ ? "\n" : "",
> 		    mkstring(buf1, VADDR_PRLEN, LJUST, "VIRTUAL"),
> 		    mkstring(buf2, VADDR_PRLEN, LJUST, "PHYSICAL"));
> 		fprintf(fp, "%s  %s\n",
> 		    mkstring(buf1, VADDR_PRLEN, LJUST|LONG_HEX, MKSTR(vaddr)),
>                     mkstring(buf2, VADDR_PRLEN, LJUST|LONGLONG_HEX,
> 			MKSTR(&paddr)));
> #if defined(ARM)
> 		} else {
> 			fprintf(fp, "Unknown virtual address for physical address
> 			0x%08llx\n", paddr);
> 		}
> #endif
> 
> 		optind++;
> 	}
> }

I hate the "#ifdef ARM" sections and the error message doesn't fit into multiple-argument usage.  How's this work for you?

--- crash-6.0.8/memory.c.orig   2012-07-06 11:28:13.000000000 -0400
+++ crash-6.0.8/memory.c        2012-07-06 11:32:02.000000000 -0400
@@ -2975,9 +2975,9 @@
 void
 cmd_ptov(void)
 {
-       int c;
+       int c, unknown;
        ulong vaddr;
-       physaddr_t paddr;
+       physaddr_t paddr, paddr_test;
        char buf1[BUFSIZE];
        char buf2[BUFSIZE];
        int others;
@@ -2999,10 +2999,14 @@
                paddr = htoll(args[optind], FAULT_ON_ERROR, NULL);
                vaddr = PTOV(paddr);

+               unknown = BITS32() && (!kvtop(0, vaddr, &paddr_test, 0) ||
+                   (paddr_test != paddr));
+
                fprintf(fp, "%s%s  %s\n", others++ ? "\n" : "",
                    mkstring(buf1, VADDR_PRLEN, LJUST, "VIRTUAL"),
                    mkstring(buf2, VADDR_PRLEN, LJUST, "PHYSICAL"));
-               fprintf(fp, "%s  %s\n",
+               fprintf(fp, "%s  %s\n", unknown ?
+                   mkstring(buf1, VADDR_PRLEN, LJUST, "unknown") :
                    mkstring(buf1, VADDR_PRLEN, LJUST|LONG_HEX, MKSTR(vaddr)),
                     mkstring(buf2, VADDR_PRLEN, LJUST|LONGLONG_HEX,


With one my sample ARM dumps, it looks like this:

  crash> kmem -p
    PAGE    PHYSICAL   MAPPING    INDEX CNT FLAGS
  c0b47000  80000000         0         0  0 0
  c0b47020  80001000         0         0  0 0
  c0b47040  80002000         0         0  0 0
  ... [ cut ] ...
  c0d46fa0  8fffd000         0         0  1 400
  c0d46fc0  8fffe000         0         0  1 400
  c0d46fe0  8ffff000         0         0  1 400
  crash> 

  crash> ptov 7ffff000 80000000 8ffff000 9000000
  VIRTUAL   PHYSICAL
  unknown   7ffff000

  VIRTUAL   PHYSICAL
  c0000000  80000000

  VIRTUAL   PHYSICAL
  cffff000  8ffff000

  VIRTUAL   PHYSICAL
  unknown   9000000 
  crash>

Dave


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ptov.patch
Type: text/x-patch
Size: 965 bytes
Desc: not available
URL: <https://www.redhat.com/archives/crash-utility/attachments/20120706/ce7d2dff/attachment.bin>

------------------------------

--
Crash-utility mailing list
Crash-utility at redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility


End of Crash-utility Digest, Vol 82, Issue 10
*********************************************




More information about the Crash-utility mailing list