Bug 525240 - [Emulex 5.5 bug] dma mpas on virtual vc ports
Summary: [Emulex 5.5 bug] dma mpas on virtual vc ports
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.5
Hardware: All
OS: Linux
Target Milestone: alpha
: 5.5
Assignee: Mike Christie
QA Contact: Red Hat Kernel QE team
Depends On:
Blocks: 525241 533941
TreeView+ depends on / blocked
Reported: 2009-09-23 18:10 UTC by Mike Christie
Modified: 2009-12-08 14:54 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 525241 (view as bug list)
Last Closed: 2009-12-08 14:54:49 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Mike Christie 2009-09-23 18:10:30 UTC
Description of problem:

Several functions in scsi-ml assume the parent of the shost is the pci dev (or some dev with dma info). For FC vports this is not true. The parent would be the pci dev's scsi host dev.

James Smart has fixed these issues upstream:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 RHEL Program Management 2009-09-25 17:43:22 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 5 Andrius Benokraitis 2009-10-30 16:18:17 UTC
Emulex - would you happen to have an easy way to test this if provided a fix? thank you!

Comment 6 James Smart 2009-11-02 15:31:45 UTC
In our testing, we're finding the patches posted upstream are not working at all.  The issue is the dev->type==NULL check in the referenced patch (and the updated patch from James B).  Not only do the vport objects have a NULL type, but all pci endpoints and bridges match this.  We have constructed a new patch over the weekend, and are testing it now. Assuming success, we'll post upstream, and update this bug, as soon as possible.

Comment 7 Andrius Benokraitis 2009-11-02 16:43:35 UTC
James - just asking if you are cool to test/verify this bug on behalf of RH is all...

Comment 8 James Smart 2009-11-02 17:03:48 UTC
Yes - although, there will be affected hardware that we don't have (it affects all scsi hosts), so we our coverage isn't 100%. But, we can extrapolate based on what we do test that they will be fine.

My main purpose of the comment was to make sure everyone is aware there is an updated patch coming.

Comment 9 James Smart 2009-11-04 13:54:27 UTC
The corrected patch has been posted upstream:

This is the patch needed in RHEL.

Comment 11 Andrius Benokraitis 2009-12-01 22:11:14 UTC
Mike, how is this looking?

Comment 12 Mike Christie 2009-12-02 18:25:43 UTC

You do not need this patch for RHEL 5, right? The driver does not use scsi_dma_map/scsi_dma_unmap, so we should be ok I think.

Still need it for RHEL 6 though. I will send that shortly.

Comment 13 James Smart 2009-12-02 20:39:27 UTC
Yes, it is needed for RHEL5 (we've filed separate bugs for each rhel version - and this one is specific for 5.5, which needs it)

-- james

Comment 14 Mike Christie 2009-12-07 17:52:59 UTC
I am lost then. Do we just need this patch
for RHEL5 or is there something else still missing? If it is just that patch, I do not think there are any users of vports and scsi_dma_map/scsi_dma_unmap in RHEL5, so could not figure out who else needs it? Is there a lpfc update for RHEL5 that has it use scsi_dma_map/scsi_dma_unmap like RHEL6/upstream? Or is it needed for another scenario?

Comment 15 James Smart 2009-12-08 14:54:49 UTC
Mike,  It was me that was confused... you're right. RHEL5 is pre scsi_lib_dma.c and scsi_dma_map.  We're fine without the patch.  Sigh.  Sorry for the wild goose chase.  I'll close the bugzilla.

Note You need to log in before you can comment on or make changes to this bug.