From: James Bruce <bruce@andrew.cmu.edu>
To: Gerd Knorr <kraxel@bytesex.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Potentially dead bttv cards from 2.6.10
Date: Tue, 01 Mar 2005 01:41:55 -0500 [thread overview]
Message-ID: <42240EB3.6040504@andrew.cmu.edu> (raw)
In-Reply-To: <87mzto3c78.fsf@bytesex.org>
Thanks for the hints. Unfortunately the cards in question really are
fairly generic and thus don't appear in the list. I tried the first 75
cards as insmod options (using a script of course), and some of them are
different, but none work properly.
I am lucky in that I still have a spare. If you could suggest a very
well tested kernel for bttv (2.6.9?), I can set up another machine with
that kernel and the remaining card. That should allow me to isolate the
problem better. At the very least I could get the right card= option
to use for the broken pair. Hopefully I will be able to generate a
table entry for this card for bttv-cards.c; I'll look some more at this
tomorrow.
I've heard that there is some way to dump eeproms; Is there a way to
write them also? If I could copy the eeprom from the unused cards to
the (now broken) pair that might fix things.
Thanks,
Jim
Gerd Knorr wrote:
> James Bruce <bruce@andrew.cmu.edu> writes:
>
>>Well, are there any theories as to why it would work flawlessly, then
>>after a hard lockup (due to what I think is a buggy V4L2 application),
>>that the cards no longer work?
>
> No idea why the eeprom doesn't respond any more. Maybe it's really
> broken. Note that the eeprom is read only at insmod time (and even
> that for some cards only), thus there isn't a clear connection between
> the crash and the eeprom issue. It could have died earlied unnoticed.
>
> The eeprom holds the PCI Subsystem ID, so without a working eeprom
> bttv can't figure automatically what exact card that is (see the
> "unknown/default" card name in the log) and maybe thats why does not
> work any more for the card in question. Thats should be easily
> fixable using the card= insmod option.
>
> Gerd
next prev parent reply other threads:[~2005-03-01 6:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-26 4:57 Potentially dead bttv cards from 2.6.10 James Bruce
2005-02-28 13:44 ` Gerd Knorr
2005-02-28 14:43 ` James Bruce
2005-02-28 16:02 ` Gerd Knorr
2005-02-28 16:45 ` Folkert van Heusden
2005-02-28 16:52 ` Gerd Knorr
2005-03-01 6:41 ` James Bruce [this message]
2005-03-01 8:44 ` Gerd Knorr
2005-03-01 13:10 ` James Bruce
2005-03-04 20:37 ` James Bruce
2005-02-28 23:14 ` Bill Davidsen
2005-03-01 7:06 ` James Bruce
2005-03-01 14:11 ` Paulo Marques
2005-03-01 15:44 ` James Bruce
2005-03-01 16:03 ` Gerd Knorr
2005-03-01 20:32 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42240EB3.6040504@andrew.cmu.edu \
--to=bruce@andrew.cmu.edu \
--cc=kraxel@bytesex.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox