Current Issues with 2.6.15-rc5
Hello Everyone,
I'm concerned about the stability of the fibre channel infrastructure in 2.6.15-rc. There are current issues which I see effecting our (SGI's) customers' satisfaction. I feel that these issues must be addressed prior to the release of 2.6.15.
1 - fc transport change gets really noisy if targets disappear from
the fabric due to recursion on the workqueue. I've seen recursion depths > 40 and it's only really limited by the number of targets on a fibre channel fabric. It's unknown (to me) what side effects this recursion might have if the number of targets is in the hundreds, which is not uncommon for our customers. James Smart is aware of this and is working on a solution.
See my posting of 12/2/2005 and replies.
"2.6.15-rc4 error messages with multiple qla2300 hba ports on fabric".
2 - qlogic fibre channel driver no longer properly handles targets coming
and going. There is a race condition within the driver which can result in targets being deleted yet they are present and accounted for. This is a show stopper for SGI's customers. We have to have reliable target [re-]discovery. Andrew Vasquez is aware of this issue. See my posting on 12/5/2005. "qla2x00 driver serialization issue".
Quoted 5 lines · Andrew
Yes, I was afraid of something like this happening (due to qla2xxx detections of ports being dropped from an interrupt context)... Codes in
qla_rscn.calready queue-uprport_adds()via the standard kernel-workqueue:
Quoted 7 lines
qla_init.c: INIT_WORK(&fcport->rport_add_work, qla2x00_rport_add, fcport); qla_rscn.c: schedule_work(&fcport->rport_add_work);With the additions though, I'm wondering if adding a special single-cpu qla2xxx-rport workqueue would make sense (at least we could enforce serialization).
What can be done to assure fc stability in the 2.6.15 release? It appears that the revision of the fc-transport from 2.6.14 has caused some difficulty for a current driver, and potentially the entire system. Is it ready for prime time?
Mike Reed