block sizes dont seem to matter, tried from 512 bytes to 64K in the adaptec case. i also get no errors in /dev/kprint. just read() returns Eio.
i have no knowledge of IDE or SATA interfaces, so i'm a little bit lost in the code. :-( the chipset specific IDE code in linux seens to set mostly some timing related control registers, but doesnt change the logic how error conditions are handled as far as i can see. maybe it does by switching some important quirk flags but its not obvious to me. i would like to raise the debug level of sdata.c, just set any bit and got flooded with messages. so it would be great if you could hint me on some interesting debug cases where to look. many thanks so far for the quick responses! :-) cinap
--- Begin Message ---> Now this is very interesting! A friend gave me an Adaptec (it really is an > SiL) 2xSATA > PCI controller [1] for testing, and i was able to generate I/O errors just by > reading from > both drives in paralel! Does anybody run multiple SATA drives in IDE-mode > without > problems under Plan9? > > [1] pci -v > 0.20.0: disk 01.80.01 1095/3112 15 0:0000fb01 16 1:0000fa01 16 > 2:0000f901 16 3:0000f801 16 4:0000f701 16 5:fdffd000 512 > Silicon Image, Inc. SiI 3112 SATALink/SATARaid Controller > > cinap yes. i have a cpu server with an nforce-based motherboard and two sata hard drives recognized as ide. i have never had a problem with the ide emulation on this motherboard. i think there is insufficient evidence to jump to the conclusion that plan 9 has trouble with >1 sata drive accessed via ide emulation. if linux uses ide emulation with the same ata commands & transfer sizes, do you get the same errors? (do you notice any performance funnies?) we have a sata protcol analyzer. we've seen some mighty interesting things with it. for instance, some hard drive firmware generates sata protocol violations when pushed hard. and some hard drive firmware generates sata protocol violations with very little load. generally hard drives, when they do this send a few data FISes but forget to finish the transaction. this causes the chipset to wait forever. this can look something like what you are seeing. on the other hand, there are reports of via chipsets having trouble dealing with concurrent access and we have also seen chipsets generating sata protocol violations. it could be that the linux driver has exactly this problem but notices that it's hung up and has a few tricky moves to get the device unstuck. - erik
--- End Message ---
