Messages in this thread | | | From | carguin@iname ... | Date | Tue, 26 Jan 1999 10:35:11 -0500 (EST) | Subject | PROBLEM: Oops in fat module in 2.2.0 |
| |
I've had this problem for the last couple of days (since I upgraded from pre6 to pre9), and I've finally managed to catch one. When the disk subsystem gets put under a moderately heavy load (eg, generating the locate db), the system has a tendency to Oops. I suspect the real problem actually lies in the SCSI driver (the NCR53c8xx driver), but the oops occurred in the fat module.
Before the oops I get tons of these in the logs:
Jan 26 04:14:04 rincewind kernel: attempt to access beyond end of device Jan 26 04:14:04 rincewind kernel: 08:07: rw=0, want=1030649, limit=819184 and Jan 26 04:14:04 rincewind kernel: Filesystem panic (dev 08:07). Jan 26 04:14:04 rincewind kernel: FAT error Jan 26 04:14:04 rincewind kernel: File system has been set read-only Jan 26 04:14:04 rincewind kernel: Directory 9240: bad FAT
Once the messages start, they continue on until the Oops (after which, the system may or may not be stable). They do not change partitions during a problem, but the problem may start in another partition. Looking back in the logs I see one that occurred on a Linux native partition, so this probably isn't a fat issue.
Here is the oops message:
Unable to handle kernel paging request at virtual address 3f3f3f53 current->tss.cr3 = 01abd000, %cr3 = 01abd000 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<c883f225>] EFLAGS: 00010202 eax: 00000001 ebx: c0a17e2c ecx: 00028020 edx: 0000000c esi: 3f3f3f3f edi: c8842c6c ebp: 00ac7712 esp: c0a17dd8 ds: 0018 es: 0018 ss: 0018 Process find (pid: 2103, process nr: 63, stackpage=c0a17000) Stack: bfffb770 00003d71 00000000 00000000 0000000c 0000000c c0a17e00 c0a17e2c 00000001 00000000 c0124300 c885b7a4 c5dba000 00000000 00000000 00000800 000000bf 000002bc 00000000 00028020 c79edc00 3462c080 03cebf40 72c0802e Call Trace: [<c0124300>] [<c885b7a4>] Code: 8b 4e 14 83 c1 e0 eb 08 8d 76 00 c6 44 24 44 00 55 0f b6 54
>>EIP: c883f225 <fat_readdirx+595/724> Trace: c0124300 <insert_into_queues+78/110> Trace: c885b7a4 <cleanup_module+718/79b8> Code: c883f226 <fat_readdirx+596/724> 00000001 <_EIP>: Code: c883f226 <fat_readdirx+596/724> 1: 8b 4e 14 movl 0x14(%esi),%ecx Code: c883f229 <fat_readdirx+599/724> 4: 83 c1 e0 addl $0xffffffe0,%ecx Code: c883f22c <fat_readdirx+59c/724> 7: eb 08 jmp 11 <_EIP+0x10> c883f235 <fat_readdirx+5a5/724> Code: c883f22e <fat_readdirx+59e/724> 9: 8d 76 00 leal 0x0(%esi),%esi Code: c883f231 <fat_readdirx+5a1/724> c: c6 44 24 44 00 movb $0x0,0x44(%esp,1) Code: c883f236 <fat_readdirx+5a6/724> 11: 55 pushl %ebp Code: c883f237 <fat_readdirx+5a7/724> 12: 0f b6 54 00 00 movzbl 0x0(%eax,%eax,1),%edx
The partition table on the disk in question is:
Disk /dev/sda: 64 heads, 32 sectors, 8296 cylinders Units = cylinders of 2048 * 512 bytes
Device Boot Start End Blocks Id System /dev/sda1 1 8296 8495088 5 Extended /dev/sda5 1 51 52192 83 Linux native /dev/sda6 52 152 103408 83 Linux native /dev/sda7 153 952 819184 e Win95 FAT16 (LBA) /dev/sda8 953 1752 819184 e Win95 FAT16 (LBA) /dev/sda9 1753 1882 133104 82 Linux swap /dev/sda10 1883 2012 133104 82 Linux swap /dev/sda11 2013 3212 1228784 83 Linux native /dev/sda12 3317 4516 1228784 83 Linux native /dev/sda13 4517 6296 1822704 83 Linux native /dev/sda14 6297 8296 2047984 83 Linux native
And the SCSI information is:
Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: MICROP Model: 3387NS Rev: X501 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: QUANTUM Model: FIREBALL_TM3200S Rev: 300X Type: Direct-Access ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 03 Lun: 00 Vendor: SEAGATE Model: SX15150W Rev: 9002 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 04 Lun: 00 Vendor: Seagate Model: STT8000N Rev: 3.16 Type: Sequential-Access ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: SONY Model: CD-R CDU948S Rev: 1.0j Type: CD-ROM ANSI SCSI revision: 02
Thank you very much.
-- Chris Arguin | "...All we had were Zeros and Ones -- And CArguin@iname.com | sometimes we didn't even have Ones." +--------------+ - Dilbert, by Scott Adams http://leonardo.sr.unh.edu/arguin/home.html |
- 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/
| |