Right up front, I must say I do NOT have a Hauppauge tuner. I think
it's like maybe Mygica/Geniatech:
Bus 002 Device 004: ID 05e1:0400 Syntek Semiconductor Co., Ltd
Whenever I update my kernel, I edit the
./drivers/media/usb/au0828/au0828-cards.c file adding an entry for my
0x400 device.
I've been doing it for years and it's been working fine... until now...
*****
Aug 16 12:07:20 computerName kernel: usb 2-2.3: Tuner is busy. Error -19
<...18 more repeated entries...>
Aug 16 12:07:20 computerName kernel: usb 2-2.3: Tuner is busy. Error -19
Aug 16 12:07:10 computerName tvheadend[3276]: main: Log started
*****
"w_scan" behaves the same way.
*****
$ modprobe au0828
Aug 16 12:52:52 computerName kernel: videodev: Linux video capture
interface: v2.00
Aug 16 12:52:52 computerName kernel: au0828: au0828_init() Debugging is enabled
Aug 16 12:52:52 computerName kernel: au0828: au0828 driver loaded
Aug 16 12:52:52 computerName kernel: au0828: au0828_usb_probe() vendor
id 0x5e1 device id 0x400 ifnum:0
Aug 16 12:52:52 computerName kernel: au0828: au0828_gpio_setup()
Aug 16 12:52:52 computerName kernel: au0828: au0828_i2c_register()
Aug 16 12:52:52 computerName kernel: au0828: i2c bus registered
Aug 16 12:52:52 computerName kernel: au0828: au0828_card_setup()
Aug 16 12:52:52 computerName kernel: tveeprom: Encountered bad packet
header [20]. Corrupt or not a Hauppauge eeprom.
Aug 16 12:52:52 computerName kernel: au0828: hauppauge_eeprom:
warning: unknown hauppauge model #0
Aug 16 12:52:52 computerName kernel: au0828: hauppauge_eeprom:
hauppauge eeprom: model=0
Aug 16 12:52:52 computerName kernel: au0828: au0828_analog_register
called for intf#0!
Aug 16 12:52:52 computerName kernel: au0828: au0828_dvb_register()
Aug 16 12:52:52 computerName kernel: au8522 7-0047: creating new instance
Aug 16 12:52:52 computerName kernel: tda18271 7-0060: creating new instance
Aug 16 12:52:52 computerName kernel: tda18271: TDA18271HD/C2 detected @ 7-0060
Aug 16 12:52:53 computerName kernel: au0828: dvb_register()
Aug 16 12:52:53 computerName kernel: dvbdev: DVB: registering new
adapter (au0828)
Aug 16 12:52:53 computerName kernel: usb 2-2.3: DVB: registering
adapter 0 frontend 0 (Auvitek AU8522 QAM/8VSB Frontend)...
Aug 16 12:52:53 computerName kernel: dvbdev: dvb_create_media_entity:
media entity 'Auvitek AU8522 QAM/8VSB Frontend' registered.
Aug 16 12:52:53 computerName kernel: dvbdev: dvb_create_media_entity:
media entity 'dvb-demux' registered.
Aug 16 12:52:53 computerName kernel: au0828: Registered device AU0828
[Hauppauge Woodbury]
Aug 16 12:52:53 computerName kernel: usbcore: registered new interface
driver au0828
*****
The "eeprom" thing has never been an issue with regard to my tuner
working. It still worked in spite of it.
It's odd because:
*****
$ lsmod | grep au0828
au0828 86016 0
tveeprom 28672 1 au0828
dvb_core 176128 1 au0828
v4l2_common 20480 1 au0828
videobuf2_vmalloc 20480 2 dvb_core,au0828
videobuf2_v4l2 28672 1 au0828
videobuf2_common 61440 3 videobuf2_v4l2,dvb_core,au0828
videodev 253952 4
v4l2_common,videobuf2_v4l2,videobuf2_common,au0828
rc_core 61440 1 au0828
media 61440 6
videodev,snd_usb_audio,videobuf2_v4l2,dvb_core,videobuf2_common,au0828
$ ls -la /dev/dvb/adapter0/
total 0
drwxr-xr-x 2 root root 120 Aug 16 12:01 .
drwxr-xr-x 3 root root 60 Aug 16 12:01 ..
crw-rw----+ 1 root video 212, 4 Aug 16 12:01 demux0
crw-rw----+ 1 root video 212, 5 Aug 16 12:01 dvr0
crw-rw----+ 1 root video 212, 3 Aug 16 12:01 frontend0
crw-rw----+ 1 root video 212, 7 Aug 16 12:01 net0
*****
The previous kernel version I was on that worked was 5.1.15.
I just reverted back to the previous version and it's working again.
I don't know what broke and where, between the versions.
I saw https://lkml.org/lkml/2019/1/21/1020 but this is back in January
so I don't know if something was more recently applied to au0828 that
makes use of the API.
"lsof" didn't show anything related to "/dev/dvb" being used.
Oh neat! Someone posted a neat git feature which I tried and I get:
*****
$ git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset
%s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative
v5.1.15..v5.2.8 drivers/media/usb/au0828/
* be50f19fee84 - media: au0828: fix null dereference in error path (12 days ago)
* c942fddf8793 - treewide: Replace GPLv2 boilerplate/reference with
SPDX - rule 157 (3 months ago)
* 16216333235a - treewide: Replace GPLv2 boilerplate/reference with
SPDX - rule 1 (3 months ago)
* ec8f24b7faaf - treewide: Add SPDX license identifier -
Makefile/Kconfig (3 months ago)
* 14340de506c9 - media: prefix header search paths with $(srctree)/ (3
months ago)
* f604f0f5afb8 - media: au0828: stop video streaming only when last
user stops (4 months ago)
* 898bc40bfcc2 - media: au0828: Fix NULL pointer dereference in
au0828_analog_stream_enable() (4 months ago)
* 383b0e5b6ebb - media: au0828: fix enable and disable source audio
and video inconsistencies (4 months ago)
* 812658d88d26 - media: change au0828 to use Media Device Allocator
API (4 months ago)
* b60a5b8dcf49 - media: Kconfig files: use the right help coding style
(5 months ago)
* f712e5358d43 - media: au0828: minor fix to a misleading comment in
_close() (5 months ago)
*****
Note the 812658d88d26 commit.
So if I did the git command correctly, then it WAS added between these versions.
Any thoughts on if it is broken or if I can hack in a fix to force it
to ignore it being thought as being busy?
On Fri, Aug 16, 2019 at 01:18:01PM -0500, Nathan Royce wrote:
> Right up front, I must say I do NOT have a Hauppauge tuner. I think
> it's like maybe Mygica/Geniatech:
> Bus 002 Device 004: ID 05e1:0400 Syntek Semiconductor Co., Ltd
>
> Whenever I update my kernel, I edit the
> ./drivers/media/usb/au0828/au0828-cards.c file adding an entry for my
> 0x400 device.
> I've been doing it for years and it's been working fine... until now...
>
> *****
> Aug 16 12:07:20 computerName kernel: usb 2-2.3: Tuner is busy. Error -19
> <...18 more repeated entries...>
> Aug 16 12:07:20 computerName kernel: usb 2-2.3: Tuner is busy. Error -19
> Aug 16 12:07:10 computerName tvheadend[3276]: main: Log started
> *****
> "w_scan" behaves the same way.
>
> *****
> $ modprobe au0828
> Aug 16 12:52:52 computerName kernel: videodev: Linux video capture
> interface: v2.00
> Aug 16 12:52:52 computerName kernel: au0828: au0828_init() Debugging is enabled
> Aug 16 12:52:52 computerName kernel: au0828: au0828 driver loaded
> Aug 16 12:52:52 computerName kernel: au0828: au0828_usb_probe() vendor
> id 0x5e1 device id 0x400 ifnum:0
> Aug 16 12:52:52 computerName kernel: au0828: au0828_gpio_setup()
> Aug 16 12:52:52 computerName kernel: au0828: au0828_i2c_register()
> Aug 16 12:52:52 computerName kernel: au0828: i2c bus registered
> Aug 16 12:52:52 computerName kernel: au0828: au0828_card_setup()
> Aug 16 12:52:52 computerName kernel: tveeprom: Encountered bad packet
> header [20]. Corrupt or not a Hauppauge eeprom.
> Aug 16 12:52:52 computerName kernel: au0828: hauppauge_eeprom:
> warning: unknown hauppauge model #0
> Aug 16 12:52:52 computerName kernel: au0828: hauppauge_eeprom:
> hauppauge eeprom: model=0
> Aug 16 12:52:52 computerName kernel: au0828: au0828_analog_register
> called for intf#0!
> Aug 16 12:52:52 computerName kernel: au0828: au0828_dvb_register()
> Aug 16 12:52:52 computerName kernel: au8522 7-0047: creating new instance
> Aug 16 12:52:52 computerName kernel: tda18271 7-0060: creating new instance
> Aug 16 12:52:52 computerName kernel: tda18271: TDA18271HD/C2 detected @ 7-0060
> Aug 16 12:52:53 computerName kernel: au0828: dvb_register()
> Aug 16 12:52:53 computerName kernel: dvbdev: DVB: registering new
> adapter (au0828)
> Aug 16 12:52:53 computerName kernel: usb 2-2.3: DVB: registering
> adapter 0 frontend 0 (Auvitek AU8522 QAM/8VSB Frontend)...
> Aug 16 12:52:53 computerName kernel: dvbdev: dvb_create_media_entity:
> media entity 'Auvitek AU8522 QAM/8VSB Frontend' registered.
> Aug 16 12:52:53 computerName kernel: dvbdev: dvb_create_media_entity:
> media entity 'dvb-demux' registered.
> Aug 16 12:52:53 computerName kernel: au0828: Registered device AU0828
> [Hauppauge Woodbury]
> Aug 16 12:52:53 computerName kernel: usbcore: registered new interface
> driver au0828
> *****
> The "eeprom" thing has never been an issue with regard to my tuner
> working. It still worked in spite of it.
>
> It's odd because:
> *****
> $ lsmod | grep au0828
> au0828 86016 0
> tveeprom 28672 1 au0828
> dvb_core 176128 1 au0828
> v4l2_common 20480 1 au0828
> videobuf2_vmalloc 20480 2 dvb_core,au0828
> videobuf2_v4l2 28672 1 au0828
> videobuf2_common 61440 3 videobuf2_v4l2,dvb_core,au0828
> videodev 253952 4
> v4l2_common,videobuf2_v4l2,videobuf2_common,au0828
> rc_core 61440 1 au0828
> media 61440 6
> videodev,snd_usb_audio,videobuf2_v4l2,dvb_core,videobuf2_common,au0828
>
> $ ls -la /dev/dvb/adapter0/
> total 0
> drwxr-xr-x 2 root root 120 Aug 16 12:01 .
> drwxr-xr-x 3 root root 60 Aug 16 12:01 ..
> crw-rw----+ 1 root video 212, 4 Aug 16 12:01 demux0
> crw-rw----+ 1 root video 212, 5 Aug 16 12:01 dvr0
> crw-rw----+ 1 root video 212, 3 Aug 16 12:01 frontend0
> crw-rw----+ 1 root video 212, 7 Aug 16 12:01 net0
> *****
>
> The previous kernel version I was on that worked was 5.1.15.
> I just reverted back to the previous version and it's working again.
> I don't know what broke and where, between the versions.
>
> I saw https://lkml.org/lkml/2019/1/21/1020 but this is back in January
> so I don't know if something was more recently applied to au0828 that
> makes use of the API.
> "lsof" didn't show anything related to "/dev/dvb" being used.
>
> Oh neat! Someone posted a neat git feature which I tried and I get:
> *****
> $ git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset
> %s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative
> v5.1.15..v5.2.8 drivers/media/usb/au0828/
> * be50f19fee84 - media: au0828: fix null dereference in error path (12 days ago)
> * c942fddf8793 - treewide: Replace GPLv2 boilerplate/reference with
> SPDX - rule 157 (3 months ago)
> * 16216333235a - treewide: Replace GPLv2 boilerplate/reference with
> SPDX - rule 1 (3 months ago)
> * ec8f24b7faaf - treewide: Add SPDX license identifier -
> Makefile/Kconfig (3 months ago)
> * 14340de506c9 - media: prefix header search paths with $(srctree)/ (3
> months ago)
> * f604f0f5afb8 - media: au0828: stop video streaming only when last
> user stops (4 months ago)
> * 898bc40bfcc2 - media: au0828: Fix NULL pointer dereference in
> au0828_analog_stream_enable() (4 months ago)
> * 383b0e5b6ebb - media: au0828: fix enable and disable source audio
> and video inconsistencies (4 months ago)
> * 812658d88d26 - media: change au0828 to use Media Device Allocator
> API (4 months ago)
> * b60a5b8dcf49 - media: Kconfig files: use the right help coding style
> (5 months ago)
> * f712e5358d43 - media: au0828: minor fix to a misleading comment in
> _close() (5 months ago)
> *****
> Note the 812658d88d26 commit.
> So if I did the git command correctly, then it WAS added between these versions.
> Any thoughts on if it is broken or if I can hack in a fix to force it
> to ignore it being thought as being busy?
If you revert that one commit, does things start working again?
thanks,
greg k-h
Hi Nathan,
On 16/08/2019 13.18, Nathan Royce wrote:
> Right up front, I must say I do NOT have a Hauppauge tuner. I think
> it's like maybe Mygica/Geniatech:
> Bus 002 Device 004: ID 05e1:0400 Syntek Semiconductor Co., Ltd
>
> Whenever I update my kernel, I edit the
> ./drivers/media/usb/au0828/au0828-cards.c file adding an entry for my
> 0x400 device.
> I've been doing it for years and it's been working fine... until now...
>
> *****
> Aug 16 12:07:20 computerName kernel: usb 2-2.3: Tuner is busy. Error -19
> <...18 more repeated entries...>
> Aug 16 12:07:20 computerName kernel: usb 2-2.3: Tuner is busy. Error -19
> Aug 16 12:07:10 computerName tvheadend[3276]: main: Log started
> *****
> "w_scan" behaves the same way.
>
> *****
I don't have a "woodbury", but I have a Hauppauge 950Q sitting around
and tested it on latest mainline kernel. w_scan is ok and streaming is
fine. There's no unexpected errors. The 950Q uses the same au0828 bridge
and au8522 demod as woodbury, but a different tuner. Your problem
wouldn't appear to be a general au0828 issue.
You might have to check out git bisect. That will be the quickest way to
get to the bottom, if you've got points A and B, and are
building/running your own kernel.
Cheers,
Brad
> $ modprobe au0828
> Aug 16 12:52:52 computerName kernel: videodev: Linux video capture
> interface: v2.00
> Aug 16 12:52:52 computerName kernel: au0828: au0828_init() Debugging is enabled
> Aug 16 12:52:52 computerName kernel: au0828: au0828 driver loaded
> Aug 16 12:52:52 computerName kernel: au0828: au0828_usb_probe() vendor
> id 0x5e1 device id 0x400 ifnum:0
> Aug 16 12:52:52 computerName kernel: au0828: au0828_gpio_setup()
> Aug 16 12:52:52 computerName kernel: au0828: au0828_i2c_register()
> Aug 16 12:52:52 computerName kernel: au0828: i2c bus registered
> Aug 16 12:52:52 computerName kernel: au0828: au0828_card_setup()
> Aug 16 12:52:52 computerName kernel: tveeprom: Encountered bad packet
> header [20]. Corrupt or not a Hauppauge eeprom.
> Aug 16 12:52:52 computerName kernel: au0828: hauppauge_eeprom:
> warning: unknown hauppauge model #0
> Aug 16 12:52:52 computerName kernel: au0828: hauppauge_eeprom:
> hauppauge eeprom: model=0
> Aug 16 12:52:52 computerName kernel: au0828: au0828_analog_register
> called for intf#0!
> Aug 16 12:52:52 computerName kernel: au0828: au0828_dvb_register()
> Aug 16 12:52:52 computerName kernel: au8522 7-0047: creating new instance
> Aug 16 12:52:52 computerName kernel: tda18271 7-0060: creating new instance
> Aug 16 12:52:52 computerName kernel: tda18271: TDA18271HD/C2 detected @ 7-0060
> Aug 16 12:52:53 computerName kernel: au0828: dvb_register()
> Aug 16 12:52:53 computerName kernel: dvbdev: DVB: registering new
> adapter (au0828)
> Aug 16 12:52:53 computerName kernel: usb 2-2.3: DVB: registering
> adapter 0 frontend 0 (Auvitek AU8522 QAM/8VSB Frontend)...
> Aug 16 12:52:53 computerName kernel: dvbdev: dvb_create_media_entity:
> media entity 'Auvitek AU8522 QAM/8VSB Frontend' registered.
> Aug 16 12:52:53 computerName kernel: dvbdev: dvb_create_media_entity:
> media entity 'dvb-demux' registered.
> Aug 16 12:52:53 computerName kernel: au0828: Registered device AU0828
> [Hauppauge Woodbury]
> Aug 16 12:52:53 computerName kernel: usbcore: registered new interface
> driver au0828
> *****
> The "eeprom" thing has never been an issue with regard to my tuner
> working. It still worked in spite of it.
>
> It's odd because:
> *****
> $ lsmod | grep au0828
> au0828 86016 0
> tveeprom 28672 1 au0828
> dvb_core 176128 1 au0828
> v4l2_common 20480 1 au0828
> videobuf2_vmalloc 20480 2 dvb_core,au0828
> videobuf2_v4l2 28672 1 au0828
> videobuf2_common 61440 3 videobuf2_v4l2,dvb_core,au0828
> videodev 253952 4
> v4l2_common,videobuf2_v4l2,videobuf2_common,au0828
> rc_core 61440 1 au0828
> media 61440 6
> videodev,snd_usb_audio,videobuf2_v4l2,dvb_core,videobuf2_common,au0828
>
> $ ls -la /dev/dvb/adapter0/
> total 0
> drwxr-xr-x 2 root root 120 Aug 16 12:01 .
> drwxr-xr-x 3 root root 60 Aug 16 12:01 ..
> crw-rw----+ 1 root video 212, 4 Aug 16 12:01 demux0
> crw-rw----+ 1 root video 212, 5 Aug 16 12:01 dvr0
> crw-rw----+ 1 root video 212, 3 Aug 16 12:01 frontend0
> crw-rw----+ 1 root video 212, 7 Aug 16 12:01 net0
> *****
>
> The previous kernel version I was on that worked was 5.1.15.
> I just reverted back to the previous version and it's working again.
> I don't know what broke and where, between the versions.
>
> I saw https://lkml.org/lkml/2019/1/21/1020 but this is back in January
> so I don't know if something was more recently applied to au0828 that
> makes use of the API.
> "lsof" didn't show anything related to "/dev/dvb" being used.
>
> Oh neat! Someone posted a neat git feature which I tried and I get:
> *****
> $ git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset
> %s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative
> v5.1.15..v5.2.8 drivers/media/usb/au0828/
> * be50f19fee84 - media: au0828: fix null dereference in error path (12 days ago)
> * c942fddf8793 - treewide: Replace GPLv2 boilerplate/reference with
> SPDX - rule 157 (3 months ago)
> * 16216333235a - treewide: Replace GPLv2 boilerplate/reference with
> SPDX - rule 1 (3 months ago)
> * ec8f24b7faaf - treewide: Add SPDX license identifier -
> Makefile/Kconfig (3 months ago)
> * 14340de506c9 - media: prefix header search paths with $(srctree)/ (3
> months ago)
> * f604f0f5afb8 - media: au0828: stop video streaming only when last
> user stops (4 months ago)
> * 898bc40bfcc2 - media: au0828: Fix NULL pointer dereference in
> au0828_analog_stream_enable() (4 months ago)
> * 383b0e5b6ebb - media: au0828: fix enable and disable source audio
> and video inconsistencies (4 months ago)
> * 812658d88d26 - media: change au0828 to use Media Device Allocator
> API (4 months ago)
> * b60a5b8dcf49 - media: Kconfig files: use the right help coding style
> (5 months ago)
> * f712e5358d43 - media: au0828: minor fix to a misleading comment in
> _close() (5 months ago)
> *****
> Note the 812658d88d26 commit.
> So if I did the git command correctly, then it WAS added between these versions.
> Any thoughts on if it is broken or if I can hack in a fix to force it
> to ignore it being thought as being busy?
On Fri, Aug 16, 2019 at 1:42 PM Greg Kroah-Hartman
<[email protected]> wrote:
> If you revert that one commit, does things start working again?
>
> thanks,
>
> greg k-h
Hey Greg, I just got finished building it after running "$ git revert
812658d88d26" and verifying it reverted by comparing one of the files
from git log -p, but alas, no joy.
On Fri, Aug 16, 2019 at 5:41 PM Brad Love <[email protected]> wrote:
>
> Hi Nathan,
>
> I don't have a "woodbury", but I have a Hauppauge 950Q sitting around
> and tested it on latest mainline kernel. w_scan is ok and streaming is
> fine. There's no unexpected errors. The 950Q uses the same au0828 bridge
> and au8522 demod as woodbury, but a different tuner. Your problem
> wouldn't appear to be a general au0828 issue.
>
> You might have to check out git bisect. That will be the quickest way to
> get to the bottom, if you've got points A and B, and are
> building/running your own kernel.
>
> Cheers,
>
> Brad
Thanks Brad, I'll explore bisecting and hopefully will be able to
narrow down the cause.
I wasn't running my own kernel, but rather using the Arch Linux kernel
and modding the one module and putting it in "extramodules".
On 8/16/19 7:15 PM, Nathan Royce wrote:
> On Fri, Aug 16, 2019 at 1:42 PM Greg Kroah-Hartman
> <[email protected]> wrote:
>> If you revert that one commit, does things start working again?
>>
>> thanks,
>>
>> greg k-h
> Hey Greg, I just got finished building it after running "$ git revert
> 812658d88d26" and verifying it reverted by comparing one of the files
> from git log -p, but alas, no joy.
>
> On Fri, Aug 16, 2019 at 5:41 PM Brad Love <[email protected]> wrote:
>>
>> Hi Nathan,
>>
>> I don't have a "woodbury", but I have a Hauppauge 950Q sitting around
>> and tested it on latest mainline kernel. w_scan is ok and streaming is
>> fine. There's no unexpected errors. The 950Q uses the same au0828 bridge
>> and au8522 demod as woodbury, but a different tuner. Your problem
>> wouldn't appear to be a general au0828 issue.
>>
Thanks Brad!
>> You might have to check out git bisect. That will be the quickest way to
>> get to the bottom, if you've got points A and B, and are
>> building/running your own kernel.
>>
>> Cheers,
>>
>> Brad
> Thanks Brad, I'll explore bisecting and hopefully will be able to
> narrow down the cause.
> I wasn't running my own kernel, but rather using the Arch Linux kernel
> and modding the one module and putting it in "extramodules".
>
Hi Nathan,
Just catching up with this thread. Let me know what you find. Can you
build your own kernel and see what you can find?
thanks,
-- Shuah
On 8/19/19 2:49 PM, shuah wrote:
> On 8/16/19 7:15 PM, Nathan Royce wrote:
>> On Fri, Aug 16, 2019 at 1:42 PM Greg Kroah-Hartman
>> <[email protected]> wrote:
>>> If you revert that one commit, does things start working again?
>>>
>>> thanks,
>>>
>>> greg k-h
>> Hey Greg, I just got finished building it after running "$ git revert
>> 812658d88d26" and verifying it reverted by comparing one of the files
>> from git log -p, but alas, no joy.
>>
>> On Fri, Aug 16, 2019 at 5:41 PM Brad Love <[email protected]> wrote:
>>>
>>> Hi Nathan,
>>>
>>> I don't have a "woodbury", but I have a Hauppauge 950Q sitting around
>>> and tested it on latest mainline kernel. w_scan is ok and streaming is
>>> fine. There's no unexpected errors. The 950Q uses the same au0828 bridge
>>> and au8522 demod as woodbury, but a different tuner. Your problem
>>> wouldn't appear to be a general au0828 issue.
>>>
>
> Thanks Brad!
>
>>> You might have to check out git bisect. That will be the quickest way to
>>> get to the bottom, if you've got points A and B, and are
>>> building/running your own kernel.
>>>
>>> Cheers,
>>>
>>> Brad
>> Thanks Brad, I'll explore bisecting and hopefully will be able to
>> narrow down the cause.
>> I wasn't running my own kernel, but rather using the Arch Linux kernel
>> and modding the one module and putting it in "extramodules".
>>
>
> Hi Nathan,
>
> Just catching up with this thread. Let me know what you find. Can you
> build your own kernel and see what you can find?
>
You said you make changes to the
"Whenever I update my kernel, I edit the
./drivers/media/usb/au0828/au0828-cards.c file adding an entry for my
0x400 device.
I've been doing it for years and it's been working fine... until now..."
Please send me the changes you make to the file. I see the following
WOODBURY devices. I am assuming you add 0x400 entry.
{ USB_DEVICE(0x05e1, 0x0480),
.driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
{ USB_DEVICE(0x2040, 0x8200),
.driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
There is another table in sound/usb/quirks-table.h for AU0828
devices. In addition to 812658d88d26, 66354f18fe5f makes change
to this table to add a flag. I see two entries in that table:
AU0828_DEVICE(0x05e1, 0x0480, "Hauppauge", "Woodbury"),
AU0828_DEVICE(0x2040, 0x8200, "Hauppauge", "Woodbury"),
Since these drivers are now coupled doing resource sharing,
could it be that with your change to au02828 device table,
your changes are bow incomplete.
I don't have a Woodbury device though. This is something to
try.
Did you consider sending patch to add your device variant,
so you don't have to keep making this change whenever you
go to a new kernel?
thanks,
-- Shuah
(resubmitting due to non "reply-to-all"):
Bugger, I just sent a reply to your last message, but it bounced back with:
*****
550 5.7.1 Content-Policy reject msg: The message contains HTML
subpart, therefore we consider it SPAM or Outlook Virus. TEXT/PLAIN is
accepted.! BF:<U 0.466751>; S1728494AbfHSVzk
*****
I just switched this email to plain-text and will resubmit my previous
email as plain-text.
Anyway, yeah, all I did in au0828-cards.c was add my 0x0400 like:
*****
{ USB_DEVICE(0x2040, 0x7281),
.driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL },
{ USB_DEVICE(0x05e1, 0x0400),
.driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
{ USB_DEVICE(0x05e1, 0x0480),
.driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
{ USB_DEVICE(0x2040, 0x8200),
.driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
*****
That's all I've ever had to do. I never knew about the quirks-table.h.
I'll take a look.
I saw in the log the 0x05e1 addition was made in 2016, but maybe it
only applies to the Media Controller API change requirement now (thus,
not having caused any problems in the past since the API wasn't being
used).
I've never sent in a patch before (anywhere. I just point out a
problem and let the dev code it in their style). Also I don't want to
be a bother in case something even that small could somehow break
something else, especially for something "off-brand"(?).
I never really minded building the module by itself.
I've just now started the build for linux-5.2.y with the
quirks-table.h change along with au0828-cards.c.
Thanks for that heads-up. Hopefully that does the trick (whatever the
trick/quirk is).
On Mon, Aug 19, 2019 at 4:44 PM shuah <[email protected]> wrote:
>
> On 8/19/19 2:49 PM, shuah wrote:
> > Hi Nathan,
> >
> > Just catching up with this thread. Let me know what you find. Can you
> > build your own kernel and see what you can find?
> >
>
> You said you make changes to the
>
> "Whenever I update my kernel, I edit the
> ./drivers/media/usb/au0828/au0828-cards.c file adding an entry for my
> 0x400 device.
> I've been doing it for years and it's been working fine... until now..."
>
> Please send me the changes you make to the file. I see the following
> WOODBURY devices. I am assuming you add 0x400 entry.
>
> { USB_DEVICE(0x05e1, 0x0480),
> .driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
> { USB_DEVICE(0x2040, 0x8200),
> .driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
>
>
> There is another table in sound/usb/quirks-table.h for AU0828
> devices. In addition to 812658d88d26, 66354f18fe5f makes change
> to this table to add a flag. I see two entries in that table:
>
> AU0828_DEVICE(0x05e1, 0x0480, "Hauppauge", "Woodbury"),
> AU0828_DEVICE(0x2040, 0x8200, "Hauppauge", "Woodbury"),
>
> Since these drivers are now coupled doing resource sharing,
> could it be that with your change to au02828 device table,
> your changes are bow incomplete.
>
> I don't have a Woodbury device though. This is something to
> try.
>
> Did you consider sending patch to add your device variant,
> so you don't have to keep making this change whenever you
> go to a new kernel?
>
> thanks,
> -- Shuah
(resubmitting due to non "plain-text" causing virus bounce):
Hey Shuah, after these few days, I FINALLY completed bisecting... much
to my dismay...
It was my first foray into bisecting and it looked simple enough, but
for some reason every subsequent step resulted in a "bad" result.
*****
$ git bisect log
git bisect start
# good: [f0fae702de30331a8ce913cdb87ac0bdf990d85f] Linux 5.1.15
git bisect good f0fae702de30331a8ce913cdb87ac0bdf990d85f
# bad: [d36a8d2fb62c7c9415213bea9cf576d8b1f9071f] Linux 5.2.8
git bisect bad d36a8d2fb62c7c9415213bea9cf576d8b1f9071f
# good: [e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd] Linux 5.1
git bisect good e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd
# bad: [a2d635decbfa9c1e4ae15cb05b68b2559f7f827c] Merge tag
'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm
git bisect bad a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
# bad: [82efe439599439a5e1e225ce5740e6cfb777a7dd] Merge tag
'devicetree-for-5.2' of
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
git bisect bad 82efe439599439a5e1e225ce5740e6cfb777a7dd
# bad: [78438ce18f26dbcaa8993bb45d20ffb0cec3bc3e] Merge branch
'stable-fodder' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect bad 78438ce18f26dbcaa8993bb45d20ffb0cec3bc3e
# bad: [275b103a26e218b3d739e5ab15be6b40303a1428] Merge tag
'edac_for_5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp
git bisect bad 275b103a26e218b3d739e5ab15be6b40303a1428
# bad: [0bc40e549aeea2de20fc571749de9bbfc099fb34] Merge branch
'x86-mm-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 0bc40e549aeea2de20fc571749de9bbfc099fb34
# bad: [007dc78fea62610bf06829e38f1d8c69b6ea5af6] Merge branch
'locking-core-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 007dc78fea62610bf06829e38f1d8c69b6ea5af6
# bad: [5ba2a4b12f450c5c69099a5c19671c6e59daa435] Merge branch
'core-rcu-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 5ba2a4b12f450c5c69099a5c19671c6e59daa435
# bad: [91df49e187c1a111e423fe0c3aec3472980385e4] Merge LKMM and RCU commits
git bisect bad 91df49e187c1a111e423fe0c3aec3472980385e4
# bad: [add0d37b4f1e77de7d170ece43c8d765572a1eab] rcu: Correct
READ_ONCE()/WRITE_ONCE() for ->rcu_read_unlock_special
git bisect bad add0d37b4f1e77de7d170ece43c8d765572a1eab
# bad: [da8739f23fadf05809c6c37c327367b229467045] rcu: Allow
rcu_nocbs= to specify all CPUs
git bisect bad da8739f23fadf05809c6c37c327367b229467045
# bad: [884157cef0acf05648fe921d80c680afababb428] rcu: Make exit_rcu()
handle non-preempted RCU readers
git bisect bad 884157cef0acf05648fe921d80c680afababb428
# bad: [671a63517cf983ad8eaa324167165cef245ab744] rcu: Avoid
unnecessary softirq when system is idle
git bisect bad 671a63517cf983ad8eaa324167165cef245ab744
# bad: [e85e6a21b2b5f31148cc3f2e785262b37c3e1ec7] rcu: Unconditionally
expedite during suspend/hibernate
git bisect bad e85e6a21b2b5f31148cc3f2e785262b37c3e1ec7
# first bad commit: [e85e6a21b2b5f31148cc3f2e785262b37c3e1ec7] rcu:
Unconditionally expedite during suspend/hibernate
*****
And those were ALL of the steps and I REALLY don't think that rcu
commit is the cause.
My testing went down something like this:
*****
$ git clean -xdf
$ git reset --hard
$ git checkout v5.1.15
$ git bisect start
$ git bisect good
$ git bisect bad v5.2.8
//edit "./drivers/media/usb/au0828/au0828-cards.c", adding my 0x400 tuner.
$ cat /proc/config.gz | gunzip > .config
$ yes '' | make oldconfig
$ make -j4
$ make modules_install
$ cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux-bisect
$ mkinitcpio -k <kernel listed from modules_install command> -g
/boot/initramfs-linux-bisect.img
//reboot into newly compiled kernel (already set in
/boot/loader/entries/bisect.conf)
$ /w_scan-20170107/w_scan -c US //test tuner which results in "...
main:4004: FATAL: ***** NO USEABLE TERRCABLE_ATSC CARD FOUND. *****
...". Same issue with tvheadend and journalctl shows the Tuner is busy
error -19 message.
$ git bisect bad
$ make mrproper //necessary? Took forever to compile all 13 steps cleanly.
//GOTO "cat /proc/config.gz | gunzip > .config" step and repeat 13
times... ugh. About 2-3 hours for each.
*****
I don't know how bisecting does it's magic, but I'd think it'd be
something like this:
v............commits...........v //(from 5.1.15 to 5.2.8)
Good ||||||||||||||||||||||| Bad
| //split the commits
| //split the bottom half if the
previous test failed
| //split the difference again if good,
and repeat.
I'd think a more intelligent way to bisect would be based on a
file/module that is known/thought to produce the error.
In my case, the starting point would be "./drivers/media/usb/au0828/"
All commit changes for any file in that directory given a branch/tag
range would be examined.
If no changes are found in that branch/tag range, then the next step
would be to analyze any commits that are affected by parents/children
(references) of au0828 within that version range, and continually move
up/down the line. (eg. linux/usb.h which is referenced by au0828.h)
This way, the scope is very narrow at the beginning and widens as needed.
I think it's something that could be implemented in the git tool and
the user only needs to provide a starting place. Just a thought.
I can only hope that I incorrectly used bisecting and someone can
point to what I did wrong and provide a better way. (maybe I wouldn't
have to mrproper, so the testing wouldn't take days?)
On Mon, Aug 19, 2019 at 3:49 PM shuah <[email protected]> wrote:
>
> On 8/16/19 7:15 PM, Nathan Royce wrote:
> Hi Nathan,
>
> Just catching up with this thread. Let me know what you find. Can you
> build your own kernel and see what you can find?
>
> thanks,
> -- Shuah
While your mention of quirks-table.h certainly had possibilities, I'm
afraid adding the "AU0828_DEVICE(0x05e1, 0x0400, "Hauppauge",
"Woodbury")," entry for my tuner did not make any difference regarding
the "Tuner is busy. Error -19" message.
I don't know if this means anything, but I see
https://patchwork.kernel.org/patch/97726/ from 2010 which contains
changes for the 0x0400 model. I guess it never got pulled in.
Really, it's fine for me just to hang back at v5.1 for a year or two
until ATSC 3.0 USB tuners come out at a reasonable price.
On Mon, Aug 19, 2019 at 4:44 PM shuah <[email protected]> wrote:
> You said you make changes to the
>
> "Whenever I update my kernel, I edit the
> ./drivers/media/usb/au0828/au0828-cards.c file adding an entry for my
> 0x400 device.
> I've been doing it for years and it's been working fine... until now..."
>
> Please send me the changes you make to the file. I see the following
> WOODBURY devices. I am assuming you add 0x400 entry.
>
> { USB_DEVICE(0x05e1, 0x0480),
> .driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
> { USB_DEVICE(0x2040, 0x8200),
> .driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
>
>
> There is another table in sound/usb/quirks-table.h for AU0828
> devices. In addition to 812658d88d26, 66354f18fe5f makes change
> to this table to add a flag. I see two entries in that table:
>
> AU0828_DEVICE(0x05e1, 0x0480, "Hauppauge", "Woodbury"),
> AU0828_DEVICE(0x2040, 0x8200, "Hauppauge", "Woodbury"),
>
> Since these drivers are now coupled doing resource sharing,
> could it be that with your change to au02828 device table,
> your changes are bow incomplete.
>
> I don't have a Woodbury device though. This is something to
> try.
>
> Did you consider sending patch to add your device variant,
> so you don't have to keep making this change whenever you
> go to a new kernel?
>
> thanks,
> -- Shuah
On 8/20/19 12:58 AM, Nathan Royce wrote:
> While your mention of quirks-table.h certainly had possibilities, I'm
> afraid adding the "AU0828_DEVICE(0x05e1, 0x0400, "Hauppauge",
> "Woodbury")," entry for my tuner did not make any difference regarding
> the "Tuner is busy. Error -19" message.
>
> I don't know if this means anything, but I see
> https://patchwork.kernel.org/patch/97726/ from 2010 which contains
> changes for the 0x0400 model. I guess it never got pulled in.
>
> Really, it's fine for me just to hang back at v5.1 for a year or two
> until ATSC 3.0 USB tuners come out at a reasonable price.
>
Hi Nathan,
The tuner busy error code is ENODEV. It appears some devices aren't
created on your system. Would it be possible for you to send me your
config and a complete dmesg.
I am curious if /dev/media0 or /dev/media1 present on your system.
Not having this could explain the ENODEV you are seeing.
thanks,
-- Shuah
On 8/20/19 7:56 AM, shuah wrote:
> On 8/20/19 12:58 AM, Nathan Royce wrote:
>> While your mention of quirks-table.h certainly had possibilities, I'm
>> afraid adding the "AU0828_DEVICE(0x05e1, 0x0400, "Hauppauge",
>> "Woodbury")," entry for my tuner did not make any difference regarding
>> the "Tuner is busy. Error -19" message.
>>
>> I don't know if this means anything, but I see
>> https://patchwork.kernel.org/patch/97726/ from 2010 which contains
>> changes for the 0x0400 model. I guess it never got pulled in.
>>
>> Really, it's fine for me just to hang back at v5.1 for a year or two
>> until ATSC 3.0 USB tuners come out at a reasonable price.
>>
>
> Hi Nathan,
>
> The tuner busy error code is ENODEV. It appears some devices aren't
> created on your system. Would it be possible for you to send me your
> config and a complete dmesg.
>
> I am curious if /dev/media0 or /dev/media1 present on your system.
> Not having this could explain the ENODEV you are seeing.
>
Thanks for sending the dmesg and config. The difference between the
two config is you have CONFIG_MEDIA_CONTROLLER_DVB set in the second
one. This is expected because this is enabled in 5.2 with the changes
to share resources.
grep MEDIA_CONTROLLER config5115.txt
CONFIG_MEDIA_CONTROLLER=y
# CONFIG_MEDIA_CONTROLLER_DVB is not set
# CONFIG_MEDIA_CONTROLLER_REQUEST_API is not set
grep MEDIA_CONTROLLER config529.txt
CONFIG_MEDIA_CONTROLLER=y
CONFIG_MEDIA_CONTROLLER_DVB=y
# CONFIG_MEDIA_CONTROLLER_REQUEST_API is not set
CONFIG_SND_USB_AUDIO_USE_MEDIA_CONTROLLER=y
A new code path in DVB is enabled in 5.2 compared to 5.1. What we are
seeing is somehow the DVB media graph is incomplete. When the enable
source tries to find the media device that corresponds to the fe entity
it can't find it and hence the -ENODEV you are seeing.
I would be curious to see what happens if you have disable
CONFIG_MEDIA_CONTROLLER
I think the problem is in dvb media graph creation on your device and
unfortunately, I don't have the device to debug the problem.
Will you be able run media-ctl --print-dot on your system and send
me the media graph. You can find media-ctl tool on
https://git.linuxtv.org/v4l-utils.git/
thanks,
-- Shuah