Re: another msi blacklist candidate?

On 1/21/07, Scott Long <scottl_at_samsco.org> wrote:
> Jack Vogel wrote:
> > On 1/20/07, Scott Long <scottl_at_samsco.org> wrote:
> >> Jack Vogel wrote:
> >> > On 1/20/07, John Baldwin <jhb_at_freebsd.org> wrote:
> >> >> On Friday 19 January 2007 13:55, Jack Vogel wrote:
> >> >> > On 1/19/07, Mark Atkinson <atkin901_at_yahoo.com> wrote:
> >> >> > > I upgraded a box to -current yesterday with the following pci card
> >> >> in it,
> >> >> > > (this is the msi disabled verbose boot below) but upon bootup, any
> >> >> heavy
> >> >> > > network activity caused watchdog timeouts and resets.   Disabling
> >> >> msi via
> >> >> > > the two tunables fixed the problem.
> >> >> > >
> >> >> > > What info do you need on this problem?
> >> >> > >
> >> >> > > found-> vendor=0x8086, dev=0x1076, revid=0x00
> >> >> > >         bus=4, slot=2, func=0
> >> >> > >         class=02-00-00, hdrtype=0x00, mfdev=0
> >> >> > >         cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords)
> >> >> > >         lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns),
> >> >> maxlat=0x00 (0 ns)
> >> >> > >         intpin=a, irq=10
> >> >> > >         powerspec 2  supports D0 D3  current D0
> >> >> > >         MSI supports 1 message, 64 bit
> >> >> > >         map[10]: type 1, range 32, base 0xdf9c0000, size 17,
> >> enabled
> >> >> > > pcib4: requested memory range 0xdf9c0000-0xdf9dffff: good
> >> >> > >         map[14]: type 1, range 32, base 0xdf9e0000, size 17,
> >> enabled
> >> >> > > pcib4: requested memory range 0xdf9e0000-0xdf9fffff: good
> >> >> > >         map[18]: type 4, range 32, base 0xdcc0, size  6, enabled
> >> >> > > pcib4: requested I/O range 0xdcc0-0xdcff: in range
> >> >> > > pcib4: matched entry for 4.2.INTA
> >> >> > > pcib4: slot 2 INTA hardwired to IRQ 18
> >> >> > > em0: <Intel(R) PRO/1000 Network Connection Version - 6.2.9> port
> >> >> > > 0xdcc0-0xdcff m
> >> >> > > em 0xdf9c0000-0xdf9dffff,0xdf9e0000-0xdf9fffff irq 18 at device
> >> >> 2.0 on pci4
> >> >> > > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdf9c0000
> >> >> > > em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdcc0
> >> >> > > em0: bpf attached
> >> >> > > em0: Ethernet address: 00:0e:0c:6e:a1:39
> >> >> > > em0: [FAST]
> >> >> >
> >> >> > Talked about this internally, and the advise here is that the em
> >> >> driver change
> >> >> > so that only PCI-E adapters can use MSI, this would eliminate the
> >> >> need to
> >> >> > blacklist in the kernel PCI code.
> >> >>
> >> >> It's not em(4) that is the problem, but the system, and I'd rather we
> >> >> fix it
> >> >> generically rather than in each driver.  Maybe we should disable MSI
> >> >> for non-PCIe
> >> >> systems?
> >> >
> >> > Depends what that means, say a system HAS PCI-E, but also a PCI and/or
> >> > a PCI-X slot will MSI be unavailable in those slots, that's what I
> >> would
> >> > prefer.
> >> >
> >> > Jack
> >>
> >> Are you saying that MSI should only be available to PCIe devices?  That
> >> will break legitimate PCI-X devices.
> >
> > True, the question is how many of those devices are problematic and need
> > blacklisting anyway? I don't have a feel for this, do you Scott?
> >
> > Jack
>
> It's up to the driver writers to keep tabs on their peripherals.  If the
> Intel 12345 PCI-X NIC can't do MSI but the Intel 23456 PCI-X NIC can,
> then it's up to the driver to know that.  Chipset support is the
> responsibility of the OS, and that's where it gets more difficult
> because MSI is still fairly immature on the x86/x64 platform.
>
> Scott
>

LOL, this conversation started because I said I was going to disallow
some adapters from MSI and John said it should be in the OS not
all the drivers :)

I'm happy to do it the way I planned at first anyway :)

Jack