Re: Enabling MSI on the Asus Vintage AH-1

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