* Re: [patch] PCI: disable MSI on more ATI NorthBridges [not found] <BLU112-W5125F6D8BEB3DF6359D53E29F0@phx.gbl> @ 2007-10-19 19:57 ` Linas Vepstas 2007-10-19 20:21 ` Jeff Garzik 2007-10-20 14:50 ` Shane Huang 0 siblings, 2 replies; 18+ messages in thread From: Linas Vepstas @ 2007-10-19 19:57 UTC (permalink / raw) To: Shane Huang Cc: davem, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, jgarzik, linux-ide On Fri, Oct 19, 2007 at 09:17:23PM +0800, Shane Huang wrote: > Since we have little experience on PCI and MSI here, we had to try to As someone else pointed out, AMD should have *lots* of people with pci and msi experience on the payroll. (Folks here buy AMD-designed pci chips ...) > ONLY > comment out the pci_intx() call in drivers/ata/ahci.c > My system can boot up too with MSI enabled! > > So does it mean that the root cause is our SB700 SATA controller > has a hardware bug where setting INTX_DISABLE in the PCI COMMAND > register masks MSI interrupts too? That's what it sounds like, to me. > And what is the software solution or workaround? Not sure. Sounds like the device driver needs a quirk for this part. The over-worked Jeff Garzik is the maintainer for that driver. You should probably provide the pci device id for this beast. --linas ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-19 19:57 ` [patch] PCI: disable MSI on more ATI NorthBridges Linas Vepstas @ 2007-10-19 20:21 ` Jeff Garzik 2007-10-20 22:03 ` Benjamin Herrenschmidt 2007-10-22 20:26 ` Daniel Barkalow 2007-10-20 14:50 ` Shane Huang 1 sibling, 2 replies; 18+ messages in thread From: Jeff Garzik @ 2007-10-19 20:21 UTC (permalink / raw) To: Linas Vepstas Cc: Shane Huang, davem, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, Brice Goglin Linas Vepstas wrote: > On Fri, Oct 19, 2007 at 09:17:23PM +0800, Shane Huang wrote: >> Since we have little experience on PCI and MSI here, we had to try to > > As someone else pointed out, AMD should have *lots* of people with > pci and msi experience on the payroll. (Folks here buy AMD-designed > pci chips ...) > >> ONLY >> comment out the pci_intx() call in drivers/ata/ahci.c >> My system can boot up too with MSI enabled! >> >> So does it mean that the root cause is our SB700 SATA controller >> has a hardware bug where setting INTX_DISABLE in the PCI COMMAND >> register masks MSI interrupts too? > > That's what it sounds like, to me. > >> And what is the software solution or workaround? > > Not sure. Sounds like the device driver needs a quirk for this part. Take a look at tg3.c net driver change 2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 which is a similar situation. However, it may turn out that removing the pci_intx() stuff as a general rule is easier than quirking these devices, if enough of them turn out to have this hardware bug. The tg3.c change should illustrate how to fix immediately, though. Jeff ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-19 20:21 ` Jeff Garzik @ 2007-10-20 22:03 ` Benjamin Herrenschmidt 2007-10-22 20:26 ` Daniel Barkalow 1 sibling, 0 replies; 18+ messages in thread From: Benjamin Herrenschmidt @ 2007-10-20 22:03 UTC (permalink / raw) To: Jeff Garzik Cc: Linas Vepstas, Shane Huang, davem, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, Brice Goglin On Fri, 2007-10-19 at 16:21 -0400, Jeff Garzik wrote: > Take a look at tg3.c net driver change > 2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 which is a similar situation. > > However, it may turn out that removing the pci_intx() stuff as a > general > rule is easier than quirking these devices, if enough of them turn > out > to have this hardware bug. We'd have to count how many have this bug vs. how many will emit both intx and msi unless pci_intx is cleared, and then how many do that regardless of pci_intx :-) yuck Ben. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-19 20:21 ` Jeff Garzik 2007-10-20 22:03 ` Benjamin Herrenschmidt @ 2007-10-22 20:26 ` Daniel Barkalow 2007-10-22 20:41 ` Jeff Garzik 1 sibling, 1 reply; 18+ messages in thread From: Daniel Barkalow @ 2007-10-22 20:26 UTC (permalink / raw) To: Jeff Garzik Cc: Linas Vepstas, Shane Huang, davem, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, Brice Goglin On Fri, 19 Oct 2007, Jeff Garzik wrote: > Linas Vepstas wrote: > > On Fri, Oct 19, 2007 at 09:17:23PM +0800, Shane Huang wrote: > > > Since we have little experience on PCI and MSI here, we had to try to > > > > As someone else pointed out, AMD should have *lots* of people with > > pci and msi experience on the payroll. (Folks here buy AMD-designed pci > > chips ...) > > > > > ONLY > > > comment out the pci_intx() call in drivers/ata/ahci.c > > > My system can boot up too with MSI enabled! > > > > > > So does it mean that the root cause is our SB700 SATA controller > > > has a hardware bug where setting INTX_DISABLE in the PCI COMMAND > > > register masks MSI interrupts too? > > > > That's what it sounds like, to me. > > > > > And what is the software solution or workaround? > > > > Not sure. Sounds like the device driver needs a quirk for this part. > > > Take a look at tg3.c net driver change > 2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 which is a similar situation. > > However, it may turn out that removing the pci_intx() stuff as a general rule > is easier than quirking these devices, if enough of them turn out to have this > hardware bug. At a first approximation, ATI/AMD devices don't send any interrupts if intx is disabled, nVidia devices send legacy interrupts in addition to MSI ones if intx isn't disabled, and Intel devices actually work correctly. So we need at least one kind of device quirk for intx and msi. (And doing it in the drivers doesn't work, since everybody is making things driven by snd_hda_intel and would like msi, afaict) -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-22 20:26 ` Daniel Barkalow @ 2007-10-22 20:41 ` Jeff Garzik 2007-10-22 21:31 ` Daniel Barkalow 2007-10-22 23:40 ` Krzysztof Halasa 0 siblings, 2 replies; 18+ messages in thread From: Jeff Garzik @ 2007-10-22 20:41 UTC (permalink / raw) To: Daniel Barkalow Cc: Linas Vepstas, Shane Huang, davem, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, Brice Goglin Daniel Barkalow wrote: > On Fri, 19 Oct 2007, Jeff Garzik wrote: > >> Linas Vepstas wrote: >>> On Fri, Oct 19, 2007 at 09:17:23PM +0800, Shane Huang wrote: >>>> Since we have little experience on PCI and MSI here, we had to try to >>> As someone else pointed out, AMD should have *lots* of people with >>> pci and msi experience on the payroll. (Folks here buy AMD-designed pci >>> chips ...) >>> >>>> ONLY >>>> comment out the pci_intx() call in drivers/ata/ahci.c >>>> My system can boot up too with MSI enabled! >>>> >>>> So does it mean that the root cause is our SB700 SATA controller >>>> has a hardware bug where setting INTX_DISABLE in the PCI COMMAND >>>> register masks MSI interrupts too? >>> That's what it sounds like, to me. >>> >>>> And what is the software solution or workaround? >>> Not sure. Sounds like the device driver needs a quirk for this part. >> >> Take a look at tg3.c net driver change >> 2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 which is a similar situation. >> >> However, it may turn out that removing the pci_intx() stuff as a general rule >> is easier than quirking these devices, if enough of them turn out to have this >> hardware bug. > > At a first approximation, ATI/AMD devices don't send any interrupts if > intx is disabled, nVidia devices send legacy interrupts in addition to MSI > ones if intx isn't disabled, and Intel devices actually work correctly. So > we need at least one kind of device quirk for intx and msi. (And doing it > in the drivers doesn't work, since everybody is making things driven by > snd_hda_intel and would like msi, afaict) Note that INTX_DISABLE is a recent addition to PCI. Older PCI devices support neither MSI nor INTX-disable, so make sure such devices don't creep into your sample. In general it is documented that INTX_DISABLE should apply only to INTx# so devices that disable MSI based on that bit are out of spec. But unfortunately that is rather irrelevant, since we see these out-of-spec devices in the field today. Jeff ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-22 20:41 ` Jeff Garzik @ 2007-10-22 21:31 ` Daniel Barkalow 2007-10-22 23:48 ` Krzysztof Halasa ` (2 more replies) 2007-10-22 23:40 ` Krzysztof Halasa 1 sibling, 3 replies; 18+ messages in thread From: Daniel Barkalow @ 2007-10-22 21:31 UTC (permalink / raw) To: Jeff Garzik Cc: Linas Vepstas, Shane Huang, davem, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, Brice Goglin On Mon, 22 Oct 2007, Jeff Garzik wrote: > Daniel Barkalow wrote: > > On Fri, 19 Oct 2007, Jeff Garzik wrote: > > > > > Linas Vepstas wrote: > > > > On Fri, Oct 19, 2007 at 09:17:23PM +0800, Shane Huang wrote: > > > > > Since we have little experience on PCI and MSI here, we had to try to > > > > As someone else pointed out, AMD should have *lots* of people with > > > > pci and msi experience on the payroll. (Folks here buy AMD-designed pci > > > > chips ...) > > > > > > > > > ONLY > > > > > comment out the pci_intx() call in drivers/ata/ahci.c > > > > > My system can boot up too with MSI enabled! > > > > > > > > > > So does it mean that the root cause is our SB700 SATA controller > > > > > has a hardware bug where setting INTX_DISABLE in the PCI COMMAND > > > > > register masks MSI interrupts too? > > > > That's what it sounds like, to me. > > > > > > > > > And what is the software solution or workaround? > > > > Not sure. Sounds like the device driver needs a quirk for this part. > > > > > > Take a look at tg3.c net driver change > > > 2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 which is a similar situation. > > > > > > However, it may turn out that removing the pci_intx() stuff as a general > > > rule > > > is easier than quirking these devices, if enough of them turn out to have > > > this > > > hardware bug. > > > > At a first approximation, ATI/AMD devices don't send any interrupts if intx > > is disabled, nVidia devices send legacy interrupts in addition to MSI ones > > if intx isn't disabled, and Intel devices actually work correctly. So we > > need at least one kind of device quirk for intx and msi. (And doing it in > > the drivers doesn't work, since everybody is making things driven by > > snd_hda_intel and would like msi, afaict) > > Note that INTX_DISABLE is a recent addition to PCI. Older PCI devices support > neither MSI nor INTX-disable, so make sure such devices don't creep into your > sample. I have a device that supports MSI and INTX-disable, and, with MSI on (and delivering interrupts successfully) also sends legacy interrupts (on the IRQ that is no longer associated with the device) unless INTX is disabled. Without the intx_disable(), the kernel disables the IRQ entirely and breaks a random other device in my system. It's: 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) I haven't tried MSI with the other devices in the system, but I expect that this: 00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2) will have the same issue, and use a multi-vendor driver. > In general it is documented that INTX_DISABLE should apply only to INTx# so > devices that disable MSI based on that bit are out of spec. But unfortunately > that is rather irrelevant, since we see these out-of-spec devices in the field > today. It's likewise documented (although maybe arguable in wording) that the device shouldn't send legacy interrupts if MSI is in use, regardless of INTX_DISABLE, but this also happens in the field. I think that the current Linux behavior with respect to INTX_DISABLE is simply due to which hardware bug was present in the device whose driver first got Linux support, but one or the other or both needs a quirk, since there's no behavior that works with everything. And it's still impossible to tell which bug is more common, since MSI isn't used most of the time, even if the hardware supports it, so it's pretty arbitrary which way Linux goes in the non-quirk case. -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-22 21:31 ` Daniel Barkalow @ 2007-10-22 23:48 ` Krzysztof Halasa 2007-10-23 0:13 ` David Miller 2007-10-23 10:15 ` Jeff Garzik 2 siblings, 0 replies; 18+ messages in thread From: Krzysztof Halasa @ 2007-10-22 23:48 UTC (permalink / raw) To: Daniel Barkalow Cc: Jeff Garzik, Linas Vepstas, Shane Huang, davem, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, Brice Goglin Daniel Barkalow <barkalow@iabervon.org> writes: > 00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2) > > will have the same issue, and use a multi-vendor driver. I think MCP55 HDA did not have such problem, though I may be wrong (AFAIR it worked with shared IRQ and with MSI). -- Krzysztof Halasa ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-22 21:31 ` Daniel Barkalow 2007-10-22 23:48 ` Krzysztof Halasa @ 2007-10-23 0:13 ` David Miller 2007-10-23 5:52 ` Daniel Barkalow ` (2 more replies) 2007-10-23 10:15 ` Jeff Garzik 2 siblings, 3 replies; 18+ messages in thread From: David Miller @ 2007-10-23 0:13 UTC (permalink / raw) To: barkalow Cc: jeff, linas, chunhao.huang, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, brice From: Daniel Barkalow <barkalow@iabervon.org> Date: Mon, 22 Oct 2007 17:31:04 -0400 (EDT) > It's likewise documented (although maybe arguable in wording) that the > device shouldn't send legacy interrupts if MSI is in use, regardless of > INTX_DISABLE, but this also happens in the field. > > I think that the current Linux behavior with respect to INTX_DISABLE is > simply due to which hardware bug was present in the device whose driver > first got Linux support, but one or the other or both needs a quirk, since > there's no behavior that works with everything. And it's still impossible > to tell which bug is more common, since MSI isn't used most of the time, > even if the hardware supports it, so it's pretty arbitrary which way Linux > goes in the non-quirk case. I think this pretty much sums up the situation accurately. My suggestion is: 1) Leave the pci_intx() twiddling code in drivers/pci/msi.c 2) Add quirks for "INTX_DISABLE turns off MSI too", this sets a flag in the pci_dev. 3) The pci_intx() calls in drivers/pci/msi.c are skipped if this flag from #2 is set. 4) Add quirk entries for drivers/net/tg3.c chips and these SATA devices we are learning about here, as well as any others we are aware of right now. 5) Remove the pci_intx() workaround code from drivers/net/tg3.c and elsewhere. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-23 0:13 ` David Miller @ 2007-10-23 5:52 ` Daniel Barkalow 2007-10-23 9:39 ` Shane Huang 2007-10-23 10:01 ` Jeff Garzik 2 siblings, 0 replies; 18+ messages in thread From: Daniel Barkalow @ 2007-10-23 5:52 UTC (permalink / raw) To: David Miller Cc: jeff, linas, chunhao.huang, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, brice On Mon, 22 Oct 2007, David Miller wrote: > My suggestion is: > > 1) Leave the pci_intx() twiddling code in drivers/pci/msi.c > > 2) Add quirks for "INTX_DISABLE turns off MSI too", this sets > a flag in the pci_dev. > > 3) The pci_intx() calls in drivers/pci/msi.c are skipped if this > flag from #2 is set. > > 4) Add quirk entries for drivers/net/tg3.c chips and these SATA > devices we are learning about here, as well as any others we > are aware of right now. > > 5) Remove the pci_intx() workaround code from drivers/net/tg3.c > and elsewhere. Seems right to me, and pretty straightforward, except that I don't really understand the pm-related logic in there to know how that should work and whether intx will need to be enabled somewhere in addition to not disabling it in the msi enable code. -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-23 0:13 ` David Miller 2007-10-23 5:52 ` Daniel Barkalow @ 2007-10-23 9:39 ` Shane Huang 2007-10-23 10:01 ` Jeff Garzik 2 siblings, 0 replies; 18+ messages in thread From: Shane Huang @ 2007-10-23 9:39 UTC (permalink / raw) To: David Miller, barkalow Cc: jeff, linas, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, linux-ide, brice, Shane Huang Hi David: > I think this pretty much sums up the situation accurately. > > My suggestion is: > > 1) Leave the pci_intx() twiddling code in drivers/pci/msi.c > > 2) Add quirks for "INTX_DISABLE turns off MSI too", this sets > a flag in the pci_dev. > > 3) The pci_intx() calls in drivers/pci/msi.c are skipped if this > flag from #2 is set. > > 4) Add quirk entries for drivers/net/tg3.c chips and these SATA > devices we are learning about here, as well as any others we > are aware of right now. > > 5) Remove the pci_intx() workaround code from drivers/net/tg3.c > and elsewhere. This quirk seems good to me. Waiting for your final decision.... This SB700 SATA controller MSI/INTx problem has been reported to our hardware team. I will forward the update information or response to you when I get any from HW team. Thanks Shane ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-23 0:13 ` David Miller 2007-10-23 5:52 ` Daniel Barkalow 2007-10-23 9:39 ` Shane Huang @ 2007-10-23 10:01 ` Jeff Garzik 2007-10-23 10:06 ` David Miller 2 siblings, 1 reply; 18+ messages in thread From: Jeff Garzik @ 2007-10-23 10:01 UTC (permalink / raw) To: David Miller Cc: barkalow, linas, chunhao.huang, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, brice David Miller wrote: > My suggestion is: > > 1) Leave the pci_intx() twiddling code in drivers/pci/msi.c > > 2) Add quirks for "INTX_DISABLE turns off MSI too", this sets > a flag in the pci_dev. > > 3) The pci_intx() calls in drivers/pci/msi.c are skipped if this > flag from #2 is set. > > 4) Add quirk entries for drivers/net/tg3.c chips and these SATA > devices we are learning about here, as well as any others we > are aware of right now. > > 5) Remove the pci_intx() workaround code from drivers/net/tg3.c > and elsewhere. Sounds good to me also. Jeff ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-23 10:01 ` Jeff Garzik @ 2007-10-23 10:06 ` David Miller 2007-10-24 2:46 ` David Miller 0 siblings, 1 reply; 18+ messages in thread From: David Miller @ 2007-10-23 10:06 UTC (permalink / raw) To: jeff Cc: barkalow, linas, chunhao.huang, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, brice From: Jeff Garzik <jeff@garzik.org> Date: Tue, 23 Oct 2007 06:01:17 -0400 > David Miller wrote: > > My suggestion is: ... > Sounds good to me also. Ok, it seems I've sort-of self-nominated myself to implement this so I'll try to work on it tomorrow :-) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-23 10:06 ` David Miller @ 2007-10-24 2:46 ` David Miller 0 siblings, 0 replies; 18+ messages in thread From: David Miller @ 2007-10-24 2:46 UTC (permalink / raw) To: jeff Cc: barkalow, linas, chunhao.huang, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, brice From: David Miller <davem@davemloft.net> Date: Tue, 23 Oct 2007 03:06:22 -0700 (PDT) > Ok, it seems I've sort-of self-nominated myself to implement > this so I'll try to work on it tomorrow :-) I have a working implementation, fully tested on a machine with Tigon3 ethernet chips that have the quirk in question. Patch set coming up next. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-22 21:31 ` Daniel Barkalow 2007-10-22 23:48 ` Krzysztof Halasa 2007-10-23 0:13 ` David Miller @ 2007-10-23 10:15 ` Jeff Garzik 2 siblings, 0 replies; 18+ messages in thread From: Jeff Garzik @ 2007-10-23 10:15 UTC (permalink / raw) To: Daniel Barkalow Cc: Linas Vepstas, Shane Huang, davem, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, Brice Goglin Daniel Barkalow wrote: > I have a device that supports MSI and INTX-disable, and, with MSI on (and > delivering interrupts successfully) also sends legacy interrupts (on > the IRQ that is no longer associated with the device) unless INTX is > disabled. Without the intx_disable(), the kernel disables the IRQ > entirely and breaks a random other device in my system. That sort of behavior is an example of why I wrote pci_intx() in the first place, and employed it by default throughout the ATA drivers (before it migrated into PCI core). Jeff ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-22 20:41 ` Jeff Garzik 2007-10-22 21:31 ` Daniel Barkalow @ 2007-10-22 23:40 ` Krzysztof Halasa 2007-10-22 23:58 ` David Miller 2007-10-23 10:13 ` Jeff Garzik 1 sibling, 2 replies; 18+ messages in thread From: Krzysztof Halasa @ 2007-10-22 23:40 UTC (permalink / raw) To: Jeff Garzik Cc: Daniel Barkalow, Linas Vepstas, Shane Huang, davem, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, Brice Goglin Jeff Garzik <jeff@garzik.org> writes: > Note that INTX_DISABLE is a recent addition to PCI. It's PCI 2.3. > Older PCI devices > support neither MSI nor INTX-disable, so make sure such devices don't > creep into your sample. MSI has been introduced by PCI 2.2 (and thus PCI-X 1.0) so there may be devices with MSI but without INTx-disable bit. I guess I have some early PCI-X hardware with MSI but I don't know if they have INTx-disable bit and I can't currently test that. And it probably doesn't matter. > In general it is documented that INTX_DISABLE should apply only to > INTx# so devices that disable MSI based on that bit are out of spec. The wording is: 10: This bit disables the device from asserting INTx#. A value of 0 enables the assertion of its INTx# signal. A value of 1 disables the assertion of its INTx# signal. This bit's state after RST# is 0. Refer to Section 6.8.1.3 for control of MSI. So strictly speaking it mandates disabling/enabling INTx but says nothing about other things (e.g. MSI). Some common sense dictates it shouldn't disable MSI, I guess. The "MSI Enable" description doesn't leave any doubt: 0: MSI Enable: If 1, the function is permitted to use MSI to request service and is prohibited from using its INTx# pin [...] > But unfortunately that is rather irrelevant, since we see these > out-of-spec devices in the field today. Right. -- Krzysztof Halasa ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-22 23:40 ` Krzysztof Halasa @ 2007-10-22 23:58 ` David Miller 2007-10-23 10:13 ` Jeff Garzik 1 sibling, 0 replies; 18+ messages in thread From: David Miller @ 2007-10-22 23:58 UTC (permalink / raw) To: khc Cc: jeff, barkalow, linas, chunhao.huang, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, brice From: Krzysztof Halasa <khc@pm.waw.pl> Date: Tue, 23 Oct 2007 01:40:18 +0200 > Jeff Garzik <jeff@garzik.org> writes: > > > In general it is documented that INTX_DISABLE should apply only to > > INTx# so devices that disable MSI based on that bit are out of spec. > > The wording is: > 10: This bit disables the device from asserting INTx#. A value of 0 > enables the assertion of its INTx# signal. A value of 1 disables the > assertion of its INTx# signal. This bit's state after RST# is 0. Refer > to Section 6.8.1.3 for control of MSI. > > So strictly speaking it mandates disabling/enabling INTx but says > nothing about other things (e.g. MSI). Some common sense dictates > it shouldn't disable MSI, I guess. Right, and every vendor I've spoken to who had the INTX_DISABLE bug clearly acknowledged that it was a bug in their RTL design and that they considered the spec to be clear on this matter in that INTX_DISABLE should not influence MSI in any way. > The "MSI Enable" description doesn't leave any doubt: > 0: MSI Enable: If 1, the function is permitted to use MSI to request > service and is prohibited from using its INTx# pin [...] Things get more complicated with PCI-Express because INTx# isn't an out-of-band "pin", but rather a message sent over the bus :-) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-22 23:40 ` Krzysztof Halasa 2007-10-22 23:58 ` David Miller @ 2007-10-23 10:13 ` Jeff Garzik 1 sibling, 0 replies; 18+ messages in thread From: Jeff Garzik @ 2007-10-23 10:13 UTC (permalink / raw) To: Krzysztof Halasa Cc: Daniel Barkalow, Linas Vepstas, Shane Huang, davem, gregkh, htejun, brice.goglin, david.gaarenstroom, linux-kernel, linux-pci, shane.huang, linux-ide, Brice Goglin Krzysztof Halasa wrote: > Jeff Garzik <jeff@garzik.org> writes: > >> Note that INTX_DISABLE is a recent addition to PCI. > > It's PCI 2.3. Yes. >> Older PCI devices >> support neither MSI nor INTX-disable, so make sure such devices don't >> creep into your sample. > > MSI has been introduced by PCI 2.2 (and thus PCI-X 1.0) so there may > be devices with MSI but without INTx-disable bit. I guess I have some > early PCI-X hardware with MSI but I don't know if they have INTx-disable > bit and I can't currently test that. > And it probably doesn't matter. Time will tell :) >> In general it is documented that INTX_DISABLE should apply only to >> INTx# so devices that disable MSI based on that bit are out of spec. > > The wording is: > 10: This bit disables the device from asserting INTx#. A value of 0 > enables the assertion of its INTx# signal. A value of 1 disables the > assertion of its INTx# signal. This bit's state after RST# is 0. Refer > to Section 6.8.1.3 for control of MSI. > > So strictly speaking it mandates disabling/enabling INTx but says > nothing about other things (e.g. MSI). Some common sense dictates > it shouldn't disable MSI, I guess. > > The "MSI Enable" description doesn't leave any doubt: > 0: MSI Enable: If 1, the function is permitted to use MSI to request > service and is prohibited from using its INTx# pin [...] Right. I was merely describing the end result, the union of that language as it applies to the kernel. Jeff ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [patch] PCI: disable MSI on more ATI NorthBridges 2007-10-19 19:57 ` [patch] PCI: disable MSI on more ATI NorthBridges Linas Vepstas 2007-10-19 20:21 ` Jeff Garzik @ 2007-10-20 14:50 ` Shane Huang 1 sibling, 0 replies; 18+ messages in thread From: Shane Huang @ 2007-10-20 14:50 UTC (permalink / raw) To: Linas Vepstas, davem, gregkh, htejun, brice.goglin, david.gaarenstroom Cc: linux-kernel, linux-pci, shane.huang, jgarzik, linux-ide, chunhao.huang Quoting "David G" > "Here" as in "here at AMD"?! I'm stunned... > Both AMD and the former ATI should have quite some experience?! When I used "here", I was just meaning our youthful linux southbridge drivers team instead of the whole AMD. Sorry for the confusion to you. Quoting "Linas" > As someone else pointed out, AMD should have *lots* of people with > pci and msi experience on the payroll. (Folks here buy AMD-designed > pci chips ...) Yes, absolutely AMD has lots of people with PCI and MSI experience, but this MSI issue is mainly under the debug of our team now. I think our team will cooperate with other teams more closely to provide linux chipset support besides fixing the MSI problem in the future. Quoting "Jeff" > Take a look at tg3.c net driver change > 2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 which is a similar > situation. However, it may turn out that removing the pci_intx() > stuff as a general rule is easier than quirking these devices, if enough > of them turn out to have this hardware bug. The tg3.c change should > illustrate how to fix immediately, though. Thanks for your suggestion. I will continue to debug this problem next Monday when I'm back to the office. Thanks Best Regards Shane _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2007-10-24 2:46 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <BLU112-W5125F6D8BEB3DF6359D53E29F0@phx.gbl>
2007-10-19 19:57 ` [patch] PCI: disable MSI on more ATI NorthBridges Linas Vepstas
2007-10-19 20:21 ` Jeff Garzik
2007-10-20 22:03 ` Benjamin Herrenschmidt
2007-10-22 20:26 ` Daniel Barkalow
2007-10-22 20:41 ` Jeff Garzik
2007-10-22 21:31 ` Daniel Barkalow
2007-10-22 23:48 ` Krzysztof Halasa
2007-10-23 0:13 ` David Miller
2007-10-23 5:52 ` Daniel Barkalow
2007-10-23 9:39 ` Shane Huang
2007-10-23 10:01 ` Jeff Garzik
2007-10-23 10:06 ` David Miller
2007-10-24 2:46 ` David Miller
2007-10-23 10:15 ` Jeff Garzik
2007-10-22 23:40 ` Krzysztof Halasa
2007-10-22 23:58 ` David Miller
2007-10-23 10:13 ` Jeff Garzik
2007-10-20 14:50 ` Shane Huang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).