Messages in this thread | | | Date | Sun, 13 Jun 1999 15:27:27 +0200 | From | Andi Kleen <> | Subject | IDE 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] | |