From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Gene Heskett <gene.heskett@verizon.net>
Cc: linux-kernel@vger.kernel.org,
Nick Piggin <nickpiggin@yahoo.com.au>,
viro@parcelfarce.linux.theplanet.co.uk,
Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>
Subject: Re: Possible dcache BUG
Date: Thu, 19 Aug 2004 15:36:43 -0300 [thread overview]
Message-ID: <20040819183643.GA5278@logos.cnet> (raw)
In-Reply-To: <200408190541.14131.gene.heskett@verizon.net>
Gene,
That is:
/*
* The buffer's backing address_space's private_lock must be held
*/
static inline void __remove_assoc_queue(struct buffer_head *bh)
{
BUG_ON(bh->b_assoc_buffers.next == NULL); <----------
BUG_ON(bh->b_assoc_buffers.prev == NULL);
list_del_init(&bh->b_assoc_buffers);
}
Viro, Linus, Andrew, dont you have any idea what could cause such mapping->b_assoc_mapping
corruption?
I can't see how that could be caused by flaky hardware.
Maybe we should include those BUGs into the official kernel, or -mm's tree?
On Thu, Aug 19, 2004 at 05:41:13AM -0400, Gene Heskett wrote:
> On Tuesday 17 August 2004 07:57, Nick Piggin wrote:
> >Gene Heskett wrote:
> >> On Tuesday 17 August 2004 00:58, Nick Piggin wrote:
> >>>Gene Heskett wrote:
> >>>>Reboot time I guess :(((
> >>>
> >>>All your low memory has been used by dentry and inode caches. This
> >>>isn't very
> >>>interesting because this would be no doubt caused by something
> >>>oopsing while holding the shrinker semaphore as Andrew pointed
> >>> out.
> >>>
> >>>What is interesting is that first Oops message (I wonder if you
> >>>don't have bad hardware though, I don't think anyone else is
> >>> seeing it).
> >>
> >> What 'first Oops message'? One I posted before?
> >
> >Well, the first Oops that your running kernel raises. Usually you
> >don't bother about subsequent oopses and misbehaviour because the
> >first one can cause the system to go into a funny state - this is
> >a prime example.
> >
> >> That comment caused me to go back in the log to well above where I
> >> had been channel surfing with tvtime, and I did find an Oops:
> >>
> >> Aug 16 21:15:46 coyote kernel: Unable to handle kernel NULL
> >> pointer dereference at virtual address 00000000 Aug 16 21:15:46
> >> coyote kernel: printing eip:
> >> Aug 16 21:15:46 coyote kernel: c015c8db
> >> Aug 16 21:15:46 coyote kernel: *pde = 00000000
> >> Aug 16 21:15:46 coyote kernel: Oops: 0002 [#1]
> >> Aug 16 21:15:46 coyote kernel: Modules linked in: tuner tvaudio
> >> bttv video_buf btcx_risc eeprom snd_seq_oss snd_seq _midi_event
> >> snd_seq snd_pcm_oss snd_mixer_oss snd_bt87x snd_intel8x0
> >> snd_ac97_codec snd_pcm snd_timer snd_page_allo c snd_mpu401_uart
> >> snd_rawmidi snd_seq_device snd forcedeth sg Aug 16 21:15:46 coyote
> >> kernel: CPU: 0
> >> Aug 16 21:15:46 coyote kernel: EIP: 0060:[<c015c8db>] Not
> >> tainted Aug 16 21:15:46 coyote kernel: EFLAGS: 00210206
> >> (2.6.8-rc4) Aug 16 21:15:46 coyote kernel: EIP is at
> >> prune_icache+0x6b/0x1b0 Aug 16 21:15:46 coyote kernel: eax:
> >> 00000000 ebx: dffe0fd0 ecx: d3eb8b80 edx: c0341660 Aug 16
> >> 21:15:46 coyote kernel: esi: dffe0fc8 edi: 0000005a ebp:
> >> d3eb8b94 esp: d3eb8b74 Aug 16 21:15:46 coyote kernel: ds: 007b
> >> es: 007b ss: 0068 Aug 16 21:15:46 coyote kernel: Process yum
> >> (pid: 30892, threadinfo=d3eb8000 task=cf6bf7b0) Aug 16 21:15:46
> >> coyote kernel: Stack: dffe0448 00000000 00000059 dffe0450 df58d0d0
> >> 00000080 00000000 d3eb8000 Aug 16 21:15:46 coyote kernel:
> >> d3eb8ba0 c015ca5f 00000080 d3eb8bd4 c0135b14 00000080 000000d2
> >> 0108bf00 Aug 16 21:15:46 coyote kernel: 00000000 00021087
> >> 00000080 00000000 f7ffea20 0000000a d3eb8c50 00000000 Aug 16
> >> 21:15:46 coyote kernel: Call Trace:
> >> Aug 16 21:15:46 coyote kernel: [<c01044ef>] show_stack+0x7f/0xa0
> >> Aug 16 21:15:46 coyote kernel: [<c0104688>]
> >> show_registers+0x158/0x1b0 Aug 16 21:15:46 coyote kernel:
> >> [<c01047e6>] die+0x66/0xd0 Aug 16 21:15:46 coyote kernel:
> >> [<c01109de>] do_page_fault+0x28e/0x548 Aug 16 21:15:46 coyote
> >> kernel: [<c010415d>] error_code+0x2d/0x38 Aug 16 21:15:46 coyote
> >> kernel: [<c015ca5f>] shrink_icache_memory+0x3f/0x50 Aug 16
> >> 21:15:46 coyote kernel: [<c0135b14>] shrink_slab+0x134/0x170 Aug
> >> 16 21:15:46 coyote kernel: [<c0136954>]
> >> try_to_free_pages+0xa4/0x160 Aug 16 21:15:46 coyote kernel:
> >> [<c012fc23>] __alloc_pages+0x1b3/0x320 Aug 16 21:15:46 coyote
> >> kernel: [<c0139a8f>] do_anonymous_page+0x5f/0x180 Aug 16 21:15:46
> >> coyote kernel: [<c0139c11>] do_no_page+0x61/0x310 Aug 16 21:15:46
> >> coyote kernel: [<c013a097>] handle_mm_fault+0xd7/0x160 Aug 16
> >> 21:15:46 coyote kernel: [<c01108a0>] do_page_fault+0x150/0x548
> >> Aug 16 21:15:46 coyote kernel: [<c010415d>] error_code+0x2d/0x38
> >> Aug 16 21:15:46 coyote kernel: [<c012c279>]
> >> do_generic_mapping_read+0x129/0x430 Aug 16 21:15:46 coyote kernel:
> >> [<c012c836>] __generic_file_aio_read+0x1b6/0x1f0 Aug 16 21:15:46
> >> coyote kernel: [<c012c8c2>] generic_file_aio_read+0x52/0x70 Aug
> >> 16 21:15:46 coyote kernel: [<c0145898>] do_sync_read+0x78/0xa0
> >> Aug 16 21:15:46 coyote kernel: [<c014598a>] vfs_read+0xca/0x140
> >> Aug 16 21:15:46 coyote kernel: [<c0145c2b>] sys_read+0x4b/0x80
> >> Aug 16 21:15:46 coyote kernel: [<c0103f61>]
> >> sysenter_past_esp+0x52/0x71 Aug 16 21:15:46 coyote kernel: Code:
> >> 89 10 a1 60 16 34 c0 89 58 04 89 03 c7 43 04 60 16 34 c0 89
> >>
> >> yum did a segfault about that time. yum is nice code, when
> >> it fscking works, which is maybe half the time on 2 different
> >> FC2 machines here now.
> >
> >Although an Oops is always the kernel's (or bad hardware's) fault.
> >So in this case you can let yum off the hook :)
> >
> >> So we're back to the dentry_cache thing... Duh, NO!, this is in
> >> prune_icache, not prune_dcache, presumably slightly different.
> >
> >Yeah, both are going to cause cache shrinking to stop working.
> >
> >> As far as bad hardware is concerned, warranty time is running out.
> >> I need something plausible to take back to tcwo as a good reason
> >> for requesting a 'blanket rma' on the whole thing, would they
> >> please send me another.
> >
> >Not too sure really. At this stage keep trying patches that you get
> >sent :P
>
> I just had another but this ones a bit different:
>
> Aug 19 04:22:11 coyote kernel: ------------[ cut here ]------------
> Aug 19 04:22:11 coyote kernel: kernel BUG at fs/buffer.c:805!
> Aug 19 04:22:11 coyote kernel: invalid operand: 0000 [#1]
> Aug 19 04:22:11 coyote kernel: Modules linked in: eeprom snd_seq_oss
> snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_bt87x
> snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd_page_alloc
> snd_mpu401_uart snd_rawmidi snd_seq_device snd forcedeth sg
> Aug 19 04:22:11 coyote kernel: CPU: 0
> Aug 19 04:22:11 coyote kernel: EIP: 0060:[<c0147d77>] Not
> tainted
> Aug 19 04:22:11 coyote kernel: EFLAGS: 00010246 (2.6.8-rc4)
> Aug 19 04:22:11 coyote kernel: EIP is at
> remove_inode_buffers+0x77/0x90
> Aug 19 04:22:11 coyote kernel: eax: 00000000 ebx: d7de519c ecx:
> d7deb99c edx: d7deb974
> Aug 19 04:22:11 coyote kernel: esi: d7de50c8 edi: 00000001 ebp:
> c198bedc esp: c198becc
> Aug 19 04:22:11 coyote kernel: ds: 007b es: 007b ss: 0068
> Aug 19 04:22:11 coyote kernel: Process kswapd0 (pid: 66,
> threadinfo=c198b000 task=c1978050)
> Aug 19 04:22:11 coyote kernel: Stack: d7de50c8 d7de50d0 d7de50c8
> 00000057 c198bf04 c015c985 d7de50c8 00000000
> Aug 19 04:22:11 coyote kernel: 00000057 d7de5290 e50ac0d0
> 00000080 00000000 c198b000 c198bf10 c015ca5f
> Aug 19 04:22:11 coyote kernel: 00000080 c198bf44 c0135b14
> 00000080 000000d0 01779600 00000000 0002d1f3
> Aug 19 04:22:11 coyote kernel: Call Trace:
> Aug 19 04:22:11 coyote kernel: [<c01044ef>] show_stack+0x7f/0xa0
> Aug 19 04:22:11 coyote kernel: [<c0104688>]
> show_registers+0x158/0x1b0
> Aug 19 04:22:11 coyote kernel: [<c01047e6>] die+0x66/0xd0
> Aug 19 04:22:12 coyote kernel: [<c0104bc3>] do_invalid_op+0xb3/0xc0
> Aug 19 04:22:12 coyote kernel: [<c010415d>] error_code+0x2d/0x38
> Aug 19 04:22:12 coyote kernel: [<c015c985>] prune_icache+0x115/0x1b0
> Aug 19 04:22:12 coyote kernel: [<c015ca5f>]
> shrink_icache_memory+0x3f/0x50
> Aug 19 04:22:12 coyote kernel: [<c0135b14>] shrink_slab+0x134/0x170
> Aug 19 04:22:12 coyote kernel: [<c0136bb9>] balance_pgdat+0x1a9/0x1f0
> Aug 19 04:22:12 coyote kernel: [<c0136cbf>] kswapd+0xbf/0xd0
> Aug 19 04:22:12 coyote kernel: [<c01023f1>]
> kernel_thread_helper+0x5/0x14
> Aug 19 04:22:12 coyote kernel: Code: 0f 0b 25 03 e5 0b 30 c0 eb c4 31
> ff eb de 0f 0b 36 04 e5 0b
>
> The system is still up but its 100 megs into swap so I'm going to
> reboot without changing anything. Is this one traceable?
next prev parent reply other threads:[~2004-08-19 19:49 UTC|newest]
Thread overview: 147+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-02 13:14 Possible dcache BUG Brett Charbeneau
2004-08-05 2:16 ` Gene Heskett
2004-08-05 3:46 ` Andrew Morton
2004-08-05 4:31 ` Gene Heskett
2004-08-05 0:44 ` Chris Shoemaker
2004-08-05 8:35 ` Denis Vlasenko
2004-08-05 14:14 ` Gene Heskett
2004-08-05 13:48 ` Gene Heskett
[not found] ` <200408210118.02011.vda@port.imtp.ilyichevsk.odessa.ua>
2004-08-21 1:40 ` Gene Heskett
2004-08-05 8:33 ` Denis Vlasenko
2004-08-05 14:19 ` Gene Heskett
[not found] ` <200408070203.35268.vda@port.imtp.ilyichevsk.odessa.ua>
2004-08-07 1:28 ` Gene Heskett
2004-08-05 21:26 ` Chris Shoemaker
2004-08-05 7:25 ` Linus Torvalds
2004-08-05 7:31 ` Andrew Morton
2004-08-05 8:33 ` Denis Vlasenko
2004-08-05 14:55 ` Gene Heskett
2004-08-05 16:26 ` Linus Torvalds
2004-08-05 18:06 ` Ingo Molnar
2004-08-05 18:50 ` Linus Torvalds
2004-08-05 20:29 ` Andi Kleen
[not found] ` <20040806073739.GA6617@elte.hu>
[not found] ` <20040806004231.143c8bd2.akpm@osdl.org>
2004-08-06 8:27 ` Ingo Molnar
2004-08-06 11:51 ` Gene Heskett
2004-08-06 16:58 ` Linus Torvalds
2004-08-06 17:16 ` Gene Heskett
2004-08-06 17:26 ` William Lee Irwin III
2004-08-06 23:19 ` Chris Shoemaker
2004-08-07 4:15 ` William Lee Irwin III
2004-08-07 0:05 ` Chris Shoemaker
2004-08-07 5:50 ` William Lee Irwin III
2004-08-06 23:09 ` Chris Shoemaker
2004-08-07 6:20 ` Linus Torvalds
2004-08-07 12:38 ` Gene Heskett
2004-08-07 13:44 ` Chris Shoemaker
2004-08-07 18:49 ` Linus Torvalds
2004-08-07 19:01 ` Gene Heskett
2004-08-06 11:31 ` Andi Kleen
2004-08-06 17:16 ` Linus Torvalds
2004-08-05 21:10 ` Chris Shoemaker
2004-08-06 2:03 ` Gene Heskett
2004-08-06 2:12 ` Gene Heskett
2004-08-06 2:50 ` Linus Torvalds
2004-08-06 3:18 ` viro
2004-08-06 3:24 ` Linus Torvalds
2004-08-08 4:42 ` Gene Heskett
2004-08-08 14:30 ` Gene Heskett
2004-08-08 18:39 ` Andrew Morton
2004-08-10 4:12 ` Gene Heskett
2004-08-11 3:42 ` Gene Heskett
2004-08-11 3:46 ` Linus Torvalds
2004-08-11 4:18 ` Udo A. Steinberg
2004-08-11 5:13 ` Linus Torvalds
2004-08-11 5:15 ` Linus Torvalds
2004-08-11 5:33 ` Udo A. Steinberg
2004-08-11 14:37 ` Gene Heskett
2004-08-12 1:26 ` Nick Piggin
2004-08-12 2:23 ` Gene Heskett
2004-08-12 2:36 ` Nick Piggin
2004-08-13 1:00 ` Udo A. Steinberg
2004-08-13 1:31 ` Linus Torvalds
2004-08-13 2:03 ` Gene Heskett
2004-08-13 2:27 ` Andreas Dilger
2004-08-13 3:33 ` Linus Torvalds
2004-08-20 7:02 ` Udo A. Steinberg
2004-08-20 7:11 ` Andrew Morton
2004-08-20 7:19 ` Udo A. Steinberg
2004-08-20 7:49 ` Nick Piggin
2004-08-24 6:08 ` Udo A. Steinberg
2004-08-24 7:41 ` Nick Piggin
2004-08-24 18:20 ` Marcelo Tosatti
2004-08-24 20:00 ` Andrew Morton
2004-08-24 18:40 ` Marcelo Tosatti
2004-08-25 0:27 ` Marcelo Tosatti
2004-09-12 7:03 ` Udo A. Steinberg
2004-09-12 7:16 ` Andrew Morton
2004-09-12 7:29 ` Udo A. Steinberg
2004-09-12 7:48 ` Andrew Morton
[not found] ` <20040912004812.3544c6de.akpm-3NddpPZAyC0@public.gmane.org>
2004-09-13 4:53 ` Len Brown
2004-09-13 4:53 ` Len Brown
2004-08-11 5:55 ` David S. Miller
2004-08-11 4:47 ` Gene Heskett
2004-08-11 4:59 ` Linus Torvalds
2004-08-11 8:05 ` Roger Luethi
2004-08-13 4:27 ` Gene Heskett
2004-08-13 8:32 ` Gene Heskett
2004-08-14 2:18 ` Marcelo Tosatti
2004-08-14 5:19 ` Gene Heskett
2004-08-14 5:50 ` Gene Heskett
2004-08-14 8:17 ` Gene Heskett
2004-08-15 4:09 ` Gene Heskett
2004-08-15 8:48 ` viro
2004-08-15 9:42 ` Gene Heskett
2004-08-15 17:31 ` Andrew Morton
2004-08-15 17:58 ` Gene Heskett
2004-08-15 9:50 ` Gene Heskett
2004-08-15 10:36 ` viro
2004-08-15 10:10 ` Gene Heskett
2004-08-15 10:37 ` viro
2004-08-15 10:42 ` Gene Heskett
2004-08-15 11:00 ` viro
[not found] ` <200408150704.49312.gene.heskett@verizon.net>
2004-08-15 11:26 ` viro
2004-08-15 17:47 ` Gene Heskett
[not found] ` <200408152257.04773.vda@port.imtp.ilyichevsk.odessa.ua>
2004-08-15 20:33 ` Gene Heskett
[not found] ` <200408160803.15206.vda@port.imtp.ilyichevsk.odessa.ua>
2004-08-16 6:32 ` Gene Heskett
2004-08-16 14:13 ` Gene Heskett
[not found] ` <200408161749.23663.vda@port.imtp.ilyichevsk.odessa.ua>
2004-08-16 15:25 ` Gene Heskett
2004-08-16 22:52 ` Gene Heskett
2004-08-16 23:01 ` viro
2004-08-17 4:44 ` Gene Heskett
2004-08-17 4:58 ` Nick Piggin
2004-08-17 5:26 ` Gene Heskett
2004-08-17 11:57 ` Nick Piggin
2004-08-19 9:41 ` Gene Heskett
2004-08-19 18:36 ` Marcelo Tosatti [this message]
2004-08-20 2:38 ` Gene Heskett
2004-08-20 7:33 ` Marcelo Tosatti
2004-08-20 15:06 ` Gene Heskett
2004-08-20 15:43 ` V13
2004-08-20 17:29 ` Gene Heskett
2004-08-20 18:13 ` Marc Ballarin
2004-08-20 20:08 ` Gene Heskett
2004-08-21 9:25 ` Barry K. Nathan
2004-08-21 18:31 ` V13
2004-08-21 18:55 ` Gene Heskett
2004-08-22 11:04 ` Helge Hafting
2004-08-22 11:40 ` Gene Heskett
2004-08-20 20:11 ` R. J. Wysocki
2004-08-20 20:17 ` Gene Heskett
2004-08-22 5:05 ` Gene Heskett
2004-08-22 11:42 ` R. J. Wysocki
2004-08-24 2:34 ` Tom Vier
2004-08-24 3:08 ` Gene Heskett
2004-08-25 1:49 ` Tom Vier
2004-08-25 2:33 ` Gene Heskett
2004-08-25 14:55 ` Martin J. Bligh
2004-08-25 17:23 ` Ryan Cumming
2004-08-25 17:36 ` Martin J. Bligh
2004-08-27 14:01 ` Gene Heskett
2004-08-25 6:13 ` Denis Vlasenko
2004-08-29 13:48 ` Gene Heskett
2004-08-29 14:34 ` Possible dcache BUG [u] Martin Schlemmer [c]
2004-08-29 15:21 ` Possible dcache BUG Rafael J. Wysocki
2004-08-29 17:23 ` Denis Vlasenko
2004-08-29 22:25 ` Gene Heskett
-- strict thread matches above, loose matches on Subject: below --
2004-08-05 14:54 Brett Charbeneau
[not found] <2oKTA-5CQ-65@gated-at.bofh.it>
[not found] ` <2r0U7-3yx-9@gated-at.bofh.it>
[not found] ` <2rwhh-BX-15@gated-at.bofh.it>
[not found] ` <2rShM-7QP-5@gated-at.bofh.it>
[not found] ` <2rSrs-7Vn-1@gated-at.bofh.it>
[not found] ` <2rSUw-8lw-3@gated-at.bofh.it>
[not found] ` <2rTGR-se-3@gated-at.bofh.it>
[not found] ` <2rUjF-Od-11@gated-at.bofh.it>
2004-08-11 12:32 ` Andi Kleen
2004-08-20 8:08 Daniel Blueman
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=20040819183643.GA5278@logos.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=akpm@osdl.org \
--cc=gene.heskett@verizon.net \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=torvalds@osdl.org \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.