Hello, Владимир Дашевский wrote: >> I really don't follow your train of thoughts here. Are you saying >> that the driver should be optimistic about the reliability about >> status reported by the hardware even when it is inherently imprecise >> (please read the spec) and real world experiments prove that? >> > No. I ment that driver should performs better if the hardware supports > some features for that. Consider two different cases. > 1. hardware derives port population status by sensing the carrier in the > data link. In this case it is possible that some EMI noise can damage > link integrity so strongly that not data bits but also a carrier will be > lost for a short time. This will lead to 'port is not present' status > however noone has actually removed the drive. SATA is even weaker than this. If you put a machine under an EMI test, SATA links check out the first together with unshielded serial connections. > 2. Hardware implements some feature like pull-up resistor in USB, or > special shorter 'present' contact as in PCI or CPCI connectors, or it > simply senses some dc current through power lines etc. In this case port > status is robust over EMI noise and be used to inform driver of actual > connection. > My thought was to improve driver behavior in case 2, either autodetected > by PCI IDs or manually overriden by some configure script. There is no extra line in SATA connector. There are only two pairs of wires, one for each direction. Each pair is used to carry voltage differential. There is no common ground or closed circuits formed. The only thing which distinguishes an online link from an offline one is live signal on the receiving side, so the earlier mention of mechnical switch. ahci actually has support for it although I haven't seen any which actually implemented it. >> -EIO will happen to any processes trying to do IO on the removed >> device. fuser will find out who's using the block device but if you >> want something more intelligent, look at hal + dbus. >> > Hm, I tried to write fuser /dev/sda and got empty output. It seems that > file system does not open sda. How it works? No it won't show up and I can't really answer all your linux related questions. Sorry. :-P >> Ah.. in that case, you can do >> >> # echo - - - > /sys/class/scsi_host/hostN/scan >> > well, it works but it takes of about 10 seconds to finish scan for > deleted drive. is this ok? > Probably, that's because drive goes down after deletion and it starts to > spin up during this scan. Yeah, probably. >> Yeah, I know it has been in the spec but without hardware to play with >> it's difficult to add driver features and lack of general availability >> also means lower demand. >> > Well, I just cannot imagine how software raid can work without clearly > visible state. One drive mixed up in RAID5 and the whole array can get > damaged. And it is not so difficult to mix them up because drive names > may differ from physical slot numbers. Yeah, it can be tricky but highend machine usually go with sas and consumer grade machines don't really care, so there just aren't too many ahci machines with enclosure support. Well, not here anyway. >> I think it should be independent from RAID but having general >> enclosure support will be nice. Care to post the patches? >> >> > Well, I can provide you with a code which works on my ICH9 Supermicro > platform. I believe it will also work with both ICH8 and ICH10. > However, since I could not install this module as traditional pci driver > (the kernel decided not to claim my ahci device since the main driver > present in the system) I had to rewrite it as a general linux kernel > module. It justs scan pci devices for AHCI capable ones and remaps their > ABAR to try enclosure management support. For now, only my ICH9 PCI IDs > are in my try list. All AHCI EM-capable devices get their associated > proc interface - /proc/ahci_emX/leds*. This module actually works in > parallel with kernel ahci driver but I think it will be a conflict with > it once the kernel driver starts to support em by itself. I guess, the > best way would be to document some API for controlling the EM, then to > declare some kernel ahci flag that will indicate full EM presence in the > kernel. Then I can improve my ahci_em module to skip its installation > when similar functions are built into the kernel. > > My interface is quite simple. You just write a char to leds-controlling > proc file to set state of leds, for example: > echo r > /proc/ahci_em0/leds0 means you asked for REBUILD state > indicated in the bay of port 0. > I think that most of users would prefer additional module rather that > kernel udgrade, for the first time. Also, I am not very close to linux > kernel to provide a kernel patch. I don't think the design you described would fit into upstream kernel too well but if you have it working it's some place to start. Just refresh in on top of the current devel kernel and let's see what can be done. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
