2.1.82 VFAT and ide-cdrom (?) problems

Stanislav Meduna (stano@trillian.eunet.sk)
Sun, 8 Feb 1998 10:50:09 +0100 (MET)


Hi all,

I would like to report some problems in 2.1.82 version.
Unfortunately (in the first case perhaps fortunately :-))
I was not able to reproduce them :-(

Environment:

Linux trillian 2.1.82 #9 Thu Jan 29 19:57:39 MET 1998 i686 unknown
Compiled with: gcc version pgcc-2.90.23 980102 (egcs-1.0.1 release)
Highly modularized kernel
Never had any hardware problem with the machine

=====
Problem 1: DOS filesystem corruption

I was running dosemu which in turn has accessed mounted partition
through LREDIR redirector. During heavy work with the disk the
system began to report

Feb 8 09:29:13 trillian kernel: FAT cache corruption inode=1466354
Feb 8 09:29:14 trillian kernel: 0
Feb 8 09:29:14 trillian kernel: file_cluster badly computed!!! 144 <> 131
Feb 8 09:29:14 trillian kernel: file_cluster badly computed!!! 145 <> 132
...
Feb 8 09:29:14 trillian kernel: file_cluster badly computed!!! 270 <> 257

and was virtually unusable due to excessive error messages. I rebooted to
DOS and have checked the partition.

- The processed file has allocation error, has enlarged it's size
several times and was corrupted (I don't know the format
so I am not able to precisely say what happened)
- The check has reported some other file having allocation error,
but I surely never had such a file in the partition
- There was a bunch of lost clusters, which contained perfectly
valid files from one directory that disappeared

I think that some directory was corrupted.

The partition was mounted as vfat (fat and vfat as modules), and
there was no long filename involved. The same setup worked flawlessly
with 2.0.33 and at least once with 2.1.82 too.

I searched the log and noticed one more such message (unnoticed at
the time it happened).

Feb 4 19:55:06 trillian kernel: FAT cache corruption inode=6172

=====

Problem 2: IDE CDROM eject problem

After several mounts and umounts I was not able to eject the CDROM.
I was able to mount and unmount the device, but the eject button
remained disabled and 'eject' command reported the device as busy
and I was forced to reboot.

The mount process has once crashed in kernel:

Feb 7 20:43:52 trillian kernel: Unable to handle kernel paging request at virtual address c282ac3c
Feb 7 20:43:52 trillian kernel: current->tss.cr3 = 01957000, ^Hr3 = 01957000
Feb 7 20:43:52 trillian kernel: *pde = 01f0d063
Feb 7 20:43:52 trillian kernel: *pte = 00000000
Feb 7 20:43:52 trillian kernel: Oops: 0000
Feb 7 20:43:52 trillian kernel: CPU: 0
Feb 7 20:43:52 trillian kernel: EIP: 0010:[<c0126c7e>]
Feb 7 20:43:52 trillian kernel: EFLAGS: 00010246
Feb 7 20:43:52 trillian kernel: eax: 0000000f ebx: c10434ec ecx: c282ac3c edx: 08055000
Feb 7 20:43:52 trillian kernel: esi: c0ed1640 edi: c1ee9000 ebp: 0000000f esp: c0fc9f48
Feb 7 20:43:52 trillian kernel: ds: 0018 es: 0018 ss: 0018
Feb 7 20:43:52 trillian kernel: Process mount (pid: 4958, process nr: 35, stack page=c0fc9000)
Feb 7 20:43:52 trillian kernel: Stack: 0000000f c1ee9000 c0fc8000 c0ed000f 0805 46e8 bffff52c 00000000 c0fc9f74
Feb 7 20:43:52 trillian kernel: 0000000f c098cea0 c282ac3c c1ee9000 0000 0000 00000000 c098cea0 c019c304
Feb 7 20:43:52 trillian kernel: 00000001 00000000 00000000 00000000 0000 0000 00000000 00000000 00000000
Feb 7 20:43:52 trillian kernel: Call Trace: [<c282ac3c>] [<c010988a>]
Feb 7 20:43:52 trillian kernel: Code: 8b 09 89 4c 24 1c 89 cf 57 8b 84 24 84 00 00 00 50 8b 8c 24

the call trace according to System.map is sys_mount called from system_call.
The c282ac3c address is in the module space, but if the adresses
do have some connection with the symbols in the module (modulo page),
it has probably something to do with ide_cdrom_register.

In fact these are probably two problems - why the Oops happened and why
the cdrom driver was then confused.

=====

Problem 3: Network-related messages in syslog

After I exit the PPP connection, there are following messages in the syslog

Feb 7 20:31:41 trillian kernel: PPP: ppp line discipline successfully unregistered
Feb 7 20:31:41 trillian kernel: unregister_proc_table: neigh not empty!
Feb 7 20:31:41 trillian kernel: unregister_proc_table: ipv4 not empty!
Feb 7 20:31:41 trillian kernel: unregister_proc_table: net not empty!

This one doesn't hurt, but perhaps is a sign of other problem.

=====

Hope this helps a bit

--
						Stano
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu