On Mon, 2009-10-19 at 17:17 -0700, Robert Love wrote: > I've pulled out the obvious fixes from fcoe-next and applied them to > fcoe-fixes (scsi-rc-fixes based) and will mail them to linux-scsi for > the current RC phase. I then rebased fcoe-next to fcoe-fixes and applied > the remaining patches. > > While testing the updated series I could not get the stack to work with > the highmem patch. I'm not convinced that there's anything wrong with > the patch, it may just be exposing something else. I've removed it from > the tree until I can root-cause the issue I'm seeing. Other than that > all patches in both trees have passed my tests. > BTW: The problem was not in the highmem patch. The problem was that in fc_ct_fill() we were filling out the FC4 types (line 135 below), which we shouldn't have been.
131 case FC_NS_RPN_ID: 132 ct = fc_ct_hdr_fill(fp, op, sizeof(struct fc_ns_rn_id)); 133 hton24(ct->payload.rn.fr_fid.fp_fid, 134 fc_host_port_id(lport->host)); 135 ct->payload.rft.fts = lport->fcts; 136 put_unaligned_be64(lport->wwpn, &ct->payload.rn.fr_wwn); 137 break; The highmem patch introduced skb cloning and when assigning the FC4 types we were overwriting the reference count on the skb shared data. This line is removed in the "libfc: RPN_ID is obsolete and unnecessary" so as long as the highmem patch is after RPN_ID removal everything is fine. //Rob _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
