Hello Tejun, unfortunately. I today tried to build the array (4x500GB, so it is still building) and i got again a error: Oct 13 12:17:56 fileserver kernel: raid5: device sdc1 operational as raid disk 2 Oct 13 12:17:56 fileserver kernel: raid5: device sdb1 operational as raid disk 1 Oct 13 12:17:56 fileserver kernel: raid5: device sda1 operational as raid disk 0 Oct 13 12:17:56 fileserver kernel: raid5: allocated 4204kB for md0 Oct 13 12:17:56 fileserver kernel: raid5: raid level 5 set md0 active with 3 out of 4 devices, algorithm 2 Oct 13 12:17:56 fileserver kernel: RAID5 conf printout: Oct 13 12:17:56 fileserver kernel: --- rd:4 wd:3 Oct 13 12:17:56 fileserver kernel: disk 0, o:1, dev:sda1 Oct 13 12:17:56 fileserver kernel: disk 1, o:1, dev:sdb1 Oct 13 12:17:56 fileserver kernel: disk 2, o:1, dev:sdc1 Oct 13 12:18:24 fileserver kernel: RAID5 conf printout: Oct 13 12:18:24 fileserver kernel: --- rd:4 wd:3 Oct 13 12:18:24 fileserver kernel: disk 0, o:1, dev:sda1 Oct 13 12:18:24 fileserver kernel: disk 1, o:1, dev:sdb1 Oct 13 12:18:24 fileserver kernel: disk 2, o:1, dev:sdc1 Oct 13 12:18:24 fileserver kernel: disk 3, o:1, dev:sdd1 Oct 13 12:18:24 fileserver kernel: md: recovery of RAID array md0 Oct 13 12:18:24 fileserver kernel: md: minimum _guaranteed_ speed: 1000 KB/sec/disk. Oct 13 12:18:24 fileserver kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery. Oct 13 12:18:24 fileserver kernel: md: using 128k window, over a total of 488383936 blocks. Oct 13 13:01:26 fileserver kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x2400000 action 0x0 Oct 13 13:01:26 fileserver kernel: ata4.00: (BMDMA2 stat 0x650001) Oct 13 13:01:26 fileserver kernel: ata4.00: cmd ca/00:f8:47:e1:5e/00:00:00:00:00/e4 tag 0 cdb 0x0 data 126976 out Oct 13 13:01:26 fileserver kernel: res 51/04:98:a7:e1:5e/00:00:00:00:00/e4 Emask 0x1 (device error) Oct 13 13:01:26 fileserver kernel: ata4.00: configured for UDMA/100 Oct 13 13:01:26 fileserver kernel: ata4: EH complete Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] 976773168 512-byte hardware sectors (500108 MB) Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Write Protect is off Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA I'm not sure if it will result in corrupt data? But i don't trust it anymore. You people advise me to not buy the Promise SATA300 TX4 controller and this Sweex PU102 (3512) seems to have problems. Not much choices left except the really expensive solutions. Is it really so hard to build a controller without problems?!? :( Thursday, October 4, 2007, 3:27:18 AM, you wrote: > Hello, > MisterE wrote: >> I build another setup with almost the same hardware. >> This motherboard had already the latest bios. >> I notice that the computer does almost never find the hard drive >> although the controller is found every time (with lspci). > What do you mean by "almost never"? Does it find the harddisk > sometimes? Also, please post kernel boot log after disk detection > failure. lspci result just indicates only that the PCI device is present. >> So i get no >> drive (sda) assigned. I don't always see the "bios" screen from the >> controller at startup. And in the past it showed the hard drive. >> So i could not experiment with this motherboard. > Can you re-seat the controller or move it to another slot and see > whether things change? >> After that i installed Windows XP and used the orginal (sweex) >> drivers with the first motherboard. This also makes the data corrupt. >> So it seems not to be an linux problem. So there is something wrong with >> the motherboard or the 3512 controller. >> >> After that i plugged both hard drives (ide with windows and sata disk) >> to the Asus board. No data corruption. So the hard disks are'nt the >> problem either. > Hmmm... It's relieving to know that the problem isn't caused by sata_sil > but I don't have much idea than it seems like something goes wrong on > the PCI bus. :-( >> I'm thinking of replacing both 3512 controllers with a Promise SATA300 >> TX4. Do you know if there are problems with this device? > I see occasional bug reports on sata_promise but AFAIK there haven't > been any data corruption report. Mikael knows much better about promise > controllers. > Thanks. -- Best regards, MisterE mailto:MisterE2002@xxxxxxxxx
Attachment:
kern.log
Description: Binary data
