Re: Fix for "MT2032 Fatal Error: PLLs didn't lock"
From: Subbu K. K. (kksubramaniam_at_novell.com)
Date: 11/25/03
- Previous message: Jos Hulzink: "Re: What exactly are the issues with 2.6.0-test10 preempt?"
- In reply to: Gerd Knorr: "Re: Fix for "MT2032 Fatal Error: PLLs didn't lock""
- Next in thread: Gerd Knorr: "Re: Fix for "MT2032 Fatal Error: PLLs didn't lock""
- Reply: Gerd Knorr: "Re: Fix for "MT2032 Fatal Error: PLLs didn't lock""
- Reply: Subbu K. K.: "Re: Fix for "MT2032 Fatal Error: PLLs didn't lock""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Gerd Knorr <kraxel@bytesex.org> Date: Tue, 25 Nov 2003 12:28:28 +0530
On Mon, 2003-11-24 at 17:16, Gerd Knorr wrote:
> > I saw others report same issues but didnt see any
> > fixes/patches/solutions. With the debug option on for bttv and tuner in
> > /etc/modules.conf and the TV frequency set to 133.25MHz and then
> > 140.25MHz, the sign extension defect pops up in rfin value below. This
> > is because 133.25MHz is 0x7F13BD0 and 140.25MHz is 0x85C0B90. The high
> > bit gets sign extended in as 0xFFFFFFFFF85C0B90 (-128185456)
>
> Huh? I can't see where a sign extension happens. 0x85C0B90 has the bit
> #27 set to one, not #31 ...
I know this sounds weird, but sign extension is happening between
invocation of set_tv_freq and the dprintk in mt2032_set_tv_freq.
> Beside that the values are passed around as unsigned values everythere.
> Can you please explain in more detail what is going on?
Except in one place where there is an implicit conversion to signed ints
in line 746:
746 mt2032_set_if_freq(c, freq*62500 /* freq*1000*1000/16 */,
> > Nov 16 21:45:56 localhost kernel: tuner: tv freq set to 133.25
> > Nov 16 21:45:56 localhost kernel: mt2032_set_if_freq rfin=133250000
> > if1=1090000000 if2=38900000 from=32900000 to=39900000
>
> > Nov 16 21:45:58 localhost kernel: tuner: tv freq set to 140.25
> > Nov 16 21:45:58 localhost kernel: mt2032_set_if_freq rfin=-128185456
> > if1=1090000000 if2=38900000 from=32900000 to=39900000
>
> Works fine here:
>
> tuner: tv freq set to 140.25
> mt2032_set_if_freq rfin=140250000 if1=1090000000 if2=38900000 from=32900000 to=39900000
Thanks for the clue. Perhaps the problem is gcc/athlon related?
> > case VIDIOCSFREQ:
> > {
> > - unsigned long *v = arg;
> > + unsigned int *v = arg;
>
> Wrong, VIDIOCSFREQ is "_IOW('v',15, unsigned long)". Beside that I'm
> very surprised that this actually makes a difference. What architecture
> is that? And what size int/long have there?
I agree that the change is rather kludgy. I was using stock Mandrake
9.1/gcc3.2.2 on AMD Athlon 1.4GHz. I have seen the error pop up on the
Knoppix (2.4.18..2.4.20 kernels) also on the same box so it doesnt seem
to be distro-specific. I dont have a Intel system to check if the
problem is related to the cpu. Clues anyone?
Let me poke around in the assembly code tonight to find out why the sign
change happens on my box. I suspect this could be due to gcc/athlon
combo.
Subbu K. K.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Jos Hulzink: "Re: What exactly are the issues with 2.6.0-test10 preempt?"
- In reply to: Gerd Knorr: "Re: Fix for "MT2032 Fatal Error: PLLs didn't lock""
- Next in thread: Gerd Knorr: "Re: Fix for "MT2032 Fatal Error: PLLs didn't lock""
- Reply: Gerd Knorr: "Re: Fix for "MT2032 Fatal Error: PLLs didn't lock""
- Reply: Subbu K. K.: "Re: Fix for "MT2032 Fatal Error: PLLs didn't lock""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
