Messages in this thread | | | From | Stanislav Meduna <> | Subject | 2.1.82 VFAT and ide-cdrom (?) problems | Date | 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
| |