Re: Unsafe to reinsert HVR-1850 kernel modules?
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unsafe to reinsert HVR-1850 kernel modules?
On 11/29/2010 04:38 AM, Andy Walls wrote: On Sun, 2010-11-28 at 23:49 -0800, David Liontooth wrote: My HVR-1850 card occasionally jams, meaning it still tunes (according to gnutv), but no mpeg stream comes through. This heals on reboot, but I figured it should also heal on module reinsertion. However, when I remove the CX23885 module, along with the full set of DVB and related modules, and then reinsert them, I get this error when I attempt to open the stream -- zvbi-atsc-cc will for instance trigger it: kernel:do_IRQ: 5.82 No irq handler for vector (irq -1) This happens when an initial MSI Data vector is assigned to the CX23888 chip and written into its PCI config space, and then the kernel assigns a new MSI Data vector for the CX23888 and writes the new MSI Data vector into its PCI config space. This is what happens at cx23885 module reload with MSI enabled on your system. The CX2388[578] chips ignore the new MSI Data vector and continue to use the first assigned one. The kernel doesn't have an IRQ handler function to call for the old vector anymore, so do_IRQ blurts out its message. If one card was initially jammed, now all the cards are jammed -- I'm testing five cards at once. They are all still trying to fire interrupts, just with the wrong vector, so the kenrel ignores them. A discussion at http://www.mail-archive.com/linux-media@vger.kernel.org/msg22375.html suggested adding the kernel parameter pci=nommconf, but when I do that the problem does not go away 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 Is it currently not safe to remove and reinsert the kernel modules for the HVR-1850, or am I just seeing a quirk? 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. (Like the bug I found and fixed just yesterday - see my latest GIT pull request.) Once the CX2388[578] A/V core is in this state, it fails to respond to reads over the internal I2C bus. That makes it impossible for the cx25840 module to interrogate the CX2388x A/V core and figure out which type it is talking to, so that it can initialize it. Testing last night indicates that, if the cx25840 module had apriori knowledge of the type of A/V core, it could do the I2C writes anyway to initialize the A/V core and bring it back to a somewhat working condition. 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. Otherwise, IR and analog video will not work properly for you. 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 -- what do we lose by removing the MSI support patch? Cheers, Dave -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unsafe to reinsert HVR-1850 kernel modules?
On Sun, 2010-11-28 at 23:49 -0800, David Liontooth wrote: My HVR-1850 card occasionally jams, meaning it still tunes (according to gnutv), but no mpeg stream comes through. This heals on reboot, but I figured it should also heal on module reinsertion. However, when I remove the CX23885 module, along with the full set of DVB and related modules, and then reinsert them, I get this error when I attempt to open the stream -- zvbi-atsc-cc will for instance trigger it: kernel:do_IRQ: 5.82 No irq handler for vector (irq -1) This happens when an initial MSI Data vector is assigned to the CX23888 chip and written into its PCI config space, and then the kernel assigns a new MSI Data vector for the CX23888 and writes the new MSI Data vector into its PCI config space. This is what happens at cx23885 module reload with MSI enabled on your system. The CX2388[578] chips ignore the new MSI Data vector and continue to use the first assigned one. The kernel doesn't have an IRQ handler function to call for the old vector anymore, so do_IRQ blurts out its message. If one card was initially jammed, now all the cards are jammed -- I'm testing five cards at once. They are all still trying to fire interrupts, just with the wrong vector, so the kenrel ignores them. A discussion at http://www.mail-archive.com/linux-media@vger.kernel.org/msg22375.html suggested adding the kernel parameter pci=nommconf, but when I do that the problem does not go away 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 Is it currently not safe to remove and reinsert the kernel modules for the HVR-1850, or am I just seeing a quirk? 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. (Like the bug I found and fixed just yesterday - see my latest GIT pull request.) Once the CX2388[578] A/V core is in this state, it fails to respond to reads over the internal I2C bus. That makes it impossible for the cx25840 module to interrogate the CX2388x A/V core and figure out which type it is talking to, so that it can initialize it. Testing last night indicates that, if the cx25840 module had apriori knowledge of the type of A/V core, it could do the I2C writes anyway to initialize the A/V core and bring it back to a somewhat working condition. 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. Otherwise, IR and analog video will not work properly for you. Regards, Andy Cheers, Dave -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Unsafe to reinsert HVR-1850 kernel modules?
My HVR-1850 card occasionally jams, meaning it still tunes (according to gnutv), but no mpeg stream comes through. This heals on reboot, but I figured it should also heal on module reinsertion. However, when I remove the CX23885 module, along with the full set of DVB and related modules, and then reinsert them, I get this error when I attempt to open the stream -- zvbi-atsc-cc will for instance trigger it: kernel:do_IRQ: 5.82 No irq handler for vector (irq -1) If one card was initially jammed, now all the cards are jammed -- I'm testing five cards at once. A discussion at http://www.mail-archive.com/linux-media@vger.kernel.org/msg22375.html suggested adding the kernel parameter pci=nommconf, but when I do that the problem does not go away -- 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 Is it currently not safe to remove and reinsert the kernel modules for the HVR-1850, or am I just seeing a quirk? Cheers, Dave -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
