Greetings,
here's a oops I received while using smbfs; the server was mounted from
the following fstab entry:
//nt_server/misc /mnt/g smbfs username=HIDDEN,password=CENSORED,uid=0,gid=40,fmask=664,dmask=775,rw,user,noauto 0 0
I did nothing special at the time; I had just mounted the device, and was
tab-completing into a directory using zsh (there are no specially named files
at all in that directory: everything matches [0-9a-zA-Z._]). The server is a
fairly storyless NT4.0 x86 server (I'm not quite sure what service pack, and
wouldn't be surprised if it was still at SP0).
Kernel version is 2.4.18-rc4
Without further ado, here's the oops:
Unable to handle kernel paging request at virtual address d0000000
d12c48f7
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<d12c48f7>] Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: db138f13 ebx: d0000000 ecx: f5fef3fd edx: 2bd0b637
esi: e1f7d45d edi: ce2efe34 ebp: ce2efecc esp: ce2efde4
ds: 0018 es: 0018 ss: 0018
Process zsh (pid: 20207, stackpage=ce2ef000)
Stack: c013c4a0 ce2efe9c d12d6730 00000000 00000000 00000000 00000000 cf4780a0
c292d8c0 20202020 00d3efd2 34333533 00000000 00000000 c80af000 0000000f
00000000 00000000 00000001 00000011 d12c3215 c635a6c0 ce2effb0 c013c4a0
Call Trace: [<c013c4a0>] [<d12c3215>] [<c013c4a0>] [<c013c4a0>] [<d12c32a4>]
[<c013c4a0>] [<d12c415b>] [<c013c4a0>] [<c013c11b>] [<c013c4a0>] [<c013c603>]
[<c013c4a0>] [<c013bb0b>] [<c0106d2b>]
Code: 0f b6 03 43 89 c2 c1 e2 04 01 f2 c1 e8 04 01 c2 8d 04 92 8d
>>EIP; d12c48f6 <[smbfs]smb_fill_cache+52/2dc> <=====
Trace; c013c4a0 <filldir64+0/114>
Trace; d12c3214 <[smbfs]smb_proc_readdir_long+3d0/434>
Trace; c013c4a0 <filldir64+0/114>
Trace; c013c4a0 <filldir64+0/114>
Trace; d12c32a4 <[smbfs]smb_proc_readdir+2c/40>
Trace; c013c4a0 <filldir64+0/114>
Trace; d12c415a <[smbfs]smb_readdir+37a/41c>
Trace; c013c4a0 <filldir64+0/114>
Trace; c013c11a <vfs_readdir+5a/7c>
Trace; c013c4a0 <filldir64+0/114>
Trace; c013c602 <sys_getdents64+4e/b2>
Trace; c013c4a0 <filldir64+0/114>
Trace; c013bb0a <sys_fcntl64+7e/88>
Trace; c0106d2a <system_call+32/38>
Code; d12c48f6 <[smbfs]smb_fill_cache+52/2dc>
00000000 <_EIP>:
Code; d12c48f6 <[smbfs]smb_fill_cache+52/2dc> <=====
0: 0f b6 03 movzbl (%ebx),%eax <=====
Code; d12c48f8 <[smbfs]smb_fill_cache+54/2dc>
3: 43 inc %ebx
Code; d12c48fa <[smbfs]smb_fill_cache+56/2dc>
4: 89 c2 mov %eax,%edx
Code; d12c48fc <[smbfs]smb_fill_cache+58/2dc>
6: c1 e2 04 shl $0x4,%edx
Code; d12c48fe <[smbfs]smb_fill_cache+5a/2dc>
9: 01 f2 add %esi,%edx
Code; d12c4900 <[smbfs]smb_fill_cache+5c/2dc>
b: c1 e8 04 shr $0x4,%eax
Code; d12c4904 <[smbfs]smb_fill_cache+60/2dc>
e: 01 c2 add %eax,%edx
Code; d12c4906 <[smbfs]smb_fill_cache+62/2dc>
10: 8d 04 92 lea (%edx,%edx,4),%eax
Code; d12c4908 <[smbfs]smb_fill_cache+64/2dc>
13: 8d 00 lea (%eax),%eax
% grep SMB /boot/config-2.4.18-rc4
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="utf8"
CONFIG_SMB_NLS=y
I hope this helps...
-- Cyrille
--
Grumpf.
> the rest. A simple but helpful thing to do would be to see if 2.4.18-rc2
> works.
2.4.18-rc2 produced no oops, at least till now.
But there are a lot of
smb_proc_readdir_long: name=<directory> result=-2, rcls=1, err=2
Messages in dmesg. I have not seen them in 2.4.17
Le Thu, Feb 28, 2002, ? 03:34:53PM +0100, Urban Widmark a ?crit:
> Does 2.4.17 work fine for everyone?
> Did any of you try something between 2.4.18-pre4 and 2.4.18-rc2?
Previously, that machine was running 2.4.17-pre8. It was running fine with
smbfs, but had never been asked to touch the NT server I mentioned. OTOH,
with the 2.4.18-rc4 kernel, I can touch other Win2K (workstation) machines
with no harmful effects.
I would like to avoid going back to 2.4.18-rc2 (lack of time to compile), if
someone with identical oopes had the time the better. But if no-one does
before tomorrow, I'll try that version.
-- Cyrille
--
Grumpf.
On Wed, 27 Feb 2002, Cyrille Chepelov wrote:
> I did nothing special at the time; I had just mounted the device, and was
> tab-completing into a directory using zsh (there are no specially named files
> at all in that directory: everything matches [0-9a-zA-Z._]). The server is a
> fairly storyless NT4.0 x86 server (I'm not quite sure what service pack, and
> wouldn't be surprised if it was still at SP0).
>
> Kernel version is 2.4.18-rc4
There is a bunch of smbfs changes in 2.4.18. Some fsx fixes from december
and some cleanups from Al Viro. The latter I have not tested myself so I'm
hoping those are causing this and that I will be able to trigger it
easily.
I now have 3 reports of identical oopses in 2.4.18. All of them crashed on
a register with contents matching x0000000 and in smb_fill_cache.
Does 2.4.17 work fine for everyone?
Did any of you try something between 2.4.18-pre4 and 2.4.18-rc2?
2.4.18-pre4 has about half the smbfs changes in 2.4.18 and 2.4.18-rc3 has
the rest. A simple but helpful thing to do would be to see if 2.4.18-rc2
works.
I have planned to actually get to do some linux work this weekend, unlike
the last few weeks, so your timing is pretty good. :)
/Urban
Urban Widmark wrote:
> Does 2.4.17 work fine for everyone?
stable since its existence. 2.4.18 oopsed at the first access.
> Did any of you try something between 2.4.18-pre4 and 2.4.18-rc2?
> 2.4.18-pre4 has about half the smbfs changes in 2.4.18 and 2.4.18-rc3 has
> the rest. A simple but helpful thing to do would be to see if 2.4.18-rc2
> works.
I will try it.