Hello Bill,
At 14:28 08-07-97 -0400, you wrote:
>The attached patch (in conjunction with my clear_inode patch) should fix
>your NCP-related inode problems (or at least some of them :-)).
>The patch is against 2.0.30. I haven't tested it (other than to see
>that it compiles), so please let me know of any further problems.
Thanks for the patch. Unfortunately, the patch doesn't fix the NCP-related
inode problems.
Setup: Clean 2.0.30 kernel + the following patches:
ncpfs DST patch: http://www.linuxhq.com/patch/20-p0375.html
inode_ci-patch: http://www.linuxhq.com/patch/20-p0616.html
buffer_rr-patch: http://www.linuxhq.com/patch/20-p0617.html
Patch for NCP inode race (the letter I'm replying to)
While holding the reload-key-combination in Netscape on a page from a
NCP-mounted volume (the page makes extensive use of SSI):
Jul 9 01:31:29 www kernel: VFS: iput: trying to free free inode
Jul 9 01:31:29 www kernel: VFS: device 00:00, inode 2626, mode=00140000
Jul 9 01:31:30 www kernel: VFS: iput: trying to free free inode
Jul 9 01:31:30 www kernel: VFS: device 00:00, inode 2729, mode=00140000
Jul 9 01:31:30 www kernel: VFS: iput: trying to free free inode
Jul 9 01:31:30 www kernel: VFS: device 00:00, inode 2852, mode=00140000
Jul 9 01:31:31 www kernel: VFS: iput: trying to free free inode
Jul 9 01:31:31 www kernel: VFS: device 00:00, inode 3207, mode=00140000
Jul 9 01:31:31 www kernel: VFS: iput: trying to free free inode
Jul 9 01:31:31 www kernel: VFS: device 00:00, inode 3456, mode=00140000
Jul 9 01:31:32 www kernel: VFS: iput: trying to free free inode
Jul 9 01:31:32 www kernel: VFS: device 00:00, inode 3535, mode=00140000
Jul 9 01:31:32 www kernel: VFS: iput: trying to free free inode
Jul 9 01:31:32 www kernel: VFS: device 00:00, inode 3627, mode=00140000
Jul 9 01:31:34 www kernel: clear_inode: inode back in use, count=1
Jul 9 01:31:34 www kernel: general protection: 0000
Jul 9 01:31:34 www kernel: CPU: 0
Jul 9 01:31:34 www kernel: EIP: 0010:[disk_change+78/608]
Jul 9 01:31:34 www kernel: EFLAGS: 00010206
Jul 9 01:31:34 www kernel: eax: 00165180 ebx: 0164bdc0 ecx: 0127c5e8
edx: f000ef6f
Jul 9 01:31:34 www kernel: esi: 00000000 edi: 00000200 ebp: 0127c5e8
esp: 00c2df74
Jul 9 01:31:34 www kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss:
0018
Jul 9 01:31:34 www kernel: Process httpd (pid: 853, process nr: 22,
stackpage=00c2d000)
Jul 9 01:31:34 www kernel: Stack: 0164bdc0 00000000 00000200 0127c5e8
00000000 00000200 0127c5e8 00000200
Jul 9 01:31:34 www kernel: 001248da 0127c5e8 0164bdc0 400e5000
00000200 01187414 080b46f0 00000200
Jul 9 01:31:34 www kernel: bffeb934 0010a819 00000005 400e5000
00000200 080b46f0 00000200 bffeb934
Jul 9 01:31:34 www kernel: Call Trace: [refill_freelist+862/932]
[ret_from_sys_call+9/136]
Jul 9 01:31:34 www kernel: Code: f6 82 d1 04 00 00 11 74 0d b8 fb ff ff ff
5b 5e 5f 5d 83 c4
Jul 9 01:31:35 www kernel: VFS: iput: trying to free free inode
Jul 9 01:31:35 www kernel: VFS: device 00:00, inode 5035, mode=00140000
Jul 9 01:32:07 www kernel: VFS: iput: trying to free free inode
Jul 9 01:32:07 www kernel: VFS: device 00:00, inode 6007, mode=00140000
Jul 9 01:32:07 www kernel: VFS: iput: trying to free free inode
Jul 9 01:32:07 www kernel: VFS: device 00:00, inode 6117, mode=00140000
Jul 9 01:32:08 www kernel: VFS: iput: trying to free free inode
Jul 9 01:32:08 www kernel: VFS: device 00:00, inode 6812, mode=00140000
Jul 9 01:32:08 www kernel: VFS: iput: trying to free free inode
Jul 9 01:32:08 www kernel: VFS: device 00:00, inode 7036, mode=00140000
Jul 9 01:32:08 www kernel: VFS: iput: trying to free free inode
Jul 9 01:32:08 www kernel: VFS: device 00:00, inode 7197, mode=00140000
Jul 9 01:32:09 www kernel: clear_inode: inode back in use, count=1
The "general protection: 0000" instances keep happening.
Finally:
Jul 9 01:32:20 www kernel: general protection: 0000
Jul 9 01:32:20 www kernel: CPU: 0
Jul 9 01:32:20 www kernel: EIP: 0010:[disk_change+78/608]
Jul 9 01:32:20 www kernel: EFLAGS: 00010202
Jul 9 01:32:20 www kernel: eax: 00165180 ebx: 0164be00 ecx: 0127c2f4
edx: f000ef6f
Jul 9 01:32:20 www kernel: esi: 00000000 edi: 00000200 ebp: 0127c2f4
esp: 016aaf74
Jul 9 01:32:20 www kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss:
0018
Jul 9 01:32:20 www kernel: Process httpd (pid: 1022, process nr: 23,
stackpage=016aa000)
Jul 9 01:32:20 www kernel: Stack: 0164be00 00000000 00000200 0127c2f4
00000000 00000200 0127c2f4 00000200
Jul 9 01:32:20 www kernel: 001248da 0127c2f4 0164be00 400e5000
00000200 00eaa018 080b46f0 00000200
Jul 9 01:32:20 www kernel: bffeb934 0010a819 00000005 400e5000
00000200 080b46f0 00000200 bffeb934
Jul 9 01:32:20 www kernel: Call Trace: [refill_freelist+862/932]
[ret_from_sys_call+9/136]
Jul 9 01:32:20 www kernel: Code: f6 82 d1 04 00 00 11 74 0d b8 fb ff ff ff
5b 5e 5f 5d 83 c4
Jul 9 01:32:20 www kernel: clear_inode: inode back in use, count=2
Jul 9 01:32:21 www kernel: general protection: 0000
Jul 9 01:32:21 www kernel: CPU: 0
Jul 9 01:32:21 www kernel: EIP: 0010:[update_process_times+276/280]
Jul 9 01:32:21 www kernel: EFLAGS: 00010286
Jul 9 01:32:21 www kernel: eax: 0000002c ebx: f000ef6f ecx: 0000002c
edx: 0103dcbc
Jul 9 01:32:21 www kernel: esi: 00e78018 edi: 00000028 ebp: 00f36f4c
esp: 00f36f40
Jul 9 01:32:21 www kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss:
0018
Jul 9 01:32:21 www kernel: Process httpd (pid: 1025, process nr: 21,
stackpage=00f36000)
Jul 9 01:32:21 www kernel: Stack: 001d0054 00e78018 00e78030 01bed5e8
00165128 0000002c 01bed5e8 00000400
Jul 9 01:32:21 www kernel: 00000200 01bed5e8 0016521c 01bed5e8
00000000 00c8cf80 00000000 00000200
Jul 9 01:32:21 www kernel: 01bed5e8 00000000 00000200 01bed5e8
00000200 001248da 01bed5e8 00c8cf80
Jul 9 01:32:21 www kernel: Call Trace: [reschedule_timeout+144/164]
[disk_change+192/608] [refill_freelist+862/932] [ret_from_sys__call+9/136]
Jul 9 01:32:21 www kernel: Code: 8b 13 8b 5b 04 85 d2 74 75 8b 02 83 f8 02
74 07 8b 02 83 f8
No the system gets full of zombies. No clean shutdown possible.
These lines mean nothing to me. But maybe to someone else?
Greetings from Troels Arvin, Copenhagen, Denmark
http://www.mdb.ku.dk/tarvin/