On 09/29/2009 04:39 PM, Mike Christie wrote: > On 09/29/2009 04:21 PM, Mike Christie wrote: >> On 09/29/2009 04:19 PM, Mike Christie wrote: >>> On 09/29/2009 02:03 PM, Joe Eykholt wrote: >>>> Joe Eykholt wrote: >>>>> The kernel no longer has symlinks where libhbalinux expected them. >>>>> I'm not sure which kernel version this was written for. >>>>> >>>>> Don't expect "/sys/class/fc_hosts/<hostx>" to be a symlink. >>>>> Change to look for the symlink "/sys/class/fc_hosts/<hostx>/device". >>>>> >>>>> Don't expect the strings "/net/" or "/virtual/net/" to be in the symlink. >>>>> >>>>> To find the real interface for a vlan, compare the iflink and ifindex. >>>>> If they are not the same, look for the interface who's ifindex matches >>>>> the iflink of the vlan. >>>>> >>>>> This is RFC until someone can test it against older kernels that might >>>>> need to be supported. This works on today's fcoe-next kernel with a >>>>> mix of fcoe and fnic. I also tried it with a mix of fcoe and >>>>> qla2xxx (without a vendor library for the latter, it is ignored). >>>> I tried this under RHEL5.4 and it works, although I wasn't able to test >>>> with VLANs. >>>> >>>> There is another somewhat-related issue that I ran across on RHEL5.4. >>>> The device passed to scsi_add_host() is from netdev->class_dev.dev->parent. >>>> I don't understand why that parent deref is there. For the enic driver, >>>> the parent is a bridge, so fcoeadm -i shows the bridge device. For ixgbe, >>>> I assume fcoeadm -i works correctly although I don't have a RHEL setup with >>>> ixgbe just now. So, is enic doing something wrong or is fcoe wrong? >>>> It seems to me that fcoe is wrong, but the parent deref must be there for >>>> a reason. Is the device supposed to be a net device instead of a pci >>>> device, >>>> such that the parent is usually the pci device? >>>> >>> scsi_add_host wants the device with dma settings/restrictions, so later > > One correction here. For vports with James's patch we do not have to > pass in the pci device, but I am not sure if the netdev will work either. > >>> in functions like scsi_alloc_queue/__scsi_alloc_queue it can set the >>> block/queue segment/dma/scatterlist settings with it. Does the netdev >>> device have that? Maybe for upstream it does and for RHEL 5 it did not. >>> I think for RHEL 5.4, there was a difference between what upstream >>> netdev device and what RHEL's netdev device have/are, because of the >> I mean I think (thought at the time) that upstream's netdev device >> pointed to the pci device, but in RHEL 5.4 the netdev->class_dev.dev > > Argh, I guess it looks like the upstream netdev device points to a net > device only. I see the netdev->dev.parent points to the pci device's device. > > For normal scsi drivers we pass the pci dev to scsi_add_host. When > vports are in use then with JamesS's dev_to_nonscsi_dev patch we can > pass in the device from the vport or scsi_host or whatever, and > dev_to_nonscsi_dev will find the first non scsi object. > > So if the netdev device does not have dma restrictions limits then what > we are passing into scsi_add_host is wrong for the non vport case, or
I miswrote that. If the netdev device does not have the dma restrictions then it is wrong for the vport and non vport case since the first non scsi object is going to be the netdevice device, and we want the pci device. > scsi-ml needs to be modified to find the parent with dma restrictions > for fcoe correctly. > _______________________________________________ > devel mailing list > [email protected] > http://www.open-fcoe.org/mailman/listinfo/devel _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
