Bug 13709
| Summary: | b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter w/ kernel-2.6.31-rc2 | ||
|---|---|---|---|
| Product: | v4l-dvb | Reporter: | boris64 (bugzilla.kernel.org) |
| Component: | dvb-frontend | Assignee: | dvb-frontend (v4l-dvb_dvb-frontend) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | rjw |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.31-rc1 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 13615 | ||
| Attachments: |
lspci output
dmesg output (kernel-2.6.30.1) with working dvb adapter dmesg output (kernel-2.6.31-rc2) lspci -vnn Kernel-2.6.30.1 config with working adapter Kernel-2.6.31-rc2 config |
||
|
Description
boris64
2009-07-05 01:36:30 UTC
Created attachment 22211 [details]
lspci output
Created attachment 22212 [details]
dmesg output (kernel-2.6.30.1) with working dvb adapter
Created attachment 22213 [details]
dmesg output (kernel-2.6.31-rc2)
FYI: There is no difference if i compile _all_ dvb frontends in the kernel or only the "ST STV0299 DVB-S" frontend(working in pre 2.6.31). Created attachment 22321 [details]
lspci -vnn
more verbose output of lspci
Created attachment 22322 [details]
Kernel-2.6.30.1 config with working adapter
Created attachment 22323 [details]
Kernel-2.6.31-rc2 config
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael to add it to the regression tracking list. btw, does the flexcop driver have a regular maintainer? Or someone who wants to volunteer? MAINTAINERS is silent about it.. Thanks. On Sun, 5 Jul 2009 01:36:31 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=13709 > > Summary: b2c2-flexcop: no frontend driver found for this > B2C2/FlexCop adapter w/ kernel-2.6.31-rc2 > Product: v4l-dvb > Version: unspecified > Kernel Version: 2.6.31-rc1 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: dvb-frontend > AssignedTo: v4l-dvb_dvb-frontend@kernel-bugs.osdl.org > ReportedBy: bugzilla.kernel.org@boris64.net > Regression: Yes > > > Hi kernel people! > > Since kernel-2.6.31-rc1 my Technisat SkyStar2 DVB card isn't > working anymore, because no frontend driver is found. > The frontend 'ST STV0299 DVB-S' is compiled into the kernel > and _did_ work fine in pre-2.6.31 kernels. > > > [lspci] > ... > 05:02.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB > chip > / Technisat SkyStar2 DVB card (rev 02) > [/lspci] > > [dmesg] > Working kernel-2.6.30.1: > ------------------------ > ... > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded > successfully > b2c2_flexcop_pci 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58 > b2c2-flexcop: found 'ST STV0299 DVB-S' . > b2c2-flexcop: initialization of 'Air2PC/AirStar 2 ATSC 3rd generation > (HD5000)' > at the 'PCI' bus controlled by a 'FlexCopIIb' complete > ... > > Non-working kernel-2.6.31-rc: > ------------------------ > ... > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded > successfully > b2c2_flexcop_pci 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58 > b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter > b2c2_flexcop_pci 0000:05:02.0: PCI INT A disabled > ... > [/dmesg] > > > I'll attach full dmesg+lspci. > Please feel free to contact me if you need more infos. > Thank you in advance ;) > > -- > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. On Mon, 20 Jul 2009, Andrew Morton wrote: > > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > > Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael to > add it to the regression tracking list. > > btw, does the flexcop driver have a regular maintainer? Or someone who > wants to volunteer? MAINTAINERS is silent about it.. I produced a patch that fixed this problem over a month ago, http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e Maybe it should go into 2.6.31? > Thanks. > > On Sun, 5 Jul 2009 01:36:31 GMT > bugzilla-daemon@bugzilla.kernel.org wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=13709 > > > > Summary: b2c2-flexcop: no frontend driver found for this > > B2C2/FlexCop adapter w/ kernel-2.6.31-rc2 > > Product: v4l-dvb > > Version: unspecified > > Kernel Version: 2.6.31-rc1 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: dvb-frontend > > AssignedTo: v4l-dvb_dvb-frontend@kernel-bugs.osdl.org > > ReportedBy: bugzilla.kernel.org@boris64.net > > Regression: Yes > > > > > > Hi kernel people! > > > > Since kernel-2.6.31-rc1 my Technisat SkyStar2 DVB card isn't > > working anymore, because no frontend driver is found. > > The frontend 'ST STV0299 DVB-S' is compiled into the kernel > > and _did_ work fine in pre-2.6.31 kernels. > > > > > > [lspci] > > ... > > 05:02.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB > chip > > / Technisat SkyStar2 DVB card (rev 02) > > [/lspci] > > > > [dmesg] > > Working kernel-2.6.30.1: > > ------------------------ > > ... > > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded > > successfully > > b2c2_flexcop_pci 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > > b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58 > > b2c2-flexcop: found 'ST STV0299 DVB-S' . > > b2c2-flexcop: initialization of 'Air2PC/AirStar 2 ATSC 3rd generation > (HD5000)' > > at the 'PCI' bus controlled by a 'FlexCopIIb' complete > > ... > > > > Non-working kernel-2.6.31-rc: > > ------------------------ > > ... > > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded > > successfully > > b2c2_flexcop_pci 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > > b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58 > > b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter > > b2c2_flexcop_pci 0000:05:02.0: PCI INT A disabled > > ... > > [/dmesg] > > > > > > I'll attach full dmesg+lspci. > > Please feel free to contact me if you need more infos. > > Thank you in advance ;) > > > > -- > > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > > ------- You are receiving this mail because: ------- > > You are on the CC list for the bug. > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > On Mon, 20 Jul 2009, Andrew Morton wrote: > > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > > Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael to > add it to the regression tracking list. > > btw, does the flexcop driver have a regular maintainer? Or someone who > wants to volunteer? MAINTAINERS is silent about it.. I produced a patch that fixed this problem over a month ago, http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e Maybe it should go into 2.6.31? > Thanks. > > On Sun, 5 Jul 2009 01:36:31 GMT > bugzilla-daemon@bugzilla.kernel.org wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=13709 > > > > Summary: b2c2-flexcop: no frontend driver found for this > > B2C2/FlexCop adapter w/ kernel-2.6.31-rc2 > > Product: v4l-dvb > > Version: unspecified > > Kernel Version: 2.6.31-rc1 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: dvb-frontend > > AssignedTo: v4l-dvb_dvb-frontend@kernel-bugs.osdl.org > > ReportedBy: bugzilla.kernel.org@boris64.net > > Regression: Yes > > > > > > Hi kernel people! > > > > Since kernel-2.6.31-rc1 my Technisat SkyStar2 DVB card isn't > > working anymore, because no frontend driver is found. > > The frontend 'ST STV0299 DVB-S' is compiled into the kernel > > and _did_ work fine in pre-2.6.31 kernels. > > > > > > [lspci] > > ... > > 05:02.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB > chip > > / Technisat SkyStar2 DVB card (rev 02) > > [/lspci] > > > > [dmesg] > > Working kernel-2.6.30.1: > > ------------------------ > > ... > > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded > > successfully > > b2c2_flexcop_pci 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > > b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58 > > b2c2-flexcop: found 'ST STV0299 DVB-S' . > > b2c2-flexcop: initialization of 'Air2PC/AirStar 2 ATSC 3rd generation > (HD5000)' > > at the 'PCI' bus controlled by a 'FlexCopIIb' complete > > ... > > > > Non-working kernel-2.6.31-rc: > > ------------------------ > > ... > > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded > > successfully > > b2c2_flexcop_pci 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > > b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58 > > b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter > > b2c2_flexcop_pci 0000:05:02.0: PCI INT A disabled > > ... > > [/dmesg] > > > > > > I'll attach full dmesg+lspci. > > Please feel free to contact me if you need more infos. > > Thank you in advance ;) > > > > -- > > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > > ------- You are receiving this mail because: ------- > > You are on the CC list for the bug. > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) Trent Piepho <xyzzy@speakeasy.org> wrote: > On Mon, 20 Jul 2009, Andrew Morton wrote: > > > > (switched to email. Please respond via emailed reply-to-all, not via the > > bugzilla web interface). > > > > > > Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael to > > add it to the regression tracking list. > > > > btw, does the flexcop driver have a regular maintainer? Or someone who > > wants to volunteer? MAINTAINERS is silent about it.. > > I produced a patch that fixed this problem over a month ago, > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e Where is that patch now? It isn't present in linux-next. If it needs to be resent, please cc me on it? Also, is there any way of avoiding this? +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) That's just way too tricky. It expects all versions of the preprocessor to be correctly implemented (unlikely) and there are other tools like unifdef which want to parse kernel #defines. otoh the trick does produce a nice result and doing it any other way (which I can think of) would make a mess. > Maybe it should go into 2.6.31? It depends on the seriousness of the regression (number of people affected, whether there's a workaround, etc) and upon the riskiness of the patch. But sure, we don't want regressions and letting one be released when we already know about it and have a fix would be bad! If the patch is judged too risky at this time, there might be a simpler one, perhaps. Or just revert whichever patch broke things. Your changelog describes this as simply "A recent patch" (bad changelog!) so I am unable to judge this. Em Mon, 20 Jul 2009 20:40:30 GMT bugzilla-daemon@bugzilla.kernel.org escreveu: > > > btw, does the flexcop driver have a regular maintainer? Or someone who > > > wants to volunteer? MAINTAINERS is silent about it.. > > I produced a patch that fixed this problem over a month ago, > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e > > Where is that patch now? It isn't present in linux-next. No, this patch is inside a series of 8 patches. They aren't at linux-next yet, since I was waiting for some tests before applying it. As there's a regression that is likely fixed by one of those patches, I'll add it today. Cheers, Mauro Reply-To: hermann-pitton@arcor.de Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton: > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) > Trent Piepho <xyzzy@speakeasy.org> wrote: > > > On Mon, 20 Jul 2009, Andrew Morton wrote: > > > > > > (switched to email. Please respond via emailed reply-to-all, not via the > > > bugzilla web interface). > > > > > > > > > Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael to > > > add it to the regression tracking list. > > > > > > btw, does the flexcop driver have a regular maintainer? Or someone who > > > wants to volunteer? MAINTAINERS is silent about it.. > > > > I produced a patch that fixed this problem over a month ago, > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e > > Where is that patch now? It isn't present in linux-next. > > If it needs to be resent, please cc me on it? > > > Also, is there any way of avoiding this? > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) > > That's just way too tricky. It expects all versions of the > preprocessor to be correctly implemented (unlikely) and there are other > tools like unifdef which want to parse kernel #defines. > > otoh the trick does produce a nice result and doing it any other way > (which I can think of) would make a mess. > > > Maybe it should go into 2.6.31? > > It depends on the seriousness of the regression (number of people > affected, whether there's a workaround, etc) and upon the riskiness of > the patch. > > But sure, we don't want regressions and letting one be released when we > already know about it and have a fix would be bad! > > If the patch is judged too risky at this time, there might be a simpler > one, perhaps. > > Or just revert whichever patch broke things. Your changelog describes > this as simply "A recent patch" (bad changelog!) so I am unable to judge > this. > Just revert it and let's wait for the next better attempt. We might get a lot of noise, but the patch was wrong. Cheers, Hermann Reply-To: cyber.bogh@gmx.de Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie: > Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton: > > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) > > > > Trent Piepho <xyzzy@speakeasy.org> wrote: > > > On Mon, 20 Jul 2009, Andrew Morton wrote: > > > > (switched to email. Please respond via emailed reply-to-all, not via > > > > the bugzilla web interface). > > > > > > > > > > > > Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael > > > > to add it to the regression tracking list. > > > > > > > > btw, does the flexcop driver have a regular maintainer? Or someone > > > > who wants to volunteer? MAINTAINERS is silent about it.. > > > > > > I produced a patch that fixed this problem over a month ago, > > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e > > > > Where is that patch now? It isn't present in linux-next. > > > > If it needs to be resent, please cc me on it? > > > > > > Also, is there any way of avoiding this? > > > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) > > > > That's just way too tricky. It expects all versions of the > > preprocessor to be correctly implemented (unlikely) and there are other > > tools like unifdef which want to parse kernel #defines. > > > > otoh the trick does produce a nice result and doing it any other way > > (which I can think of) would make a mess. > > > > > Maybe it should go into 2.6.31? > > > > It depends on the seriousness of the regression (number of people > > affected, whether there's a workaround, etc) and upon the riskiness of > > the patch. > > > > But sure, we don't want regressions and letting one be released when we > > already know about it and have a fix would be bad! > > > > If the patch is judged too risky at this time, there might be a simpler > > one, perhaps. > > > > Or just revert whichever patch broke things. Your changelog describes > > this as simply "A recent patch" (bad changelog!) so I am unable to judge > > this. > > Just revert it and let's wait for the next better attempt. > > We might get a lot of noise, but the patch was wrong. Absolutely nothing was wrong. Your pure existance here is wrong if there is something wrong here! As long as you do not have any clue about the subject I advise you to simply shut up, Pitton! Is that clear, Pitton??? cyber.bogh > Cheers, > Hermann > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Reply-To: cyber.bogh@gmx.de Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie: > Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton: > > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) > > > > Trent Piepho <xyzzy@speakeasy.org> wrote: > > > On Mon, 20 Jul 2009, Andrew Morton wrote: > > > > (switched to email. Please respond via emailed reply-to-all, not via > > > > the bugzilla web interface). > > > > > > > > > > > > Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael > > > > to add it to the regression tracking list. > > > > > > > > btw, does the flexcop driver have a regular maintainer? Or someone > > > > who wants to volunteer? MAINTAINERS is silent about it.. > > > > > > I produced a patch that fixed this problem over a month ago, > > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e > > > > Where is that patch now? It isn't present in linux-next. > > > > If it needs to be resent, please cc me on it? > > > > > > Also, is there any way of avoiding this? > > > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) > > > > That's just way too tricky. It expects all versions of the > > preprocessor to be correctly implemented (unlikely) and there are other > > tools like unifdef which want to parse kernel #defines. > > > > otoh the trick does produce a nice result and doing it any other way > > (which I can think of) would make a mess. > > > > > Maybe it should go into 2.6.31? > > > > It depends on the seriousness of the regression (number of people > > affected, whether there's a workaround, etc) and upon the riskiness of > > the patch. > > > > But sure, we don't want regressions and letting one be released when we > > already know about it and have a fix would be bad! > > > > If the patch is judged too risky at this time, there might be a simpler > > one, perhaps. > > > > Or just revert whichever patch broke things. Your changelog describes > > this as simply "A recent patch" (bad changelog!) so I am unable to judge > > this. > > Just revert it and let's wait for the next better attempt. > > We might get a lot of noise, but the patch was wrong. Absolutely nothing was wrong. Your pure existance here is wrong if there is something wrong here! As long as you do not have any clue about the subject I advise you to simply shut up, Pitton! Is that clear, Pitton??? cyber.bogh > Cheers, > Hermann > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Reply-To: patrick.boettcher@desy.de Hi all, On Mon, 20 Jul 2009, Mauro Carvalho Chehab wrote: > Em Mon, 20 Jul 2009 20:40:30 GMT > bugzilla-daemon@bugzilla.kernel.org escreveu: > >>>> btw, does the flexcop driver have a regular maintainer? Or someone who >>>> wants to volunteer? MAINTAINERS is silent about it.. > >>> I produced a patch that fixed this problem over a month ago, >>> http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e >> >> Where is that patch now? It isn't present in linux-next. > > No, this patch is inside a series of 8 patches. They aren't at linux-next > yet, > since I was waiting for some tests before applying it. > > As there's a regression that is likely fixed by one of those patches, I'll > add > it today. Please go ahead committing this patch as it fixes a bug. Full validation is not yet done and not so easily possible - seems to become an indirect validation. thanks, Patrick. -- Mail: patrick.boettcher@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ Reply-To: hermann-pitton@arcor.de Am Dienstag, den 21.07.2009, 11:20 +0200 schrieb cyber.bogh: > Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie: > > Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton: > > > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) > > > > > > Trent Piepho <xyzzy@speakeasy.org> wrote: > > > > On Mon, 20 Jul 2009, Andrew Morton wrote: > > > > > (switched to email. Please respond via emailed reply-to-all, not via > > > > > the bugzilla web interface). > > > > > > > > > > > > > > > Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael > > > > > to add it to the regression tracking list. > > > > > > > > > > btw, does the flexcop driver have a regular maintainer? Or someone > > > > > who wants to volunteer? MAINTAINERS is silent about it.. > > > > > > > > I produced a patch that fixed this problem over a month ago, > > > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e > > > > > > Where is that patch now? It isn't present in linux-next. > > > > > > If it needs to be resent, please cc me on it? > > > > > > > > > Also, is there any way of avoiding this? > > > > > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ > > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) > > > > > > That's just way too tricky. It expects all versions of the > > > preprocessor to be correctly implemented (unlikely) and there are other > > > tools like unifdef which want to parse kernel #defines. > > > > > > otoh the trick does produce a nice result and doing it any other way > > > (which I can think of) would make a mess. > > > > > > > Maybe it should go into 2.6.31? > > > > > > It depends on the seriousness of the regression (number of people > > > affected, whether there's a workaround, etc) and upon the riskiness of > > > the patch. > > > > > > But sure, we don't want regressions and letting one be released when we > > > already know about it and have a fix would be bad! > > > > > > If the patch is judged too risky at this time, there might be a simpler > > > one, perhaps. > > > > > > Or just revert whichever patch broke things. Your changelog describes > > > this as simply "A recent patch" (bad changelog!) so I am unable to judge > > > this. > > > > Just revert it and let's wait for the next better attempt. > > > > We might get a lot of noise, but the patch was wrong. > > Absolutely nothing was wrong. > Your pure existance here is wrong if there is something wrong here! > As long as you do not have any clue about the subject I advise you to simply > shut up, Pitton! > Is that clear, Pitton??? > > cyber.bogh > As always and as expected ;) Uwe, use at least your real name, if you say you are not trolling this time and serious about it. Bad enough, that you always have to come with new names and addresses. The way you dealt with Boris reporting his trouble was disgusting. Started here. http://www.spinics.net/lists/linux-media/msg07746.html Likely Matthias giving the hint with the #ifdef MODULE stuff has no clue either ??? Trent's patches converting the tuners to dvb-pll later are not yet in rc3 and the above fix attempt also not, but are all in mercurial v4l-dvb. All not needed? Why you don't provide Andrew with the information he is asking for? Cheers, Hermann Reply-To: cyber.bogh@gmx.de Am Mittwoch 22 Juli 2009 00:16:54 schrieben Sie: > Am Dienstag, den 21.07.2009, 11:20 +0200 schrieb cyber.bogh: > > Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie: > > > Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton: > > > > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) > > > > > > > > Trent Piepho <xyzzy@speakeasy.org> wrote: > > > > > On Mon, 20 Jul 2009, Andrew Morton wrote: > > > > > > (switched to email. Please respond via emailed reply-to-all, not > > > > > > via the bugzilla web interface). > > > > > > > > > > > > > > > > > > Guys, this is reportedly a post-2.6.30 regression - I'll ask > > > > > > Rafael to add it to the regression tracking list. > > > > > > > > > > > > btw, does the flexcop driver have a regular maintainer? Or > > > > > > someone who wants to volunteer? MAINTAINERS is silent about it.. > > > > > > > > > > I produced a patch that fixed this problem over a month ago, > > > > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e > > > > > > > > Where is that patch now? It isn't present in linux-next. > > > > > > > > If it needs to be resent, please cc me on it? > > > > > > > > > > > > Also, is there any way of avoiding this? > > > > > > > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ > > > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) > > > > > > > > That's just way too tricky. It expects all versions of the > > > > preprocessor to be correctly implemented (unlikely) and there are > > > > other tools like unifdef which want to parse kernel #defines. > > > > > > > > otoh the trick does produce a nice result and doing it any other way > > > > (which I can think of) would make a mess. > > > > > > > > > Maybe it should go into 2.6.31? > > > > > > > > It depends on the seriousness of the regression (number of people > > > > affected, whether there's a workaround, etc) and upon the riskiness > > > > of the patch. > > > > > > > > But sure, we don't want regressions and letting one be released when > > > > we already know about it and have a fix would be bad! > > > > > > > > If the patch is judged too risky at this time, there might be a > > > > simpler one, perhaps. > > > > > > > > Or just revert whichever patch broke things. Your changelog > > > > describes this as simply "A recent patch" (bad changelog!) so I am > > > > unable to judge this. > > > > > > Just revert it and let's wait for the next better attempt. > > > > > > We might get a lot of noise, but the patch was wrong. > > > > Absolutely nothing was wrong. > > Your pure existance here is wrong if there is something wrong here! > > As long as you do not have any clue about the subject I advise you to > > simply shut up, Pitton! > > Is that clear, Pitton??? > > > > cyber.bogh > > As always and as expected ;) > > Uwe, use at least your real name, if you say you are not trolling this > time and serious about it. Bad enough, that you always have to come with > new names and addresses. > > The way you dealt with Boris reporting his trouble was disgusting. As long as idiots do not start to think they should be smashed right into their faces..... > Started here. > http://www.spinics.net/lists/linux-media/msg07746.html > > Likely Matthias giving the hint with the #ifdef MODULE stuff has no clue > either ??? > > Trent's patches converting the tuners to dvb-pll later are not yet in > rc3 and the above fix attempt also not, but are all in mercurial > v4l-dvb. All not needed? The question is: Why is this crap in Mercurial? The answer is: Chehab policy! What does "Chehab policy" mean? Well, it means that if you're Trent Piepho your stuff will be pulled in, even if it is the biggest thinkable crap that one ever can imagine. For every other person really investigating and bringing in substantially better stuff there will be a public request whether there are objections or not (plus other possible hindrances of the more unfair kind), while people owing a repo at linuxtv.org are being trusted blindly. This policy I would compare to the functionality of a small reactionary village of petit bourgeois small brains (i. e. IQ extremely limited - somewhere in the Southern states of the US perhaps?). In other and thus quite non-misunderstanding words: It's definitely NOT the task of Andrew Morton to take care that crap like this never reaches any relevant tree, may it be kernel or may it be Mercurial: +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) It's Chehab's task and noone else's. Basta! And shall I tell you what the biggest pain about it all is? Chehab is no single example. So-called "maintainers" more and more degenerate to gatekeepers and patch samplers that wink through untested crap and thus produce unusable kernels. "Responsible and honest behaviour" does not seem to exist in those no brains. But: Sorry if I overestimated your real IQ capabilities, Pitton! cyber.bogh > Why you don't provide Andrew with the information he is asking for? > > Cheers, > Hermann Reply-To: cyber.bogh@gmx.de Am Mittwoch 22 Juli 2009 00:16:54 schrieben Sie: > Am Dienstag, den 21.07.2009, 11:20 +0200 schrieb cyber.bogh: > > Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie: > > > Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton: > > > > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) > > > > > > > > Trent Piepho <xyzzy@speakeasy.org> wrote: > > > > > On Mon, 20 Jul 2009, Andrew Morton wrote: > > > > > > (switched to email. Please respond via emailed reply-to-all, not > > > > > > via the bugzilla web interface). > > > > > > > > > > > > > > > > > > Guys, this is reportedly a post-2.6.30 regression - I'll ask > > > > > > Rafael to add it to the regression tracking list. > > > > > > > > > > > > btw, does the flexcop driver have a regular maintainer? Or > > > > > > someone who wants to volunteer? MAINTAINERS is silent about it.. > > > > > > > > > > I produced a patch that fixed this problem over a month ago, > > > > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e > > > > > > > > Where is that patch now? It isn't present in linux-next. > > > > > > > > If it needs to be resent, please cc me on it? > > > > > > > > > > > > Also, is there any way of avoiding this? > > > > > > > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ > > > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) > > > > > > > > That's just way too tricky. It expects all versions of the > > > > preprocessor to be correctly implemented (unlikely) and there are > > > > other tools like unifdef which want to parse kernel #defines. > > > > > > > > otoh the trick does produce a nice result and doing it any other way > > > > (which I can think of) would make a mess. > > > > > > > > > Maybe it should go into 2.6.31? > > > > > > > > It depends on the seriousness of the regression (number of people > > > > affected, whether there's a workaround, etc) and upon the riskiness > > > > of the patch. > > > > > > > > But sure, we don't want regressions and letting one be released when > > > > we already know about it and have a fix would be bad! > > > > > > > > If the patch is judged too risky at this time, there might be a > > > > simpler one, perhaps. > > > > > > > > Or just revert whichever patch broke things. Your changelog > > > > describes this as simply "A recent patch" (bad changelog!) so I am > > > > unable to judge this. > > > > > > Just revert it and let's wait for the next better attempt. > > > > > > We might get a lot of noise, but the patch was wrong. > > > > Absolutely nothing was wrong. > > Your pure existance here is wrong if there is something wrong here! > > As long as you do not have any clue about the subject I advise you to > > simply shut up, Pitton! > > Is that clear, Pitton??? > > > > cyber.bogh > > As always and as expected ;) > > Uwe, use at least your real name, if you say you are not trolling this > time and serious about it. Bad enough, that you always have to come with > new names and addresses. > > The way you dealt with Boris reporting his trouble was disgusting. As long as idiots do not start to think they should be smashed right into their faces..... > Started here. > http://www.spinics.net/lists/linux-media/msg07746.html > > Likely Matthias giving the hint with the #ifdef MODULE stuff has no clue > either ??? > > Trent's patches converting the tuners to dvb-pll later are not yet in > rc3 and the above fix attempt also not, but are all in mercurial > v4l-dvb. All not needed? The question is: Why is this crap in Mercurial? The answer is: Chehab policy! What does "Chehab policy" mean? Well, it means that if you're Trent Piepho your stuff will be pulled in, even if it is the biggest thinkable crap that one ever can imagine. For every other person really investigating and bringing in substantially better stuff there will be a public request whether there are objections or not (plus other possible hindrances of the more unfair kind), while people owing a repo at linuxtv.org are being trusted blindly. This policy I would compare to the functionality of a small reactionary village of petit bourgeois small brains (i. e. IQ extremely limited - somewhere in the Southern states of the US perhaps?). In other and thus quite non-misunderstanding words: It's definitely NOT the task of Andrew Morton to take care that crap like this never reaches any relevant tree, may it be kernel or may it be Mercurial: +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) It's Chehab's task and noone else's. Basta! And shall I tell you what the biggest pain about it all is? Chehab is no single example. So-called "maintainers" more and more degenerate to gatekeepers and patch samplers that wink through untested crap and thus produce unusable kernels. "Responsible and honest behaviour" does not seem to exist in those no brains. But: Sorry if I overestimated your real IQ capabilities, Pitton! cyber.bogh > Why you don't provide Andrew with the information he is asking for? > > Cheers, > Hermann On Mon, 20 Jul 2009, Andrew Morton wrote: > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) > Trent Piepho <xyzzy@speakeasy.org> wrote: > > On Mon, 20 Jul 2009, Andrew Morton wrote: > > I produced a patch that fixed this problem over a month ago, > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e > > Where is that patch now? It isn't present in linux-next. Mauro has how pulled it from me and so it will probably show up in his tree soon. > Also, is there any way of avoiding this? > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) > > That's just way too tricky. It expects all versions of the > preprocessor to be correctly implemented (unlikely) and there are other > tools like unifdef which want to parse kernel #defines. What's so tricky about it? A quick grep shows hundreds of uses of ## for concatenation. > otoh the trick does produce a nice result and doing it any other way > (which I can think of) would make a mess. This particular kind of test is something that is used many times in the dvb code. This isn't the first time someone has gotten it wrong by a long shot. Mauro suggested, and I agree, that for the next kernel we should put FE_SUPPORTED into a dvb header file and convert the many existing tests to use it. Maybe this will reduce the number of mistakes. > Or just revert whichever patch broke things. Your changelog describes > this as simply "A recent patch" (bad changelog!) so I am unable to judge > this. It was commit d66b94b4aa2f40e134f8c07c58ae74ef3d523ee0, but it was not committed until five days after I made my patch, so there was no hash to reference yet. I suppose I should have used the patch title. On Mon, 20 Jul 2009, Andrew Morton wrote: > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) > Trent Piepho <xyzzy@speakeasy.org> wrote: > > On Mon, 20 Jul 2009, Andrew Morton wrote: > > I produced a patch that fixed this problem over a month ago, > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e > > Where is that patch now? It isn't present in linux-next. Mauro has how pulled it from me and so it will probably show up in his tree soon. > Also, is there any way of avoiding this? > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) > > That's just way too tricky. It expects all versions of the > preprocessor to be correctly implemented (unlikely) and there are other > tools like unifdef which want to parse kernel #defines. What's so tricky about it? A quick grep shows hundreds of uses of ## for concatenation. > otoh the trick does produce a nice result and doing it any other way > (which I can think of) would make a mess. This particular kind of test is something that is used many times in the dvb code. This isn't the first time someone has gotten it wrong by a long shot. Mauro suggested, and I agree, that for the next kernel we should put FE_SUPPORTED into a dvb header file and convert the many existing tests to use it. Maybe this will reduce the number of mistakes. > Or just revert whichever patch broke things. Your changelog describes > this as simply "A recent patch" (bad changelog!) so I am unable to judge > this. It was commit d66b94b4aa2f40e134f8c07c58ae74ef3d523ee0, but it was not committed until five days after I made my patch, so there was no hash to reference yet. I suppose I should have used the patch title. On Wed, 22 Jul 2009 00:19:00 -0700 (PDT) Trent Piepho <xyzzy@speakeasy.org> wrote: > On Mon, 20 Jul 2009, Andrew Morton wrote: > > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) > > Trent Piepho <xyzzy@speakeasy.org> wrote: > > > On Mon, 20 Jul 2009, Andrew Morton wrote: > > > I produced a patch that fixed this problem over a month ago, > > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e > > > > Where is that patch now? It isn't present in linux-next. > > Mauro has how pulled it from me and so it will probably show up in his tree > soon. > > > Also, is there any way of avoiding this? > > > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) > > > > That's just way too tricky. It expects all versions of the > > preprocessor to be correctly implemented (unlikely) and there are other > > tools like unifdef which want to parse kernel #defines. > > What's so tricky about it? A quick grep shows hundreds of uses of > ## for concatenation. Not the concatenation, of course. The worrisomie thing is the macro which expands to preprocessor statements. It requires that the preprocessor run itself multiple times across the same line. Or something. I don't recall seeing that trick used elsewhere in the kernel and I have vague memories of it causing problems in the past. Em Wed, 22 Jul 2009 07:58:08 GMT bugzilla-daemon@bugzilla.kernel.org escreveu: > --- Comment #22 from Andrew Morton <akpm@linux-foundation.org> 2009-07-22 > 07:58:08 --- > On Wed, 22 Jul 2009 00:19:00 -0700 (PDT) Trent Piepho <xyzzy@speakeasy.org> > wrote: > > On Mon, 20 Jul 2009, Andrew Morton wrote: > > > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) > > > Trent Piepho <xyzzy@speakeasy.org> wrote: > > > > On Mon, 20 Jul 2009, Andrew Morton wrote: > > > > I produced a patch that fixed this problem over a month ago, > > > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e > > > > > > Where is that patch now? It isn't present in linux-next. > > > > Mauro has how pulled it from me and so it will probably show up in his tree > > soon. Looking at commit d66b94b4aa2f40e134f8c07c58ae74ef3d523ee0, it is clear that the case where DVB frontends are builtin into kernel weren't considered. So, the better is to add this patch or something similar to fix the issue. Except for that, the patch seems correct. Since this is a cleanup patch, reverting it won't cause regressions, but IMO, now the code looks on a better shape. > > > Also, is there any way of avoiding this? > > > > > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ > > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) > > > > > > That's just way too tricky. It expects all versions of the > > > preprocessor to be correctly implemented (unlikely) and there are other > > > tools like unifdef which want to parse kernel #defines. > > > > What's so tricky about it? A quick grep shows hundreds of uses of > > ## for concatenation. > > Not the concatenation, of course. > > The worrisomie thing is the macro which expands to preprocessor > statements. It requires that the preprocessor run itself multiple > times across the same line. Or something. I don't recall seeing that > trick used elsewhere in the kernel and I have vague memories of it > causing problems in the past. Hmm... if the macro shouldn't be used due to gcc preprocessor bugs, we need to seek to another alternative for doing something similar. A simple fix would be to add the check for CONFIG_DVB_foo on all places at flexcorp. However, as the number of tests like that on DVB is very high and, as almost all DVB developers use modules only on their tests, it is a common bug to forget to test for the builtin case. So, I prefer to have an approach that would avoid regressions. One alternative would be to create a series of hidden Kconfig boolean items that is true if a frontend is selected as module or as builtin, like: config DVB_MT312 tristate "Zarlink VP310/MT312/ZL10313 based" depends on DVB_CORE && I2C default m if DVB_FE_CUSTOMISE help A DVB-S tuner module. Say Y when you want to support this frontend. config FE_MT312 boolean depends on DVB_MT312 However, this would duplicate all FE Kbuild items (and probably tuners) and will increase the complexity of Kconfig. Another alternative would be to use boolean Kconfig items for enabling/disabling FE/tuners, and a global boolean item to select if fronends would be built as modules or as builtin. The rationale is that there aren't much advantage of having parts of the frontends built as modules and others as builtin, and such patch will reduce the number of possibilities (and the probability of potential failures) at Kbuild. A third alternative would be to have a header file that does the trick on an old way, like: #ifdef CONFIG_MODULE #ifdef CONFIG_DVB_MT312_MODULE) #define FE_MT312 #endif ... #else #ifdef CONFIG_DVB_MT312) #define FE_MT312 #endif ... #endif Finally, a forth alternative would be to change Kbuild to define a macro symbol that will be true if the driver is either a module or builtin. IMO, Trent's solution were the clearer one, but, if this won't work with all supported gcc versions, we need another alternative. I'm in favor of using a solution that will avoid future regressions like that by either some concatenation macro or by some other build tricks. Andrew, what do you think it would work better? PS.: It should be noticed that there are other patches at Trent's series that will use this macro while moving trivial tuner code from flexcop into dvb-pll (where we handle the trivial tuner cases). So, if we decide to remove it, we'll need to apply some glue to avoid bisect breakages. Cheers, Mauro On Monday 27 July 2009, Boris Cuber wrote:
> Am Sonntag, 26. Juli 2009 schrieben Sie:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.30. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13709
> > Subject : b2c2-flexcop: no frontend driver found for this
> B2C2/FlexCop
> > adapter w/ kernel-2.6.31-rc2 Submitter : boris64
> > <bugzilla.kernel.org@boris64.net>
> > Date : 2009-07-05 01:36 (22 days old)
>
> Compiling the b2c2-flexcop and frontend modules into the kernel
> still (kernel-2.6.31-rc4) results in a nonworking "Technisat SkyStar2"
> dvb adapter.
This issue is fixed since 2.6.31-rc4-00109-ge00b95d-dirty. (-> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;f=drivers/media/dvb/b2c2/flexcop-fe-tuner.c;hb=68b7f7616add4b1de0fe75015ba3884d2d9ff796) Thank you for helping out. On Wed, 22 Jul 2009, Andrew Morton wrote: > > > Also, is there any way of avoiding this? > > > > > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ > > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) > > > > > > That's just way too tricky. It expects all versions of the > > > preprocessor to be correctly implemented (unlikely) and there are other > > > tools like unifdef which want to parse kernel #defines. > > > > What's so tricky about it? A quick grep shows hundreds of uses of > > ## for concatenation. > > Not the concatenation, of course. > > The worrisomie thing is the macro which expands to preprocessor > statements. It requires that the preprocessor run itself multiple > times across the same line. Or something. I don't recall seeing that > trick used elsewhere in the kernel and I have vague memories of it > causing problems in the past. Well, there is this now: arch/powerpc/include/asm/cputable.h:#define CLASSIC_PPC (!defined(CONFIG_8xx) && !defined(CONFIG_4xx) && \ include/drm/drmP.h:#define __OS_HAS_AGP (defined(CONFIG_AGP) || (defined(CONFIG_AGP_MODULE) && defined(MODULE))) include/drm/drmP.h:#define __OS_HAS_MTRR (defined(CONFIG_MTRR)) Though I can't find any macros with arguments that use those arguments in preprocessor directives. On Wed, 22 Jul 2009, Andrew Morton wrote: > > > Also, is there any way of avoiding this? > > > > > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ > > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) > > > > > > That's just way too tricky. It expects all versions of the > > > preprocessor to be correctly implemented (unlikely) and there are other > > > tools like unifdef which want to parse kernel #defines. > > > > What's so tricky about it? A quick grep shows hundreds of uses of > > ## for concatenation. > > Not the concatenation, of course. > > The worrisomie thing is the macro which expands to preprocessor > statements. It requires that the preprocessor run itself multiple > times across the same line. Or something. I don't recall seeing that > trick used elsewhere in the kernel and I have vague memories of it > causing problems in the past. Well, there is this now: arch/powerpc/include/asm/cputable.h:#define CLASSIC_PPC (!defined(CONFIG_8xx) && !defined(CONFIG_4xx) && \ include/drm/drmP.h:#define __OS_HAS_AGP (defined(CONFIG_AGP) || (defined(CONFIG_AGP_MODULE) && defined(MODULE))) include/drm/drmP.h:#define __OS_HAS_MTRR (defined(CONFIG_MTRR)) Though I can't find any macros with arguments that use those arguments in preprocessor directives. |