lkml.org 
[lkml]   [1999]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectIDE fs corruptions in 2.3.
On Thu, Jun 10, 1999 at 11:45:26PM +0200, Andi Kleen wrote:
> > Linus,
> >
> > This is assuming the ide-driver core has a fault.
> >
> > I want to know if it happens with out the ALI15x3 driver.
> > There are so many versions of this nasty thing, I am about one aspirin
> > short of root-wadding that chipset driver.......
>
> Sorry for the late reply:
>
> I can easily reproduce the corrupted directories on a 2CPU SMP machine with
> 82371AB PIIX4 IDE interface/IBM-DTTA-351010/extended DMA by
> doing
> cp -a /usr/src/linux . ; cd linux ; make clean ; make depend
> make MAKE='make -j6' bzImage
>
> I tried with both 1K and 4K ext2, it happens on both block sizes so my
> initial guess seems to be wrong.
>
> I cannot reproduce it on a IBM SCSI disk hanging of the same machine on a
> 2940 (only tested with 1K fs)
>
> ---
>
> The corruptions I reported on the ALI15x3 (same symptoms) happened on
> single CPU machine with the same IDE disk (IBM-DTTA-351010). It was caused
> by a parallel kernel compile here too.
>
> Both tests with 2.3.4. I'll try 2.3.6 later tonight, althought it is a
> bit problematic because it doesn't boot on the single CPU because init
> cannot map all libraries (seems do_mmap is broken)

[...]

Here is even more data. I can reproduce the "corruption" easily on
my 2.3.6/PIIX IDE/DTA351010 system with the following easy script:

4K ext2; kernel output:

Uniform Multi-Platform E-IDE driver Revision: 6.19
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
hda: IBM-DTTA-351010, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
uhci_control_thread at c01e8afc
New bus registered
usb_hub_thread at c01e9f48
hda: lost interrupt
hda: set_geometry_intr: status=0x00 { }
hda: IBM-DTTA-351010, 9671MB w/466kB Cache, CHS=9825/32/63, UDMA(33)


#!/bin/sh
mkdir TEST
cd TEST
i=0 ; while [ $i -le 100 ] ; do touch "abcdefghijklm$i" ; i=$[$i+1]; done
ls
for i in * ; do cat $i > $i.1 ; touch $i ; done
ls

Result: empty directory (not even . or ..)

kali:~% ls -a TEST
kali:~% rmdir TEST
rmdir: TEST: Directory not empty

The inode looks ok:

File: "TEST"
Size: 8192 Filetype: Directory
Mode: (0775/drwxrwxr-x) Uid: ( 500/ andi) Gid: ( 500/ andi)
Device: 3,6 Inode: 64176 Links: 2
Access: Sun Jun 13 14:59:38 1999(00000.00:10:27)
Modify: Sun Jun 13 14:59:33 1999(00000.00:10:32)
Change: Sun Jun 13 14:59:33 1999(00000.00:10:32)

The second ls already shows an empty directory. Strange thing is that the
direntries still seem to exist on the disk/in the buffer cache.

I attached a debugsfs dump
of the directory, which looks ok to my untrained eye. I also tried the
debugfs dump with both mounted and unmounted fs (to flush the buffer cache) -
identical; and changed the IDE cable - no luck.

It does not seem to dependent on SMP, it even happens when I boot with
nosmp. On a SCSI disk in the same machine everything works fine.

I would appreciate any clues, because I cannot even compile kernel anymore
(either drivers/net or drivers/char disappear reliably)


-Andi

--
This is like TV. I don't like TV.
[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.018 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site