Please CC me I'm not on the list
Hi, I get the following oops, usually after booting. I've done things
like run memtest86 and changed the scsi cable.
Thanks.
ksymoops 2.4.3 on i686 2.4.17. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.17/ (default)
-m /boot/System.map-2.4.17 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file?
cpu: 0, clocks: 1339387, slice: 446462
cpu: 1, clocks: 1339387, slice: 446462
kernel BUG at dcache.c:654!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0144b52>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 0000001c ebx: f5f66210 ecx: c028dd20 edx: 00003757
esi: f5da5280 edi: f5f661e0 ebp: f5f661e0 esp: f7a7df08
ds: 0018 es: 0018 ss: 0018
Process devfsd (pid: 24, stackpage=f7a7d000)
Stack: c02408d3 0000028e f7324b40 f5da5280 f7a869a0 c016a31f f5f661e0 f5da5280
f5f661e0 00000000 f7a7dfa4 f7a87c40 c013be5e f5f661e0 00000000 f7a7df74
c013c6c1 f7a87c40 f7a7df74 00000000 f7a6a000 00000000 f7a7dfa4 00000009
Call Trace: [<c016a31f>] [<c013be5e>] [<c013c6c1>] [<c013c94a>] [<c013ce31>]
[<c013984d>] [<c0132824>] [<c0106dbb>]
Code: 0f 0b 83 c4 08 f0 fe 0d a0 36 2e c0 0f 88 a3 63 0e 00 85 f6
>>EIP; c0144b52 <d_instantiate+22/58> <=====
Trace; c016a31e <devfs_d_revalidate_wait+8a/bc>
Trace; c013be5e <cached_lookup+2e/54>
Trace; c013c6c0 <link_path_walk+5e0/850>
Trace; c013c94a <path_walk+1a/1c>
Trace; c013ce30 <__user_walk+34/50>
Trace; c013984c <sys_stat64+18/70>
Trace; c0132824 <sys_read+bc/c4>
Trace; c0106dba <system_call+32/38>
Code; c0144b52 <d_instantiate+22/58>
00000000 <_EIP>:
Code; c0144b52 <d_instantiate+22/58> <=====
0: 0f 0b ud2a <=====
Code; c0144b54 <d_instantiate+24/58>
2: 83 c4 08 add $0x8,%esp
Code; c0144b56 <d_instantiate+26/58>
5: f0 fe 0d a0 36 2e c0 lock decb 0xc02e36a0
Code; c0144b5e <d_instantiate+2e/58>
c: 0f 88 a3 63 0e 00 js e63b5 <_EIP+0xe63b5> c022af06 <stext_lo
ck+2c22/88ee>
Code; c0144b64 <d_instantiate+34/58>
12: 85 f6 test %esi,%esi
2 warnings issued. Results may not be reliable.
Jason Thomas writes:
> Please CC me I'm not on the list
>
> Hi, I get the following oops, usually after booting. I've done things
> like run memtest86 and changed the scsi cable.
>
> Thanks.
>
> cpu: 0, clocks: 1339387, slice: 446462
> cpu: 1, clocks: 1339387, slice: 446462
> kernel BUG at dcache.c:654!
> invalid operand: 0000
> CPU: 0
> EIP: 0010:[<c0144b52>] Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010286
> eax: 0000001c ebx: f5f66210 ecx: c028dd20 edx: 00003757
> esi: f5da5280 edi: f5f661e0 ebp: f5f661e0 esp: f7a7df08
> ds: 0018 es: 0018 ss: 0018
> Process devfsd (pid: 24, stackpage=f7a7d000)
> Stack: c02408d3 0000028e f7324b40 f5da5280 f7a869a0 c016a31f f5f661e0 f5da5280
> f5f661e0 00000000 f7a7dfa4 f7a87c40 c013be5e f5f661e0 00000000 f7a7df74
> c013c6c1 f7a87c40 f7a7df74 00000000 f7a6a000 00000000 f7a7dfa4 00000009
> Call Trace: [<c016a31f>] [<c013be5e>] [<c013c6c1>] [<c013c94a>] [<c013ce31>]
> [<c013984d>] [<c0132824>] [<c0106dbb>]
> Code: 0f 0b 83 c4 08 f0 fe 0d a0 36 2e c0 0f 88 a3 63 0e 00 85 f6
>
> >>EIP; c0144b52 <d_instantiate+22/58> <=====
> Trace; c016a31e <devfs_d_revalidate_wait+8a/bc>
> Trace; c013be5e <cached_lookup+2e/54>
> Trace; c013c6c0 <link_path_walk+5e0/850>
> Trace; c013c94a <path_walk+1a/1c>
> Trace; c013ce30 <__user_walk+34/50>
> Trace; c013984c <sys_stat64+18/70>
> Trace; c0132824 <sys_read+bc/c4>
> Trace; c0106dba <system_call+32/38>
> Code; c0144b52 <d_instantiate+22/58>
> 00000000 <_EIP>:
> Code; c0144b52 <d_instantiate+22/58> <=====
> 0: 0f 0b ud2a <=====
> Code; c0144b54 <d_instantiate+24/58>
> 2: 83 c4 08 add $0x8,%esp
> Code; c0144b56 <d_instantiate+26/58>
> 5: f0 fe 0d a0 36 2e c0 lock decb 0xc02e36a0
> Code; c0144b5e <d_instantiate+2e/58>
> c: 0f 88 a3 63 0e 00 js e63b5 <_EIP+0xe63b5> c022af06 <stext_lo
> ck+2c22/88ee>
> Code; c0144b64 <d_instantiate+34/58>
> 12: 85 f6 test %esi,%esi
Grab devfs-patch-v199.6 from your local kernel.org mirror site and try
again. If you still have the same problem, send the new ksymoops
output as well as *complete* kernel boot logs.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Okay same thing.
On Thu, Jan 03, 2002 at 12:24:23AM -0700, Richard Gooch wrote:
> Grab devfs-patch-v199.6 from your local kernel.org mirror site and try
> again. If you still have the same problem, send the new ksymoops
> output as well as *complete* kernel boot logs.
they are attached.
Jason Thomas writes:
> Okay same thing.
>
> On Thu, Jan 03, 2002 at 12:24:23AM -0700, Richard Gooch wrote:
> > Grab devfs-patch-v199.6 from your local kernel.org mirror site and try
> > again. If you still have the same problem, send the new ksymoops
> > output as well as *complete* kernel boot logs.
>
> they are attached.
[...]
> LVM version 1.0.1-rc4(ish)(03/10/2001)
Ah! You're using LVM! There are known bugs in LVM which cause memory
corruptions. I told Heinz about this on 16-DEC, but it appears the CVS
tree hasn't been updated yet. So grab the latest CVS tree (which fixes
some bugs) and then apply the appended patch (which fixes more
bugs). You definately need both. The patch should be applied in the
drivers/md directory.
I'm afraid that you will need to manually apply this patch, because
the LVM CVS tree has a pile of #ifdef CONFIG_DEVFS_FS's in it, whereas
the LVM code in the kernel tree (which is what I generated the patch
against) has these #ifdef's stripped.
I've offered to Marcelo to take the current LVM CVS, apply my fixes
and send him a patch. That would avoid this problem coming up again
(and again). I haven't had a response yet. Perhaps he's still
recovering from his holiday. I hope so, because that probably means he
enjoyed himself :-)
Marcelo: will you accept such a patch?
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
--- lvm-fs.c~ Sun Nov 11 11:09:32 2001
+++ lvm-fs.c Sun Dec 16 17:37:32 2001
@@ -30,6 +30,7 @@
* 04/10/2001 - corrected devfs_register() call in lvm_init_fs()
* 11/04/2001 - don't devfs_register("lvm") as user-space always does it
* 10/05/2001 - show more of PV name in /proc/lvm/global
+ * 16/12/2001 - fix devfs unregister order and prevent duplicate unreg (REG)
*
*/
@@ -138,7 +139,7 @@
int i;
devfs_unregister(ch_devfs_handle[vg_ptr->vg_number]);
- devfs_unregister(vg_devfs_handle[vg_ptr->vg_number]);
+ ch_devfs_handle[vg_ptr->vg_number] = NULL;
/* remove lv's */
for(i = 0; i < vg_ptr->lv_max; i++)
@@ -148,6 +149,10 @@
for(i = 0; i < vg_ptr->pv_max; i++)
if(vg_ptr->pv[i]) lvm_fs_remove_pv(vg_ptr, vg_ptr->pv[i]);
+ /* must not remove directory before leaf nodes */
+ devfs_unregister(vg_devfs_handle[vg_ptr->vg_number]);
+ vg_devfs_handle[vg_ptr->vg_number] = NULL;
+
if(vg_ptr->vg_dir_pde) {
remove_proc_entry(LVM_LV_SUBDIR, vg_ptr->vg_dir_pde);
vg_ptr->lv_subdir_pde = NULL;
@@ -189,6 +194,7 @@
void lvm_fs_remove_lv(vg_t *vg_ptr, lv_t *lv) {
devfs_unregister(lv_devfs_handle[MINOR(lv->lv_dev)]);
+ lv_devfs_handle[MINOR(lv->lv_dev)] = NULL;
if(vg_ptr->lv_subdir_pde) {
const char *name = _basename(lv->lv_name);
On Jan 05, 2002 17:47 -0700, Richard Gooch wrote:
> Ah! You're using LVM! There are known bugs in LVM which cause memory
> corruptions. I told Heinz about this on 16-DEC, but it appears the CVS
> tree hasn't been updated yet. So grab the latest CVS tree (which fixes
> some bugs) and then apply the appended patch (which fixes more
> bugs). You definately need both. The patch should be applied in the
> drivers/md directory.
Hmm, my understanding was that the LVM CVS already had this patch
applied, but I could be wrong... In any case, I haven't seen anything
about updating the kernel LVM to match CVS since Alan merged in his
-ac LVM code into 2.4.15 or so.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Andreas Dilger writes:
> On Jan 05, 2002 17:47 -0700, Richard Gooch wrote:
> > Ah! You're using LVM! There are known bugs in LVM which cause memory
> > corruptions. I told Heinz about this on 16-DEC, but it appears the CVS
> > tree hasn't been updated yet. So grab the latest CVS tree (which fixes
> > some bugs) and then apply the appended patch (which fixes more
> > bugs). You definately need both. The patch should be applied in the
> > drivers/md directory.
>
> Hmm, my understanding was that the LVM CVS already had this patch
> applied, but I could be wrong... In any case, I haven't seen
> anything about updating the kernel LVM to match CVS since Alan
> merged in his -ac LVM code into 2.4.15 or so.
When I wrote this message, I had just before downloaded LVM using CVS,
following the instructions at: http://www.sistina.com/products_CVS.htm
AFAIK, that's the most recent version of LVM.
Hm. Andreas: do you have write access?
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Sat, Jan 05, 2002 at 05:47:04PM -0700, Richard Gooch wrote:
> > LVM version 1.0.1-rc4(ish)(03/10/2001)
>
> Ah! You're using LVM! There are known bugs in LVM which cause memory
> corruptions. I told Heinz about this on 16-DEC, but it appears the CVS
> tree hasn't been updated yet. So grab the latest CVS tree (which fixes
> some bugs) and then apply the appended patch (which fixes more
> bugs). You definately need both. The patch should be applied in the
> drivers/md directory.
okay done this and still the same thing oops just after boot. dmesg with
oops and ksymoops stuff attached