Re: Intel azalia(4) and MSI
> Date: Wed, 14 Nov 2012 22:30:48 -0500 > From: Brad Smith > > On Fri, Sep 28, 2012 at 12:07:31AM -0400, Brad Smith wrote: > > On Fri, Sep 28, 2012 at 04:06:32AM +0200, Mark Kettenis wrote: > > > > Date: Mon, 24 Sep 2012 03:49:41 -0400 > > > > From: Brad Smith > > > > > > > > I've always wondered why this workaround was not removed once MSI > > > > support was added. This was added before we had MSI support to > > > > workaround some Intel azalia(4) being setup by the BIOS as far > > > > as I know to use MSI and thus interrupts on system that were > > > > affected by this did not work at all for azalia(4). > > > > > > Because there still are conditions under which we would not be able to > > > use MSI. > > > > I had 6 people reply off list indicating their Intel azalia controllers > > didn't seem to have any regressions with the previous diff applied. > > > > Can you expand upon this and explain what you mean. What are these > > conditions? It would be nice to mention what those conditions are > > within the comment. > > > > > Perhaps we should change the generic PCI code to explicitly disable > > > MSIs if they are turned on. But until we do that, this workaround > > > needs to stay in place. > > > > Since MSI is being disabled for the Intel azalia controller and the > > datasheet does confirm that is what this code is doing shouldn't > > we be telling the PCI layer MSI is disabled too like so? It doesn't > > make sense to have MSI disabled for the controller and then the > > PCI layer still thinking MSI should be used. You clearly don't understand how the code works. The flag indicates whether MSIs are supported by the host bridge (and the device). Not whether MSIs are actually enabled on the device. The PCI layer will turn MSIs back on if it decides to use them. We just want to make sure MSIs aren't accidentally enabled when we decide not to use them. Something that apparently happened on some machines with Intel HD Audio.
Re: Intel azalia(4) and MSI
On Fri, Sep 28, 2012 at 12:07:31AM -0400, Brad Smith wrote: > On Fri, Sep 28, 2012 at 04:06:32AM +0200, Mark Kettenis wrote: > > > Date: Mon, 24 Sep 2012 03:49:41 -0400 > > > From: Brad Smith > > > > > > I've always wondered why this workaround was not removed once MSI > > > support was added. This was added before we had MSI support to > > > workaround some Intel azalia(4) being setup by the BIOS as far > > > as I know to use MSI and thus interrupts on system that were > > > affected by this did not work at all for azalia(4). > > > > Because there still are conditions under which we would not be able to > > use MSI. > > I had 6 people reply off list indicating their Intel azalia controllers > didn't seem to have any regressions with the previous diff applied. > > Can you expand upon this and explain what you mean. What are these > conditions? It would be nice to mention what those conditions are > within the comment. > > > Perhaps we should change the generic PCI code to explicitly disable > > MSIs if they are turned on. But until we do that, this workaround > > needs to stay in place. > > Since MSI is being disabled for the Intel azalia controller and the > datasheet does confirm that is what this code is doing shouldn't > we be telling the PCI layer MSI is disabled too like so? It doesn't > make sense to have MSI disabled for the controller and then the > PCI layer still thinking MSI should be used. ping. > Index: azalia.c > === > RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v > retrieving revision 1.201 > diff -u -p -r1.201 azalia.c > --- azalia.c 12 Aug 2012 19:32:22 - 1.201 > +++ azalia.c 28 Sep 2012 02:17:31 - > @@ -515,6 +515,7 @@ azalia_pci_attach(struct device *parent, > > /* disable MSI, use INTx instead */ > if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_INTEL) { > + pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED; > reg = azalia_pci_read(sc->pc, sc->tag, ICH_PCI_MMC); > reg &= ~(ICH_PCI_MMC_ME); > azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg); -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Intel azalia(4) and MSI
On Fri, Sep 28, 2012 at 04:06:32AM +0200, Mark Kettenis wrote: > > Date: Mon, 24 Sep 2012 03:49:41 -0400 > > From: Brad Smith > > > > I've always wondered why this workaround was not removed once MSI > > support was added. This was added before we had MSI support to > > workaround some Intel azalia(4) being setup by the BIOS as far > > as I know to use MSI and thus interrupts on system that were > > affected by this did not work at all for azalia(4). > > Because there still are conditions under which we would not be able to > use MSI. I had 6 people reply off list indicating their Intel azalia controllers didn't seem to have any regressions with the previous diff applied. Can you expand upon this and explain what you mean. What are these conditions? It would be nice to mention what those conditions are within the comment. > Perhaps we should change the generic PCI code to explicitly disable > MSIs if they are turned on. But until we do that, this workaround > needs to stay in place. Since MSI is being disabled for the Intel azalia controller and the datasheet does confirm that is what this code is doing shouldn't we be telling the PCI layer MSI is disabled too like so? It doesn't make sense to have MSI disabled for the controller and then the PCI layer still thinking MSI should be used. Index: azalia.c === RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v retrieving revision 1.201 diff -u -p -r1.201 azalia.c --- azalia.c12 Aug 2012 19:32:22 - 1.201 +++ azalia.c28 Sep 2012 02:17:31 - @@ -515,6 +515,7 @@ azalia_pci_attach(struct device *parent, /* disable MSI, use INTx instead */ if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_INTEL) { + pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED; reg = azalia_pci_read(sc->pc, sc->tag, ICH_PCI_MMC); reg &= ~(ICH_PCI_MMC_ME); azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg); -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Intel azalia(4) and MSI
> Date: Mon, 24 Sep 2012 03:49:41 -0400 > From: Brad Smith > > I've always wondered why this workaround was not removed once MSI > support was added. This was added before we had MSI support to > workaround some Intel azalia(4) being setup by the BIOS as far > as I know to use MSI and thus interrupts on system that were > affected by this did not work at all for azalia(4). Because there still are conditions under which we would not be able to use MSI. Perhaps we should change the generic PCI code to explicitly disable MSIs if they are turned on. But until we do that, this workaround needs to stay in place. > Index: azalia.c > === > RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v > retrieving revision 1.200 > diff -u -p -r1.200 azalia.c > --- azalia.c 10 May 2012 22:46:48 - 1.200 > +++ azalia.c 2 Aug 2012 10:41:02 - > @@ -488,7 +488,6 @@ azalia_pci_attach(struct device *parent, > azalia_t *sc; > struct pci_attach_args *pa; > pcireg_t v; > - uint8_t reg; > pci_intr_handle_t ih; > const char *interrupt_str; > > @@ -511,13 +510,6 @@ azalia_pci_attach(struct device *parent, > sc->subid = pci_conf_read(pa->pa_pc, pa->pa_tag, PCI_SUBSYS_ID_REG); > > azalia_configure_pci(sc); > - > - /* disable MSI, use INTx instead */ > - if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_INTEL) { > - reg = azalia_pci_read(sc->pc, sc->tag, ICH_PCI_MMC); > - reg &= ~(ICH_PCI_MMC_ME); > - azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg); > - } > > /* interrupt */ > if (pci_intr_map_msi(pa, &ih) && pci_intr_map(pa, &ih)) { > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean.
Re: Intel azalia(4) and MSI
On 2012/09/24 03:49, Brad Smith wrote: > I've always wondered why this workaround was not removed once MSI > support was added. This was added before we had MSI support to > workaround some Intel azalia(4) being setup by the BIOS as far > as I know to use MSI and thus interrupts on system that were > affected by this did not work at all for azalia(4). > > If you have Intel azalia(4) could you please test this. Seems alright on X220. OpenBSD 5.2-current (GENERIC.MP) #0: Tue Sep 25 12:57:38 BST 2012 st...@bamboo.spacehopper.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8466853888 (8074MB) avail mem = 8219013120 (7838MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (66 entries) bios0: vendor LENOVO version "8DET63WW (1.33 )" date 07/19/2012 bios0: LENOVO 4287CTO acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2791.35 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2790.94 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF cpu1: 256KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2790.94 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF cpu2: 256KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2790.94 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF cpu3: 256KB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 5 (EXP4) acpiprt5 at acpi0: bus 13 (EXP5) acpiprt6 at acpi0: bus 14 (EXP7) acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model "42T4861" serial 12519 type LION oem "SANYO" acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 2791 MHz: speeds: 2801, 2800, 2600, 2400, 2200, 2000, 1800, 1600, 1400, 1200, 1000, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09 vga1 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0 at vga1: apic 2 int 16 drm0 at inteldrm0 "Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured puc0 at pci0 dev 22 function 3 "Intel 6 Series KT" rev 0x04: ports: 1 com com2 at puc0 port 0 apic 2 int 19: ns16550a, 16 byte fifo com2: probed fifo depth: 0 bytes em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address f0:de:f1:f9:a7:52 ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x04: apic 2 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 6 Series HD Audio" rev 0x04: msi azalia0: codecs: Conexant/0x506e, Intel/0x2805, using Conexant/0x506e audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb4: msi pci1 at ppb0 bus 2 ppb1 at pci0 dev 28 function 1 "Intel 6 Series PCIE" rev 0xb4: msi pci2 at ppb1 bus 3 iwn0 at pci2 dev
Intel azalia(4) and MSI
I've always wondered why this workaround was not removed once MSI support was added. This was added before we had MSI support to workaround some Intel azalia(4) being setup by the BIOS as far as I know to use MSI and thus interrupts on system that were affected by this did not work at all for azalia(4). If you have Intel azalia(4) could you please test this. Index: azalia.c === RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v retrieving revision 1.200 diff -u -p -r1.200 azalia.c --- azalia.c10 May 2012 22:46:48 - 1.200 +++ azalia.c2 Aug 2012 10:41:02 - @@ -488,7 +488,6 @@ azalia_pci_attach(struct device *parent, azalia_t *sc; struct pci_attach_args *pa; pcireg_t v; - uint8_t reg; pci_intr_handle_t ih; const char *interrupt_str; @@ -511,13 +510,6 @@ azalia_pci_attach(struct device *parent, sc->subid = pci_conf_read(pa->pa_pc, pa->pa_tag, PCI_SUBSYS_ID_REG); azalia_configure_pci(sc); - - /* disable MSI, use INTx instead */ - if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_INTEL) { - reg = azalia_pci_read(sc->pc, sc->tag, ICH_PCI_MMC); - reg &= ~(ICH_PCI_MMC_ME); - azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg); - } /* interrupt */ if (pci_intr_map_msi(pa, &ih) && pci_intr_map(pa, &ih)) { -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.