Re: another msi blacklist candidate?

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