Alex Sidorenko wrote: I don't know. I don't have an x86 2.6.20 live system or dumpfile readily available, so I'll need some help from the "outside world" here... Anybody else know anything about this? Dave

On Tue, 2007-05-29 at 15:45 -0400, David Anderson wrote: On a 2.6.21 kernel with the -rt patchset, and crash-4.0-4.1, I see some of this: PID: 3093 TASK: f69793b0 CPU: 0 COMMAND: "mingetty" ps: cannot access user stack address: bf9fdf4c PID: 3094 TASK: f7f2abf0 CPU: 0 COMMAND: "mingetty" ps: cannot access user stack address: bfbb2f4c on i686 but I haven't seen it on x86_64. (Dave, I have these kernels, and systems with these kernels, you can access if you wish) --Guy

Alex Sidorenko wrote: Alex, I think the mystery is solved. I believe that if you do a "ps -a" on your machine with the 2.6.20 kernel, you will find that *some* of the user process may show their arguments and environment data. Testing this on a 2.6.21-based kernel, I see that to be the case, where there's a mix of success with "ps -a", say for example, just taking the "mingetty" processes: crash> ps -a mingetty PID: 3125 TASK: f7e33870 CPU: 2 COMMAND: "mingetty" ps: cannot access user stack address: bfe76f4c PID: 3126 TASK: f6b08430 CPU: 0 COMMAND: "mingetty" ps: cannot access user stack address: bfac8f4c PID: 3127 TASK: f66b7730 CPU: 3 COMMAND: "mingetty" ps: cannot access user stack address: bfeeff4c PID: 3128 TASK: f693d170 CPU: 2 COMMAND: "mingetty" ps: cannot access user stack address: bfe45f4c PID: 3129 TASK: f6160630 CPU: 3 COMMAND: "mingetty" ps: cannot access user stack address: bfb72f4c PID: 3137 TASK: f68be0b0 CPU: 2 COMMAND: "mingetty" ARG: /sbin/mingetty tty6 ENV: HOME=/ TERM=linux SELINUX_INIT=YES PATH=/bin:/usr/bin:/sbin:/usr/sbin RUNLEVEL=3 PREVLEVEL=N CONSOLE=/dev/console INIT_VERSION=sysvinit-2.86 crash> So obviously if user virtual address translation works for one task, it has to work for all of them. However, presumably the similarity between the 2.6.21-based kernel above and your 2.6.20 Ubuntu kernel is that they both use /dev/mem for physical memory access. And that is a weakness that has existed all along for the i386 /dev/mem driver. Here is the top of the read_mem() function in "drivers/char/mem.c": static ssize_t read_mem(struct file * file, char __user * buf, size_t count, loff_t *ppos) { unsigned long p = *ppos; ssize_t read, sz; char *ptr; if (!valid_phys_addr_range(p, count)) return -EFAULT; And since i386 does not have ARCH_HAS_VALID_PHYS_ADDR_RANGE #define'd, it is bounded by the value of high_memory: #ifndef ARCH_HAS_VALID_PHYS_ADDR_RANGE static inline int valid_phys_addr_range(unsigned long addr, size_t count) { if (addr + count > __pa(high_memory)) return 0; return 1; } So if your system has more than 896MB installed (0x38000000), any memory at and above that is not accessible. My test box has 1GB (0x40000000) installed: crash> rd -p 38000000 rd: read error: physical address: 38000000 type: "32-bit PHYSADDR" crash> rd -p 37fff000 37fff000: f7ffdcc8 crash> And user virtual addresses pages, and usually their page tables, are biased to use high_memory. So if your system has memory above 896MB, the user virtual memory page tables will be allocated from highmem if CONFIG_HIGHPTE: struct page *pte_alloc_one(struct mm_struct *mm, unsigned long address) { struct page *pte; #ifdef CONFIG_HIGHPTE pte = alloc_pages(GFP_KERNEL|__GFP_HIGHMEM|__GFP_REPEAT|__GFP_ZERO,0); #else pte = alloc_pages(GFP_KERNEL|__GFP_REPEAT|__GFP_ZERO, 0); #endif return pte; } And even if the page table still comes from low memory, the actual user data pages will always be biased to use __GFP_HIGHMEM. I should have recognized this by your error message: ps: read error: physical address: 7f2f0000 type: "page table" where physical address 7f2f0000 was way up there... I forgot about this anomoly because Red Hat RHEL kernels outlaw the use of /dev/mem for anything above the first 256 pages of physical memory (for security purposes). And for that reason, RHEL kernels contain the /dev/crash driver for live memory access, which is unrestricted. Dave The same crash-4.0-4.1 works fine on live 2.6.15 kernel