public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gerd Knorr <kraxel@bytesex.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Michael Hunold <hunold@convergence.de>,
	Meelis Roos <mroos@linux.ee>,
	linux-kernel@vger.kernel.org
Subject: Re: Fw: Re: Serious stability issues with 2.6.10-rc1 - more info
Date: Tue, 26 Oct 2004 13:38:35 +0200	[thread overview]
Message-ID: <20041026113835.GB11239@bytesex> (raw)
In-Reply-To: <20041026035104.7d805289.akpm@osdl.org>

> Then I tried SysRq-T to capture the task list. dmesg in yet another
> terminal was the last command that worked before the complete hang where
> only sysrq-b worked. But I got the sysrq-t ouput to disk, maybe it is of
> some help (tvtime and ps are the last ones but here is the full dmesg).
> 
> This shows that the first thing that happened was an oops in
> dma_free_coherent:

> Unable to handle kernel paging request at virtual address 08e1c5a0
> EIP:    0060:[dma_free_coherent+41/96]    Not tainted VLI
>  [pg0+407638071/1069536256] btcx_riscmem_free+0x37/0x80 [btcx_risc]

Hmm, btcx_riscmem_free does nothing but calling pci_free_consistent with
the values recorded at pci_alloc_consistent time, thats something which
really shouldn't fail ...

memory corruption?

>  [pg0+407770590/1069536256] videobuf_dma_pci_unmap+0x2e/0x80 [video_buf]
>  [pg0+407989509/1069536256] bttv_dma_free+0x55/0x80 [bttv]
>  [pg0+407775739/1069536256] videobuf_vm_close+0x8b/0xc0 [video_buf]
>  [remove_vm_struct+90/96] remove_vm_struct+0x5a/0x60
>  [unmap_vma_list+14/32] unmap_vma_list+0xe/0x20
>  [do_munmap+246/320] do_munmap+0xf6/0x140
>  [sys_munmap+64/112] sys_munmap+0x40/0x70
>  [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71

> tvtime        D C02E482C     0  5895   4655                     (NOTLB)
> d1b31d80 00200082 00000000 c02e482c d1b31d84 c01296bb 7ac8f240 000f45d5 
>        0001b207 7ac8f240 000f45d5 c0b58040 c0b5819c d68c1b6c d1b31d90 c0b58040 
>        0000000b c02972f5 00200082 d68c1b70 cee95ed4 d68c1b70 c0b58040 00000001 
> Call Trace:
>  [autoremove_wake_function+27/80] autoremove_wake_function+0x1b/0x50
>  [rwsem_down_read_failed+117/352] rwsem_down_read_failed+0x75/0x160
>  [.text.lock.exit+107/261] .text.lock.exit+0x6b/0x105
>  [printk+23/32] printk+0x17/0x20
>  [die+317/320] die+0x13d/0x140
>  [do_page_fault+0/1434] do_page_fault+0x0/0x59a
>  [do_page_fault+0/1434] do_page_fault+0x0/0x59a
>  [do_page_fault+682/1434] do_page_fault+0x2aa/0x59a
>  [mark_page_accessed+40/48] mark_page_accessed+0x28/0x30
>  [filemap_nopage+364/688] filemap_nopage+0x16c/0x2b0
>  [do_no_page+334/496] do_no_page+0x14e/0x1f0
>  [zap_pte_range+314/560] zap_pte_range+0x13a/0x230
>  [do_page_fault+0/1434] do_page_fault+0x0/0x59a
>  [error_code+45/56] error_code+0x2d/0x38
>  [dma_free_coherent+41/96] dma_free_coherent+0x29/0x60
>  [pg0+407638071/1069536256] btcx_riscmem_free+0x37/0x80 [btcx_risc]
>  [pg0+407770590/1069536256] videobuf_dma_pci_unmap+0x2e/0x80 [video_buf]
>  [pg0+407989509/1069536256] bttv_dma_free+0x55/0x80 [bttv]
>  [pg0+407775739/1069536256] videobuf_vm_close+0x8b/0xc0 [video_buf]
>  [remove_vm_struct+90/96] remove_vm_struct+0x5a/0x60
>  [unmap_vma_list+14/32] unmap_vma_list+0xe/0x20
>  [do_munmap+246/320] do_munmap+0xf6/0x140
>  [sys_munmap+64/112] sys_munmap+0x40/0x70
>  [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71

Same trace as above, just a bit deeper on the stack.  Looks like the
kernel didn't even manage to kill tvtime after the oops because it
couldn't get some lock (process list?) ...

> ps            D C02E8740     0  6010   4657                     (NOTLB)
> cee95ec4 00200086 cdd81878 c02e8740 fffffff4 cdd818e0 5d6adac0 000f45de 
>        00000000 5d6adac0 000f45de c61cc5d0 c61cc72c d68c1b6c cee95ed4 c61cc5d0 
>        cdd82000 c02972f5 00000000 d68c1b70 d68c1b70 d1b31d90 c61cc5d0 00000001 
> Call Trace:
>  [rwsem_down_read_failed+117/352] rwsem_down_read_failed+0x75/0x160
>  [.text.lock.ptrace+7/79] .text.lock.ptrace+0x7/0x4f
>  [proc_pid_cmdline+96/256] proc_pid_cmdline+0x60/0x100

probably the same lock ps needs.

  Gerd

-- 
#define printk(args...) fprintf(stderr, ## args)

           reply	other threads:[~2004-10-26 12:01 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20041026035104.7d805289.akpm@osdl.org>]

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=20041026113835.GB11239@bytesex \
    --to=kraxel@bytesex.org \
    --cc=akpm@osdl.org \
    --cc=hunold@convergence.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mroos@linux.ee \
    /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