9:57 a.m.
Thanks for the invite Chuck. Great to read about your appointment working
with Dave by the way. I can confirm that this rocks.
To the matter at hand folks:
See:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233416
for dirty debugging output but essentially:
I'm running MythTV and the cx88-dvb driver that loaded with all the
2.6.18-2.6.19 kernels fails to do so with 2.6.20. Running modprobe loads the
drivers fine. In the not too distant past there used to be a problem with
the blackbird drivers grabbing control of the card(s) before the correct
driver did so. I therefore blacklisted the blackbird driver and the correct
driver loaded, the clouds cleared and the sun shone once more on green
fields. Now it looks like something similar has returned and I can only
force the driver to load by adding it to /etc/rc.modules
Any ideas?
Cheers
Chris
--
http://www.chruz.com
10:15 a.m.
Chris Brown wrote:
Thanks for the invite Chuck. Great to read about your appointment
working
with Dave by the way. I can confirm that this rocks.
To the matter at hand folks:
See:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233416
for dirty debugging output but essentially:
I'm running MythTV and the cx88-dvb driver that loaded with all the
2.6.18-2.6.19 kernels fails to do so with 2.6.20. Running modprobe loads
the
drivers fine. In the not too distant past there used to be a problem with
the blackbird drivers grabbing control of the card(s) before the correct
driver did so. I therefore blacklisted the blackbird driver and the correct
driver loaded, the clouds cleared and the sun shone once more on green
fields. Now it looks like something similar has returned and I can only
force the driver to load by adding it to /etc/rc.modules
What are we supposed to do when this kind of thing happens? It appears that
multiple drivers claim to support the same hardware.
10:31 a.m.
Chuck Ebbert wrote:
What are we supposed to do when this kind of thing happens? It appears that
multiple drivers claim to support the same hardware.
dunno, but this needs a solution
the same happens with tifm_sd/tifm_7xx1 and sdhci
a workaround is to blacklist one of this modules. (if you know which one
works better for you / which one do you want to use)
11:31 a.m.
On Thu, Mar 22, 2007 at 11:15:32AM -0400, Chuck Ebbert wrote:
Chris Brown wrote:
> Thanks for the invite Chuck. Great to read about your appointment working
> with Dave by the way. I can confirm that this rocks.
>
> To the matter at hand folks:
>
> See:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233416
>
> for dirty debugging output but essentially:
>
> I'm running MythTV and the cx88-dvb driver that loaded with all the
> 2.6.18-2.6.19 kernels fails to do so with 2.6.20. Running modprobe loads
> the
> drivers fine. In the not too distant past there used to be a problem with
> the blackbird drivers grabbing control of the card(s) before the correct
> driver did so. I therefore blacklisted the blackbird driver and the correct
> driver loaded, the clouds cleared and the sun shone once more on green
> fields. Now it looks like something similar has returned and I can only
> force the driver to load by adding it to /etc/rc.modules
>
What are we supposed to do when this kind of thing happens? It appears that
multiple drivers claim to support the same hardware.
Grr, this happens far too often. We have the same with for eg,
orinoco and hostap right now. The usual deal is that we either
just build the 'best' driver for that hardware, or if there's a case
where both drivers support the same hardware _and_ some hardware unique
to them, we nobble the pci table so that the crappier driver
doesn't load on that hardware.
As to which is the best one in this case.. I really don't know.
Or maybe this is a situation where it's valid to have both drivers loaded?
We don't actually support that right now, but patches went to linux-pci list
last week that should be showing up in GregKHs tree adding an alternative
method for drivers to bind to a device in situations where it's possible
for two drivers to drive different parts of the same chip.
(This case has been showing up more and more recently too..
agp vs edac, matroxfb vs lm_sensors,..)
Dave
--
http://www.codemonkey.org.uk
12:03 p.m.
On 22/03/07, Dave Jones <davej(a)redhat.com> wrote:
On Thu, Mar 22, 2007 at 11:15:32AM -0400, Chuck Ebbert wrote:
> What are we supposed to do when this kind of thing happens? It appears
that
> multiple drivers claim to support the same hardware.
Grr, this happens far too often. We have the same with for eg,
orinoco and hostap right now. The usual deal is that we either
just build the 'best' driver for that hardware, or if there's a case
where both drivers support the same hardware _and_ some hardware unique
to them, we nobble the pci table so that the crappier driver
doesn't load on that hardware.
As to which is the best one in this case.. I really don't know.
Or maybe this is a situation where it's valid to have both drivers loaded?
We don't actually support that right now, but patches went to linux-pci
list
last week that should be showing up in GregKHs tree adding an alternative
method for drivers to bind to a device in situations where it's possible
for two drivers to drive different parts of the same chip.
(This case has been showing up more and more recently too..
agp vs edac, matroxfb vs lm_sensors,..)
Taking a look at:
http://lwn.net/Articles/212535/
which may be able to shed some light on the changes. Even with the blackbird
driver blacklisted, the v4l2 loads but the dvb driver does not. It should be
noted that the two co-exist peacefully when loaded but something is
preventing the latter from loading - perhaps because the kernel "sees" the
driver requirements as being satisfied by the v4l2 module?
In any case, in this instance it is just that the cx88-dvb driver is failing
to load as opposed to anything more sinister.
Cheers
Chris
--
http://www.chruz.com
8:37 a.m.
Chris Brown wrote:
On 22/03/07, *Dave Jones* <davej(a)redhat.com <mailto:davej@redhat.com>>
wrote:
On Thu, Mar 22, 2007 at 11:15:32AM -0400, Chuck Ebbert wrote:
> What are we supposed to do when this kind of thing happens? It
appears that
> multiple drivers claim to support the same hardware.
Grr, this happens far too often. We have the same with for eg,
orinoco and hostap right now. The usual deal is that we either
just build the 'best' driver for that hardware, or if there's a case
where both drivers support the same hardware _and_ some hardware unique
to them, we nobble the pci table so that the crappier driver
doesn't load on that hardware.
As to which is the best one in this case.. I really don't know.
Or maybe this is a situation where it's valid to have both drivers
loaded?
We don't actually support that right now, but patches went to
linux-pci list
last week that should be showing up in GregKHs tree adding an
alternative
method for drivers to bind to a device in situations where it's
possible
for two drivers to drive different parts of the same chip.
(This case has been showing up more and more recently too..
agp vs edac, matroxfb vs lm_sensors,..)
Taking a look at:
http://lwn.net/Articles/212535/
which may be able to shed some light on the changes.
Yep.
Even with the
blackbird driver blacklisted, the v4l2 loads but the dvb driver does
not. It should be noted that the two co-exist peacefully when loaded but
something is preventing the latter from loading - perhaps because the
kernel "sees" the driver requirements as being satisfied by the v4l2 module?
In any case, in this instance it is just that the cx88-dvb driver is
failing to load as opposed to anything more sinister.
Interestingly enough, I was talking to one of the vl4-dvb maintainers
(Michael Krufky) on irc about this very driver two days ago. The
cx88-dvb driver is *supposed* to auto-load via a request_module() call
in cx8802. Similar for cx88-blackbird. Things broke when support for the
Hauppauge HVR1300 was added, because it actually needs *both* cx88-dvb
and cx88-blackbird. Upstream v4l-dvb has this fixed, verified by me from
20070302 snapshot cx88-dvb/cx8802 drivers.
--
Jarod Wilson
jwilson(a)redhat.com
9:06 a.m.
Jarod Wilson wrote:
Chris Brown wrote:
>
> On 22/03/07, *Dave Jones* <davej(a)redhat.com <mailto:davej@redhat.com>>
> wrote:
>
> On Thu, Mar 22, 2007 at 11:15:32AM -0400, Chuck Ebbert wrote:
>
> > What are we supposed to do when this kind of thing happens? It
> appears that
> > multiple drivers claim to support the same hardware.
>
> Grr, this happens far too often. We have the same with for eg,
> orinoco and hostap right now. The usual deal is that we either
> just build the 'best' driver for that hardware, or if there's a case
> where both drivers support the same hardware _and_ some hardware unique
> to them, we nobble the pci table so that the crappier driver
> doesn't load on that hardware.
>
> As to which is the best one in this case.. I really don't know.
>
> Or maybe this is a situation where it's valid to have both drivers
> loaded?
> We don't actually support that right now, but patches went to
> linux-pci list
> last week that should be showing up in GregKHs tree adding an
> alternative
> method for drivers to bind to a device in situations where it's
> possible
> for two drivers to drive different parts of the same chip.
> (This case has been showing up more and more recently too..
> agp vs edac, matroxfb vs lm_sensors,..)
>
>
> Taking a look at:
>
> http://lwn.net/Articles/212535/
>
> which may be able to shed some light on the changes.
Yep.
> Even with the
> blackbird driver blacklisted, the v4l2 loads but the dvb driver does
> not. It should be noted that the two co-exist peacefully when loaded but
> something is preventing the latter from loading - perhaps because the
> kernel "sees" the driver requirements as being satisfied by the v4l2
module?
>
> In any case, in this instance it is just that the cx88-dvb driver is
> failing to load as opposed to anything more sinister.
Interestingly enough, I was talking to one of the vl4-dvb maintainers
(Michael Krufky) on irc about this very driver two days ago. The
cx88-dvb driver is *supposed* to auto-load via a request_module() call
in cx8802. Similar for cx88-blackbird. Things broke when support for the
Hauppauge HVR1300 was added, because it actually needs *both* cx88-dvb
and cx88-blackbird. Upstream v4l-dvb has this fixed, verified by me from
20070302 snapshot cx88-dvb/cx8802 drivers.
So can they send a patch for -stable to fix it in 2.6.20?
1:49 p.m.
Chuck Ebbert wrote:
Jarod Wilson wrote:
> Chris Brown wrote:
>> On 22/03/07, *Dave Jones* <davej(a)redhat.com
<mailto:davej@redhat.com>>
>> wrote:
>>
>> On Thu, Mar 22, 2007 at 11:15:32AM -0400, Chuck Ebbert wrote:
>>
>> > What are we supposed to do when this kind of thing happens? It
>> appears that
>> > multiple drivers claim to support the same hardware.
>>
>> Grr, this happens far too often. We have the same with for eg,
>> orinoco and hostap right now. The usual deal is that we either
>> just build the 'best' driver for that hardware, or if there's a
case
>> where both drivers support the same hardware _and_ some hardware unique
>> to them, we nobble the pci table so that the crappier driver
>> doesn't load on that hardware.
>>
>> As to which is the best one in this case.. I really don't know.
>>
>> Or maybe this is a situation where it's valid to have both drivers
>> loaded?
>> We don't actually support that right now, but patches went to
>> linux-pci list
>> last week that should be showing up in GregKHs tree adding an
>> alternative
>> method for drivers to bind to a device in situations where it's
>> possible
>> for two drivers to drive different parts of the same chip.
>> (This case has been showing up more and more recently too..
>> agp vs edac, matroxfb vs lm_sensors,..)
>>
>>
>> Taking a look at:
>>
>> http://lwn.net/Articles/212535/
>>
>> which may be able to shed some light on the changes.
> Yep.
>
>> Even with the
>> blackbird driver blacklisted, the v4l2 loads but the dvb driver does
>> not. It should be noted that the two co-exist peacefully when loaded but
>> something is preventing the latter from loading - perhaps because the
>> kernel "sees" the driver requirements as being satisfied by the v4l2
module?
>>
>> In any case, in this instance it is just that the cx88-dvb driver is
>> failing to load as opposed to anything more sinister.
> Interestingly enough, I was talking to one of the vl4-dvb maintainers
> (Michael Krufky) on irc about this very driver two days ago. The
> cx88-dvb driver is *supposed* to auto-load via a request_module() call
> in cx8802. Similar for cx88-blackbird. Things broke when support for the
> Hauppauge HVR1300 was added, because it actually needs *both* cx88-dvb
> and cx88-blackbird. Upstream v4l-dvb has this fixed, verified by me from
> 20070302 snapshot cx88-dvb/cx8802 drivers.
So can they send a patch for -stable to fix it in 2.6.20?
Okay, patches are good to go for both cx88-dvb and dvb-bt8xx autoload
support. The cx88-dvb patch is a roll-up of three patches from upstream
v4l-dvb. I've successfully tested this patch atop 2.6.20 with a pcHDTV
HD-3000 card.
http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-cx88-dvb-auto...
The dvb-bt8xx patch is a newly-created patch by myself (with pointers
from Michael) that is essentially a clone of the cx88-dvb autoload bits.
It works flawlessly in my testing with a pcHDTV HD-2000 card. Its in
Michael's hands now, and he says he'll get it committed to the v4l-dvb
tree this afternoon.
http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-cx88-dvb-auto...
Semi-related to these patches is another cx88-dvb fix that we could
optionally add to fix some buffer issues on nxt200x-based cx88-dvb cards:
http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-nxt200x-buffe...
All three apply cleanly to the current FC6 2.6.20 kernel tree, as
Patch30-32.
Lemme know if I can provide any further info!
--
Jarod Wilson
jwilson(a)redhat.com
1:51 p.m.
Jarod Wilson wrote:
The dvb-bt8xx patch is a newly-created patch by myself (with pointers
from Michael) that is essentially a clone of the cx88-dvb autoload bits.
It works flawlessly in my testing with a pcHDTV HD-2000 card. Its in
Michael's hands now, and he says he'll get it committed to the v4l-dvb
tree this afternoon.
http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-cx88-dvb-auto...
D'oh, this one should be:
http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-dvb-bt8xx-aut...
--
Jarod Wilson
jwilson(a)redhat.com
11:50 a.m.
Jarod Wilson wrote:
Jarod Wilson wrote:
> The dvb-bt8xx patch is a newly-created patch by myself (with pointers
> from Michael) that is essentially a clone of the cx88-dvb autoload
> bits. It works flawlessly in my testing with a pcHDTV HD-2000 card.
> Its in Michael's hands now, and he says he'll get it committed to the
> v4l-dvb tree this afternoon.
>
> http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-cx88-dvb-auto...
D'oh, this one should be:
http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-dvb-bt8xx-aut...
And of course, I managed to put the upstream version of the patch there,
rather than the 2.6.20-based version. Here's the right one:
http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-20.5t-dvb-bt8...
The upstream commit can be seen here:
http://linuxtv.org/hg/~mkrufky/bt8xx?cmd=changeset;node=328d9710a012;styl...
--
Jarod Wilson
jwilson(a)redhat.com
6240
days inactive
6244
days old
kernel@lists.fedoraproject.org
9 comments
5 participants
participants (5)
-
Christopher Brown -
Chuck Ebbert -
Dave Jones -
drago01 -
Jarod Wilson