On Wed, 2010-12-01 at 21:52 -0800, David Liontooth wrote: > On 11/29/2010 04:38 AM, Andy Walls wrote: > > On Sun, 2010-11-28 at 23:49 -0800, David Liontooth wrote: > > For a quick band-aid, use "pci=nomsi" on your kernel command line, and > > reboot to reset the CX23888 hardware. > > > > The problem is MSI. The cx23885 driver isn't ready for it. The patch > > that enabled MSI for cx23885 probably needs to be reverted until some of > > these issues are sorted out. > >> -- and I also got this (perhaps unrelated): > >> > >> cx25840 15-0044: likely a confused/unresponsive cx2388[578] A/V > >> decoder found @ 0x88 (cx23885[4]) > >> cx25840 15-0044: A method to reset it from the cx25840 driver software > >> is not known at this time > > This is unrelated. This happens when the CX2388[578] A/V core device > > probe fails to complete - usually due to a missing firmware file or some > > other Linux cx23885 or cx25840 module unhappiness. > > Your only course of action right now is, again, a hardware reset to get > > the CX2388[578] A/V core's I2C interface block back to a sane state. > Thanks, Andy, that's very helpful. I wouldn't care that much about > module reinsertion if it weren't for the fact that the HVR-1850 behaves > in a very finicky way, jamming on the smallest pretext. That said, once > I put the cards in a fully automated environment where they only get > correct gnutv requests, they've been behaving well. If it's possible to > modify the driver so reinsertion is possible, that would be a big help cx23885-core.c has a couple of calls with "msi" in it. That's the logic that needs to modified to not use MSI. I've known about the problem for weeks, but I just haven't had time to submit a patch to at least selectively not use MSI with a module option. (Since April I've been the principal engineer and COO for a small business. I have little to no time to play with git kernel builds and submit 3 versions of the same patch for .36, .37, and .38. Sorry.) The fastest way to make thing happen for yourself is probably to submit a patch to the mailing list yourself. > -- what do we lose by removing the MSI support patch? Problems mostly. The driver was written to work with emulated legacy PCI INTx interrupts, which are to be treated as level triggered, and not PCIe MSI, which are to be treated as edge triggered. That's why I say the cx23885 driver isn't ready for MSI, but I'm not sure how involved an audit and conversion would be. I know an audit will take time and expertise. To answer your question: MSI provides better overall performance as the interrupt vectors are never shared. A card never has to wait on the interrupt service routine of another device, if there is a CPU core available. A few Linux device drivers likely still have ISRs that don't just "get-in and get-out" as fast as they can, so you do really want to avoid sharing interrupts with other device drivers. MSI provides for scalability of the I/O bus interrupts. If you have a machine with many I/O devices that use interrupts - let's pretend more than 8 TV cards, 2 disk controllers, and 2 NICs - you really want to use MSI for as many of the devices as possible. That way each device has a low likelihood of having to wait when it needs interrupt service. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
