public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 08:10:59 -0500	[thread overview]
Message-ID: <422469E3.7010805@andrew.cmu.edu> (raw)
In-Reply-To: <87is4b21s5.fsf@bytesex.org>

Forgive me for being annoying; I'm trying to be careful because I get 
one more failure in a test and then that's it.  The manufacturer no 
longer lists that model as being produced.  Thus if there's a way to 
ruin a bttv card through the V4L2 interface I will no longer be of any 
assistance in finding it.

Gerd Knorr wrote:
> James Bruce <bruce@andrew.cmu.edu> writes:
>>If you could suggest a very well tested kernel for bttv (2.6.9?),
> What do you expect?  With just one single report and not remotely
> being clear what exactly caused it ...

It goes further than that though; I have about 3+ people a month asking 
me what camera and capture card to use with my GPL'd machine vision library:
	http://www-2.cs.cmu.edu/~jbruce/cmvision/

Right now, I have to tell them "use 2.4 patched with V4L2", which is 
neither what they want to hear nor what I want to tell them.  CMVision 
can use IEEE1394 cameras, but since that has been "working, not working, 
then working again" in relatively recent 2.6.x, I can't sanely tell 
people to use that yet.  Now that the V4L2 API churn rate has gone down, 
I'm trying to get it working properly with the 2.6.x V4L2 API (which 
AFAICT doesn't match any 2.4.x V4L2 API variant).  If it works I could 
just tell people "Use 2.6.x with a commonly available bttv card", which 
would be great.  However, so far I've gotten that to work for five days 
before the cards stopped working.  I've been tracking the V4L API since 
1999, on something like 10 different cards, and this is the most serious 
failure I've had.  So I'm back to telling CMVision users "Use 2.4 + 
patches", which I would really like to *not* have to tell people.

As far as kernels go, there was the guy only one report on lkml by 
someone overwritting mozilla by running XawTV in 2.6.10-ac8.  The 
changes between 2.6.11-rc* and 2.6.10 seem to be minor, but I guess I2C 
has changed causing the reported 2.6.11-rc* bttv issues.  Going back to 
2.6.9 there are a lot more changes in the driver.  I'd know more if 
linux.bkbits didn't seem to be down at the moment.

Google says:
[linux bttv problem "2.6.7"]  -> 1230 hits
[linux bttv problem "2.6.8"]  -> 1010 hits
[linux bttv problem "2.6.9"]  ->  958 hits
[linux bttv problem "2.6.10"] ->  831 hits

That's certainly promising, so I guess I'll try 2.6.9 and 2.6.10 on 
another computer with the remaining card.  If you want me to also try 
some out-of-tree-latest-version patches, now would be the time to speak 
up before I've messed up the third card.

>>I've heard that there is some way to dump eeproms; Is there a way to
>>write them also?
> 
> Yes, you can.  That works only if you can still talk to it though.

I'll gather all the information I can from the remaining card.

>>If I could copy the eeprom from the unused cards to the (now broken)
>>pair that might fix things.
> 
> No.  It's not accessable, not just the content scrambled.
> 
>   Gerd

Ok.

Thanks,
   Jim Bruce

  reply	other threads:[~2005-03-01 13:12 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
2005-03-01  8:44         ` Gerd Knorr
2005-03-01 13:10           ` James Bruce [this message]
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=422469E3.7010805@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