Enabling MSI on the Asus Vintage AH-1
Pyun YongHyeon
pyunyh at gmail.com
Fri Dec 29 03:19:31 PST 2006
On Thu, Dec 28, 2006 at 03:50:54PM -0500, John Baldwin wrote:
> On Tuesday 26 December 2006 02:29, Pyun YongHyeon wrote:
> > On Mon, Dec 25, 2006 at 11:30:45PM -0500, Scott Long wrote:
> > > Pyun YongHyeon wrote:
> > > >On Sat, Dec 23, 2006 at 09:54:58PM +0000, Bruce M. Simpson wrote:
> > > > > Hi,
> > > > >
> > > > > It looks like MSI was detected, but not used by the msk(4) driver on
> > > > the > Asus Vintage AH-1.
> > > > >
> > > > > This is a uniprocessor Athlon64 system. The PCI bridges on this system
> > > > > aren't in the MSI blacklist, however, there are several odd messages
> > > > > regarding a non-default MSI window. Looking at the code suggests it
> > > > > expects to see the MSI window at 0xfee00000.
> > > > >
> > > > > BTW: This system's on-board SATA controller stopped working with
> > > > 6.2-RC, > so I'm using an add-on PCI-e card for SATA to connect the root
> > > > disk.
> > > > >
> > > > > pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> > > > > pci0: <ACPI PCI bus> on pcib0
> > > > > pci0: physical bus=0
> > > >
> > > >[...]
> > > >
> > > > > pcib2: <ACPI PCI-PCI bridge> at device 6.0 on pci0
> > > > > pcib2: secondary bus 2
> > > > > pcib2: subordinate bus 2
> > > > > pcib2: I/O decode 0xc000-0xcfff
> > > > > pcib2: memory decode 0xfe400000-0xfe4fffff
> > > > > pcib2: no prefetched decode
> > > > > pci2: <ACPI PCI bus> on pcib2
> > > > > pci2: physical bus=2
> > > > > found-> vendor=0x11ab, dev=0x4362, revid=0x19
> > > > > bus=2, slot=0, func=0
> > > > > class=02-00-00, hdrtype=0x00, mfdev=0
> > > > > cmdreg=0x0107, statreg=0x4010, cachelnsz=16 (dwords)
> > > > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> > > > > intpin=a, irq=5
> > > > > powerspec 2 supports D0 D1 D2 D3 current D0
> > > > > VPD Ident: Marvell Yukon 88E8053 Gigabit Ethernet Controller
> > > > > PN: Yukon 88E8053
> > > > > EC: Rev. 1.9
> > > > > MN: Marvell
> > > > > SN: AbCdEfG32a88a
> > > > > CP: id 1, BAR16, off 0x3cc
> > > > > RV: 0x24
> > > > > MSI supports 2 messages, 64 bit
> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > >I think Yukon II supports one MSI message. But all systems I know
> > > >reported that it supports two MSI messages. This is main reason why
> > > >msk(4) doesn't use MSI ATM. I don't know why Yukon II claims to
> > > >support two MSI messages.(for dual port MAC configuraiton?)
> > >
> > > My guess is that it advertises 2 messages for the dual-port
> > > configuration. The intention is probably that the driver would
> > > run a loop where it allocates a message as it configures each port.
> > > So if you only have a single port, then you only allocate a single
> > > message and ignore the other one. This looks like it will be hard to
> > > fit into the msk+mskc code that is there right now.
> > >
> > > >
> > > >You can force to use MSI by assigning 'msic = 1' before calling
> > > >pci_alloc_msi(9) in mskc_attach(). However it wouldn't work if you
> > > >reload the msk(4) again. Other than that it works well with MSI.
> > >
> > > I don't understand why there would be a failure here. Can you explain?
> > >
> >
> > Me too.
> >
> > I don't remember what message it was but it's somthing like
> > a message with two irq numbers for the device on second loading
> > and then it failed to allocate interrupt handler.
> >
> > mskc0: <Marvell Yukon 88E8053 Gigabit Ethernet> port 0xXXXX-0xYYYY mem
> > 0xXXXXXXXX-0xYYYYYYYY irq 19, 256 at device X.Y on pciX
> > ^^^^^^^^^^^
>
> You need to do the pci_release_msi() after releasing the SYS_RES_IRQ resource.
> Also, to support MSI-X parts, you need to alloc your SYS_RES_MEMORY resource
> before you call pci_alloc_msi(). The patch below fixes much of this, but
> disables MSI for the dual port cards for now since I didn't want to untangle
> all the interrupt code to create separate MSI handlers for each port. You
> also have a bug in your task where it seems that if you ifconfig the first
> port on a dual port card down, you won't ever handle interrupts for the
> second port:
>
> if (sc_if0 != NULL) {
> ifp0 = sc_if0->msk_ifp;
> if ((ifp0->if_drv_flags & IFF_DRV_RUNNING) == 0)
> goto done;
> }
> if (sc_if1 != NULL) {
> ifp1 = sc_if1->msk_ifp;
> if ((ifp1->if_drv_flags & IFF_DRV_RUNNING) == 0)
> goto done;
> }
>
> Since RUNNING would be clear for ifp0, you would goto done and not handle
Possible fix committed. Needs more testing for dual port card.
> any of the events for ifp1. Anyways, here is the patch I came up with so
> far:
>
Thank you very much for taking care of this!
Patch committed.
--
Regards,
Pyun YongHyeon
More information about the freebsd-current
mailing list