Mailing List Archive

[2.3.24, smbfs] Kernel panic: put_cached_page: page count=1
Hi
My apologies if someone has already reported this. I had my x86 single
procesor box lock solid with 2.3.24 when trying to ls a smbfs mounted
directory just now:
I found this in the logs:
Oct 28 11:05:55 flat kernel: Kernel panic: put_cached_page: page count=1
I hope it helps someone track down the problem. More details on request
through direct email to me please.
Thank you!
--Craig
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.3.24, smbfs] Kernel panic: put_cached_page: page count=1 [ In reply to ]
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
---559023410-810309993-941115704=:8761
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 28 Oct 1999 craig@qualica.com wrote:
> Hi
>
> My apologies if someone has already reported this. I had my x86 single
> procesor box lock solid with 2.3.24 when trying to ls a smbfs mounted
> directory just now:
>
> I found this in the logs:
>
> Oct 28 11:05:55 flat kernel: Kernel panic: put_cached_page: page count=1
>
> I hope it helps someone track down the problem. More details on request
> through direct email to me please.
Stack trace would be useful, but in that case methink I know WTF had
happened. Patch attached.
---559023410-810309993-941115704=:8761
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=smbfs-patch-1
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.10.9910280901440.8761@weyl.math.psu.edu>
Content-Description:
Content-Disposition: attachment; filename=smbfs-patch-1
LS0tIGNhY2hlLmMJVGh1IE9jdCAyOCAwMjo1MzowNSAxOTk5DQorKysgY2Fj
aGUuYy5uZXcJVGh1IE9jdCAyOCAwODo1MzowNiAxOTk5DQpAQCAtNDgsMzAg
KzQ4LDM1IEBADQogew0KIAlzdHJ1Y3QgcGFnZSAqIHBhZ2U7DQogCXN0cnVj
dCBwYWdlICoqIGhhc2g7DQotCXVuc2lnbmVkIGxvbmcgbmV3X3BhZ2U7DQor
CXN0cnVjdCBwYWdlICpjYWNoZWRfcGFnZTsNCiANCiAgYWdhaW46DQogCWhh
c2ggPSBwYWdlX2hhc2gobWFwcGluZywgb2Zmc2V0KTsNCiAJcGFnZSA9IF9f
ZmluZF9sb2NrX3BhZ2UobWFwcGluZywgb2Zmc2V0LCBoYXNoKTsNCiAJaWYo
IXBhZ2UgJiYgbmV3KSB7DQotCQkvKiBub3QgaW4gY2FjaGUsIGFsbG9jIGEg
bmV3IHBhZ2UgKi8NCi0JCW5ld19wYWdlID0gcGFnZV9jYWNoZV9hbGxvYygp
Ow0KLQkJaWYgKCFuZXdfcGFnZSkNCi0JCQlyZXR1cm4gMDsNCi0JCWNsZWFy
X3BhZ2UobmV3X3BhZ2UpOwkvKiBzbWIgY29kZSBhc3N1bWVzIHBhZ2VzIGFy
ZSB6ZXJvZWQgKi8NCi0JCXBhZ2UgPSBwYWdlX2NhY2hlX2VudHJ5KG5ld19w
YWdlKTsNCi0JCWlmIChhZGRfdG9fcGFnZV9jYWNoZV91bmlxdWUocGFnZSwg
bWFwcGluZywgb2Zmc2V0LCBoYXNoKSkgew0KKwkJLyogbm90IGluIGNhY2hl
LCBhbGxvYyBhIG5ldyBwYWdlIGlmIHdlIGRpZG4ndCBkbyBpdCB5ZXQgKi8N
CisJCWlmICghY2FjaGVkX3BhZ2UpIHsNCisJCQljYWNoZWRfcGFnZSA9IHBh
Z2VfY2FjaGVfYWxsb2MoKTsNCisJCQlpZiAoIWNhY2hlZF9wYWdlKQ0KKwkJ
CQlyZXR1cm4gMDsNCisJCQkvKiBzbWIgY29kZSBhc3N1bWVzIHBhZ2VzIGFy
ZSB6ZXJvZWQgKi8NCisJCQljbGVhcl9wYWdlKHBhZ2VfYWRkcmVzcyhjYWNo
ZWRfcGFnZSkpOw0KKwkJCWdvdG8gYWdhaW47DQorCQl9DQorCQlwYWdlID0g
Y2FjaGVkX3BhZ2U7DQorCQlpZiAoYWRkX3RvX3BhZ2VfY2FjaGVfdW5pcXVl
KHBhZ2UsIG1hcHBpbmcsIG9mZnNldCwgaGFzaCkpDQogCQkJLyogSG1tLCBh
IHBhZ2UgaGFzIG1hdGVyaWFsaXplZCBpbiB0aGUNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBjYWNoZS4gRmluZS4gR28gYmFjayBhbmQgZ2V0IHRo
YXQgcGFnZQ0KLSAgICAgICAgICAgICAgICAgICAgICAgICAgIGluc3RlYWQg
Li4uIHRocm93aW5nIGF3YXkgdGhpcyBvbmUgZmlyc3QuICovDQotCQkJcHV0
X2NhY2hlZF9wYWdlKCh1bnNpZ25lZCBsb25nKSBwYWdlKTsNCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICBpbnN0ZWFkLi4uICovDQogCQkJZ290byBh
Z2FpbjsNCi0JCX0NCisJCWNhY2hlZF9wYWdlID0gTlVMTDsNCiAJfQ0KKwlp
ZiAoY2FjaGVkX3BhZ2UpDQorCQlwYWdlX2NhY2hlX2ZyZWUoY2FjaGVkX3Bh
Z2UpOw0KIAlpZighcGFnZSkNCiAJCXJldHVybiAwOw0KIAlpZighUGFnZUxv
Y2tlZChwYWdlKSkNCi0JCXByaW50ayhLRVJOX0VSUiAic21iZnMvY2FjaGUu
YzogcGFnZSBpc24ndCBsb2NrZWQhIFRoaXMgY291bGQgYmUgZnVuIC4uLlxu
Iik7DQorCQlCVUcoKTsNCiAJcmV0dXJuIHBhZ2VfYWRkcmVzcyhwYWdlKTsN
CiB9DQogDQo=
---559023410-810309993-941115704=:8761--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.3.24, smbfs] Kernel panic: put_cached_page: page count=1 [ In reply to ]
On Thu, Oct 28, 1999 at 09:01:44AM -0400, Alexander Viro wrote:
>
> On Thu, 28 Oct 1999 craig@qualica.com wrote:
>
> > Hi
> >
> > My apologies if someone has already reported this. I had my x86 single
> > procesor box lock solid with 2.3.24 when trying to ls a smbfs mounted
> > directory just now:
> >
> > I found this in the logs:
> >
> > Oct 28 11:05:55 flat kernel: Kernel panic: put_cached_page: page count=1
> >
> > I hope it helps someone track down the problem. More details on request
> > through direct email to me please.
>
> Stack trace would be useful, but in that case methink I know WTF had
> happened. Patch attached.
Hi
Thanks for the snappy reply!
I had no stack trace in the logs and nothing on the screen as I was in X
at the time and the box froze solid. I have compiled with the patch and got
this:
cache.c:51: warning: `cached_page' might be used uninitialized in this function
I've added a = NULL on that line but that doesn't seem entirely right somehow
but it should trigger the alloc thing further down I think ...
Now I get (no reboot, just a make modules && make modules_install which
should be ok I think. smbfs module was not loaded at the time but was
auto-loaded when I did the smbmount which seemed fine)
[craig@flat craig]$ ls -l /mnt/Downloads/
kernel BUG at filemap.c:65!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c011ecec>]
EFLAGS: 00010286
eax: 0000001c ebx: c5777f04 ecx: 00000027 edx: 00000014
esi: c5777e80 edi: 00000000 ebp: c11e84f4 esp: c3a21ee4
ds: 0018 es: 0018 ss: 0018
Process ls (pid: 2227, stackpage=c3a21000)
Stack: 00000041 c5777f04 c011f529 c5777e80 c11e84f4 c5777e80 c11e84f4 c5777e80
00000000 c68544fa c5777e80 c5777f04 00000000 c11e84f4 c5777e80 c301ac60
c0d27840 c5777f04 00008000 18aeefe0 c685457b c5777f04 00000000 00000001
Call Trace: [<c011f529>] [<c68544fa>] [<c685457b>] [<c6853e1f>] [<c010fa48>] [<c0133645>] [<c01334e8>]
[<c010a640>]
Code: 0f 0b 83 c4 0c 5b c3 90 8b 4c 24 04 8b 51 34 85 d2 74 19 8b
Segmentation fault
Checking out /var/log/messages for symbol info yields:
Oct 28 15:12:01 flat kernel: kernel BUG at filemap.c:65!
Oct 28 15:12:01 flat kernel: invalid operand: 0000
Oct 28 15:12:01 flat kernel: CPU: 0
Oct 28 15:12:01 flat kernel: EIP: 0010:[__add_page_to_hash_queue+60/68]
Oct 28 15:12:01 flat kernel: EFLAGS: 00010286
Oct 28 15:12:01 flat kernel: eax: 0000001c ebx: c5777f04 ecx: 00000027 edx: 00000014
Oct 28 15:12:01 flat kernel: esi: c5777e80 edi: 00000000 ebp: c11e84f4 esp: c3a21ee4
Oct 28 15:12:01 flat kernel: ds: 0018 es: 0018 ss: 0018
Oct 28 15:12:01 flat kernel: Process ls (pid: 2227, stackpage=c3a21000)
Oct 28 15:12:01 flat kernel: Stack: 00000041 c5777f04 c011f529 c5777e80 c11e84f4 c5777e80 c11e84f4 c5777e80
Oct 28 15:12:01 flat kernel: 00000000 c68544fa c5777e80 c5777f04 00000000 c11e84f4 c5777e80 c301ac60
Oct 28 15:12:01 flat kernel: c0d27840 c5777f04 00008000 18aeefe0 c685457b c5777f04 00000000 00000001
Oct 28 15:12:01 flat kernel: Call Trace: [add_to_page_cache_unique+177/288] [<c68544fa>] [<c685457b>] [<c6853e1f>] [do_page_fault+352/1192] [sys_getdents+221/360] [filldir+0/128]
Oct 28 15:12:01 flat kernel: [system_call+52/56]
Oct 28 15:12:01 flat kernel: Code: 0f 0b 83 c4 0c 5b c3 90 8b 4c 24 04 8b 51 34 85 d2 74 19 8b
The box is a pretty standard RH6 setup btw. i.e.
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
if that makes any difference. I'm happy to provide any other info and
test out other ideas.
Thank you,
--Craig
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.3.24, smbfs] Kernel panic: put_cached_page: page count=1 [ In reply to ]
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
---559023410-2093070253-941124338=:8761
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 28 Oct 1999 craig@qualica.com wrote:
> Now I get (no reboot, just a make modules && make modules_install which
> should be ok I think. smbfs module was not loaded at the time but was
> auto-loaded when I did the smbmount which seemed fine)
[snip]
> Oct 28 15:12:01 flat kernel: kernel BUG at filemap.c:65!
> Oct 28 15:12:01 flat kernel: invalid operand: 0000
> Oct 28 15:12:01 flat kernel: CPU: 0
> Oct 28 15:12:01 flat kernel: EIP: 0010:[__add_page_to_hash_queue+60/68]
> Oct 28 15:12:01 flat kernel: EFLAGS: 00010286
> Oct 28 15:12:01 flat kernel: eax: 0000001c ebx: c5777f04 ecx: 00000027 edx: 00000014
> Oct 28 15:12:01 flat kernel: esi: c5777e80 edi: 00000000 ebp: c11e84f4 esp: c3a21ee4
> Oct 28 15:12:01 flat kernel: ds: 0018 es: 0018 ss: 0018
> Oct 28 15:12:01 flat kernel: Process ls (pid: 2227, stackpage=c3a21000)
> Oct 28 15:12:01 flat kernel: Stack: 00000041 c5777f04 c011f529 c5777e80 c11e84f4 c5777e80 c11e84f4 c5777e80
> Oct 28 15:12:01 flat kernel: 00000000 c68544fa c5777e80 c5777f04 00000000 c11e84f4 c5777e80 c301ac60
> Oct 28 15:12:01 flat kernel: c0d27840 c5777f04 00008000 18aeefe0 c685457b c5777f04 00000000 00000001
> Oct 28 15:12:01 flat kernel: Call Trace: [add_to_page_cache_unique+177/288] [<c68544fa>] [<c685457b>] [<c6853e1f>] [do_page_fault+352/1192] [sys_getdents+221/360] [filldir+0/128]
> Oct 28 15:12:01 flat kernel: [system_call+52/56]
> Oct 28 15:12:01 flat kernel: Code: 0f 0b 83 c4 0c 5b c3 90 8b 4c 24 04 8b 51 34 85 d2 74 19 8b
Interesting... Could you try the attached patch (braino with missed
initialization fixed + debugging stuff added) and see what will it give?
I don't see how could that path give buffers on the new page, but IIRC
there was something similar in 2.3.22 (not in smbfs). At least that might
somewhat narrow the things down.
---559023410-2093070253-941124338=:8761
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=smbfs-patch-3
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.10.9910281125380.8761@weyl.math.psu.edu>
Content-Description:
Content-Disposition: attachment; filename=smbfs-patch-3
LS0tIGNhY2hlLmMJVGh1IE9jdCAyOCAwMjo1MzowNSAxOTk5DQorKysgY2Fj
aGUuYy5uZXcJVGh1IE9jdCAyOCAxMToxODo1NyAxOTk5DQpAQCAtNDgsMzAg
KzQ4LDM5IEBADQogew0KIAlzdHJ1Y3QgcGFnZSAqIHBhZ2U7DQogCXN0cnVj
dCBwYWdlICoqIGhhc2g7DQotCXVuc2lnbmVkIGxvbmcgbmV3X3BhZ2U7DQor
CXN0cnVjdCBwYWdlICpjYWNoZWRfcGFnZSA9IE5VTEw7DQogDQogIGFnYWlu
Og0KIAloYXNoID0gcGFnZV9oYXNoKG1hcHBpbmcsIG9mZnNldCk7DQogCXBh
Z2UgPSBfX2ZpbmRfbG9ja19wYWdlKG1hcHBpbmcsIG9mZnNldCwgaGFzaCk7
DQogCWlmKCFwYWdlICYmIG5ldykgew0KLQkJLyogbm90IGluIGNhY2hlLCBh
bGxvYyBhIG5ldyBwYWdlICovDQotCQluZXdfcGFnZSA9IHBhZ2VfY2FjaGVf
YWxsb2MoKTsNCi0JCWlmICghbmV3X3BhZ2UpDQotCQkJcmV0dXJuIDA7DQot
CQljbGVhcl9wYWdlKG5ld19wYWdlKTsJLyogc21iIGNvZGUgYXNzdW1lcyBw
YWdlcyBhcmUgemVyb2VkICovDQotCQlwYWdlID0gcGFnZV9jYWNoZV9lbnRy
eShuZXdfcGFnZSk7DQotCQlpZiAoYWRkX3RvX3BhZ2VfY2FjaGVfdW5pcXVl
KHBhZ2UsIG1hcHBpbmcsIG9mZnNldCwgaGFzaCkpIHsNCisJCS8qIG5vdCBp
biBjYWNoZSwgYWxsb2MgYSBuZXcgcGFnZSBpZiB3ZSBkaWRuJ3QgZG8gaXQg
eWV0ICovDQorCQlpZiAoIWNhY2hlZF9wYWdlKSB7DQorCQkJY2FjaGVkX3Bh
Z2UgPSBwYWdlX2NhY2hlX2FsbG9jKCk7DQorCQkJaWYgKCFjYWNoZWRfcGFn
ZSkNCisJCQkJcmV0dXJuIDA7DQorCQkJLyogc21iIGNvZGUgYXNzdW1lcyBw
YWdlcyBhcmUgemVyb2VkICovDQorCQkJY2xlYXJfcGFnZShwYWdlX2FkZHJl
c3MoY2FjaGVkX3BhZ2UpKTsNCisJCQlnb3RvIGFnYWluOw0KKwkJfQ0KKwkJ
cGFnZSA9IGNhY2hlZF9wYWdlOw0KKwkJaWYgKHBhZ2UtPmJ1ZmZlcnMpDQor
CQkJQlVHKCk7DQorCQlwcmludGsoS0VSTl9ERUJVRyAic21iZnM6IGdldF9j
YWNoZWRfcGFnZVxuIik7DQorCQlpZiAoYWRkX3RvX3BhZ2VfY2FjaGVfdW5p
cXVlKHBhZ2UsIG1hcHBpbmcsIG9mZnNldCwgaGFzaCkpDQogCQkJLyogSG1t
LCBhIHBhZ2UgaGFzIG1hdGVyaWFsaXplZCBpbiB0aGUNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBjYWNoZS4gRmluZS4gR28gYmFjayBhbmQgZ2V0
IHRoYXQgcGFnZQ0KLSAgICAgICAgICAgICAgICAgICAgICAgICAgIGluc3Rl
YWQgLi4uIHRocm93aW5nIGF3YXkgdGhpcyBvbmUgZmlyc3QuICovDQotCQkJ
cHV0X2NhY2hlZF9wYWdlKCh1bnNpZ25lZCBsb25nKSBwYWdlKTsNCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICBpbnN0ZWFkLi4uICovDQogCQkJZ290
byBhZ2FpbjsNCi0JCX0NCisJCWNhY2hlZF9wYWdlID0gTlVMTDsNCiAJfQ0K
KwlwcmludGsoS0VSTl9ERUJVRyAic21iZnM6IGdldF9jYWNoZWRfcGFnZSBk
b25lXG4iKTsNCisJaWYgKGNhY2hlZF9wYWdlKQ0KKwkJcGFnZV9jYWNoZV9m
cmVlKGNhY2hlZF9wYWdlKTsNCiAJaWYoIXBhZ2UpDQogCQlyZXR1cm4gMDsN
CiAJaWYoIVBhZ2VMb2NrZWQocGFnZSkpDQotCQlwcmludGsoS0VSTl9FUlIg
InNtYmZzL2NhY2hlLmM6IHBhZ2UgaXNuJ3QgbG9ja2VkISBUaGlzIGNvdWxk
IGJlIGZ1biAuLi5cbiIpOw0KKwkJQlVHKCk7DQogCXJldHVybiBwYWdlX2Fk
ZHJlc3MocGFnZSk7DQogfQ0KIA0K
---559023410-2093070253-941124338=:8761--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.3.24, smbfs] Kernel panic: put_cached_page: page count=1 [ In reply to ]
On Thu, Oct 28, 1999 at 11:25:38AM -0400, Alexander Viro wrote:
>
[ my messages info snipped ]
>
> Interesting... Could you try the attached patch (braino with missed
> initialization fixed + debugging stuff added) and see what will it give?
Applied and rebuilt module but I had to reboot as the previous smbfs
module couldn't be rmmod'ed. Now it works though! Very strange.
No nasties in the logs. dmesg has some debug stuff but it all seems fine
now:
smbfs: get_cached_page
smbfs: get_cached_page done
smbfs: get_cached_page
smbfs: get_cached_page done
smbfs: get_cached_page done
smbfs: get_cached_page done
> I don't see how could that path give buffers on the new page, but IIRC
> there was something similar in 2.3.22 (not in smbfs). At least that might
> somewhat narrow the things down.
I'll stress the machine a little over the next few days and see what happens.
If I get any exciting debug messages I'll post them to the list.
Thank you,
--Craig
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/