[2.4.18] OOPS in smbfs

[2.4.18] OOPS in smbfs

[Cyrille Chepelov]

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.

Re: [2.4.18] OOPS in smbfs

[Urban Widmark]

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

Re: [2.4.18] OOPS in smbfs

[Cyrille Chepelov]

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.

Re: [2.4.18] OOPS in smbfs

[Christian Bornträger]

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.

Re: [2.4.18] OOPS in smbfs. Tested with 1.4.18rc2

[Christian Bornträger]

> 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