On Thu, 2008-09-04 at 15:57 -0400, Andy Walls wrote:
> On Thu, 2008-09-04 at 11:00 -0700, Michael wrote:
> > Hey Andy
> >
> > I hate to be the first to report this, but I'm still obtaining the
> > eeprom error.
>
> :( Bummer.
>
>
>
> > I'm currently away from the computer (I tested this last
> > night, but was too tired to write up the email yet...), but when I do
> > get a chance, would a dmesg be of any help, or what would you like?
>
> I need to know if your card works under windows in that same machine. I
> can't remember if you said it did or not.
>
> And the dmesg output will help me see the current failure mode.
>
>
> > Anyways, you said if it doesn't work, run "/sbin/modprobe
> > cx18 mmio_ndelay=61". I've gotten up to 152, yet it still doesn't
> > work. Should I keep going, to see if it'll eventually catch it? How high?
>
> 500 is half a microsecond and about 16.5 PCI bus cycles delay for each
> IO access. That should be ridiculously long in PCI bus terms as a one
> word transaction can take as little as 4 PCI bus cycles.
>
>
> > I really appericate your help on this.
>
> Unfortunately your case doesn't fit with the other users who were having
> problems. I have the *exact* same motherboard as you (MSI-7184) in my
> HP machine as you have in your Compaq machine and HP owns Compaq (I
> think). My HVR-1600's have worked in the machine from day 1, yet yours
> hasn't.
>
> I am at a loss as to why the card doesn't work for you specifically. I
> can only think of a few things:
>
> 1. You have a bad card. (Does it work in Windows? Does it work in
> another machine? Do you have another CX23418 based card you can try?)
>
> 2. You have a bad slot in you motherboard. Have you tried switching
> slots? (I can't remember if you have.)
>
> 3. The kernels or distributions we run are different enough that one of
> us has a kernel bug related to PCI IO that the other doesn't.
>
>
> Regards,
> Andy
Michael,
OK. I have some other ideas on how to collect information on the
problem on your setup, but it involves a bit of work. (After 3 weeks of
working this bug and having fixed it for at least my older mobo, I can't
say I too keen to look at it right now. :P )
But anyway here's kind of a strategy:
1. All non-DMA IO to and from the CX23418 is now consolidated through
through the routines in cx18-io.[ch]. It should be possible to
instrument the primitive IO to and from the CX23418 to monitor what's
going on (e.g. printk or CX18_DEBUG_HI() statements). This could give
some insight into when the CX23418 in you system "goes stupid", but not
why per se.
2. Since all IO to and from the CX23418 is consilated through
cx18-io.[ch], I could build a per card ring buffer to record an IO
access and timestamp history of accesses to the CX23418. When we detect
an PCI or CX23418 IO error, the routines could dump the ring buffer to
give an immediate history of how the CX23418 was accessed. Hopefully
that would give some insight into the failure mode.
3. Instead of delays, if we can detect an PCI/CX23418 error through
snooping in cx18-io.[ch], then a write to and from PCI config space for
the CX23418 (i.e. the PCI status register), may bring the CX23418 back
into responsiveness to retry the actual IO command.
4. If I had specs for the AMD/ATI chipset (which I don't :{ ), I could
have the chipset generate an NMI on a PCI bridge/bus error and add a
special NMI handler which would then call CX23418 error
recovery/investigation routines.
I want to hold off on the above for a little, until I can get a CX23418
datasheet from Conexant. I may have better options after reading that.
Regards,
Andy
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
