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 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
