Re: kernel Oops in ext3 code
Hi all, On Fr, 28 Sep 2007, Mingming Cao wrote: > i_block_alloc_info, it should be 0x14(20 bytes)...Are you running a > vanilla 2.6.23-rc6? Well yes, I add one patch for reducing the usb device resetting time, but this was definitely not the problem, no usb device was attached. > from the cache, so racing is not a issue there. Possible random memory > corruption? Could be could be. I would say since it is such a strange thing and nobody has an idea we leave it for now, random memory corruption sounds nice. If it occurs I can come back. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- in the space-time continuum.' is he? Is he?' --- Arthur failing in his first lesson of galactic physics --- in four years. --- Douglas Adams, The Hitchhikers Guide to the Galaxy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel Oops in ext3 code
Mingming Cao wrote:
BUG: unable to handle kernel paging request at virtual address 104b
printing eip:
c0195bd3
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: vboxdrv binfmt_misc fuse coretemp hwmon gspca videodev v4l2_common v4l1_compat iwl3945 mac80211 tifm_7xx1 tifm_core joydev irda crc_ccitt 8250_pnp 8250 serial_core firewire_ohci firewire_core crc_itu_t
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010206 (2.6.23-rc6 #1)
EIP is at ext3_discard_reservation+0x18/0x4d
eax: dff23800 ebx: 1033 ecx: dfc15ec0 edx:
esi: c0007c44 edi: 1033 ebp: dfc2bef4 esp: dfc2beac
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process kswapd0 (pid: 261, ti=dfc2a000 task=dfcac570 task.ti=dfc2a000)
Stack: c0007ba4 c0007c44 1033 c019ec51 c0007c44 c0007d8c 002c c0171b1b
002c c0007c44 c0007c4c c0171da2 c050880c 0080 0080
c0171fb8 0080 c0007e48 df9e3910 7404 c03f5634 0080 00d0
Call Trace:
[] ext3_clear_inode+0x5d/0x76
[] clear_inode+0x6b/0xb9
[] dispose_list+0x48/0xc9
[] shrink_icache_memory+0x195/0x1bd
[] shrink_slab+0xe2/0x159
[] kswapd+0x2d3/0x431
[] autoremove_wake_function+0x0/0x33
[] kswapd+0x0/0x431
[] kthread+0x38/0x5d
[] kthread+0x0/0x5d
[] kernel_thread_helper+0x7/0x10
===
Code: 83 f8 01 19 c0 f7 d0 83 e0 08 89 42 0c 89 56 b4 5b 5e c3 57 56 89 c6 53 8b 58 b4 8b 80 a4 00 00 00 85 db 8b 80 78 01 00 00 74 30 <83> 7b 18 00 74 2a 8d b8 00 03 00 00 89 f8 e8 b8 ca 1a 00 83 7b
EIP: [] ext3_discard_reservation+0x18/0x4d SS:ESP 0068:dfc2beac
On Fri, 2007-09-28 at 17:00 +0200, Norbert Preining wrote:
On Fr, 28 Sep 2007, Badari Pulavarty wrote:
objdump -DlS balloc.o
Here it is
Thanks
Looks like kernel oops at 1753(173b+0x18):
173b :
ext3_discard_reservation():
173b: 57 push %edi
173c: 56 push %esi
173d: 89 c6 mov%eax,%esi
173f: 53 push %ebx
1740: 8b 58 b4mov-0x4c(%eax),%ebx
1743: 8b 80 a4 00 00 00 mov0xa4(%eax),%eax
1749: 85 db test %ebx,%ebx
174b: 8b 80 78 01 00 00 mov0x178(%eax),%eax
1751: 74 30 je 1783
1753: 83 7b 18 00 cmpl $0x0,0x18(%ebx)
==> Kernel oops here, ebx=1033, match bad
page location 104b(=1033+0x18)
1757: 74 2a je 1783
1759: 8d b8 00 03 00 00 lea0x300(%eax),%edi
175f: 89 f8 mov%edi,%eax
1761: e8 fc ff ff ff call 1762
1766: 83 7b 18 00 cmpl $0x0,0x18(%ebx)
176a: 74 0d je 1779
176c: 8b 86 a4 00 00 00 mov0xa4(%esi),%eax
1772: 89 da mov%ebx,%edx
1774: e8 dc eb ff ff call 355
1779: 89 f8 mov%edi,%eax
177b: 5b pop%ebx
177c: 5e pop%esi
177d: 5f pop%edi
177e: e9 fc ff ff ff jmp177f
1783: 5b pop%ebx
1784: 5e pop%esi
1785: 5f pop%edi
1786: c3 ret
And trying to matching to the code:
void ext3_discard_reservation(struct inode *inode)
{
struct ext3_inode_info *ei = EXT3_I(inode);
struct ext3_block_alloc_info *block_i = ei->i_block_alloc_info;
struct ext3_reserve_window_node *rsv;
spinlock_t *rsv_lock = _SB(inode->i_sb)->s_rsv_window_lock;
if (!block_i)
return;
rsv = _i->rsv_window_node;
if (!rsv_is_empty(>rsv_window)) {
=> kernel oops here
spin_lock(rsv_lock);
if (!rsv_is_empty(>rsv_window))
rsv_window_remove(inode->i_sb, rsv);
spin_unlock(rsv_lock);
}
}
It seems ebx points to block_i(i_block_alloc_info), and that is bad
memory location, so that leads to bad paging request when try to get the
rsv_window structure.
But it confused me why the rsv_window offset is 0x18 to
i_block_alloc_info, it should be 0x14(20 bytes)...Are you running a
vanilla 2.6.23-rc6?
That is 0x14 + 4
(gdb) offset ext3_reserve_window_node rsv_window
$7 = (struct ext3_reserve_window *) 0x14
(gdb) offset ext3_reserve_window _rsv_end
$8 = (ext3_fsblk_t *) 0x4
-aneesh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel Oops in ext3 code
> BUG: unable to handle kernel paging request at virtual address 104b
> printing eip:
> c0195bd3
> *pde =
> Oops: [#1]
> PREEMPT SMP
> Modules linked in: vboxdrv binfmt_misc fuse coretemp hwmon gspca videodev
> v4l2_common v4l1_compat iwl3945 mac80211 tifm_7xx1 tifm_core joydev irda
> crc_ccitt 8250_pnp 8250 serial_core firewire_ohci firewire_core crc_itu_t
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00010206 (2.6.23-rc6 #1)
> EIP is at ext3_discard_reservation+0x18/0x4d
> eax: dff23800 ebx: 1033 ecx: dfc15ec0 edx:
> esi: c0007c44 edi: 1033 ebp: dfc2bef4 esp: dfc2beac
> ds: 007b es: 007b fs: 00d8 gs: ss: 0068
> Process kswapd0 (pid: 261, ti=dfc2a000 task=dfcac570 task.ti=dfc2a000)
> Stack: c0007ba4 c0007c44 1033 c019ec51 c0007c44 c0007d8c 002c
> c0171b1b
> 002c c0007c44 c0007c4c c0171da2 c050880c 0080
> 0080
> c0171fb8 0080 c0007e48 df9e3910 7404 c03f5634 0080
> 00d0
> Call Trace:
> [] ext3_clear_inode+0x5d/0x76
> [] clear_inode+0x6b/0xb9
> [] dispose_list+0x48/0xc9
> [] shrink_icache_memory+0x195/0x1bd
> [] shrink_slab+0xe2/0x159
> [] kswapd+0x2d3/0x431
> [] autoremove_wake_function+0x0/0x33
> [] kswapd+0x0/0x431
> [] kthread+0x38/0x5d
> [] kthread+0x0/0x5d
> [] kernel_thread_helper+0x7/0x10
> ===
> Code: 83 f8 01 19 c0 f7 d0 83 e0 08 89 42 0c 89 56 b4 5b 5e c3 57 56 89 c6
> 53 8b 58 b4 8b 80 a4 00 00 00 85 db 8b 80 78 01 00 00 74 30 <83> 7b 18 00 74
> 2a 8d b8 00 03 00 00 89 f8 e8 b8 ca 1a 00 83 7b
> EIP: [] ext3_discard_reservation+0x18/0x4d SS:ESP 0068:dfc2beac
>
>
On Fri, 2007-09-28 at 17:00 +0200, Norbert Preining wrote:
> On Fr, 28 Sep 2007, Badari Pulavarty wrote:
> > objdump -DlS balloc.o
>
> Here it is
>
Thanks
Looks like kernel oops at 1753(173b+0x18):
173b :
ext3_discard_reservation():
173b: 57 push %edi
173c: 56 push %esi
173d: 89 c6 mov%eax,%esi
173f: 53 push %ebx
1740: 8b 58 b4mov-0x4c(%eax),%ebx
1743: 8b 80 a4 00 00 00 mov0xa4(%eax),%eax
1749: 85 db test %ebx,%ebx
174b: 8b 80 78 01 00 00 mov0x178(%eax),%eax
1751: 74 30 je 1783
1753: 83 7b 18 00 cmpl $0x0,0x18(%ebx)
==> Kernel oops here, ebx=1033, match bad
page location 104b(=1033+0x18)
1757: 74 2a je 1783
1759: 8d b8 00 03 00 00 lea0x300(%eax),%edi
175f: 89 f8 mov%edi,%eax
1761: e8 fc ff ff ff call 1762
1766: 83 7b 18 00 cmpl $0x0,0x18(%ebx)
176a: 74 0d je 1779
176c: 8b 86 a4 00 00 00 mov0xa4(%esi),%eax
1772: 89 da mov%ebx,%edx
1774: e8 dc eb ff ff call 355
1779: 89 f8 mov%edi,%eax
177b: 5b pop%ebx
177c: 5e pop%esi
177d: 5f pop%edi
177e: e9 fc ff ff ff jmp177f
1783: 5b pop%ebx
1784: 5e pop%esi
1785: 5f pop%edi
1786: c3 ret
And trying to matching to the code:
void ext3_discard_reservation(struct inode *inode)
{
struct ext3_inode_info *ei = EXT3_I(inode);
struct ext3_block_alloc_info *block_i = ei->i_block_alloc_info;
struct ext3_reserve_window_node *rsv;
spinlock_t *rsv_lock = _SB(inode->i_sb)->s_rsv_window_lock;
if (!block_i)
return;
rsv = _i->rsv_window_node;
if (!rsv_is_empty(>rsv_window)) {
=> kernel oops here
spin_lock(rsv_lock);
if (!rsv_is_empty(>rsv_window))
rsv_window_remove(inode->i_sb, rsv);
spin_unlock(rsv_lock);
}
}
It seems ebx points to block_i(i_block_alloc_info), and that is bad
memory location, so that leads to bad paging request when try to get the
rsv_window structure.
But it confused me why the rsv_window offset is 0x18 to
i_block_alloc_info, it should be 0x14(20 bytes)...Are you running a
vanilla 2.6.23-rc6?
No clue how i_block_alloc_info pointing to a bad location for now.
ext3_alloc_inode() clearly init this field to NULL, and
ext3_clear_inode() clearly set this field to NULL. So during the
lifecycle of the inode, i_block_alloc_info should point to a valid
address or being NULL.
And the stack trace indicating the oops happened when pushing the inode
from the
Re: kernel Oops in ext3 code
On Fri, 2007-09-28 at 06:54 +0200, Norbert Preining wrote: > Hi Mingming, > > On Do, 27 Sep 2007, Mingming Cao wrote: > > Could you please sent the objdump of the ext4_discard_reservation > > function? It doesn't match what I see here. > > I assume you meant ext3_ I made > objdump -x -D -s super.o > (the only place where I found this function in the source code). If you > want something else, let me know, but a bit more specific. Can I do the > objdump directly from the kernel image file? > objdump -DlS balloc.o would give us ext3_discard_reservation() Thanks, Badari - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel Oops in ext3 code
On Fri, 2007-09-28 at 06:54 +0200, Norbert Preining wrote: Hi Mingming, On Do, 27 Sep 2007, Mingming Cao wrote: Could you please sent the objdump of the ext4_discard_reservation function? It doesn't match what I see here. I assume you meant ext3_ I made objdump -x -D -s super.o (the only place where I found this function in the source code). If you want something else, let me know, but a bit more specific. Can I do the objdump directly from the kernel image file? objdump -DlS balloc.o would give us ext3_discard_reservation() Thanks, Badari - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel Oops in ext3 code
BUG: unable to handle kernel paging request at virtual address 104b
printing eip:
c0195bd3
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: vboxdrv binfmt_misc fuse coretemp hwmon gspca videodev
v4l2_common v4l1_compat iwl3945 mac80211 tifm_7xx1 tifm_core joydev irda
crc_ccitt 8250_pnp 8250 serial_core firewire_ohci firewire_core crc_itu_t
CPU:0
EIP:0060:[c0195bd3]Not tainted VLI
EFLAGS: 00010206 (2.6.23-rc6 #1)
EIP is at ext3_discard_reservation+0x18/0x4d
eax: dff23800 ebx: 1033 ecx: dfc15ec0 edx:
esi: c0007c44 edi: 1033 ebp: dfc2bef4 esp: dfc2beac
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process kswapd0 (pid: 261, ti=dfc2a000 task=dfcac570 task.ti=dfc2a000)
Stack: c0007ba4 c0007c44 1033 c019ec51 c0007c44 c0007d8c 002c
c0171b1b
002c c0007c44 c0007c4c c0171da2 c050880c 0080
0080
c0171fb8 0080 c0007e48 df9e3910 7404 c03f5634 0080
00d0
Call Trace:
[c019ec51] ext3_clear_inode+0x5d/0x76
[c0171b1b] clear_inode+0x6b/0xb9
[c0171da2] dispose_list+0x48/0xc9
[c0171fb8] shrink_icache_memory+0x195/0x1bd
[c014f5ec] shrink_slab+0xe2/0x159
[c014f9a0] kswapd+0x2d3/0x431
[c0132520] autoremove_wake_function+0x0/0x33
[c014f6cd] kswapd+0x0/0x431
[c0132453] kthread+0x38/0x5d
[c013241b] kthread+0x0/0x5d
[c0104b73] kernel_thread_helper+0x7/0x10
===
Code: 83 f8 01 19 c0 f7 d0 83 e0 08 89 42 0c 89 56 b4 5b 5e c3 57 56 89 c6
53 8b 58 b4 8b 80 a4 00 00 00 85 db 8b 80 78 01 00 00 74 30 83 7b 18 00 74
2a 8d b8 00 03 00 00 89 f8 e8 b8 ca 1a 00 83 7b
EIP: [c0195bd3] ext3_discard_reservation+0x18/0x4d SS:ESP 0068:dfc2beac
On Fri, 2007-09-28 at 17:00 +0200, Norbert Preining wrote:
On Fr, 28 Sep 2007, Badari Pulavarty wrote:
objdump -DlS balloc.o
Here it is
Thanks
Looks like kernel oops at 1753(173b+0x18):
173b ext3_discard_reservation:
ext3_discard_reservation():
173b: 57 push %edi
173c: 56 push %esi
173d: 89 c6 mov%eax,%esi
173f: 53 push %ebx
1740: 8b 58 b4mov-0x4c(%eax),%ebx
1743: 8b 80 a4 00 00 00 mov0xa4(%eax),%eax
1749: 85 db test %ebx,%ebx
174b: 8b 80 78 01 00 00 mov0x178(%eax),%eax
1751: 74 30 je 1783
ext3_discard_reservation+0x48
1753: 83 7b 18 00 cmpl $0x0,0x18(%ebx)
== Kernel oops here, ebx=1033, match bad
page location 104b(=1033+0x18)
1757: 74 2a je 1783
ext3_discard_reservation+0x48
1759: 8d b8 00 03 00 00 lea0x300(%eax),%edi
175f: 89 f8 mov%edi,%eax
1761: e8 fc ff ff ff call 1762
ext3_discard_reservation+0x27
1766: 83 7b 18 00 cmpl $0x0,0x18(%ebx)
176a: 74 0d je 1779
ext3_discard_reservation+0x3e
176c: 8b 86 a4 00 00 00 mov0xa4(%esi),%eax
1772: 89 da mov%ebx,%edx
1774: e8 dc eb ff ff call 355 rsv_window_remove
1779: 89 f8 mov%edi,%eax
177b: 5b pop%ebx
177c: 5e pop%esi
177d: 5f pop%edi
177e: e9 fc ff ff ff jmp177f
ext3_discard_reservation+0x44
1783: 5b pop%ebx
1784: 5e pop%esi
1785: 5f pop%edi
1786: c3 ret
And trying to matching to the code:
void ext3_discard_reservation(struct inode *inode)
{
struct ext3_inode_info *ei = EXT3_I(inode);
struct ext3_block_alloc_info *block_i = ei-i_block_alloc_info;
struct ext3_reserve_window_node *rsv;
spinlock_t *rsv_lock = EXT3_SB(inode-i_sb)-s_rsv_window_lock;
if (!block_i)
return;
rsv = block_i-rsv_window_node;
if (!rsv_is_empty(rsv-rsv_window)) {
= kernel oops here
spin_lock(rsv_lock);
if (!rsv_is_empty(rsv-rsv_window))
rsv_window_remove(inode-i_sb, rsv);
spin_unlock(rsv_lock);
}
}
It seems ebx points to block_i(i_block_alloc_info), and that is bad
memory location, so that leads to bad paging request when try to get the
rsv_window structure.
But it confused me why the rsv_window offset is 0x18 to
i_block_alloc_info, it should be 0x14(20 bytes)...Are you running a
vanilla 2.6.23-rc6?
No clue how i_block_alloc_info pointing to a bad location for now.
ext3_alloc_inode() clearly init this field to
Re: kernel Oops in ext3 code
Mingming Cao wrote:
BUG: unable to handle kernel paging request at virtual address 104b
printing eip:
c0195bd3
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: vboxdrv binfmt_misc fuse coretemp hwmon gspca videodev v4l2_common v4l1_compat iwl3945 mac80211 tifm_7xx1 tifm_core joydev irda crc_ccitt 8250_pnp 8250 serial_core firewire_ohci firewire_core crc_itu_t
CPU:0
EIP:0060:[c0195bd3]Not tainted VLI
EFLAGS: 00010206 (2.6.23-rc6 #1)
EIP is at ext3_discard_reservation+0x18/0x4d
eax: dff23800 ebx: 1033 ecx: dfc15ec0 edx:
esi: c0007c44 edi: 1033 ebp: dfc2bef4 esp: dfc2beac
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process kswapd0 (pid: 261, ti=dfc2a000 task=dfcac570 task.ti=dfc2a000)
Stack: c0007ba4 c0007c44 1033 c019ec51 c0007c44 c0007d8c 002c c0171b1b
002c c0007c44 c0007c4c c0171da2 c050880c 0080 0080
c0171fb8 0080 c0007e48 df9e3910 7404 c03f5634 0080 00d0
Call Trace:
[c019ec51] ext3_clear_inode+0x5d/0x76
[c0171b1b] clear_inode+0x6b/0xb9
[c0171da2] dispose_list+0x48/0xc9
[c0171fb8] shrink_icache_memory+0x195/0x1bd
[c014f5ec] shrink_slab+0xe2/0x159
[c014f9a0] kswapd+0x2d3/0x431
[c0132520] autoremove_wake_function+0x0/0x33
[c014f6cd] kswapd+0x0/0x431
[c0132453] kthread+0x38/0x5d
[c013241b] kthread+0x0/0x5d
[c0104b73] kernel_thread_helper+0x7/0x10
===
Code: 83 f8 01 19 c0 f7 d0 83 e0 08 89 42 0c 89 56 b4 5b 5e c3 57 56 89 c6 53 8b 58 b4 8b 80 a4 00 00 00 85 db 8b 80 78 01 00 00 74 30 83 7b 18 00 74 2a 8d b8 00 03 00 00 89 f8 e8 b8 ca 1a 00 83 7b
EIP: [c0195bd3] ext3_discard_reservation+0x18/0x4d SS:ESP 0068:dfc2beac
On Fri, 2007-09-28 at 17:00 +0200, Norbert Preining wrote:
On Fr, 28 Sep 2007, Badari Pulavarty wrote:
objdump -DlS balloc.o
Here it is
Thanks
Looks like kernel oops at 1753(173b+0x18):
173b ext3_discard_reservation:
ext3_discard_reservation():
173b: 57 push %edi
173c: 56 push %esi
173d: 89 c6 mov%eax,%esi
173f: 53 push %ebx
1740: 8b 58 b4mov-0x4c(%eax),%ebx
1743: 8b 80 a4 00 00 00 mov0xa4(%eax),%eax
1749: 85 db test %ebx,%ebx
174b: 8b 80 78 01 00 00 mov0x178(%eax),%eax
1751: 74 30 je 1783
ext3_discard_reservation+0x48
1753: 83 7b 18 00 cmpl $0x0,0x18(%ebx)
== Kernel oops here, ebx=1033, match bad
page location 104b(=1033+0x18)
1757: 74 2a je 1783
ext3_discard_reservation+0x48
1759: 8d b8 00 03 00 00 lea0x300(%eax),%edi
175f: 89 f8 mov%edi,%eax
1761: e8 fc ff ff ff call 1762
ext3_discard_reservation+0x27
1766: 83 7b 18 00 cmpl $0x0,0x18(%ebx)
176a: 74 0d je 1779
ext3_discard_reservation+0x3e
176c: 8b 86 a4 00 00 00 mov0xa4(%esi),%eax
1772: 89 da mov%ebx,%edx
1774: e8 dc eb ff ff call 355 rsv_window_remove
1779: 89 f8 mov%edi,%eax
177b: 5b pop%ebx
177c: 5e pop%esi
177d: 5f pop%edi
177e: e9 fc ff ff ff jmp177f
ext3_discard_reservation+0x44
1783: 5b pop%ebx
1784: 5e pop%esi
1785: 5f pop%edi
1786: c3 ret
And trying to matching to the code:
void ext3_discard_reservation(struct inode *inode)
{
struct ext3_inode_info *ei = EXT3_I(inode);
struct ext3_block_alloc_info *block_i = ei-i_block_alloc_info;
struct ext3_reserve_window_node *rsv;
spinlock_t *rsv_lock = EXT3_SB(inode-i_sb)-s_rsv_window_lock;
if (!block_i)
return;
rsv = block_i-rsv_window_node;
if (!rsv_is_empty(rsv-rsv_window)) {
= kernel oops here
spin_lock(rsv_lock);
if (!rsv_is_empty(rsv-rsv_window))
rsv_window_remove(inode-i_sb, rsv);
spin_unlock(rsv_lock);
}
}
It seems ebx points to block_i(i_block_alloc_info), and that is bad
memory location, so that leads to bad paging request when try to get the
rsv_window structure.
But it confused me why the rsv_window offset is 0x18 to
i_block_alloc_info, it should be 0x14(20 bytes)...Are you running a
vanilla 2.6.23-rc6?
That is 0x14 + 4
(gdb) offset ext3_reserve_window_node rsv_window
$7 = (struct ext3_reserve_window *) 0x14
(gdb) offset
Re: kernel Oops in ext3 code
Hi all, On Fr, 28 Sep 2007, Mingming Cao wrote: i_block_alloc_info, it should be 0x14(20 bytes)...Are you running a vanilla 2.6.23-rc6? Well yes, I add one patch for reducing the usb device resetting time, but this was definitely not the problem, no usb device was attached. from the cache, so racing is not a issue there. Possible random memory corruption? Could be could be. I would say since it is such a strange thing and nobody has an idea we leave it for now, random memory corruption sounds nice. If it occurs I can come back. Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Vienna University of Technology Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- in the space-time continuum.' is he? Is he?' --- Arthur failing in his first lesson of galactic physics --- in four years. --- Douglas Adams, The Hitchhikers Guide to the Galaxy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel Oops in ext3 code
Hi, Could you please sent the objdump of the ext4_discard_reservation function? It doesn't match what I see here. Thanks, Mingming On Thu, 2007-09-27 at 12:31 +0200, [EMAIL PROTECTED] wrote: > Hi all! > > (Please Cc) > > kernel 2.6.23-rc6 > Debian/sid > > kernel ooops: > > BUG: unable to handle kernel paging request at virtual address 104b > printing eip: > c0195bd3 > *pde = > Oops: [#1] > PREEMPT SMP > Modules linked in: vboxdrv binfmt_misc fuse coretemp hwmon gspca videodev > v4l2_common v4l1_compat iwl3945 mac80211 tifm_7xx1 tifm_core joydev irda > crc_ccitt 8250_pnp 8250 serial_core firewire_ohci firewire_core crc_itu_t > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010206 (2.6.23-rc6 #1) > EIP is at ext3_discard_reservation+0x18/0x4d > eax: dff23800 ebx: 1033 ecx: dfc15ec0 edx: > esi: c0007c44 edi: 1033 ebp: dfc2bef4 esp: dfc2beac > ds: 007b es: 007b fs: 00d8 gs: ss: 0068 > Process kswapd0 (pid: 261, ti=dfc2a000 task=dfcac570 task.ti=dfc2a000) > Stack: c0007ba4 c0007c44 1033 c019ec51 c0007c44 c0007d8c 002c > c0171b1b > 002c c0007c44 c0007c4c c0171da2 c050880c 0080 > 0080 > c0171fb8 0080 c0007e48 df9e3910 7404 c03f5634 0080 > 00d0 > Call Trace: > [] ext3_clear_inode+0x5d/0x76 > [] clear_inode+0x6b/0xb9 > [] dispose_list+0x48/0xc9 > [] shrink_icache_memory+0x195/0x1bd > [] shrink_slab+0xe2/0x159 > [] kswapd+0x2d3/0x431 > [] autoremove_wake_function+0x0/0x33 > [] kswapd+0x0/0x431 > [] kthread+0x38/0x5d > [] kthread+0x0/0x5d > [] kernel_thread_helper+0x7/0x10 > === > Code: 83 f8 01 19 c0 f7 d0 83 e0 08 89 42 0c 89 56 b4 5b 5e c3 57 56 89 c6 > 53 8b 58 b4 8b 80 a4 00 00 00 85 db 8b 80 78 01 00 00 74 30 <83> 7b 18 00 74 > 2a 8d b8 00 03 00 00 89 f8 e8 b8 ca 1a 00 83 7b > EIP: [] ext3_discard_reservation+0x18/0x4d SS:ESP 0068:dfc2beac > > > Sysrq did work, so the oops was saved. Good. > > Any ideas? > > Best wishes > > Norbert > > --- > Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of > Technology > Debian Developer <[EMAIL PROTECTED]> Debian TeX Group > gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 > B094 > --- > As he came into the light they could see his black and > gold uniform on which the buttons were so highly polished > that they shone with an intensity that would have made an > approaching motorist flash his lights in annoyance. > --- Douglas Adams, The Hitchhikers Guide to the Galaxy > - > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel Oops in ext3 code
On Thursday, 27 September 2007 15:13, Norbert Preining wrote: > On Do, 27 Sep 2007, Rafael J. Wysocki wrote: > > Does it happen with 2.6.22? > > Hard to say. It didn't happen as long as I used -22, but it didn't > happen for a long time (since I run -rc6), and it is not reproducible. > > What I did at this time is a: > tar -cjf foo.tar.bz2 a-big-dir-with-more-than-800Mb > I retried it again with -rc6 and it succeeded. So hard to say. > > Best wishes Thanks. Let's assume it's not a regression from 2.6.22, then. ;-) Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel Oops in ext3 code
On Do, 27 Sep 2007, Rafael J. Wysocki wrote: > Does it happen with 2.6.22? Hard to say. It didn't happen as long as I used -22, but it didn't happen for a long time (since I run -rc6), and it is not reproducible. What I did at this time is a: tar -cjf foo.tar.bz2 a-big-dir-with-more-than-800Mb I retried it again with -rc6 and it succeeded. So hard to say. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- ALDCLUNE (n.) One who collects ten-year-old telephone directories. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel Oops in ext3 code
On Thursday, 27 September 2007 12:31, Norbert Preining wrote: > Hi all! > > (Please Cc) > > kernel 2.6.23-rc6 > Debian/sid Does it happen with 2.6.22? > kernel ooops: > > BUG: unable to handle kernel paging request at virtual address 104b > printing eip: > c0195bd3 > *pde = > Oops: [#1] > PREEMPT SMP > Modules linked in: vboxdrv binfmt_misc fuse coretemp hwmon gspca videodev > v4l2_common v4l1_compat iwl3945 mac80211 tifm_7xx1 tifm_core joydev irda > crc_ccitt 8250_pnp 8250 serial_core firewire_ohci firewire_core crc_itu_t > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010206 (2.6.23-rc6 #1) > EIP is at ext3_discard_reservation+0x18/0x4d > eax: dff23800 ebx: 1033 ecx: dfc15ec0 edx: > esi: c0007c44 edi: 1033 ebp: dfc2bef4 esp: dfc2beac > ds: 007b es: 007b fs: 00d8 gs: ss: 0068 > Process kswapd0 (pid: 261, ti=dfc2a000 task=dfcac570 task.ti=dfc2a000) > Stack: c0007ba4 c0007c44 1033 c019ec51 c0007c44 c0007d8c 002c > c0171b1b > 002c c0007c44 c0007c4c c0171da2 c050880c 0080 > 0080 > c0171fb8 0080 c0007e48 df9e3910 7404 c03f5634 0080 > 00d0 > Call Trace: > [] ext3_clear_inode+0x5d/0x76 > [] clear_inode+0x6b/0xb9 > [] dispose_list+0x48/0xc9 > [] shrink_icache_memory+0x195/0x1bd > [] shrink_slab+0xe2/0x159 > [] kswapd+0x2d3/0x431 > [] autoremove_wake_function+0x0/0x33 > [] kswapd+0x0/0x431 > [] kthread+0x38/0x5d > [] kthread+0x0/0x5d > [] kernel_thread_helper+0x7/0x10 > === > Code: 83 f8 01 19 c0 f7 d0 83 e0 08 89 42 0c 89 56 b4 5b 5e c3 57 56 89 c6 > 53 8b 58 b4 8b 80 a4 00 00 00 85 db 8b 80 78 01 00 00 74 30 <83> 7b 18 00 74 > 2a 8d b8 00 03 00 00 89 f8 e8 b8 ca 1a 00 83 7b > EIP: [] ext3_discard_reservation+0x18/0x4d SS:ESP 0068:dfc2beac Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel Oops in ext3 code
Hi all! (Please Cc) kernel 2.6.23-rc6 Debian/sid kernel ooops: BUG: unable to handle kernel paging request at virtual address 104b printing eip: c0195bd3 *pde = Oops: [#1] PREEMPT SMP Modules linked in: vboxdrv binfmt_misc fuse coretemp hwmon gspca videodev v4l2_common v4l1_compat iwl3945 mac80211 tifm_7xx1 tifm_core joydev irda crc_ccitt 8250_pnp 8250 serial_core firewire_ohci firewire_core crc_itu_t CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010206 (2.6.23-rc6 #1) EIP is at ext3_discard_reservation+0x18/0x4d eax: dff23800 ebx: 1033 ecx: dfc15ec0 edx: esi: c0007c44 edi: 1033 ebp: dfc2bef4 esp: dfc2beac ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Process kswapd0 (pid: 261, ti=dfc2a000 task=dfcac570 task.ti=dfc2a000) Stack: c0007ba4 c0007c44 1033 c019ec51 c0007c44 c0007d8c 002c c0171b1b 002c c0007c44 c0007c4c c0171da2 c050880c 0080 0080 c0171fb8 0080 c0007e48 df9e3910 7404 c03f5634 0080 00d0 Call Trace: [] ext3_clear_inode+0x5d/0x76 [] clear_inode+0x6b/0xb9 [] dispose_list+0x48/0xc9 [] shrink_icache_memory+0x195/0x1bd [] shrink_slab+0xe2/0x159 [] kswapd+0x2d3/0x431 [] autoremove_wake_function+0x0/0x33 [] kswapd+0x0/0x431 [] kthread+0x38/0x5d [] kthread+0x0/0x5d [] kernel_thread_helper+0x7/0x10 === Code: 83 f8 01 19 c0 f7 d0 83 e0 08 89 42 0c 89 56 b4 5b 5e c3 57 56 89 c6 53 8b 58 b4 8b 80 a4 00 00 00 85 db 8b 80 78 01 00 00 74 30 <83> 7b 18 00 74 2a 8d b8 00 03 00 00 89 f8 e8 b8 ca 1a 00 83 7b EIP: [] ext3_discard_reservation+0x18/0x4d SS:ESP 0068:dfc2beac Sysrq did work, so the oops was saved. Good. Any ideas? Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- As he came into the light they could see his black and gold uniform on which the buttons were so highly polished that they shone with an intensity that would have made an approaching motorist flash his lights in annoyance. --- Douglas Adams, The Hitchhikers Guide to the Galaxy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel Oops in ext3 code
Hi all! (Please Cc) kernel 2.6.23-rc6 Debian/sid kernel ooops: BUG: unable to handle kernel paging request at virtual address 104b printing eip: c0195bd3 *pde = Oops: [#1] PREEMPT SMP Modules linked in: vboxdrv binfmt_misc fuse coretemp hwmon gspca videodev v4l2_common v4l1_compat iwl3945 mac80211 tifm_7xx1 tifm_core joydev irda crc_ccitt 8250_pnp 8250 serial_core firewire_ohci firewire_core crc_itu_t CPU:0 EIP:0060:[c0195bd3]Not tainted VLI EFLAGS: 00010206 (2.6.23-rc6 #1) EIP is at ext3_discard_reservation+0x18/0x4d eax: dff23800 ebx: 1033 ecx: dfc15ec0 edx: esi: c0007c44 edi: 1033 ebp: dfc2bef4 esp: dfc2beac ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Process kswapd0 (pid: 261, ti=dfc2a000 task=dfcac570 task.ti=dfc2a000) Stack: c0007ba4 c0007c44 1033 c019ec51 c0007c44 c0007d8c 002c c0171b1b 002c c0007c44 c0007c4c c0171da2 c050880c 0080 0080 c0171fb8 0080 c0007e48 df9e3910 7404 c03f5634 0080 00d0 Call Trace: [c019ec51] ext3_clear_inode+0x5d/0x76 [c0171b1b] clear_inode+0x6b/0xb9 [c0171da2] dispose_list+0x48/0xc9 [c0171fb8] shrink_icache_memory+0x195/0x1bd [c014f5ec] shrink_slab+0xe2/0x159 [c014f9a0] kswapd+0x2d3/0x431 [c0132520] autoremove_wake_function+0x0/0x33 [c014f6cd] kswapd+0x0/0x431 [c0132453] kthread+0x38/0x5d [c013241b] kthread+0x0/0x5d [c0104b73] kernel_thread_helper+0x7/0x10 === Code: 83 f8 01 19 c0 f7 d0 83 e0 08 89 42 0c 89 56 b4 5b 5e c3 57 56 89 c6 53 8b 58 b4 8b 80 a4 00 00 00 85 db 8b 80 78 01 00 00 74 30 83 7b 18 00 74 2a 8d b8 00 03 00 00 89 f8 e8 b8 ca 1a 00 83 7b EIP: [c0195bd3] ext3_discard_reservation+0x18/0x4d SS:ESP 0068:dfc2beac Sysrq did work, so the oops was saved. Good. Any ideas? Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Vienna University of Technology Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- As he came into the light they could see his black and gold uniform on which the buttons were so highly polished that they shone with an intensity that would have made an approaching motorist flash his lights in annoyance. --- Douglas Adams, The Hitchhikers Guide to the Galaxy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel Oops in ext3 code
On Thursday, 27 September 2007 12:31, Norbert Preining wrote: Hi all! (Please Cc) kernel 2.6.23-rc6 Debian/sid Does it happen with 2.6.22? kernel ooops: BUG: unable to handle kernel paging request at virtual address 104b printing eip: c0195bd3 *pde = Oops: [#1] PREEMPT SMP Modules linked in: vboxdrv binfmt_misc fuse coretemp hwmon gspca videodev v4l2_common v4l1_compat iwl3945 mac80211 tifm_7xx1 tifm_core joydev irda crc_ccitt 8250_pnp 8250 serial_core firewire_ohci firewire_core crc_itu_t CPU:0 EIP:0060:[c0195bd3]Not tainted VLI EFLAGS: 00010206 (2.6.23-rc6 #1) EIP is at ext3_discard_reservation+0x18/0x4d eax: dff23800 ebx: 1033 ecx: dfc15ec0 edx: esi: c0007c44 edi: 1033 ebp: dfc2bef4 esp: dfc2beac ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Process kswapd0 (pid: 261, ti=dfc2a000 task=dfcac570 task.ti=dfc2a000) Stack: c0007ba4 c0007c44 1033 c019ec51 c0007c44 c0007d8c 002c c0171b1b 002c c0007c44 c0007c4c c0171da2 c050880c 0080 0080 c0171fb8 0080 c0007e48 df9e3910 7404 c03f5634 0080 00d0 Call Trace: [c019ec51] ext3_clear_inode+0x5d/0x76 [c0171b1b] clear_inode+0x6b/0xb9 [c0171da2] dispose_list+0x48/0xc9 [c0171fb8] shrink_icache_memory+0x195/0x1bd [c014f5ec] shrink_slab+0xe2/0x159 [c014f9a0] kswapd+0x2d3/0x431 [c0132520] autoremove_wake_function+0x0/0x33 [c014f6cd] kswapd+0x0/0x431 [c0132453] kthread+0x38/0x5d [c013241b] kthread+0x0/0x5d [c0104b73] kernel_thread_helper+0x7/0x10 === Code: 83 f8 01 19 c0 f7 d0 83 e0 08 89 42 0c 89 56 b4 5b 5e c3 57 56 89 c6 53 8b 58 b4 8b 80 a4 00 00 00 85 db 8b 80 78 01 00 00 74 30 83 7b 18 00 74 2a 8d b8 00 03 00 00 89 f8 e8 b8 ca 1a 00 83 7b EIP: [c0195bd3] ext3_discard_reservation+0x18/0x4d SS:ESP 0068:dfc2beac Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel Oops in ext3 code
On Do, 27 Sep 2007, Rafael J. Wysocki wrote: Does it happen with 2.6.22? Hard to say. It didn't happen as long as I used -22, but it didn't happen for a long time (since I run -rc6), and it is not reproducible. What I did at this time is a: tar -cjf foo.tar.bz2 a-big-dir-with-more-than-800Mb I retried it again with -rc6 and it succeeded. So hard to say. Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Vienna University of Technology Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- ALDCLUNE (n.) One who collects ten-year-old telephone directories. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel Oops in ext3 code
On Thursday, 27 September 2007 15:13, Norbert Preining wrote: On Do, 27 Sep 2007, Rafael J. Wysocki wrote: Does it happen with 2.6.22? Hard to say. It didn't happen as long as I used -22, but it didn't happen for a long time (since I run -rc6), and it is not reproducible. What I did at this time is a: tar -cjf foo.tar.bz2 a-big-dir-with-more-than-800Mb I retried it again with -rc6 and it succeeded. So hard to say. Best wishes Thanks. Let's assume it's not a regression from 2.6.22, then. ;-) Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel Oops in ext3 code
Hi, Could you please sent the objdump of the ext4_discard_reservation function? It doesn't match what I see here. Thanks, Mingming On Thu, 2007-09-27 at 12:31 +0200, [EMAIL PROTECTED] wrote: Hi all! (Please Cc) kernel 2.6.23-rc6 Debian/sid kernel ooops: BUG: unable to handle kernel paging request at virtual address 104b printing eip: c0195bd3 *pde = Oops: [#1] PREEMPT SMP Modules linked in: vboxdrv binfmt_misc fuse coretemp hwmon gspca videodev v4l2_common v4l1_compat iwl3945 mac80211 tifm_7xx1 tifm_core joydev irda crc_ccitt 8250_pnp 8250 serial_core firewire_ohci firewire_core crc_itu_t CPU:0 EIP:0060:[c0195bd3]Not tainted VLI EFLAGS: 00010206 (2.6.23-rc6 #1) EIP is at ext3_discard_reservation+0x18/0x4d eax: dff23800 ebx: 1033 ecx: dfc15ec0 edx: esi: c0007c44 edi: 1033 ebp: dfc2bef4 esp: dfc2beac ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Process kswapd0 (pid: 261, ti=dfc2a000 task=dfcac570 task.ti=dfc2a000) Stack: c0007ba4 c0007c44 1033 c019ec51 c0007c44 c0007d8c 002c c0171b1b 002c c0007c44 c0007c4c c0171da2 c050880c 0080 0080 c0171fb8 0080 c0007e48 df9e3910 7404 c03f5634 0080 00d0 Call Trace: [c019ec51] ext3_clear_inode+0x5d/0x76 [c0171b1b] clear_inode+0x6b/0xb9 [c0171da2] dispose_list+0x48/0xc9 [c0171fb8] shrink_icache_memory+0x195/0x1bd [c014f5ec] shrink_slab+0xe2/0x159 [c014f9a0] kswapd+0x2d3/0x431 [c0132520] autoremove_wake_function+0x0/0x33 [c014f6cd] kswapd+0x0/0x431 [c0132453] kthread+0x38/0x5d [c013241b] kthread+0x0/0x5d [c0104b73] kernel_thread_helper+0x7/0x10 === Code: 83 f8 01 19 c0 f7 d0 83 e0 08 89 42 0c 89 56 b4 5b 5e c3 57 56 89 c6 53 8b 58 b4 8b 80 a4 00 00 00 85 db 8b 80 78 01 00 00 74 30 83 7b 18 00 74 2a 8d b8 00 03 00 00 89 f8 e8 b8 ca 1a 00 83 7b EIP: [c0195bd3] ext3_discard_reservation+0x18/0x4d SS:ESP 0068:dfc2beac Sysrq did work, so the oops was saved. Good. Any ideas? Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Vienna University of Technology Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- As he came into the light they could see his black and gold uniform on which the buttons were so highly polished that they shone with an intensity that would have made an approaching motorist flash his lights in annoyance. --- Douglas Adams, The Hitchhikers Guide to the Galaxy - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
