On 13 Jul 2000, Tom Crane wrote:
What is this?
To: mail2news@checked_ok.outbound.mail2news@checked_ok.outbound.mllk
SEP I guess, but it makes it hard to reply to the lists as well.
> Dear All,
> Has anybody seen the following?; remote mounting a Win98 FS with
> smbmount and doing ls -laR. After proceeding some way through the listing it
> reports "I/O Error" and the session hangs. No more smbmount connections to
> the remote machine are possible. 'df' etc. hang when it gets to attempting to
> display that mount's info. From syslog I have,
When it oopsed it held a lock and anyone trying to get that lock will
hang. Not sure about the new mounts, but probably the same reason.
> Jul 12 16:57:56 mklab kernel: SMBFS: need mount version 6
> Jul 12 16:58:08 mklab kernel: SMBFS: need mount version 6
What smbmount are you using? Does it mount anything at all?
(it shouldn't ... :)
Or is that from some earlier attempt at mounting with a different smbmount
program? You should be using smbmount from samba 2.0.7.
> Jul 12 18:09:58 mklab kernel: Unable to handle kernel paging request at virtual address c40481fc
> Jul 12 18:09:58 mklab kernel: current->tss.cr3 = 01791000, %cr3 = 01791000
> Jul 12 18:09:58 mklab kernel: *pde = 03d51063
> Jul 12 18:09:58 mklab kernel: *pte = 00000000
> Jul 12 18:09:58 mklab kernel: Oops: 0000
> Jul 12 18:09:58 mklab kernel: CPU: 0
> Jul 12 18:09:58 mklab kernel: EIP: 0010:[smb_decode_long_dirent+60/180]
> Jul 12 18:09:58 mklab kernel: EFLAGS: 00010246
> Jul 12 18:09:58 mklab kernel: eax: 00000104 ebx: 00000000 ecx: c35d7844 edx: c11ab000
> Jul 12 18:09:58 mklab kernel: esi: c40481fc edi: c3627ee4 ebp: c40481fc esp: c3627e94
> Jul 12 18:09:58 mklab kernel: ds: 0018 es: 0018 ss: 0018
> Jul 12 18:09:58 mklab kernel: Process ls (pid: 18388, process nr: 94, stackpage=c3627000)
> Jul 12 18:09:58 mklab kernel: Stack: 00000026 c40481fc c0157e41 c35d7844 c40481fc c3627ee4 00000104 c23a5000
> Jul 12 18:09:58 mklab kernel: 00000002 c23a5000 c1a81c20 c3627ee4 00000018 000062e0 00000000 00000104
> Jul 12 18:09:58 mklab kernel: 00000005 00000003 c1b0b800 c1b0b80c 00000000 c3fc0000 000000fe c404122c
> Jul 12 18:09:58 mklab kernel: Call Trace: [<c40481fc>] [smb_proc_readdir_long+653/784] [<c40481fc>] [<c404122c>] [<c404103b>] [<c4041046>] [smb_proc_readdir+35/60]
> Jul 12 18:09:58 mklab kernel: [smb_refill_dircache+31/100] [smb_readdir+85/400] [smb_dir_open+67/80] [sys_getdents+220/304] [filldir+0/132] [smb_readdir+0/400] [sys_open+99/148] [system_call+52/64]
> Jul 12 18:09:58 mklab kernel: Code: 0f b7 06 8d 2c 30 8b 5e 3c 81 fb ff 00 00 00 76 05 bb ff 00
eax $104 = 260 = info_level, so it's in the switch ... hmm, I'm guessing
the problem is the 'p' pointer with the following reasoning from your
decoded oops:
0: 0f b7 06 movzwl (%esi),%eax
3: 8d 2c 30 leal (%eax,%esi,1),%ebp
result = p + WVAL(p, 0); /* I guess, the others match */
6: 8b 5e 3c movl 0x3c(%esi),%ebx
len = DVAL(p, 60); /* 0x3c = 60 */
9: 81 fb ff 00 00 cmpl $0xff,%ebx
e: 00
f: 76 05 jbe 16 <_XXX+0x16>
11: bb ff 00 00 00 movl $0xff,%ebx
if (len > 255) len = 255;
The p pointer is the rdata output from the smb_trans2_request call.
p should be pointing at a vmalloc'ed area that is SMB_INITIAL_PACKET_SIZE
sized, or possibly larger if the initial packet was replaced. The initial
size is 4000 bytes (= $0fa0).
vmalloc rounds the size to whole pages, c40481fc is 508 bytes from a page
boundary. I thought that it might have been pointing outside the
allocated memory (it still may, but it's less obvious).
> I have seen reports of problems with oops 0002 and kernel 2.2.14 which I am
> running but not oops 0000. Should I upgrade to 2.2.16? Is the "SMBFS: need
> mount version 6" significant? Any other ideas?
smbfs in 2.2.16 does not intentionally fix any oopses AFAIK. But it's
probably quicker for you to test it than it is for me to figure out what
is wrong. And replace your smbmount too (try to find out which version you
were using).
Does it happen every time? Yes, I'm asking you to intentionally oops your
machine :) I usually umount everything I can or remount read-only, then
sync, and then try to trigger the oops. If it doesn't testing 2.2.16
doesn't mean much.
Also, if you can repeat it than I could send a patch vs 2.2.14/15/16/17pre
that adds a few printk's (first to see where the server->packet memory
starts, second to see what happens in the
for (i = 0; i < ff_searchcount; i++)
loop in smb_proc_readdir_long).
If you can't repeat it or don't have time to test things I'll probably put
this report in my collection of bad smbfs things (not that the report was
bad) and look at it later.
Btw, 'ls -laR' is working fine here (don't have a win98, but vs win95).
The mount version message should be insignificant, the current version
only passes permission modes and uids (unless you are using a smbmount or
smbfs that is patched).
/Urban
-
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/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:19 EST