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@xxxxxxxxxxxxxxx/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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
