Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
> > It would be nice, however, to have a patch making dvb_attach more
> > generic, by e.g. having a variant that allows passing another message.
>
> Only this message is from dvb_attach():
> > DVB: Unable to find symbol dst_attach()
>
> Is it saying that it cannot load the module that dst_attach() is in (it
> doesn't know what module that is, modprobe knows that). If you enabled dst
> support and deleted the module, it would be the same.
>
> If you turn off dvb_attach() and also disable dst, you should instead get
> this message:
> dst_attach: driver disabled by Kconfig
>
> Maybe that would look nicer with a "DVB: " prefix? That would easier if it
> wasn't necessary to update the printk in each boilerplate stub function. What
> if one macro created these stubs
>
> > frontend_init: Could not find a Twinhan DST.
> > dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem
> > fbfb/f800
>
> These two messages are printed by the dvb-bt8xx driver, not by dvb_attach().
> It would be trivial to change of course, but I'm not sure what would be
> pedantically correct for both dst and non-dst based hardware.
Sorry, this is what I meant: to fix the above message. The dvb_attach is
generic enough.
Maybe a more nice text would be something like:
"Couldn't initialize frontend helper modules for device ..."
since dvb_attach will also print what modules were not loaded.
>
> > There's an argument against the prototype changes on dst_attach and
> > dst_ca_attach since they aren't frontend.
>
> The reason I changed that, is the dst_attach() already did return a
> dvb_frontend pointer, it was just inside an enclosing structure. i.e. what
> existed before:
>
> {
> struct dst_state *state;
> state = dst_attach(...);
> card->fe = >frontend;
> } /* state goes out of scope */
>
> The frontend is inside the state struct and the state pointer isn't saved
> anywhere. dvb-bt8xx just saves a frontend pointer from inside the dst state
> and tosses the state pointer away. So I changed that to:
>
> card->fe = dst_attach(...);
IMO, this made the code cleaner.
--
Cheers,
Mauro
-
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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
It would be nice, however, to have a patch making dvb_attach more
generic, by e.g. having a variant that allows passing another message.
Only this message is from dvb_attach():
DVB: Unable to find symbol dst_attach()
Is it saying that it cannot load the module that dst_attach() is in (it
doesn't know what module that is, modprobe knows that). If you enabled dst
support and deleted the module, it would be the same.
If you turn off dvb_attach() and also disable dst, you should instead get
this message:
dst_attach: driver disabled by Kconfig
Maybe that would look nicer with a DVB: prefix? That would easier if it
wasn't necessary to update the printk in each boilerplate stub function. What
if one macro created these stubs
frontend_init: Could not find a Twinhan DST.
dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem
fbfb/f800
These two messages are printed by the dvb-bt8xx driver, not by dvb_attach().
It would be trivial to change of course, but I'm not sure what would be
pedantically correct for both dst and non-dst based hardware.
Sorry, this is what I meant: to fix the above message. The dvb_attach is
generic enough.
Maybe a more nice text would be something like:
Couldn't initialize frontend helper modules for device ...
since dvb_attach will also print what modules were not loaded.
There's an argument against the prototype changes on dst_attach and
dst_ca_attach since they aren't frontend.
The reason I changed that, is the dst_attach() already did return a
dvb_frontend pointer, it was just inside an enclosing structure. i.e. what
existed before:
{
struct dst_state *state;
state = dst_attach(...);
card-fe = state-frontend;
} /* state goes out of scope */
The frontend is inside the state struct and the state pointer isn't saved
anywhere. dvb-bt8xx just saves a frontend pointer from inside the dst state
and tosses the state pointer away. So I changed that to:
card-fe = dst_attach(...);
IMO, this made the code cleaner.
--
Cheers,
Mauro
-
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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
On Thu, 3 May 2007, Mauro Carvalho Chehab wrote:
> Em Qua, 2007-05-02 ??s 04:10 -0700, Trent Piepho escreveu:
> > I promise, this time it's right!
> > http://linuxtv.org/hg/~tap/dst-new
>
> Confirmed. Now the patch is properly working. My tests were done with a
> board with DST. Those are the results:
>
> 1) when DST is unselected, on a board with DST, it will print the errors
> indicating that the Kconfig items were not selected:
>
> DVB: registering new adapter (bttv0).
> DVB: Unable to find symbol dst_attach()
> frontend_init: Could not find a Twinhan DST.
> dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem
> fbfb/f800
>
> The only issue is the wrong printk msg, stating that a "frontend driver"
> were not found. As this issue also happens with the current driver, due
> the usage of dvb_attach() macro, I don't see any regressions.
>
> It would be nice, however, to have a patch making dvb_attach more
> generic, by e.g. having a variant that allows passing another message.
Only this message is from dvb_attach():
> DVB: Unable to find symbol dst_attach()
Is it saying that it cannot load the module that dst_attach() is in (it
doesn't know what module that is, modprobe knows that). If you enabled dst
support and deleted the module, it would be the same.
If you turn off dvb_attach() and also disable dst, you should instead get
this message:
dst_attach: driver disabled by Kconfig
Maybe that would look nicer with a "DVB: " prefix? That would easier if it
wasn't necessary to update the printk in each boilerplate stub function. What
if one macro created these stubs
> frontend_init: Could not find a Twinhan DST.
> dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem
> fbfb/f800
These two messages are printed by the dvb-bt8xx driver, not by dvb_attach().
It would be trivial to change of course, but I'm not sure what would be
pedantically correct for both dst and non-dst based hardware.
> There's an argument against the prototype changes on dst_attach and
> dst_ca_attach since they aren't frontend.
The reason I changed that, is the dst_attach() already did return a
dvb_frontend pointer, it was just inside an enclosing structure. i.e. what
existed before:
{
struct dst_state *state;
state = dst_attach(...);
card->fe = >frontend;
} /* state goes out of scope */
The frontend is inside the state struct and the state pointer isn't saved
anywhere. dvb-bt8xx just saves a frontend pointer from inside the dst state
and tosses the state pointer away. So I changed that to:
card->fe = dst_attach(...);
-
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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Thu, 03 May 2007 19:15:32 +0400 Von: Manu Abraham <[EMAIL PROTECTED]> An: Mauro Carvalho Chehab <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], Trent Piepho <[EMAIL PROTECTED]>, linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...) > Mauro Carvalho Chehab wrote: > > Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu: > >> On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > > > >>> However, when dst is selected, I got those errors: > >> When I made this patch I was basing it off a patch I made around 9 > months > >> ago. I thought since that one was ok, this would be ok too, and in my > >> hurry to get it done I've clearly put too little effort into checking > it, > >> and I'm sorry to have wasted your time. > >> > >> I promise, this time it's right! > >> http://linuxtv.org/hg/~tap/dst-new > > > > Confirmed. Now the patch is properly working. My tests were done with a > > board with DST. Those are the results: > > > > 1) when DST is unselected, on a board with DST, it will print the errors > > indicating that the Kconfig items were not selected: > > > > DVB: registering new adapter (bttv0). > > DVB: Unable to find symbol dst_attach() > > frontend_init: Could not find a Twinhan DST. > > dvb-bt8xx: A frontend driver was not found for device 109e/0878 > subsystem fbfb/f800 > > > > The only issue is the wrong printk msg, stating that a "frontend driver" > > were not found. As this issue also happens with the current driver, due > > the usage of dvb_attach() macro, I don't see any regressions. > > > > It would be nice, however, to have a patch making dvb_attach more > > generic, by e.g. having a variant that allows passing another message. > > > > Trying to run dvb programs like scan and kaffeine will properly fail. > > > > 2) With DST selected, the driver works properly. > > > > The changes also solved the issue of removing the dst drivers. Before > > the patch, sometimes it is required to force removal of dst module with > > the '-f' flag, since the module count were wrong. > > > > --- > > > > I'll risk to make a briefing of the technical points: > > > > > > Current issues: > > 1) allow deselecting DST/DST_CA support, since this is not needed by > > some supported boards; > > 2) sometimes, module removal don't work with dst, since usage count > > becomes wrong; > > 3) if dst or dst_ca is not properly loaded, the printk message wrongly > > indicates that "A frontend driver was not found" > > > > The Trent's original patch were written on Aug, 2006 (*). The current > > version fixes (1) and (2). It doesn't touch on (3). There aren't any > > other patches properly fixing (1) and (2). > > > > There's an argument against the prototype changes on dst_attach and > > dst_ca_attach since they aren't frontend. > > > > > > (*) Notice: I can't remember why the patches were not applied on that > > time. I think somebody nacked they, although I didn't found any record > > about the patch on my mailbox. > > > > About the usage of frontend support for a non-frontend module, I really > > can't see any issues at the current implementation, since even before > > the patch, all DST initialization are done by a routine called > > "frontend_init()". > > *Wrong*. Frontend Init sends a command to the whole system to > initialize the frontend, Not initialize the DST > Whatever frontend naming conventions are in there are a relic from > Andrew's FE_REFACTORING changesets. > > Even dst not being a frontend, the initialization > > gets the result of the attachment process, using it as a "frontend": > > > > state = kmalloc(sizeof (struct dst_state), GFP_KERNEL); > > > > state->config = _config; > > state->i2c = card->i2c_adapter; > > state->bt = card->bt; > > state->dst_ca = NULL; > > > > dvb_attach(dst_attach, state, >dvb_adapter); > > > > card->fe = >frontend; > > > > (comments and error checks removed to make code cleaner) > > > > The patch basically moved state initialization to dst_attach. The above > > code, after the patch is: > > > > card->fe = dvb_attach(dst_attach, _config, card->bt, > card->i2c_adapter); > > > >
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Mauro Carvalho Chehab wrote: > Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu: >> On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > >>> However, when dst is selected, I got those errors: >> When I made this patch I was basing it off a patch I made around 9 months >> ago. I thought since that one was ok, this would be ok too, and in my >> hurry to get it done I've clearly put too little effort into checking it, >> and I'm sorry to have wasted your time. >> >> I promise, this time it's right! >> http://linuxtv.org/hg/~tap/dst-new > > Confirmed. Now the patch is properly working. My tests were done with a > board with DST. Those are the results: > > 1) when DST is unselected, on a board with DST, it will print the errors > indicating that the Kconfig items were not selected: > > DVB: registering new adapter (bttv0). > DVB: Unable to find symbol dst_attach() > frontend_init: Could not find a Twinhan DST. > dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem > fbfb/f800 > > The only issue is the wrong printk msg, stating that a "frontend driver" > were not found. As this issue also happens with the current driver, due > the usage of dvb_attach() macro, I don't see any regressions. > > It would be nice, however, to have a patch making dvb_attach more > generic, by e.g. having a variant that allows passing another message. > > Trying to run dvb programs like scan and kaffeine will properly fail. > > 2) With DST selected, the driver works properly. > > The changes also solved the issue of removing the dst drivers. Before > the patch, sometimes it is required to force removal of dst module with > the '-f' flag, since the module count were wrong. > > --- > > I'll risk to make a briefing of the technical points: > > > Current issues: > 1) allow deselecting DST/DST_CA support, since this is not needed by > some supported boards; > 2) sometimes, module removal don't work with dst, since usage count > becomes wrong; > 3) if dst or dst_ca is not properly loaded, the printk message wrongly > indicates that "A frontend driver was not found" > > The Trent's original patch were written on Aug, 2006 (*). The current > version fixes (1) and (2). It doesn't touch on (3). There aren't any > other patches properly fixing (1) and (2). > > There's an argument against the prototype changes on dst_attach and > dst_ca_attach since they aren't frontend. > > > (*) Notice: I can't remember why the patches were not applied on that > time. I think somebody nacked they, although I didn't found any record > about the patch on my mailbox. > > About the usage of frontend support for a non-frontend module, I really > can't see any issues at the current implementation, since even before > the patch, all DST initialization are done by a routine called > "frontend_init()". *Wrong*. Frontend Init sends a command to the whole system to initialize the frontend, Not initialize the DST Whatever frontend naming conventions are in there are a relic from Andrew's FE_REFACTORING changesets. Even dst not being a frontend, the initialization > gets the result of the attachment process, using it as a "frontend": > > state = kmalloc(sizeof (struct dst_state), GFP_KERNEL); > > state->config = _config; > state->i2c = card->i2c_adapter; > state->bt = card->bt; > state->dst_ca = NULL; > > dvb_attach(dst_attach, state, >dvb_adapter); > > card->fe = >frontend; > > (comments and error checks removed to make code cleaner) > > The patch basically moved state initialization to dst_attach. The above > code, after the patch is: > > card->fe = dvb_attach(dst_attach, _config, card->bt, > card->i2c_adapter); > > So, I didn't noticed any regressions by running the modified driver nor > I couldn't identify any regressions by inspecting the source code. > > The end result seems also cleaner and easier to understand, preserving > all characteristics of the original code. Also, it uses dvb_attach the > same way as the other dvb helper modules. > > If later any changes will be needed to allow using DST on different > configurations, future patches probably will need to move dst > initialization to other places, and use different callbacks for it, > altering the above initialization. I can't see why those changes would > possibly avoid any further changes at the driver. > > That's said, I intend to commit the two patches, fixing the current > issues, at this weekend. > I did explain my stand in a previous mail. NACK - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu: > On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > > However, when dst is selected, I got those errors: > > When I made this patch I was basing it off a patch I made around 9 months > ago. I thought since that one was ok, this would be ok too, and in my > hurry to get it done I've clearly put too little effort into checking it, > and I'm sorry to have wasted your time. > > I promise, this time it's right! > http://linuxtv.org/hg/~tap/dst-new Confirmed. Now the patch is properly working. My tests were done with a board with DST. Those are the results: 1) when DST is unselected, on a board with DST, it will print the errors indicating that the Kconfig items were not selected: DVB: registering new adapter (bttv0). DVB: Unable to find symbol dst_attach() frontend_init: Could not find a Twinhan DST. dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800 The only issue is the wrong printk msg, stating that a "frontend driver" were not found. As this issue also happens with the current driver, due the usage of dvb_attach() macro, I don't see any regressions. It would be nice, however, to have a patch making dvb_attach more generic, by e.g. having a variant that allows passing another message. Trying to run dvb programs like scan and kaffeine will properly fail. 2) With DST selected, the driver works properly. The changes also solved the issue of removing the dst drivers. Before the patch, sometimes it is required to force removal of dst module with the '-f' flag, since the module count were wrong. --- I'll risk to make a briefing of the technical points: Current issues: 1) allow deselecting DST/DST_CA support, since this is not needed by some supported boards; 2) sometimes, module removal don't work with dst, since usage count becomes wrong; 3) if dst or dst_ca is not properly loaded, the printk message wrongly indicates that "A frontend driver was not found" The Trent's original patch were written on Aug, 2006 (*). The current version fixes (1) and (2). It doesn't touch on (3). There aren't any other patches properly fixing (1) and (2). There's an argument against the prototype changes on dst_attach and dst_ca_attach since they aren't frontend. (*) Notice: I can't remember why the patches were not applied on that time. I think somebody nacked they, although I didn't found any record about the patch on my mailbox. About the usage of frontend support for a non-frontend module, I really can't see any issues at the current implementation, since even before the patch, all DST initialization are done by a routine called "frontend_init()". Even dst not being a frontend, the initialization gets the result of the attachment process, using it as a "frontend": state = kmalloc(sizeof (struct dst_state), GFP_KERNEL); state->config = _config; state->i2c = card->i2c_adapter; state->bt = card->bt; state->dst_ca = NULL; dvb_attach(dst_attach, state, >dvb_adapter); card->fe = >frontend; (comments and error checks removed to make code cleaner) The patch basically moved state initialization to dst_attach. The above code, after the patch is: card->fe = dvb_attach(dst_attach, _config, card->bt, card->i2c_adapter); So, I didn't noticed any regressions by running the modified driver nor I couldn't identify any regressions by inspecting the source code. The end result seems also cleaner and easier to understand, preserving all characteristics of the original code. Also, it uses dvb_attach the same way as the other dvb helper modules. If later any changes will be needed to allow using DST on different configurations, future patches probably will need to move dst initialization to other places, and use different callbacks for it, altering the above initialization. I can't see why those changes would possibly avoid any further changes at the driver. That's said, I intend to commit the two patches, fixing the current issues, at this weekend. I'm open to other technical reviews of the patches. -- Cheers, Mauro - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu: On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: However, when dst is selected, I got those errors: When I made this patch I was basing it off a patch I made around 9 months ago. I thought since that one was ok, this would be ok too, and in my hurry to get it done I've clearly put too little effort into checking it, and I'm sorry to have wasted your time. I promise, this time it's right! http://linuxtv.org/hg/~tap/dst-new Confirmed. Now the patch is properly working. My tests were done with a board with DST. Those are the results: 1) when DST is unselected, on a board with DST, it will print the errors indicating that the Kconfig items were not selected: DVB: registering new adapter (bttv0). DVB: Unable to find symbol dst_attach() frontend_init: Could not find a Twinhan DST. dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800 The only issue is the wrong printk msg, stating that a frontend driver were not found. As this issue also happens with the current driver, due the usage of dvb_attach() macro, I don't see any regressions. It would be nice, however, to have a patch making dvb_attach more generic, by e.g. having a variant that allows passing another message. Trying to run dvb programs like scan and kaffeine will properly fail. 2) With DST selected, the driver works properly. The changes also solved the issue of removing the dst drivers. Before the patch, sometimes it is required to force removal of dst module with the '-f' flag, since the module count were wrong. --- I'll risk to make a briefing of the technical points: SUMMARY Current issues: 1) allow deselecting DST/DST_CA support, since this is not needed by some supported boards; 2) sometimes, module removal don't work with dst, since usage count becomes wrong; 3) if dst or dst_ca is not properly loaded, the printk message wrongly indicates that A frontend driver was not found The Trent's original patch were written on Aug, 2006 (*). The current version fixes (1) and (2). It doesn't touch on (3). There aren't any other patches properly fixing (1) and (2). There's an argument against the prototype changes on dst_attach and dst_ca_attach since they aren't frontend. /SUMMARY (*) Notice: I can't remember why the patches were not applied on that time. I think somebody nacked they, although I didn't found any record about the patch on my mailbox. About the usage of frontend support for a non-frontend module, I really can't see any issues at the current implementation, since even before the patch, all DST initialization are done by a routine called frontend_init(). Even dst not being a frontend, the initialization gets the result of the attachment process, using it as a frontend: state = kmalloc(sizeof (struct dst_state), GFP_KERNEL); state-config = dst_config; state-i2c = card-i2c_adapter; state-bt = card-bt; state-dst_ca = NULL; dvb_attach(dst_attach, state, card-dvb_adapter); card-fe = state-frontend; (comments and error checks removed to make code cleaner) The patch basically moved state initialization to dst_attach. The above code, after the patch is: card-fe = dvb_attach(dst_attach, dst_config, card-bt, card-i2c_adapter); So, I didn't noticed any regressions by running the modified driver nor I couldn't identify any regressions by inspecting the source code. The end result seems also cleaner and easier to understand, preserving all characteristics of the original code. Also, it uses dvb_attach the same way as the other dvb helper modules. If later any changes will be needed to allow using DST on different configurations, future patches probably will need to move dst initialization to other places, and use different callbacks for it, altering the above initialization. I can't see why those changes would possibly avoid any further changes at the driver. That's said, I intend to commit the two patches, fixing the current issues, at this weekend. I'm open to other technical reviews of the patches. -- Cheers, Mauro - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Mauro Carvalho Chehab wrote: Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu: On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: However, when dst is selected, I got those errors: When I made this patch I was basing it off a patch I made around 9 months ago. I thought since that one was ok, this would be ok too, and in my hurry to get it done I've clearly put too little effort into checking it, and I'm sorry to have wasted your time. I promise, this time it's right! http://linuxtv.org/hg/~tap/dst-new Confirmed. Now the patch is properly working. My tests were done with a board with DST. Those are the results: 1) when DST is unselected, on a board with DST, it will print the errors indicating that the Kconfig items were not selected: DVB: registering new adapter (bttv0). DVB: Unable to find symbol dst_attach() frontend_init: Could not find a Twinhan DST. dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800 The only issue is the wrong printk msg, stating that a frontend driver were not found. As this issue also happens with the current driver, due the usage of dvb_attach() macro, I don't see any regressions. It would be nice, however, to have a patch making dvb_attach more generic, by e.g. having a variant that allows passing another message. Trying to run dvb programs like scan and kaffeine will properly fail. 2) With DST selected, the driver works properly. The changes also solved the issue of removing the dst drivers. Before the patch, sometimes it is required to force removal of dst module with the '-f' flag, since the module count were wrong. --- I'll risk to make a briefing of the technical points: SUMMARY Current issues: 1) allow deselecting DST/DST_CA support, since this is not needed by some supported boards; 2) sometimes, module removal don't work with dst, since usage count becomes wrong; 3) if dst or dst_ca is not properly loaded, the printk message wrongly indicates that A frontend driver was not found The Trent's original patch were written on Aug, 2006 (*). The current version fixes (1) and (2). It doesn't touch on (3). There aren't any other patches properly fixing (1) and (2). There's an argument against the prototype changes on dst_attach and dst_ca_attach since they aren't frontend. /SUMMARY (*) Notice: I can't remember why the patches were not applied on that time. I think somebody nacked they, although I didn't found any record about the patch on my mailbox. About the usage of frontend support for a non-frontend module, I really can't see any issues at the current implementation, since even before the patch, all DST initialization are done by a routine called frontend_init(). *Wrong*. Frontend Init sends a command to the whole system to initialize the frontend, Not initialize the DST Whatever frontend naming conventions are in there are a relic from Andrew's FE_REFACTORING changesets. Even dst not being a frontend, the initialization gets the result of the attachment process, using it as a frontend: state = kmalloc(sizeof (struct dst_state), GFP_KERNEL); state-config = dst_config; state-i2c = card-i2c_adapter; state-bt = card-bt; state-dst_ca = NULL; dvb_attach(dst_attach, state, card-dvb_adapter); card-fe = state-frontend; (comments and error checks removed to make code cleaner) The patch basically moved state initialization to dst_attach. The above code, after the patch is: card-fe = dvb_attach(dst_attach, dst_config, card-bt, card-i2c_adapter); So, I didn't noticed any regressions by running the modified driver nor I couldn't identify any regressions by inspecting the source code. The end result seems also cleaner and easier to understand, preserving all characteristics of the original code. Also, it uses dvb_attach the same way as the other dvb helper modules. If later any changes will be needed to allow using DST on different configurations, future patches probably will need to move dst initialization to other places, and use different callbacks for it, altering the above initialization. I can't see why those changes would possibly avoid any further changes at the driver. That's said, I intend to commit the two patches, fixing the current issues, at this weekend. I did explain my stand in a previous mail. NACK - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Thu, 03 May 2007 19:15:32 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Mauro Carvalho Chehab [EMAIL PROTECTED] CC: [EMAIL PROTECTED], Trent Piepho [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Criticalpoints about ...) Mauro Carvalho Chehab wrote: Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu: On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: However, when dst is selected, I got those errors: When I made this patch I was basing it off a patch I made around 9 months ago. I thought since that one was ok, this would be ok too, and in my hurry to get it done I've clearly put too little effort into checking it, and I'm sorry to have wasted your time. I promise, this time it's right! http://linuxtv.org/hg/~tap/dst-new Confirmed. Now the patch is properly working. My tests were done with a board with DST. Those are the results: 1) when DST is unselected, on a board with DST, it will print the errors indicating that the Kconfig items were not selected: DVB: registering new adapter (bttv0). DVB: Unable to find symbol dst_attach() frontend_init: Could not find a Twinhan DST. dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800 The only issue is the wrong printk msg, stating that a frontend driver were not found. As this issue also happens with the current driver, due the usage of dvb_attach() macro, I don't see any regressions. It would be nice, however, to have a patch making dvb_attach more generic, by e.g. having a variant that allows passing another message. Trying to run dvb programs like scan and kaffeine will properly fail. 2) With DST selected, the driver works properly. The changes also solved the issue of removing the dst drivers. Before the patch, sometimes it is required to force removal of dst module with the '-f' flag, since the module count were wrong. --- I'll risk to make a briefing of the technical points: SUMMARY Current issues: 1) allow deselecting DST/DST_CA support, since this is not needed by some supported boards; 2) sometimes, module removal don't work with dst, since usage count becomes wrong; 3) if dst or dst_ca is not properly loaded, the printk message wrongly indicates that A frontend driver was not found The Trent's original patch were written on Aug, 2006 (*). The current version fixes (1) and (2). It doesn't touch on (3). There aren't any other patches properly fixing (1) and (2). There's an argument against the prototype changes on dst_attach and dst_ca_attach since they aren't frontend. /SUMMARY (*) Notice: I can't remember why the patches were not applied on that time. I think somebody nacked they, although I didn't found any record about the patch on my mailbox. About the usage of frontend support for a non-frontend module, I really can't see any issues at the current implementation, since even before the patch, all DST initialization are done by a routine called frontend_init(). *Wrong*. Frontend Init sends a command to the whole system to initialize the frontend, Not initialize the DST Whatever frontend naming conventions are in there are a relic from Andrew's FE_REFACTORING changesets. Even dst not being a frontend, the initialization gets the result of the attachment process, using it as a frontend: state = kmalloc(sizeof (struct dst_state), GFP_KERNEL); state-config = dst_config; state-i2c = card-i2c_adapter; state-bt = card-bt; state-dst_ca = NULL; dvb_attach(dst_attach, state, card-dvb_adapter); card-fe = state-frontend; (comments and error checks removed to make code cleaner) The patch basically moved state initialization to dst_attach. The above code, after the patch is: card-fe = dvb_attach(dst_attach, dst_config, card-bt, card-i2c_adapter); So, I didn't noticed any regressions by running the modified driver nor I couldn't identify any regressions by inspecting the source code. The end result seems also cleaner and easier to understand, preserving all characteristics of the original code. Also, it uses dvb_attach the same way as the other dvb helper modules. If later any changes will be needed to allow using DST on different configurations, future patches probably will need to move dst initialization to other places, and use different callbacks for it, altering the above initialization. I can't see why those changes would possibly avoid any further changes at the driver. That's said, I intend to commit the two patches, fixing the current issues, at this weekend. I did explain my stand in a previous mail. NACK Technically may be OK, psychologically this decision
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
On Thu, 3 May 2007, Mauro Carvalho Chehab wrote:
Em Qua, 2007-05-02 ??s 04:10 -0700, Trent Piepho escreveu:
I promise, this time it's right!
http://linuxtv.org/hg/~tap/dst-new
Confirmed. Now the patch is properly working. My tests were done with a
board with DST. Those are the results:
1) when DST is unselected, on a board with DST, it will print the errors
indicating that the Kconfig items were not selected:
DVB: registering new adapter (bttv0).
DVB: Unable to find symbol dst_attach()
frontend_init: Could not find a Twinhan DST.
dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem
fbfb/f800
The only issue is the wrong printk msg, stating that a frontend driver
were not found. As this issue also happens with the current driver, due
the usage of dvb_attach() macro, I don't see any regressions.
It would be nice, however, to have a patch making dvb_attach more
generic, by e.g. having a variant that allows passing another message.
Only this message is from dvb_attach():
DVB: Unable to find symbol dst_attach()
Is it saying that it cannot load the module that dst_attach() is in (it
doesn't know what module that is, modprobe knows that). If you enabled dst
support and deleted the module, it would be the same.
If you turn off dvb_attach() and also disable dst, you should instead get
this message:
dst_attach: driver disabled by Kconfig
Maybe that would look nicer with a DVB: prefix? That would easier if it
wasn't necessary to update the printk in each boilerplate stub function. What
if one macro created these stubs
frontend_init: Could not find a Twinhan DST.
dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem
fbfb/f800
These two messages are printed by the dvb-bt8xx driver, not by dvb_attach().
It would be trivial to change of course, but I'm not sure what would be
pedantically correct for both dst and non-dst based hardware.
There's an argument against the prototype changes on dst_attach and
dst_ca_attach since they aren't frontend.
The reason I changed that, is the dst_attach() already did return a
dvb_frontend pointer, it was just inside an enclosing structure. i.e. what
existed before:
{
struct dst_state *state;
state = dst_attach(...);
card-fe = state-frontend;
} /* state goes out of scope */
The frontend is inside the state struct and the state pointer isn't saved
anywhere. dvb-bt8xx just saves a frontend pointer from inside the dst state
and tosses the state pointer away. So I changed that to:
card-fe = dst_attach(...);
-
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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Wed, 2 May 2007 04:10:03 -0700 (PDT) Von: Trent Piepho <[EMAIL PROTECTED]> An: Mauro Carvalho Chehab <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Manu Abraham <[EMAIL PROTECTED]> Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...) > On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > > Em Ter, 2007-05-01 Ã s 16:16 -0700, Trent Piepho escreveu: > > > On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > > > > With this configuration, dvb-bt8xx hangs during initialization, > > > > generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx > > > > never returns). > > > > > > Stupid typo in the first patch, a != should have been ==. > > > > > > Fixed: > > > http://linuxtv.org/hg/~tap/dst-new > > > > With the changes, the dst unselection worked. > > > > Those are the logs with dst unselected: > > > > DVB: registering new adapter (bttv0). > > DVB: Unable to find symbol dst_attach() > > frontend_init: Could not find a Twinhan DST. > > dvb-bt8xx: A frontend driver was not found for device 109e/0878 > subsystem fbfb/f800 > > This is the dvb_attach() "not found" message. You should see this same > message if you leave dst selected and then just delete the dst modules > before > loading dvb-bt8xx. > > If you turn dvb_attach off, you should see a different "dst support was > disabled" message (and no crash!). > > > However, when dst is selected, I got those errors: > > When I made this patch I was basing it off a patch I made around 9 months > ago. I thought since that one was ok, this would be ok too, and in my > hurry to get it done I've clearly put too little effort into checking it, > and I'm sorry to have wasted your time. > > I promise, this time it's right! > http://linuxtv.org/hg/~tap/dst-new The DST card with CA slot and the DST card without CA slot are two different cases. Like the Pinnacle PCTV SAT with CI extension and the Pinnacle PCTV SAT without CI extension. In so far my questions are: Shouldn't there be two cases for deselecting DST modules? At least my basic approach tried to distinct those two cases. In how far is it enough or technically sufficient to treat those two cases as one? And, as already mentioned: At least in all of those 4 cases no dvb-pll module isn't needed at all - someone simply forgot to add some lines for the exception handling in dvb-bt8xx to get rid of dvb-pll.c if there is no lgdt330x frontend needed (read: if there is no Fusion HDTV Lite card in the machine at all). If this small case is being fixed you simply can expand the deselection of dvb-pll.c on all cards treated in backend module dvb-bt8xx.c. Uwe > > ___ > linux-dvb mailing list > [EMAIL PROTECTED] > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > Em Ter, 2007-05-01 ??s 16:16 -0700, Trent Piepho escreveu: > > On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > > > With this configuration, dvb-bt8xx hangs during initialization, > > > generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx > > > never returns). > > > > Stupid typo in the first patch, a != should have been ==. > > > > Fixed: > > http://linuxtv.org/hg/~tap/dst-new > > With the changes, the dst unselection worked. > > Those are the logs with dst unselected: > > DVB: registering new adapter (bttv0). > DVB: Unable to find symbol dst_attach() > frontend_init: Could not find a Twinhan DST. > dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem > fbfb/f800 This is the dvb_attach() "not found" message. You should see this same message if you leave dst selected and then just delete the dst modules before loading dvb-bt8xx. If you turn dvb_attach off, you should see a different "dst support was disabled" message (and no crash!). > However, when dst is selected, I got those errors: When I made this patch I was basing it off a patch I made around 9 months ago. I thought since that one was ok, this would be ok too, and in my hurry to get it done I've clearly put too little effort into checking it, and I'm sorry to have wasted your time. I promise, this time it's right! http://linuxtv.org/hg/~tap/dst-new - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: Em Ter, 2007-05-01 ??s 16:16 -0700, Trent Piepho escreveu: On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: With this configuration, dvb-bt8xx hangs during initialization, generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx never returns). Stupid typo in the first patch, a != should have been ==. Fixed: http://linuxtv.org/hg/~tap/dst-new With the changes, the dst unselection worked. Those are the logs with dst unselected: DVB: registering new adapter (bttv0). DVB: Unable to find symbol dst_attach() frontend_init: Could not find a Twinhan DST. dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800 This is the dvb_attach() not found message. You should see this same message if you leave dst selected and then just delete the dst modules before loading dvb-bt8xx. If you turn dvb_attach off, you should see a different dst support was disabled message (and no crash!). However, when dst is selected, I got those errors: When I made this patch I was basing it off a patch I made around 9 months ago. I thought since that one was ok, this would be ok too, and in my hurry to get it done I've clearly put too little effort into checking it, and I'm sorry to have wasted your time. I promise, this time it's right! http://linuxtv.org/hg/~tap/dst-new - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Wed, 2 May 2007 04:10:03 -0700 (PDT) Von: Trent Piepho [EMAIL PROTECTED] An: Mauro Carvalho Chehab [EMAIL PROTECTED] CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Manu Abraham [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Criticalpoints about ...) On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: Em Ter, 2007-05-01 Ã s 16:16 -0700, Trent Piepho escreveu: On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: With this configuration, dvb-bt8xx hangs during initialization, generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx never returns). Stupid typo in the first patch, a != should have been ==. Fixed: http://linuxtv.org/hg/~tap/dst-new With the changes, the dst unselection worked. Those are the logs with dst unselected: DVB: registering new adapter (bttv0). DVB: Unable to find symbol dst_attach() frontend_init: Could not find a Twinhan DST. dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800 This is the dvb_attach() not found message. You should see this same message if you leave dst selected and then just delete the dst modules before loading dvb-bt8xx. If you turn dvb_attach off, you should see a different dst support was disabled message (and no crash!). However, when dst is selected, I got those errors: When I made this patch I was basing it off a patch I made around 9 months ago. I thought since that one was ok, this would be ok too, and in my hurry to get it done I've clearly put too little effort into checking it, and I'm sorry to have wasted your time. I promise, this time it's right! http://linuxtv.org/hg/~tap/dst-new The DST card with CA slot and the DST card without CA slot are two different cases. Like the Pinnacle PCTV SAT with CI extension and the Pinnacle PCTV SAT without CI extension. In so far my questions are: Shouldn't there be two cases for deselecting DST modules? At least my basic approach tried to distinct those two cases. In how far is it enough or technically sufficient to treat those two cases as one? And, as already mentioned: At least in all of those 4 cases no dvb-pll module isn't needed at all - someone simply forgot to add some lines for the exception handling in dvb-bt8xx to get rid of dvb-pll.c if there is no lgdt330x frontend needed (read: if there is no Fusion HDTV Lite card in the machine at all). If this small case is being fixed you simply can expand the deselection of dvb-pll.c on all cards treated in backend module dvb-bt8xx.c. Uwe ___ linux-dvb mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Em Ter, 2007-05-01 às 16:16 -0700, Trent Piepho escreveu:
> On Tue, 1 May 2007, Mauro Carvalho Chehab wrote:
> > With this configuration, dvb-bt8xx hangs during initialization,
> > generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
> > never returns).
>
> Stupid typo in the first patch, a != should have been ==.
>
> Fixed:
> http://linuxtv.org/hg/~tap/dst-new
With the changes, the dst unselection worked.
Those are the logs with dst unselected:
DVB: registering new adapter (bttv0).
DVB: Unable to find symbol dst_attach()
frontend_init: Could not find a Twinhan DST.
dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem
fbfb/f800
However, when dst is selected, I got those errors:
DVB: registering new adapter (bttv0).
dst(0) dst_get_device_id: Recognise [DSTMCI]
dst(0) dst_get_device_id: Unsupported
dst(0) dst_check_mb86a15: Found a MB86A15 NIM
DST type flags : 0x1 newtuner 0x1000 VLF 0x10 firmware version = 2
dst(0) dst_get_mac: MAC Address=[00:00:00:00:00:00]
dst(0) dst_get_tuner_info: DST TYpe = MULTI FE
dst(0) dst_fw_ver: Firmware Ver = 1.4 Build = 02, on 11:5, 22-2-2005
dst(0) dst_card_type: Device Model=[VP1032]
dst(0) dst_get_vendor: Vendor=[TWINHAN]
Unable to handle kernel NULL pointer dereference at 02f0 RIP:
{:dvb_bt8xx:dvb_bt8xx_probe+2548}
PGD 6c2c1067 PUD 73f56067 PMD 0
Oops: [1] SMP
CPU 0
Modules linked in: dst dvb_bt8xx dvb_core bt878 tuner bttv video_buf ir_common
compat_ioctl32 btcx_risc tveeprom videodev v4l2_common v4l1_compat dvb_pll
ipt_ULOG x_tables autofs4 tun it87 hwmon_vid hwmon eeprom i2c_isa i2c_nforce2
ipv6 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device
snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm
snd_timer snd_page_alloc snd soundcore af_packet capi capifs kernelcapi bridge
ide_cd binfmt_misc isofs loop nls_iso8859_1 nls_cp850 vfat fat evdev dm_mod
usbmouse video usbhid thermal fan container button battery ac cpufreq_ondemand
cpufreq_conservative cpufreq_powersave powernow_k8 freq_table processor
firmware_class i2c_algo_bit i2c_core pcspkr forcedeth kqemu joydev analog
gameport ohci1394 ieee1394 ehci_hcd ohci_hcd usbcore reiserfs sd_mod sata_nv
libata scsi_mod
Pid: 4211, comm: modprobe Tainted: P 2.6.17.4 #1
RIP: 0010:[]
{:dvb_bt8xx:dvb_bt8xx_probe+2548}
RSP: 0018:81006f0b5e38 EFLAGS: 00010286
RAX: 8100716bf018 RBX: 81007962a000 RCX:
RDX: RSI: 8100716bf018 RDI: 8100716bf270
RBP: R08: R09: 0080
R10: R11: 8011c530 R12: 8100717f7800
R13: 81007962a0d0 R14: 81007962a498 R15: 81007962a3c8
FS: 2aff6d9c06f0() GS:80476000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 02f0 CR3: 6c1d4000 CR4: 06e0
Process modprobe (pid: 4211, threadinfo 81006f0b4000, task 81007dff42c0)
Stack: 81007962a4b0 81007962a070 007176bdc0c0 8100717f7998
8100717f7800 883f0940 883f0940
00518130 8026ce95
Call Trace: {driver_probe_device+101}
{__driver_attach+122}
{__driver_attach+0}
{bus_for_each_dev+73}
{bus_add_driver+136}
{sys_init_module+199}
{system_call+126}
Code: f6 04 25 f0 02 00 00 20 0f 84 ae 01 00 00 48 c7 c7 ae ee 3e
RIP {:dvb_bt8xx:dvb_bt8xx_probe+2548} RSP
CR2: 02f0
--
Cheers,
Mauro
-
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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > With this configuration, dvb-bt8xx hangs during initialization, > generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx > never returns). Stupid typo in the first patch, a != should have been ==. Fixed: http://linuxtv.org/hg/~tap/dst-new - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Tue, 01 May 2007 21:35:44 +0100 Von: Simon Arlott <[EMAIL PROTECTED]> An: Uwe Bugla <[EMAIL PROTECTED]> CC: linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...) > On 01/05/07 20:34, Uwe Bugla wrote: > > Original-Nachricht > > Datum: Tue, 01 May 2007 19:50:38 +0100 > > Von: Simon Arlott <[EMAIL PROTECTED]> > >> On 01/05/07 19:30, Uwe Bugla wrote: > >>> > >> If you would avoid making inflammatory comments, the people who are > trying > >> to > >> help you will be more inclined to fix the problems that these patches > DO > >> cause > >> so they can be added. > >> > >> A while ago, you went on and on about your broken floppy drive and how > >> people > >> shouldn't do things that break other systems - even if they have no > idea > >> that > >> was happening - yet here you are now demanding people do the same > thing. > > > > WRONG! > > I offered a patch for the broken floppy, but Linus was faster and ripped > the whole section out, so do not even try to misunderstand or quote me out > of context! > > You complained that changes which break your system[1] shouldn't be added > and now rudely demand your desired changes which have been shown to break > others' should be added immediately. I don't believe I misunderstood you > or got the wrong context - it has nothing to do with the related patch. > > [1] http://lkml.org/lkml/2007/2/25/127 > > > > So I say it again: > > The theses Mr. Chehab invents NOT TO DO SOMETHING do never carry fully > transparent information with them. It's just air bubbles that he is > producing, nothing else! > > It's always and ever the other part that is exposed to offer transparent > info, but never Chehab himself! > > And it's exactly the same thing with Abraham or Krufky! > > > > And does that behaviour conform with democratic terms? NO WAY! > > So there are three mismatches around: Their names are: Abraham, Krufky, > and Chehab! > > You're worse than that reiser4 fanatic, at least he wasn't rude when he > repeated himself over and over and over. I was going to offer to help > you bisect between -git1 and -git2 (it'd be trivial to run the bisect > here and provide patches to test) Well, thank you for that offer in mind, but the git bisect is only necessary for some people needing to know what the reasons for the AMD K7 router Oopses are (speak: what needs to be inserted in vanilla mainline to make it "round" (2.6.21.3, 4, 5,.)). But meanwhile I got three perfect running machines, implying Trent's stuff, implying self-built stuff, and everything built up on 2.6.21-git4), so I can solve my problems on my own. See, if it is almost impossible to build up necessary majorities to get rid of some utmost nasty gatekeepers @linuxtv.org then I can keep my own patch repositories and save lots of energy. Why should I fight against windmills of such an enourmous stupidity like diagnosed around here? No reason for that! Why should I take part in testing the mm-tree? Nothing but waste of time, isn't it?? The technical issues that still need to be fixed plus some creative ideas I sent to [EMAIL PROTECTED] plus to Trent Piepho. If they get this done - excellent! If not - why should I waste nerves? Because of some stupid Abraham or Krufky?? Or the intransparence of Mr. Chehab's air bubbles?? Why should I?? snip _ Uwe (Rest blather cut off) > Simon Arlott -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
On 01/05/07 20:34, Uwe Bugla wrote: Original-Nachricht Datum: Tue, 01 May 2007 19:50:38 +0100 Von: Simon Arlott <[EMAIL PROTECTED]> On 01/05/07 19:30, Uwe Bugla wrote: If you would avoid making inflammatory comments, the people who are trying to help you will be more inclined to fix the problems that these patches DO cause so they can be added. A while ago, you went on and on about your broken floppy drive and how people shouldn't do things that break other systems - even if they have no idea that was happening - yet here you are now demanding people do the same thing. WRONG! I offered a patch for the broken floppy, but Linus was faster and ripped the whole section out, so do not even try to misunderstand or quote me out of context! You complained that changes which break your system[1] shouldn't be added and now rudely demand your desired changes which have been shown to break others' should be added immediately. I don't believe I misunderstood you or got the wrong context - it has nothing to do with the related patch. [1] http://lkml.org/lkml/2007/2/25/127 So I say it again: The theses Mr. Chehab invents NOT TO DO SOMETHING do never carry fully transparent information with them. It's just air bubbles that he is producing, nothing else! It's always and ever the other part that is exposed to offer transparent info, but never Chehab himself! And it's exactly the same thing with Abraham or Krufky! And does that behaviour conform with democratic terms? NO WAY! So there are three mismatches around: Their names are: Abraham, Krufky, and Chehab! You're worse than that reiser4 fanatic, at least he wasn't rude when he repeated himself over and over and over. I was going to offer to help you bisect between -git1 and -git2 (it'd be trivial to run the bisect here and provide patches to test) but I won't bother if you're going to hijack every email with your abuse. -- Simon Arlott - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Tue, 01 May 2007 19:50:38 +0100 Von: Simon Arlott <[EMAIL PROTECTED]> An: Uwe Bugla <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...) > On 01/05/07 19:30, Uwe Bugla wrote: > > > > If you would avoid making inflammatory comments, the people who are trying > to > help you will be more inclined to fix the problems that these patches DO > cause > so they can be added. > > A while ago, you went on and on about your broken floppy drive and how > people > shouldn't do things that break other systems - even if they have no idea > that > was happening - yet here you are now demanding people do the same thing. WRONG! I offered a patch for the broken floppy, but Linus was faster and ripped the whole section out, so do not even try to misunderstand or quote me out of context! So I say it again: The theses Mr. Chehab invents NOT TO DO SOMETHING do never carry fully transparent information with them. It's just air bubbles that he is producing, nothing else! It's always and ever the other part that is exposed to offer transparent info, but never Chehab himself! And it's exactly the same thing with Abraham or Krufky! And does that behaviour conform with democratic terms? NO WAY! So there are three mismatches around: Their names are: Abraham, Krufky, and Chehab! Uwe > > It's easy to maintain your own changes to the kernel until equivalent > changes > are committed - you need to be much more patient, especially when > something is > being done about them. > > -- > Simon Arlott -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Tue, 01 May 2007 21:20:01 +0200 Von: e9hack <[EMAIL PROTECTED]> An: Uwe Bugla <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...) > Uwe Bugla wrote: > > > > The biggest problem that I had with you in the past weeks is and was > that you never even once offer full transparency when you are building up > theses NOT TO accept patches. > > > > And if it is only the other side (me, Trent, others) to be forced to > offer transparent information BUT NOT YOU YOURSELF > > then this is what I would call a deep anti-democratic behaviour. > > > > You can neither help nor can you solve any problem continuing in that > manner, > > can you? > > > > Happy reflection on your very strange methods, with the hope to do > better in the future! If there is some hope - well, I doubt! > > > > Hi Uwe, > > I would like it if you only post technical topics without any comments to > some person. In your case, the comments are > mostly a personally attacks against someone. If I use google to search for > your name: in the last 5 years, on every > board, forum, ML,.. you had trouble with many people. It was always > because someone wasn't your opinion or someone > didn't do what you seems to expect. Afterwards, you did always start your > attacks and flame war. As a result nobody did > response to you and you was fired from some places. Your problem with some > people from this list isn't a problem of this > people. It's a problem of your own and of your communicative skills. If > you cannot respect sentence #1, please go away > and do never post to this list again. > > Just my two cents.. > > - Hartmut Hartmut, one strategy to establish democratic principles is showing up methods of other people like Abraham and Chehab. If you are not ready to perceive this you're really poor. Uwe -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Uwe Bugla wrote: > > The biggest problem that I had with you in the past weeks is and was that you > never even once offer full transparency when you are building up theses NOT > TO accept patches. > > And if it is only the other side (me, Trent, others) to be forced to offer > transparent information BUT NOT YOU YOURSELF > then this is what I would call a deep anti-democratic behaviour. > > You can neither help nor can you solve any problem continuing in that manner, > can you? > > Happy reflection on your very strange methods, with the hope to do better in > the future! If there is some hope - well, I doubt! > Hi Uwe, I would like it if you only post technical topics without any comments to some person. In your case, the comments are mostly a personally attacks against someone. If I use google to search for your name: in the last 5 years, on every board, forum, ML,.. you had trouble with many people. It was always because someone wasn't your opinion or someone didn't do what you seems to expect. Afterwards, you did always start your attacks and flame war. As a result nobody did response to you and you was fired from some places. Your problem with some people from this list isn't a problem of this people. It's a problem of your own and of your communicative skills. If you cannot respect sentence #1, please go away and do never post to this list again. Just my two cents.. - Hartmut - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
On 01/05/07 19:30, Uwe Bugla wrote: If you would avoid making inflammatory comments, the people who are trying to help you will be more inclined to fix the problems that these patches DO cause so they can be added. A while ago, you went on and on about your broken floppy drive and how people shouldn't do things that break other systems - even if they have no idea that was happening - yet here you are now demanding people do the same thing. It's easy to maintain your own changes to the kernel until equivalent changes are committed - you need to be much more patient, especially when something is being done about them. -- Simon Arlott - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht
Datum: Tue, 01 May 2007 18:40:54 +0200
Von: "Uwe Bugla" <[EMAIL PROTECTED]>
An: Mauro Carvalho Chehab <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL
PROTECTED]
Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical
points about ...)
>
> Original-Nachricht
> Datum: Tue, 01 May 2007 11:55:33 -0300
> Von: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
> An: Markus Rechberger <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Manu Abraham
> <[EMAIL PROTECTED]>
> Betreff: [linux-dvb] Re: DST/BT878 module customization (.. was:
> Critical points about ...)
>
> > Hi Markus,
> >
> > Em Seg, 2007-04-30 às 23:17 +0200, Markus Rechberger escreveu:
> > > Hi,
> > >
> > > Trent Piepho wrote another patch for it, it just completes Uwe's patch
> > > in the end.
> > >
> > >
> >
> http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb
> >
> > The above patch plus the other on
> >
> http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=32fb55ac9501;style=gitweb
> >
> > Implements properly the Uwe's ide.
> >
> > However, I did a test here applying both patches, and de-selecting dst
> > drivers.
> >
> > With this configuration, dvb-bt8xx hangs during initialization,
> > generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
> > never returns).
> Hi, please: Could you explain to me why you are turning around the logical
> principle all the time?
>
> Those patches (and my humble ones too of course that gained no attention
> for months) were made for the POSITIVE CASE
> in which it is ENSURED that a DST card DOES NOT EXIST in the machine, NOT
> VICE VERSA!
>
> So please in how far isn't that fantastic work done by Trent enough?
> So it is very clear that if there are oopses and hangups if such a card
> exists and its drivers are deselected.
> No point at all!
> So please explain me the essence why you use the inversion of the given
> logic to NOT ACK or SIGN this beautiful work.
> I want to see THREE valid arguments for this turnaround illogical
> behaviour please.
>
> Uwe
>
> P. S.: I tested Trent's work and I can ensure that there aren't any Oopses
> at all!
> So your case studies are not only highly invented and strange, but they
> aren't any help either. I really wonder what the hell is going on in your
> brain.
> I really ask myself why you are doing this nerve war, this ping-pong game
> all the time.
> This work is done for the case where there aren't any DST cards inside the
> machine,
> so you cannot just come up, turn everything around, and thus pick up the
> inversion that fits into your strange concept (whatever that may be - noone
> except you
> knows) for blocking that good work.
> So I'd deeply appreciate you to stop this strange hindrance policy. You
> will do nobody any favour with that strange behaviour!
> In my eyes you do not want to help at all - you just want to provoke. And
> if in the end someone insults you you seem to have won.
> But you do not win anything with your strange gestures behind other
> peoples backs, you're instead counterproductive.
>
> And EVEN IF you write this publically you should immediately stop to do
> this behind the author's back - so I CCed Trent Piepho.
> Just to see and show him the bad methods that you are using to qualify
> other people's efforts.
>
> >
> > $ ps ax|grep modprobe
> > 2769 pts/0S 0:00 modprobe dvb_bt8xx
> > 2779 pts/0S+ 0:00 grep --color modprobe
> >
> > $ dmesg
> > DVB: registering new adapter (bttv0).
> > DVB: Unable to find symbol dst_attach()
> > Unable to handle kernel NULL pointer dereference at 02f0
> RIP:
> > {:dvb_bt8xx:dvb_bt8xx_probe+3195}
> > PGD 7cfba067 PUD 7cfc5067 PMD 0
> > Oops: [1] SMP
> > CPU 0
> > Modules linked in: dvb_bt8xx dvb_core cx8800 cx88xx bt878 usbhid dvb_pll
> > tuner bttv video_buf firmware_class ir_common i2c_algo_bit btcx_risc
> > tveeprom i2c_core pcspkr sn9c102 compat_ioctl32 videodev v4l1_compat
> v4l2_common
> > forcedeth kqemu joydev analog gameport ohci1394 ieee1394 ehci_hcd
> ohci_hcd
> > usbcore reiserfs sd_mod sata_nv libata scsi_mod
> > Pid: 1286, comm: modprobe Tainted: P 2.6.17.4 #1
> > RIP: 0010:[]
> > {:dvb_bt8xx:dvb_bt8xx_probe+3195}
> > RSP: 0018:81007c239e38 EFLAGS: 00010296
> > RAX: 002b RBX: 81007c05a800 RCX:
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht
Datum: Tue, 01 May 2007 11:55:33 -0300
Von: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
An: Markus Rechberger <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Manu Abraham <[EMAIL
PROTECTED]>
Betreff: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical
points about ...)
> Hi Markus,
>
> Em Seg, 2007-04-30 às 23:17 +0200, Markus Rechberger escreveu:
> > Hi,
> >
> > Trent Piepho wrote another patch for it, it just completes Uwe's patch
> > in the end.
> >
> >
> http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb
>
> The above patch plus the other on
> http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=32fb55ac9501;style=gitweb
>
> Implements properly the Uwe's ide.
>
> However, I did a test here applying both patches, and de-selecting dst
> drivers.
>
> With this configuration, dvb-bt8xx hangs during initialization,
> generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
> never returns).
Hi, please: Could you explain to me why you are turning around the logical
principle all the time?
Those patches (and my humble ones too of course that gained no attention for
months) were made for the POSITIVE CASE
in which it is ENSURED that a DST card DOES NOT EXIST in the machine, NOT VICE
VERSA!
So please in how far isn't that fantastic work done by Trent enough?
So it is very clear that if there are oopses and hangups if such a card exists
and its drivers are deselected.
No point at all!
So please explain me the essence why you use the inversion of the given logic
to NOT ACK or SIGN this beautiful work.
I want to see THREE valid arguments for this turnaround illogical behaviour
please.
Uwe
P. S.: I tested Trent's work and I can ensure that there aren't any Oopses at
all!
So your case studies are not only highly invented and strange, but they aren't
any help either. I really wonder what the hell is going on in your brain.
I really ask myself why you are doing this nerve war, this ping-pong game all
the time.
This work is done for the case where there aren't any DST cards inside the
machine,
so you cannot just come up, turn everything around, and thus pick up the
inversion that fits into your strange concept (whatever that may be - noone
except you
knows) for blocking that good work.
So I'd deeply appreciate you to stop this strange hindrance policy. You will do
nobody any favour with that strange behaviour!
In my eyes you do not want to help at all - you just want to provoke. And if in
the end someone insults you you seem to have won.
But you do not win anything with your strange gestures behind other peoples
backs, you're instead counterproductive.
And EVEN IF you write this publically you should immediately stop to do this
behind the author's back - so I CCed Trent Piepho.
Just to see and show him the bad methods that you are using to qualify other
people's efforts.
>
> $ ps ax|grep modprobe
> 2769 pts/0S 0:00 modprobe dvb_bt8xx
> 2779 pts/0S+ 0:00 grep --color modprobe
>
> $ dmesg
> DVB: registering new adapter (bttv0).
> DVB: Unable to find symbol dst_attach()
> Unable to handle kernel NULL pointer dereference at 02f0 RIP:
> {:dvb_bt8xx:dvb_bt8xx_probe+3195}
> PGD 7cfba067 PUD 7cfc5067 PMD 0
> Oops: [1] SMP
> CPU 0
> Modules linked in: dvb_bt8xx dvb_core cx8800 cx88xx bt878 usbhid dvb_pll
> tuner bttv video_buf firmware_class ir_common i2c_algo_bit btcx_risc
> tveeprom i2c_core pcspkr sn9c102 compat_ioctl32 videodev v4l1_compat
> v4l2_common
> forcedeth kqemu joydev analog gameport ohci1394 ieee1394 ehci_hcd ohci_hcd
> usbcore reiserfs sd_mod sata_nv libata scsi_mod
> Pid: 1286, comm: modprobe Tainted: P 2.6.17.4 #1
> RIP: 0010:[]
> {:dvb_bt8xx:dvb_bt8xx_probe+3195}
> RSP: 0018:81007c239e38 EFLAGS: 00010296
> RAX: 002b RBX: 81007c05a800 RCX: 0003
> RDX: RSI: 0292 RDI: 803905bc
> RBP: R08: 4c72 R09:
> R10: R11: R12: 81007c19
> R13: 81007c05a8d0 R14: 81007c05ac98 R15: 81007c05abc8
> FS: 2b8b39ddf6f0() GS:80476000()
> knlGS:
> CS: 0010 DS: ES: CR0: 8005003b
> CR2: 02f0 CR3: 7cfc2000 CR4: 06e0
> Process modprobe (pid: 1286, threadinfo 81007c238000, task
> 81007dfd4960)
> Stack: 81007c05acb0 81007c05a870 00717c1e31c0 81007c190198
>81007c19 88261940 88261940
>00518130 8026ce95
> Call Trace: {driver_probe_device+101}
>{__dri
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht
Datum: Tue, 01 May 2007 11:55:33 -0300
Von: Mauro Carvalho Chehab [EMAIL PROTECTED]
An: Markus Rechberger [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Manu Abraham [EMAIL
PROTECTED]
Betreff: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical
points about ...)
Hi Markus,
Em Seg, 2007-04-30 às 23:17 +0200, Markus Rechberger escreveu:
Hi,
Trent Piepho wrote another patch for it, it just completes Uwe's patch
in the end.
http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb
The above patch plus the other on
http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=32fb55ac9501;style=gitweb
Implements properly the Uwe's ide.
However, I did a test here applying both patches, and de-selecting dst
drivers.
With this configuration, dvb-bt8xx hangs during initialization,
generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
never returns).
Hi, please: Could you explain to me why you are turning around the logical
principle all the time?
Those patches (and my humble ones too of course that gained no attention for
months) were made for the POSITIVE CASE
in which it is ENSURED that a DST card DOES NOT EXIST in the machine, NOT VICE
VERSA!
So please in how far isn't that fantastic work done by Trent enough?
So it is very clear that if there are oopses and hangups if such a card exists
and its drivers are deselected.
No point at all!
So please explain me the essence why you use the inversion of the given logic
to NOT ACK or SIGN this beautiful work.
I want to see THREE valid arguments for this turnaround illogical behaviour
please.
Uwe
P. S.: I tested Trent's work and I can ensure that there aren't any Oopses at
all!
So your case studies are not only highly invented and strange, but they aren't
any help either. I really wonder what the hell is going on in your brain.
I really ask myself why you are doing this nerve war, this ping-pong game all
the time.
This work is done for the case where there aren't any DST cards inside the
machine,
so you cannot just come up, turn everything around, and thus pick up the
inversion that fits into your strange concept (whatever that may be - noone
except you
knows) for blocking that good work.
So I'd deeply appreciate you to stop this strange hindrance policy. You will do
nobody any favour with that strange behaviour!
In my eyes you do not want to help at all - you just want to provoke. And if in
the end someone insults you you seem to have won.
But you do not win anything with your strange gestures behind other peoples
backs, you're instead counterproductive.
And EVEN IF you write this publically you should immediately stop to do this
behind the author's back - so I CCed Trent Piepho.
Just to see and show him the bad methods that you are using to qualify other
people's efforts.
$ ps ax|grep modprobe
2769 pts/0S 0:00 modprobe dvb_bt8xx
2779 pts/0S+ 0:00 grep --color modprobe
$ dmesg
DVB: registering new adapter (bttv0).
DVB: Unable to find symbol dst_attach()
Unable to handle kernel NULL pointer dereference at 02f0 RIP:
8825f11b{:dvb_bt8xx:dvb_bt8xx_probe+3195}
PGD 7cfba067 PUD 7cfc5067 PMD 0
Oops: [1] SMP
CPU 0
Modules linked in: dvb_bt8xx dvb_core cx8800 cx88xx bt878 usbhid dvb_pll
tuner bttv video_buf firmware_class ir_common i2c_algo_bit btcx_risc
tveeprom i2c_core pcspkr sn9c102 compat_ioctl32 videodev v4l1_compat
v4l2_common
forcedeth kqemu joydev analog gameport ohci1394 ieee1394 ehci_hcd ohci_hcd
usbcore reiserfs sd_mod sata_nv libata scsi_mod
Pid: 1286, comm: modprobe Tainted: P 2.6.17.4 #1
RIP: 0010:[8825f11b]
8825f11b{:dvb_bt8xx:dvb_bt8xx_probe+3195}
RSP: 0018:81007c239e38 EFLAGS: 00010296
RAX: 002b RBX: 81007c05a800 RCX: 0003
RDX: RSI: 0292 RDI: 803905bc
RBP: R08: 4c72 R09:
R10: R11: R12: 81007c19
R13: 81007c05a8d0 R14: 81007c05ac98 R15: 81007c05abc8
FS: 2b8b39ddf6f0() GS:80476000()
knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 02f0 CR3: 7cfc2000 CR4: 06e0
Process modprobe (pid: 1286, threadinfo 81007c238000, task
81007dfd4960)
Stack: 81007c05acb0 81007c05a870 00717c1e31c0 81007c190198
81007c19 88261940 88261940
00518130 8026ce95
Call Trace: 8026ce95{driver_probe_device+101}
8026d00a{__driver_attach+122}
8026cf90{__driver_attach+0}
8026c6f9{bus_for_each_dev+73}
8026c2e8{bus_add_driver+136}
80152977{sys_init_module+199}
80109d2a{system_call+126}
Code: f6 04 25 f0
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht
Datum: Tue, 01 May 2007 18:40:54 +0200
Von: Uwe Bugla [EMAIL PROTECTED]
An: Mauro Carvalho Chehab [EMAIL PROTECTED], [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL
PROTECTED]
Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical
points about ...)
Original-Nachricht
Datum: Tue, 01 May 2007 11:55:33 -0300
Von: Mauro Carvalho Chehab [EMAIL PROTECTED]
An: Markus Rechberger [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Manu Abraham
[EMAIL PROTECTED]
Betreff: [linux-dvb] Re: DST/BT878 module customization (.. was:
Critical points about ...)
Hi Markus,
Em Seg, 2007-04-30 às 23:17 +0200, Markus Rechberger escreveu:
Hi,
Trent Piepho wrote another patch for it, it just completes Uwe's patch
in the end.
http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb
The above patch plus the other on
http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=32fb55ac9501;style=gitweb
Implements properly the Uwe's ide.
However, I did a test here applying both patches, and de-selecting dst
drivers.
With this configuration, dvb-bt8xx hangs during initialization,
generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
never returns).
Hi, please: Could you explain to me why you are turning around the logical
principle all the time?
Those patches (and my humble ones too of course that gained no attention
for months) were made for the POSITIVE CASE
in which it is ENSURED that a DST card DOES NOT EXIST in the machine, NOT
VICE VERSA!
So please in how far isn't that fantastic work done by Trent enough?
So it is very clear that if there are oopses and hangups if such a card
exists and its drivers are deselected.
No point at all!
So please explain me the essence why you use the inversion of the given
logic to NOT ACK or SIGN this beautiful work.
I want to see THREE valid arguments for this turnaround illogical
behaviour please.
Uwe
P. S.: I tested Trent's work and I can ensure that there aren't any Oopses
at all!
So your case studies are not only highly invented and strange, but they
aren't any help either. I really wonder what the hell is going on in your
brain.
I really ask myself why you are doing this nerve war, this ping-pong game
all the time.
This work is done for the case where there aren't any DST cards inside the
machine,
so you cannot just come up, turn everything around, and thus pick up the
inversion that fits into your strange concept (whatever that may be - noone
except you
knows) for blocking that good work.
So I'd deeply appreciate you to stop this strange hindrance policy. You
will do nobody any favour with that strange behaviour!
In my eyes you do not want to help at all - you just want to provoke. And
if in the end someone insults you you seem to have won.
But you do not win anything with your strange gestures behind other
peoples backs, you're instead counterproductive.
And EVEN IF you write this publically you should immediately stop to do
this behind the author's back - so I CCed Trent Piepho.
Just to see and show him the bad methods that you are using to qualify
other people's efforts.
$ ps ax|grep modprobe
2769 pts/0S 0:00 modprobe dvb_bt8xx
2779 pts/0S+ 0:00 grep --color modprobe
$ dmesg
DVB: registering new adapter (bttv0).
DVB: Unable to find symbol dst_attach()
Unable to handle kernel NULL pointer dereference at 02f0
RIP:
8825f11b{:dvb_bt8xx:dvb_bt8xx_probe+3195}
PGD 7cfba067 PUD 7cfc5067 PMD 0
Oops: [1] SMP
CPU 0
Modules linked in: dvb_bt8xx dvb_core cx8800 cx88xx bt878 usbhid dvb_pll
tuner bttv video_buf firmware_class ir_common i2c_algo_bit btcx_risc
tveeprom i2c_core pcspkr sn9c102 compat_ioctl32 videodev v4l1_compat
v4l2_common
forcedeth kqemu joydev analog gameport ohci1394 ieee1394 ehci_hcd
ohci_hcd
usbcore reiserfs sd_mod sata_nv libata scsi_mod
Pid: 1286, comm: modprobe Tainted: P 2.6.17.4 #1
RIP: 0010:[8825f11b]
8825f11b{:dvb_bt8xx:dvb_bt8xx_probe+3195}
RSP: 0018:81007c239e38 EFLAGS: 00010296
RAX: 002b RBX: 81007c05a800 RCX: 0003
RDX: RSI: 0292 RDI: 803905bc
RBP: R08: 4c72 R09:
R10: R11: R12: 81007c19
R13: 81007c05a8d0 R14: 81007c05ac98 R15: 81007c05abc8
FS: 2b8b39ddf6f0() GS:80476000()
knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 02f0 CR3: 7cfc2000 CR4: 06e0
Process modprobe (pid: 1286, threadinfo 81007c238000, task
81007dfd4960)
Stack: 81007c05acb0 81007c05a870 00717c1e31c0
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
On 01/05/07 19:30, Uwe Bugla wrote: fewer rude comments than usual If you would avoid making inflammatory comments, the people who are trying to help you will be more inclined to fix the problems that these patches DO cause so they can be added. A while ago, you went on and on about your broken floppy drive and how people shouldn't do things that break other systems - even if they have no idea that was happening - yet here you are now demanding people do the same thing. It's easy to maintain your own changes to the kernel until equivalent changes are committed - you need to be much more patient, especially when something is being done about them. -- Simon Arlott - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Uwe Bugla wrote: The biggest problem that I had with you in the past weeks is and was that you never even once offer full transparency when you are building up theses NOT TO accept patches. And if it is only the other side (me, Trent, others) to be forced to offer transparent information BUT NOT YOU YOURSELF then this is what I would call a deep anti-democratic behaviour. You can neither help nor can you solve any problem continuing in that manner, can you? Happy reflection on your very strange methods, with the hope to do better in the future! If there is some hope - well, I doubt! Hi Uwe, I would like it if you only post technical topics without any comments to some person. In your case, the comments are mostly a personally attacks against someone. If I use google to search for your name: in the last 5 years, on every board, forum, ML,.. you had trouble with many people. It was always because someone wasn't your opinion or someone didn't do what you seems to expect. Afterwards, you did always start your attacks and flame war. As a result nobody did response to you and you was fired from some places. Your problem with some people from this list isn't a problem of this people. It's a problem of your own and of your communicative skills. If you cannot respect sentence #1, please go away and do never post to this list again. Just my two cents.. - Hartmut - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Tue, 01 May 2007 21:20:01 +0200 Von: e9hack [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...) Uwe Bugla wrote: The biggest problem that I had with you in the past weeks is and was that you never even once offer full transparency when you are building up theses NOT TO accept patches. And if it is only the other side (me, Trent, others) to be forced to offer transparent information BUT NOT YOU YOURSELF then this is what I would call a deep anti-democratic behaviour. You can neither help nor can you solve any problem continuing in that manner, can you? Happy reflection on your very strange methods, with the hope to do better in the future! If there is some hope - well, I doubt! Hi Uwe, I would like it if you only post technical topics without any comments to some person. In your case, the comments are mostly a personally attacks against someone. If I use google to search for your name: in the last 5 years, on every board, forum, ML,.. you had trouble with many people. It was always because someone wasn't your opinion or someone didn't do what you seems to expect. Afterwards, you did always start your attacks and flame war. As a result nobody did response to you and you was fired from some places. Your problem with some people from this list isn't a problem of this people. It's a problem of your own and of your communicative skills. If you cannot respect sentence #1, please go away and do never post to this list again. Just my two cents.. - Hartmut Hartmut, one strategy to establish democratic principles is showing up methods of other people like Abraham and Chehab. If you are not ready to perceive this you're really poor. Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Tue, 01 May 2007 19:50:38 +0100 Von: Simon Arlott [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...) On 01/05/07 19:30, Uwe Bugla wrote: fewer rude comments than usual If you would avoid making inflammatory comments, the people who are trying to help you will be more inclined to fix the problems that these patches DO cause so they can be added. A while ago, you went on and on about your broken floppy drive and how people shouldn't do things that break other systems - even if they have no idea that was happening - yet here you are now demanding people do the same thing. WRONG! I offered a patch for the broken floppy, but Linus was faster and ripped the whole section out, so do not even try to misunderstand or quote me out of context! So I say it again: The theses Mr. Chehab invents NOT TO DO SOMETHING do never carry fully transparent information with them. It's just air bubbles that he is producing, nothing else! It's always and ever the other part that is exposed to offer transparent info, but never Chehab himself! And it's exactly the same thing with Abraham or Krufky! And does that behaviour conform with democratic terms? NO WAY! So there are three mismatches around: Their names are: Abraham, Krufky, and Chehab! Uwe It's easy to maintain your own changes to the kernel until equivalent changes are committed - you need to be much more patient, especially when something is being done about them. -- Simon Arlott -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
On 01/05/07 20:34, Uwe Bugla wrote: Original-Nachricht Datum: Tue, 01 May 2007 19:50:38 +0100 Von: Simon Arlott [EMAIL PROTECTED] On 01/05/07 19:30, Uwe Bugla wrote: fewer rude comments than usual If you would avoid making inflammatory comments, the people who are trying to help you will be more inclined to fix the problems that these patches DO cause so they can be added. A while ago, you went on and on about your broken floppy drive and how people shouldn't do things that break other systems - even if they have no idea that was happening - yet here you are now demanding people do the same thing. WRONG! I offered a patch for the broken floppy, but Linus was faster and ripped the whole section out, so do not even try to misunderstand or quote me out of context! You complained that changes which break your system[1] shouldn't be added and now rudely demand your desired changes which have been shown to break others' should be added immediately. I don't believe I misunderstood you or got the wrong context - it has nothing to do with the related patch. [1] http://lkml.org/lkml/2007/2/25/127 So I say it again: The theses Mr. Chehab invents NOT TO DO SOMETHING do never carry fully transparent information with them. It's just air bubbles that he is producing, nothing else! It's always and ever the other part that is exposed to offer transparent info, but never Chehab himself! And it's exactly the same thing with Abraham or Krufky! And does that behaviour conform with democratic terms? NO WAY! So there are three mismatches around: Their names are: Abraham, Krufky, and Chehab! You're worse than that reiser4 fanatic, at least he wasn't rude when he repeated himself over and over and over. I was going to offer to help you bisect between -git1 and -git2 (it'd be trivial to run the bisect here and provide patches to test) but I won't bother if you're going to hijack every email with your abuse. -- Simon Arlott - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Tue, 01 May 2007 21:35:44 +0100 Von: Simon Arlott [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...) On 01/05/07 20:34, Uwe Bugla wrote: Original-Nachricht Datum: Tue, 01 May 2007 19:50:38 +0100 Von: Simon Arlott [EMAIL PROTECTED] On 01/05/07 19:30, Uwe Bugla wrote: fewer rude comments than usual If you would avoid making inflammatory comments, the people who are trying to help you will be more inclined to fix the problems that these patches DO cause so they can be added. A while ago, you went on and on about your broken floppy drive and how people shouldn't do things that break other systems - even if they have no idea that was happening - yet here you are now demanding people do the same thing. WRONG! I offered a patch for the broken floppy, but Linus was faster and ripped the whole section out, so do not even try to misunderstand or quote me out of context! You complained that changes which break your system[1] shouldn't be added and now rudely demand your desired changes which have been shown to break others' should be added immediately. I don't believe I misunderstood you or got the wrong context - it has nothing to do with the related patch. [1] http://lkml.org/lkml/2007/2/25/127 So I say it again: The theses Mr. Chehab invents NOT TO DO SOMETHING do never carry fully transparent information with them. It's just air bubbles that he is producing, nothing else! It's always and ever the other part that is exposed to offer transparent info, but never Chehab himself! And it's exactly the same thing with Abraham or Krufky! And does that behaviour conform with democratic terms? NO WAY! So there are three mismatches around: Their names are: Abraham, Krufky, and Chehab! You're worse than that reiser4 fanatic, at least he wasn't rude when he repeated himself over and over and over. I was going to offer to help you bisect between -git1 and -git2 (it'd be trivial to run the bisect here and provide patches to test) Well, thank you for that offer in mind, but the git bisect is only necessary for some people needing to know what the reasons for the AMD K7 router Oopses are (speak: what needs to be inserted in vanilla mainline to make it round (2.6.21.3, 4, 5,.)). But meanwhile I got three perfect running machines, implying Trent's stuff, implying self-built stuff, and everything built up on 2.6.21-git4), so I can solve my problems on my own. See, if it is almost impossible to build up necessary majorities to get rid of some utmost nasty gatekeepers @linuxtv.org then I can keep my own patch repositories and save lots of energy. Why should I fight against windmills of such an enourmous stupidity like diagnosed around here? No reason for that! Why should I take part in testing the mm-tree? Nothing but waste of time, isn't it?? The technical issues that still need to be fixed plus some creative ideas I sent to [EMAIL PROTECTED] plus to Trent Piepho. If they get this done - excellent! If not - why should I waste nerves? Because of some stupid Abraham or Krufky?? Or the intransparence of Mr. Chehab's air bubbles?? Why should I?? snip _ Uwe (Rest blather cut off) Simon Arlott -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: With this configuration, dvb-bt8xx hangs during initialization, generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx never returns). Stupid typo in the first patch, a != should have been ==. Fixed: http://linuxtv.org/hg/~tap/dst-new - 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/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Em Ter, 2007-05-01 às 16:16 -0700, Trent Piepho escreveu:
On Tue, 1 May 2007, Mauro Carvalho Chehab wrote:
With this configuration, dvb-bt8xx hangs during initialization,
generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
never returns).
Stupid typo in the first patch, a != should have been ==.
Fixed:
http://linuxtv.org/hg/~tap/dst-new
With the changes, the dst unselection worked.
Those are the logs with dst unselected:
DVB: registering new adapter (bttv0).
DVB: Unable to find symbol dst_attach()
frontend_init: Could not find a Twinhan DST.
dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem
fbfb/f800
However, when dst is selected, I got those errors:
DVB: registering new adapter (bttv0).
dst(0) dst_get_device_id: Recognise [DSTMCI]
dst(0) dst_get_device_id: Unsupported
dst(0) dst_check_mb86a15: Found a MB86A15 NIM
DST type flags : 0x1 newtuner 0x1000 VLF 0x10 firmware version = 2
dst(0) dst_get_mac: MAC Address=[00:00:00:00:00:00]
dst(0) dst_get_tuner_info: DST TYpe = MULTI FE
dst(0) dst_fw_ver: Firmware Ver = 1.4 Build = 02, on 11:5, 22-2-2005
dst(0) dst_card_type: Device Model=[VP1032]
dst(0) dst_get_vendor: Vendor=[TWINHAN]
Unable to handle kernel NULL pointer dereference at 02f0 RIP:
883ede94{:dvb_bt8xx:dvb_bt8xx_probe+2548}
PGD 6c2c1067 PUD 73f56067 PMD 0
Oops: [1] SMP
CPU 0
Modules linked in: dst dvb_bt8xx dvb_core bt878 tuner bttv video_buf ir_common
compat_ioctl32 btcx_risc tveeprom videodev v4l2_common v4l1_compat dvb_pll
ipt_ULOG x_tables autofs4 tun it87 hwmon_vid hwmon eeprom i2c_isa i2c_nforce2
ipv6 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device
snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm
snd_timer snd_page_alloc snd soundcore af_packet capi capifs kernelcapi bridge
ide_cd binfmt_misc isofs loop nls_iso8859_1 nls_cp850 vfat fat evdev dm_mod
usbmouse video usbhid thermal fan container button battery ac cpufreq_ondemand
cpufreq_conservative cpufreq_powersave powernow_k8 freq_table processor
firmware_class i2c_algo_bit i2c_core pcspkr forcedeth kqemu joydev analog
gameport ohci1394 ieee1394 ehci_hcd ohci_hcd usbcore reiserfs sd_mod sata_nv
libata scsi_mod
Pid: 4211, comm: modprobe Tainted: P 2.6.17.4 #1
RIP: 0010:[883ede94]
883ede94{:dvb_bt8xx:dvb_bt8xx_probe+2548}
RSP: 0018:81006f0b5e38 EFLAGS: 00010286
RAX: 8100716bf018 RBX: 81007962a000 RCX:
RDX: RSI: 8100716bf018 RDI: 8100716bf270
RBP: R08: R09: 0080
R10: R11: 8011c530 R12: 8100717f7800
R13: 81007962a0d0 R14: 81007962a498 R15: 81007962a3c8
FS: 2aff6d9c06f0() GS:80476000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 02f0 CR3: 6c1d4000 CR4: 06e0
Process modprobe (pid: 4211, threadinfo 81006f0b4000, task 81007dff42c0)
Stack: 81007962a4b0 81007962a070 007176bdc0c0 8100717f7998
8100717f7800 883f0940 883f0940
00518130 8026ce95
Call Trace: 8026ce95{driver_probe_device+101}
8026d00a{__driver_attach+122}
8026cf90{__driver_attach+0}
8026c6f9{bus_for_each_dev+73}
8026c2e8{bus_add_driver+136}
80152977{sys_init_module+199}
80109d2a{system_call+126}
Code: f6 04 25 f0 02 00 00 20 0f 84 ae 01 00 00 48 c7 c7 ae ee 3e
RIP 883ede94{:dvb_bt8xx:dvb_bt8xx_probe+2548} RSP 81006f0b5e38
CR2: 02f0
--
Cheers,
Mauro
-
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/
