PROBLEM: Oops in fat module in 2.2.0

carguin@iname.com
Tue, 26 Jan 1999 10:35:11 -0500 (EST)


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/