Re: ptrace problem on ia64 with kernel 2.4.26

From: Marcelo Tosatti (marcelo.tosatti_at_cyclades.com)
Date: 08/10/04

  • Next message: John Rose: "Re: [Pcihpd-discuss] struct pci_bus, no release() function?"
    Date:	Mon, 9 Aug 2004 21:28:08 -0300
    To: Mike Becher <Mike.Becher@lrz-muenchen.de>
    
    

    Woh, I've got no clue, but I believe the check you are hitting is:

    ia64/kernel/ptrace.c sys_ptrace():

            /* read the word at location addr in the USER area. */
            case PTRACE_PEEKUSR: {
                    unsigned long tmp;
                                                                                          
                    ret = -EIO;
                    if ((addr & 3) || addr < 0 ||
                        addr > sizeof(struct user) - 3)
                            break;
                    ***********************************
                                                                                          
                    tmp = 0; /* Default return condition */
                    if(addr < FRAME_SIZE*sizeof(long))
                            tmp = getreg(child, addr);
                    if(addr >= (long) &dummy->u_debugreg[0] &&
                       addr <= (long) &dummy->u_debugreg[7]){
                            addr -= (long) &dummy->u_debugreg[0];
                            addr = addr >> 2;
                            tmp = child->thread.debugreg[addr];
                    }
                    ret = put_user(tmp,(unsigned long *) data);
                    break;
            }

    Can you show us the address which is being passed to successful ptrace's
    and to the failed ones?

    Bjorn, David?

    On Thu, Aug 05, 2004 at 12:06:08PM +0200, Mike Becher wrote:
    > Hi,
    >
    > on our Linux IA64 cluster we got the problem that tools like strace, gdb,
    > ddd, and other debugging tools, which depend on ptrace system call, don't
    > work after some days of uptime of a node. I have searched already in the
    > web about information relating to that problem but haven't found any answer.
    >
    > description:
    > ------------
    > On a node that got the problem (when it runs longer than 3 days) strace
    > produce this output:
    > [mibe@lxsrv154]# strace /bin/true
    > execve("/bin/true", ["/bin/true"], [/* 38 vars */]) = 0
    > upeek: ptrace(PTRACE_PEEKUSER, ... ): Input/output error
    > Instead on a `younger' node or fresh booted node strace works fine.
    >
    > To find out what is differnt I have used also the `utrace' tool
    > (http://www.gelato.unsw.edu.au/IA64wiki/utrace) with a small
    > modification to peek info about register r4.
    >
    > diff utrace.c.orig utrace.c
    > 62c62
    > < long scnum, result, error, val;
    > ---
    > > long scnum, result, result_r4, error, val;
    > 74a75
    > > result_r4 = ptrace (PTRACE_PEEKUSER, child_pid, PT_R4, 0);
    >
    > With this register starts the critical area of ptrace for debuggers
    > when problem exists. They all don't do their work because they cannot
    > gather information about some registers like r4, r5, r6, r7.
    > Also it doesn't work for user `root'.
    > Whether in messages files nor in /proc filesystem nor with dmesg I
    > have found any info that can give me a hint what has changed.
    >
    > configuration:
    > --------------
    > We use the following configuration:
    > * kernel 2.4.26 (vanilla kernel) with
    > - official linux-2.4.26-ia64-040510.diff.bz2 (11-May-2004 11:18)
    > - EXPORT_SYMBOL_NOVERS(iosapic_fixup_pci_interrupt) in
    > linux-2.4.26/arch/ia64/kernel/ia64_ksyms.c
    > - commented out
    > printk(KERN_WARNING "%s(%d): floating-point assist...)
    > in linux-2.4.26/arch/ia64/kernel/traps.c
    > - BitKeeper patch which fixes x86 "clear_cpu()" macro.
    > on line 34 to >>> asm volatile("fnclex ; fwait");
    > * openafs 1.2.11
    > * Myrinet driver GM build ID is "1.6.4_Linux_and_AIX
    > * PVFS 1.6.2 with pvfs-1.6.2-01292004.patch
    > * following modules are loaded:
    > [mibe@lxsrv154 ia64]# lsmod
    > Module Size Used by Tainted: PF
    > pvfs 147336 7
    > imb 43024 0
    > gm 620176 1 (autoclean)
    > libafs-2.4.26.mp 1296528 2
    > e1000 170976 1
    > nls_iso8859-1 6000 1 (autoclean)
    > nls_cp437 7680 1 (autoclean)
    > usbkbd 9040 0 (unused)
    > ehci-hcd 54872 0 (unused)
    > usb-uhci 66888 0 (unused)
    > usbcore 182800 1 [usbkbd ehci-hcd usb-uhci]
    > aacraid 95512 7
    > sd_mod 33856 14
    >
    > Hope someone can help me to solve this problem.
    >
    > best regards,
    > Mike
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: John Rose: "Re: [Pcihpd-discuss] struct pci_bus, no release() function?"

    Relevant Pages

    • Re: EBOOT SMSC91C113L Ethernet registers not accessible
      ... fine, SMSC Shld be configured as Asynchronous, PXA 255 shld be configured as ... I checked the SMSC Signals and read 0x404 from MIR Register of it using ... Then, i made all the MSC1, GPIOs Registers configuration in the REset_Handler ... >> the controller, here the verification of initialization is done by checking ...
      (microsoft.public.windowsce.embedded)
    • Re: fpga locks up with slow signal, spartan chip, pin type issues.
      ... cables. ... YOU MUST ERASE platform flash for reliable JTAG configuration ... Read the Status Register after failing operations on an FPGA ... Also the system is non-responsive after the CRC error, ...
      (comp.arch.fpga)
    • Re: [PATCH 2.6] Altix - ioc3 serial support
      ... ports, and for console ports, it is assumed that the console code has ... >> tty_buffer_request_room is a hint to help the kernel manage buffers>> better. ... register for this. ... To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ...
      (Linux-Kernel)
    • Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture
      ... The current code also does not touch any register. ... The wmb() change is not needed, unless you have an oostore CPU ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] S3 suspend/resume with noexec
      ... >>Please analyse surrounding code a bit more. ... > and restore every register that is being touched here. ... I'd like minimal push/pops. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)