Gene Heskett wrote:
On Monday 28 November 2005 20:17, Michael Krufky wrote:
Gene Heskett wrote:
Well, based on the note about -rc2-git6 having the v4l stuff reverted,
I just built it. Same song, same verse. The tuner acts as if the
antenna has been disconnected and held a fraction of an inch away.
The video is all digital noise (in VSB), and the audio has a fraction
of a word now and then, buried in white noise. As my dish receiver
has about a 65,000 u-volt output, I find that sort of signal loss
almost unbelievable.
It still takes a cold reboot back to 2.6.14.3 or I think any earlier
kernel (that worked ok) in order to restore the cards normal
operation, I'm watching cnn on it right now after having done so.
So to me, there is little difference between git3 and git6. Neither
works, failing in the same manner exactly, and matching the
performance of 15-rc2 as issued. I didn't build -rc1, so I can't say
exactly where the hose got cut.
I'd suggest just blowing the v4l directory in the -rc2 kernel away,
and replacing it with that from 2.6.14.3 just to get back to a
working sitiuation that you can then start from scratch on. But
whatdoIknow? :)Gene Heskett <[email protected]>
EEK! This is not the problem that I'm having at all..... Then again,
I have a different board.
Gene, telling someone to revert all the v4l changes in 2.6.15 doesn't
help us to fix the actual problem at all, nor will it help them use
their hardware.
Gene, I believe that I asked you to install the cvs modules against
2.6.14, and you told me that doing that works.
No, I never did get it to work Michael, and I believe I said so, mainly
because it wouldn't even compile. ISTR I sent a message with the
compiler exit messages at the time.
Now I'd be willing to try it again, but I'd need exactly the proceedure
as it would apply to a working 2.6.14.x kernel. I don't think I did it
right the last time. My script, fwiw, renames one generation back so
that a bad kernel can be reverted easily by renameing the vmlinuz and
/lib/modules/version-number trees. Its kind of a swiss army knife in
that I comment/uncomment stuff in the buildit (thats another script I
use to apply then patches etc), but the makeit script only needs the
version number updated to match the Makefile and from there its a 'time
./makeit' till I'm done editing grub.conf & ready to reboot. I've taken
note that the recent makefiles apparently does its own depmod operation
when doing the modules_install but haven't taken my command out of it
yet so that gets done twice..
The code in cvs
contains all the patches that we have sent to 2.6.15 and THEN some.
Can you please confirm that installing the cvs modules from v4l-dvb
cvs (v4l and dvb have merged cvs repo's) against 2.6.14 is NOT
broken?? This would rule out any possibility of the v4l changes in
2.6.15 being the cause of your problems.
See above.
It is WELL established that there are memory errors in 2.6.15
(although I thought they were all fixed -- guess not). I understand
that you are using some MakeIt script to build your kernel -- have you
tried the standard method?
My script does it essentially the same as one would do it by hand. The
exception being that I understand the Makefile now has an install target
for the kernel, but my script does the copying rather than calling that,
and *I* do the grub.conf editing.
[...a few minutes go by...]
OKAY, I concur -- When I did my testing for 2.6.15-rc2-git6, that was
with my saa7134-based card, using nxt200x ... success!
However, when I tried using my FusionHDTV3 Gold-T (cx88 card using
lgdt3302), neither analog nor digital works in 2.6.15-rc2-git6....
Under 2.6.13 (and 2.6.14, i think), however, digital DOES work. Analog
still doesnt work, but i believe that my hardware is damaged.
He should do a full shutdown and cold boot to a kernel he knows works,
and I expect the analog will work again. Warm reboots DO NOT DO IT!
SO, looks like we have a regression somewhere in the kernel that breaks
the cx88 driver :-(
I don't even know where to begin.
...One idea... We also know that upstream changes created some compile
warnings in tuner-core... Hans has fixed that in cvs -- maybe Hans'
patch in v4l-dvb cvs could fix it? Gene, try installing v4l-dvb cvs
against 2.6.15-rc2-git6 (or later) and see if that might fix NTSC.
Somehow, I doubt it -- but it is certainly worth a try.
Like I said, complete instructions please so that we are on the same
page. I still have the rc2-git6 tree that didn't work, so as my script
does a make clean, it should be easy enough to do with the right
instructions. Like what dir in the kernel tree am I supposed to be in
when I issue the cvs checkout command etc.
Gene-
Let's go a slightly different route... First off, I must say:
I think that I over-reacted in my previous email. To test, I have
installed v4l-dvb cvs over kernels 2.6.13, 2.6.14, and 2.6.15-rc2-git6,
and all three worked fine with my FusionHDTV3 Gold-T in ATSC mode. It
was the vanilla 2.6.15-rc2-git6 that didnt work for me. With the cvs
modules installed, however, it is working well.
Right now, I am in the process of recompiling my vanilla 2.6.15-rc2-git6
kernel, to confirm that this actually is a new regression. If it is in
fact a regression in 2.6.15, then it is likely to be a v4l regression.
Luckily, Mauro and I have prepared some patchsets to fix some 2.6.15
bugs and compile warnings. It seems that this might be one of the bugs
that is now fixed in cvs.
Anyhow, would you like to give cvs a whirl under your 2.6.15-rc2-git6
kernel?
There is a wiki-howto, located at:
http://linuxtv.org/v4lwiki/index.php/How_to_build_from_CVS
... but I will include instructions in this email for your convenience.
Here's how:
1) Please start with vanilla 2.6.15-rc2-git6 ... Have the kernel already
installed and running.
2) Check-out the newly merged v4l-dvb cvs repository:
cvs -d :pserver:[email protected]:/cvs/video4linux login
cvs -d :pserver:[email protected]:/cvs/video4linux co v4l-dvb
3) Change into the v4l-dvb directory:
cd v4l-dvb
4) (optional) If you are recompiling the cvs modules against a different
kernel, clean the tree and kernel version info:
make distclean
5) Compile the modules:
make
6) Install them: (as root)
make install
7) Reboot the machine
Hopefully, this will fix your problem. Please let me know.
-Michael Krufky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
