search for: msis

On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach <dev at lynxeye.de> wrote: > MSIs were only problematic on some old, broken chipsets. But now that we > already see systems where PCI legacy interrupts are somewhat flaky, it's > really time to move to MSIs. > > Signed-off-by: Lucas Stach <dev at lynxeye.de> > --- > drivers/gpu/drm/nouveau/core/include/...

On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach <dev at lynxeye.de> wrote: > Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs: >> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach <dev at lynxeye.de> wrote: >> > MSIs were only problematic on some old, broken chipsets. But now that we >> > already see systems where PCI legacy interrupts are somewhat flaky, it's >> > really time to move to MSIs. >> > >> > Signed-off-by: Lucas Stach <dev at lynxeye.de> >> > --...

...ich forwards the "event" to the appropriate handler (in my case it is the NMI handler in dom0 with ring1 privileges). [+] At the same time, PCI SERR interrupts refer to hardware errors that is generated by my passthrough NIC directly, so I expect that these interrupts are physical (e.g., MSIs) so they should go directly either to the BSP or one of the APs. However, Interrupt remapping is in place which should check the origin of such interrupts and should remap the interrupts by using the BDF id of the device. Thus, the real interrupt is generated by the Interrupt Remapping hardware uni...

...ke the ARM consolidator. Of course, we can make the MSI devices have their own struct device, and register to device tree, eg, add a class device named MSI_DEV. But I'm not sure whether it is appropriate. > > The other part I'm not completely sure about is how you want to > have MSIs map into normal IRQ descriptors. At the moment, all > MSI users are based on IRQ numbers, but this has known scalability problems. Hmmm, I still use the IRQ number to map the MSIs to IRQ description. I'm sorry, I don't understand you meaning. What are the scalability problems you mentio...

...ke the ARM consolidator. Of course, we can make the MSI devices have their own struct device, and register to device tree, eg, add a class device named MSI_DEV. But I'm not sure whether it is appropriate. > > The other part I'm not completely sure about is how you want to > have MSIs map into normal IRQ descriptors. At the moment, all > MSI users are based on IRQ numbers, but this has known scalability problems. Hmmm, I still use the IRQ number to map the MSIs to IRQ description. I'm sorry, I don't understand you meaning. What are the scalability problems you mentio...

...lmost everything uses > a device, and the ones that don't do that today can be easily changed. I will try to use "struct device" infrastructure, thanks for your suggestion. :) > >>> The other part I'm not completely sure about is how you want to >>> have MSIs map into normal IRQ descriptors. At the moment, all >>> MSI users are based on IRQ numbers, but this has known scalability problems. >> >> Hmmm, I still use the IRQ number to map the MSIs to IRQ description. >> I'm sorry, I don't understand you meaning. >> W...

...lmost everything uses > a device, and the ones that don't do that today can be easily changed. I will try to use "struct device" infrastructure, thanks for your suggestion. :) > >>> The other part I'm not completely sure about is how you want to >>> have MSIs map into normal IRQ descriptors. At the moment, all >>> MSI users are based on IRQ numbers, but this has known scalability problems. >> >> Hmmm, I still use the IRQ number to map the MSIs to IRQ description. >> I'm sorry, I don't understand you meaning. >> W...

...m 0.6, included below, is fairly small and consists of the following changes: * Address comments from 0.6, rework bits of the implementation notes. * Change resv_mem parameters to be consistent with the rest of the spec. * Add the MMIO flag to MAP requests. At the moment it is used by mapped MSIs mostly for completeness, but will be important for IDENTITY resv_mem regions that next versions introduce. Please find more information about this on the v0.6 thread [1]. For mapped MSIs, the MMIO flag allows host userspace to easily catch MSI maps, and route the rest to VFIO. Without it t...

I want to use Puppet to manage deployment of internal .Net software. The CI build can generate a versioned MSI file and push that out to Puppet. I am creating an MSI with the same name, but different versions for each release. Puppet detects the missing Package and properly installs the new Package from MSI. However, Puppet does not detect that a new MSI needs to replace the already

...ka: *weka.attributeSelection.InfoGainAttributeEval* Is it possible to use this function with RWeka? If yes how? list_Weka_interfaces doesn't show it and there is no make function for AttributeEvaluators. Is there any other implementation of InformationGain in R? Thank you Michael Olschimke MSIS Graduate Student Santa Clara University [[alternative HTML version deleted]]

On Wednesday 30 July 2014, Yijing Wang wrote: > >>> > >>> The other part I'm not completely sure about is how you want to > >>> have MSIs map into normal IRQ descriptors. At the moment, all > >>> MSI users are based on IRQ numbers, but this has known scalability problems. > >> > >> Hmmm, I still use the IRQ number to map the MSIs to IRQ description. > >> I'm sorry, I don't understand you...

On Wednesday 30 July 2014, Yijing Wang wrote: > >>> > >>> The other part I'm not completely sure about is how you want to > >>> have MSIs map into normal IRQ descriptors. At the moment, all > >>> MSI users are based on IRQ numbers, but this has known scalability problems. > >> > >> Hmmm, I still use the IRQ number to map the MSIs to IRQ description. > >> I'm sorry, I don't understand you...

...t;imirkin at alum.mit.edu> wrote: > On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach <dev at lynxeye.de> wrote: >> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs: >>> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach <dev at lynxeye.de> wrote: >>> > MSIs were only problematic on some old, broken chipsets. But now that we >>> > already see systems where PCI legacy interrupts are somewhat flaky, it's >>> > really time to move to MSIs. >>> > >>> > Signed-off-by: Lucas Stach <dev at lynxeye.de>...

...04 August 2014, Yijing Wang wrote: > On 2014/8/1 21:52, Arnd Bergmann wrote: > > On Wednesday 30 July 2014, Yijing Wang wrote: > >> On 2014/7/29 22:08, Arnd Bergmann wrote: > >>> The other part I'm not completely sure about is how you want to > >>> have MSIs map into normal IRQ descriptors. At the moment, all > >>> MSI users are based on IRQ numbers, but this has known scalability problems. > >> > >> Hmmm, I still use the IRQ number to map the MSIs to IRQ description. > >> I'm sorry, I don't understand you...

Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs: > On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach <dev at lynxeye.de> wrote: > > MSIs were only problematic on some old, broken chipsets. But now that we > > already see systems where PCI legacy interrupts are somewhat flaky, it's > > really time to move to MSIs. > > > > Signed-off-by: Lucas Stach <dev at lynxeye.de> > > --- > > drivers...

...> Of course, we can make the MSI devices have their own struct device, and register to > device tree, eg, add a class device named MSI_DEV. But I'm not sure whether it is appropriate. > >> >> The other part I'm not completely sure about is how you want to >> have MSIs map into normal IRQ descriptors. At the moment, all >> MSI users are based on IRQ numbers, but this has known scalability problems. > > Hmmm, I still use the IRQ number to map the MSIs to IRQ description. > I'm sorry, I don't understand you meaning. > What are the scalabi...

...> Of course, we can make the MSI devices have their own struct device, and register to > device tree, eg, add a class device named MSI_DEV. But I'm not sure whether it is appropriate. > >> >> The other part I'm not completely sure about is how you want to >> have MSIs map into normal IRQ descriptors. At the moment, all >> MSI users are based on IRQ numbers, but this has known scalability problems. > > Hmmm, I still use the IRQ number to map the MSIs to IRQ description. > I'm sorry, I don't understand you meaning. > What are the scalabi...

...vice tree, but I think it absolutely makes sense to use the 'struct device' infrastructure here, as almost everything uses a device, and the ones that don't do that today can be easily changed. > > The other part I'm not completely sure about is how you want to > > have MSIs map into normal IRQ descriptors. At the moment, all > > MSI users are based on IRQ numbers, but this has known scalability problems. > > Hmmm, I still use the IRQ number to map the MSIs to IRQ description. > I'm sorry, I don't understand you meaning. > What are the scalab...

...m.mit.edu> wrote: >> On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach <dev at lynxeye.de> wrote: >>> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs: >>>> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach <dev at lynxeye.de> wrote: >>>> > MSIs were only problematic on some old, broken chipsets. But now that we >>>> > already see systems where PCI legacy interrupts are somewhat flaky, it's >>>> > really time to move to MSIs. >>>> > >>>> > Signed-off-by: Lucas Stach <dev at...

...ain cards, where it isn't entirely clear if this is a GPU errata or some other component in the PCIe chain failing. Could you perhaps investigate if there are any known Nvidia GPU erratas with regard to MSI interrupts, or maybe tell us the generations of cards that are generally safe to enable MSIs with? Thanks, Lucas