another msi blacklist candidate?

[Scott Long]

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.

Scott