disable 64-bit dma for one PCI slot only?

John Baldwin jhb at freebsd.org
Tue Jul 19 13:31:38 UTC 2011


On Monday, July 18, 2011 5:22:26 pm Scott Long wrote:
> 
> On Jul 18, 2011, at 3:14 PM, John Baldwin wrote:
> 
> > On Monday, July 18, 2011 5:06:40 pm Scott Long wrote:
> >> On Jul 18, 2011, at 12:02 PM, John Baldwin wrote:
> >>> On Friday, July 15, 2011 6:07:31 pm Mark McConnell wrote:
> >>>> Dear folks,
> >>>> 
> >>>> I have two LSI raid cards, one of which (SCSI 320-I) supports 
> >>>> 64-bit DMA when 4GB+ of DDR is present and another which 
> >>>> does not (SATA 150-D) .  Consquently I've disabled 64-bit 
> >>>> addressing for amr devices.
> >>>> 
> >>>> I would like to disable 64-bit addressing for the SATA card, but 
> >>>> permit it for the SCSI card.  Is this possible?
> >>> 
> >>> You'd have to hack the driver perhaps to only disable 64-bit DMA for certain 
> >>> PCI IDs.  It probably already does this?
> >>> 
> >> 
> >> The driver already had a table for determining 64bit DMA based on the PCI ID.
> >> I guess there's a mistake in the table for this particular card.  I think that
> >> changing the following line to remove the AMR_ID_DO_SG64 flag will fix the
> >> problem:
> >> 
> >>    {0x1000, 0x1960, AMR_ID_QUARTZ | AMR_ID_DO_SG64 | AMR_ID_PROBE_SIG},
> >> 
> >> Actually, what's probably going on is that the driver is only looking at the
> >> vendor and device id's, and is ignoring the subvendor and subdevice id's that
> >> would give it a better clue on the exact hardware in use.  Fixing the driver
> >> to look at all 64bits of id info (and take into account wildcards where
> >> needed) would be a good project, if anyone is interested.
> >> 
> >> Btw, I *HATE* the "chip" and "card" identifiers used in pciconf.  Can we
> >> change it to emit the standard (sub)vendor/(sub)device terminology?
> > 
> > Oh, yeah.  I hate that too.  Would you want them as 4 separate entities or to
> > just rename the labels to 'devid' and 'subdevid'?
> > 
> 
> If we're going to change it, might as well break it down into 4 fields.  Maybe
> we retain the old format under a legacy switch and/or env variable for users
> that have tools that parse the output (cough yahoo cough).

The only reason it might be nice to stick with two fields is due to the line
length (though the first line is over 80 cols even in the current format).  Here
are two possible suggestions:

old:

hostb0 at pci0:0:0:0:      class=0x060000 card=0x20108086 chip=0x01008086 rev=0x09 hdr=0x00
pcib1 at pci0:0:1:0:       class=0x060400 card=0x20108086 chip=0x01018086 rev=0x09 hdr=0x01
pcib2 at pci0:0:1:1:       class=0x060400 card=0x20108086 chip=0x01058086 rev=0x09 hdr=0x01
none0 at pci0:0:22:0:      class=0x078000 card=0x47428086 chip=0x1c3a8086 rev=0x04 hdr=0x00
em0 at pci0:0:25:0:        class=0x020000 card=0x00008086 chip=0x15038086 rev=0x04 hdr=0x00
...

A)

hostb0 at pci0:0:0:0:      class=0x060000 vendor=0x8086 device=0x0100 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x00
pcib1 at pci0:0:1:0:       class=0x060400 vendor=0x8086 device=0x0101 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01
pcib2 at pci0:0:1:1:       class=0x060400 vendor=0x8086 device=0x0105 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01
none0 at pci0:0:22:0:      class=0x078000 vendor=0x8086 device=0x1c3a subvendor=0x8086 subdevice=0x4742 rev=0x04 hdr=0x00
em0 at pci0:0:25:0:        class=0x020000 vendor=0x8086 device=0x1503 subvendor=0x8086 subdevice=0x0000 rev=0x04 hdr=0x00
...

B)

hostb0 at pci0:0:0:0:      class=0x060000 devid=0x8086:0100 subid=0x8086:2010 rev=0x09 hdr=0x00
pcib1 at pci0:0:1:0:       class=0x060400 devid=0x8086:0101 subid=0x8086:2010 rev=0x09 hdr=0x01
pcib2 at pci0:0:1:1:       class=0x060400 devid=0x8086:0105 subid=0x8086:2010 rev=0x09 hdr=0x01
none0 at pci0:0:22:0:      class=0x078000 devid=0x8086:1c3a subid=0x8086:4742 rev=0x04 hdr=0x00
em0 at pci0:0:25:0:        class=0x020000 devid=0x8086:1503 subid=0x8086:0000 rev=0x04 hdr=0x00
...

I went with vendor word first for both A) and B) as in my experience that is
the more common ordering in driver tables, etc.

-- 
John Baldwin


More information about the freebsd-stable mailing list