Mailing List Archive

Kernel Crash when starting up in au0828-video.c line 895
greetings!

I think I have uncovered a nasty little bug in either the referenced module, or something is fishy happening.

This occurs at boot time when mythbackend is starting up. I can't make a copy of the dump info as it is not responsive, even though there is mouse movement.

I have enabled analog video using an HVR950Q tuner. Prior to setting up the tuner in mythbackend, tvtime was able to watch analog video via the ntsc cable tuner.


Help!
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
I neglected to say that this was in mythbuntu 12.04 beta, running mythtv .25

On Apr 7, 2012, at 5:54 PM, jrh wrote:

> greetings!
>
> I think I have uncovered a nasty little bug in either the referenced module, or something is fishy happening.
>
> This occurs at boot time when mythbackend is starting up. I can't make a copy of the dump info as it is not responsive, even though there is mouse movement.
>
> I have enabled analog video using an HVR950Q tuner. Prior to setting up the tuner in mythbackend, tvtime was able to watch analog video via the ntsc cable tuner.
>
>
> Help!

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On 12-04-07 05:54 PM, jrh wrote:
> greetings!
>
> I think I have uncovered a nasty little bug in either the referenced module, or something is fishy happening.
>
> This occurs at boot time when mythbackend is starting up. I can't make a copy of the dump info as it is not responsive, even though there is mouse movement.
>
> I have enabled analog video using an HVR950Q tuner. Prior to setting up the tuner in mythbackend, tvtime was able to watch analog video via the ntsc cable tuner.

The HVR950Q suffers from race conditions between the various
kernel modules that control different internal parts of the device.

The standard way of avoiding most of the issues is to blacklist au0828
so that the kernel won't autoload it at boot time.

Then, just before starting mythbackend, manually insmod au0828,
and then delay (sleep for a couple of seconds).

After which it's usually working.

I have a script that does this for me in a somewhat fancier fashion,
resetting the 950Q's beforehand, and then loading xc5000/au0828 in
the order that seems to work, with the magic sleeps.

But it's not too hard to roll one's own, either.

Cheers


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
Would you mind sharing your script?

thanks!

On Apr 7, 2012, at 6:30 PM, Mark Lord wrote:

> On 12-04-07 05:54 PM, jrh wrote:
>> greetings!
>>
>> I think I have uncovered a nasty little bug in either the referenced module, or something is fishy happening.
>>
>> This occurs at boot time when mythbackend is starting up. I can't make a copy of the dump info as it is not responsive, even though there is mouse movement.
>>
>> I have enabled analog video using an HVR950Q tuner. Prior to setting up the tuner in mythbackend, tvtime was able to watch analog video via the ntsc cable tuner.
>
> The HVR950Q suffers from race conditions between the various
> kernel modules that control different internal parts of the device.
>
> The standard way of avoiding most of the issues is to blacklist au0828
> so that the kernel won't autoload it at boot time.
>
> Then, just before starting mythbackend, manually insmod au0828,
> and then delay (sleep for a couple of seconds).
>
> After which it's usually working.
>
> I have a script that does this for me in a somewhat fancier fashion,
> resetting the 950Q's beforehand, and then loading xc5000/au0828 in
> the order that seems to work, with the magic sleeps.
>
> But it's not too hard to roll one's own, either.
>
> Cheers
>
>

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On Apr 7, 2012, at 6:30 PM, Mark Lord wrote:

> On 12-04-07 05:54 PM, jrh wrote:
>> greetings!
>>
>> I think I have uncovered a nasty little bug in either the referenced module, or something is fishy happening.
>>
>> This occurs at boot time when mythbackend is starting up. I can't make a copy of the dump info as it is not responsive, even though there is mouse movement.
>>
>> I have enabled analog video using an HVR950Q tuner. Prior to setting up the tuner in mythbackend, tvtime was able to watch analog video via the ntsc cable tuner.
>
> The HVR950Q suffers from race conditions between the various
> kernel modules that control different internal parts of the device.
>
> The standard way of avoiding most of the issues is to blacklist au0828
> so that the kernel won't autoload it at boot time.
>
> Then, just before starting mythbackend, manually insmod au0828,
> and then delay (sleep for a couple of seconds).
>
> After which it's usually working.
>
> I have a script that does this for me in a somewhat fancier fashion,
> resetting the 950Q's beforehand, and then loading xc5000/au0828 in
> the order that seems to work, with the magic sleeps.
>
> But it's not too hard to roll one's own, either.
>
> Cheers
>
>


Background information: I am running mythbuntu 1204 beta, with the.25 version that was built 0406 build 0401ecad.

I did the above steps manually, and I am still having the kernel crash.I did find that the last thing done in mythbackend was the following line

Apr 7 19:20:13 myth1204 mythbackend[2224]: I CoreContext v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0): SetInputAndFormat(1, NTSC) (v4l v2) input_switch: 0 mode_switch: 1

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On 12-04-07 06:44 PM, jrh wrote:
> Would you mind sharing your script?
..
> On Apr 7, 2012, at 6:30 PM, Mark Lord wrote:
..
>> The HVR950Q suffers from race conditions between the various
>> kernel modules that control different internal parts of the device.
>>
>> The standard way of avoiding most of the issues is to blacklist au0828
>> so that the kernel won't autoload it at boot time.
>>
>> Then, just before starting mythbackend, manually insmod au0828,
>> and then delay (sleep for a couple of seconds).
>>
>> After which it's usually working.
>>
>> I have a script that does this for me in a somewhat fancier fashion,
>> resetting the 950Q's beforehand, and then loading xc5000/au0828 in
>> the order that seems to work, with the magic sleeps.


Sure, no problem at all.

Here (attached, hopefully, is the /etc/init/mythtv.conf Upstart script
that I use for starting mythbackend -- free free to edit/rename it
to match what Mythbuntu calls it. I use this in Xubuntu-12.04 prerelease.

The /etc/init/mythtv.conf script invokes /usr/local/bin/reset_hauppauge_usb.sh
to do the dirty work. That script is also attached.

Finally, that latter script needs to perform USB resets,
which involves a very simple C program called usbreset.c (attached),
which you should compile and place the binary into /usr/local/bin/usbreset

My scripts may assume free use of "sudo",
which I've configured in /etc/sudoers to never prompt for passwords.
That file is _also_ attached, but the critical line is this one:

mythtv ALL=NOPASSWD: ALL

Cheers
-ml
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On 12-04-07 08:53 PM, Mark Lord wrote:
..
> Here (attached, hopefully, is the /etc/init/mythtv.conf Upstart script
> that I use for starting mythbackend -- free free to edit/rename it
> to match what Mythbuntu calls it. I use this in Xubuntu-12.04 prerelease.
>
> The /etc/init/mythtv.conf script invokes /usr/local/bin/reset_hauppauge_usb.sh
> to do the dirty work. That script is also attached.
>
> Finally, that latter script needs to perform USB resets,
> which involves a very simple C program called usbreset.c (attached),
> which you should compile and place the binary into /usr/local/bin/usbreset
>
> My scripts may assume free use of "sudo",
> which I've configured in /etc/sudoers to never prompt for passwords.
> That file is _also_ attached, but the critical line is this one:
>
> mythtv ALL=NOPASSWD: ALL
>
> Cheers


I should add that, even with the above workarounds, there is STILL an issue
when mythbackend starts up: If you have "multi-rec" enabled (more than one
virtual tuner per physical HVR-950Q), then the backend will have several
near-simultaneous "tune to initial channel" calls into the drivers.

This will cause tuner failure.

So, go into mythtv-setup and set the maximum simultaneous recordings per tuner
to be exactly "1" (the default is "2"). A nuisance, particularly if you have
only a single HVR-950Q, but at least it does make things a lot more reliable.

Cheers

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On 12-04-07 08:56 PM, Mark Lord wrote:
> On 12-04-07 08:53 PM, Mark Lord wrote:
> ..
>> Here (attached, hopefully, is the /etc/init/mythtv.conf Upstart script
>> that I use for starting mythbackend -- free free to edit/rename it
>> to match what Mythbuntu calls it. I use this in Xubuntu-12.04 prerelease.
>>
>> The /etc/init/mythtv.conf script invokes /usr/local/bin/reset_hauppauge_usb.sh
>> to do the dirty work. That script is also attached.
>>
>> Finally, that latter script needs to perform USB resets,
>> which involves a very simple C program called usbreset.c (attached),
>> which you should compile and place the binary into /usr/local/bin/usbreset
>>
>> My scripts may assume free use of "sudo",
>> which I've configured in /etc/sudoers to never prompt for passwords.
>> That file is _also_ attached, but the critical line is this one:
>>
>> mythtv ALL=NOPASSWD: ALL
>>
>> Cheers
>
>
> I should add that, even with the above workarounds, there is STILL an issue
> when mythbackend starts up: If you have "multi-rec" enabled (more than one
> virtual tuner per physical HVR-950Q), then the backend will have several
> near-simultaneous "tune to initial channel" calls into the drivers.
>
> This will cause tuner failure.
>
> So, go into mythtv-setup and set the maximum simultaneous recordings per tuner
> to be exactly "1" (the default is "2"). A nuisance, particularly if you have
> only a single HVR-950Q, but at least it does make things a lot more reliable.


And while I'm at it, there are a couple of kernel patches that make this all
work a bit better. First, this one to partially fix various tuning errors:

30_au8522_tuning_fix.patch

And also this patch from me, to speed the firmware download to the xc5000
on the 950Q (only!) from 6.5 seconds down to a more reasonable 2.5 seconds:

15_au0828_faster_i2c.patch

The first patch is winding it's way into a someday new kernel at the moment,
and the second patch is never going to make it there. :)

Cheers
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On 12-04-07 08:59 PM, Mark Lord wrote:
> And while I'm at it, there are a couple of kernel patches that make this all
> work a bit better. First, this one to partially fix various tuning errors:
>
> 30_au8522_tuning_fix.patch
>
> And also this patch from me, to speed the firmware download to the xc5000
> on the 950Q (only!) from 6.5 seconds down to a more reasonable 2.5 seconds:
>
> 15_au0828_faster_i2c.patch
>
> The first patch is winding it's way into a someday new kernel at the moment,
> and the second patch is never going to make it there. :)


Forgot to attach the patches. Here they are now.
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On 04/07/12 21:00, Mark Lord wrote:
> On 12-04-07 08:59 PM, Mark Lord wrote:
>> And while I'm at it, there are a couple of kernel patches that make this all
>> work a bit better. First, this one to partially fix various tuning errors:
>>
>> 30_au8522_tuning_fix.patch
>>
>> And also this patch from me, to speed the firmware download to the xc5000
>> on the 950Q (only!) from 6.5 seconds down to a more reasonable 2.5 seconds:
>>
>> 15_au0828_faster_i2c.patch
>>
>> The first patch is winding it's way into a someday new kernel at the moment,
>> and the second patch is never going to make it there. :)
>
> Forgot to attach the patches. Here they are now.
>

Thanks, I will check them out and see if they help!
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
> Date: Sat, 07 Apr 2012 20:56:23 -0400
> From: Mark Lord <mythtv@rtr.ca>

> I should add that, even with the above workarounds, there is STILL an issue
> when mythbackend starts up: If you have "multi-rec" enabled (more than one
> virtual tuner per physical HVR-950Q), then the backend will have several
> near-simultaneous "tune to initial channel" calls into the drivers.

> This will cause tuner failure.

I haven't been following this thread closely (not my hardware), but
would it be possible to tune using an external tuner script that uses
a mutex and some sleeps to avoid simultaneous tunes? I have no idea
if the way multirec tunes this hardware is amenable to breaking it
out externally like that.

I actually do something like this with Motorola STB's being tuned
through their serial ports. I discovered experimentally that
commanding more than 2 USB-serial devices causes garblage among
them,* so I wrote a script that only allows 2 simultaneous tunes to
happen---if there are 3 queued, the third waits until one of the first
two finishes, then gets to happen, etc. Works great. But I don't know
if your tuner is amenable to being controlled via an external script.


* No idea where in the stack this is happening, or if it's the USB
hub, or something else, and since it was very old code anyway I
figured it'll probably go away on an upgrade, so writing the script
was quick & easy.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On 12-04-08 02:34 AM, f-myth-users@media.mit.edu wrote:
> > Date: Sat, 07 Apr 2012 20:56:23 -0400
> > From: Mark Lord <mythtv@rtr.ca>
>
> > I should add that, even with the above workarounds, there is STILL an issue
> > when mythbackend starts up: If you have "multi-rec" enabled (more than one
> > virtual tuner per physical HVR-950Q), then the backend will have several
> > near-simultaneous "tune to initial channel" calls into the drivers.
>
> > This will cause tuner failure.
>
> I haven't been following this thread closely (not my hardware), but
> would it be possible to tune using an external tuner script that uses
> a mutex and some sleeps to avoid simultaneous tunes? I have no idea
> if the way multirec tunes this hardware is amenable to breaking it
> out externally like that.

Mythtv doesn't offer external channel change scripts for all digital tuners,
dunno if it has the option for the 950Q or not.

But the place for the mutex is somewhere in one of the drivers that manages
the 950Q, probably in the au0828 driver. At some point I suspect I'll go in
there and just fix the danged thing myself. But for now, disabling multirec
keeps it working well enough.

Cheers
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On 12-04-08 04:01 PM, Mark Lord wrote:
> On 12-04-08 02:34 AM, f-myth-users@media.mit.edu wrote:
>> > Date: Sat, 07 Apr 2012 20:56:23 -0400
>> > From: Mark Lord <mythtv@rtr.ca>
>>
>> > I should add that, even with the above workarounds, there is STILL an issue
>> > when mythbackend starts up: If you have "multi-rec" enabled (more than one
>> > virtual tuner per physical HVR-950Q), then the backend will have several
>> > near-simultaneous "tune to initial channel" calls into the drivers.
>>
>> > This will cause tuner failure.
>>
>> I haven't been following this thread closely (not my hardware), but
>> would it be possible to tune using an external tuner script that uses
>> a mutex and some sleeps to avoid simultaneous tunes? I have no idea
>> if the way multirec tunes this hardware is amenable to breaking it
>> out externally like that.
>
> Mythtv doesn't offer external channel change scripts for all digital tuners,
> dunno if it has the option for the 950Q or not.
>
> But the place for the mutex is somewhere in one of the drivers that manages
> the 950Q, probably in the au0828 driver. At some point I suspect I'll go in
> there and just fix the danged thing myself. But for now, disabling multirec
> keeps it working well enough.

Another related thing might be to fix mythbackend to NOT issue channel tuning
requests to virtual tuners when the physical tuner is already tuned appropriately.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On Apr 8, 2012, at 4:03 PM, Mark Lord wrote:

> On 12-04-08 04:01 PM, Mark Lord wrote:
>> On 12-04-08 02:34 AM, f-myth-users@media.mit.edu wrote:
>>>> Date: Sat, 07 Apr 2012 20:56:23 -0400
>>>> From: Mark Lord <mythtv@rtr.ca>
>>>
>>>> I should add that, even with the above workarounds, there is STILL an issue
>>>> when mythbackend starts up: If you have "multi-rec" enabled (more than one
>>>> virtual tuner per physical HVR-950Q), then the backend will have several
>>>> near-simultaneous "tune to initial channel" calls into the drivers.
>>>
>>>> This will cause tuner failure.
>>>
>>> I haven't been following this thread closely (not my hardware), but
>>> would it be possible to tune using an external tuner script that uses
>>> a mutex and some sleeps to avoid simultaneous tunes? I have no idea
>>> if the way multirec tunes this hardware is amenable to breaking it
>>> out externally like that.
>>
>> Mythtv doesn't offer external channel change scripts for all digital tuners,
>> dunno if it has the option for the 950Q or not.
>>
>> But the place for the mutex is somewhere in one of the drivers that manages
>> the 950Q, probably in the au0828 driver. At some point I suspect I'll go in
>> there and just fix the danged thing myself. But for now, disabling multirec
>> keeps it working well enough.
>
> Another related thing might be to fix mythbackend to NOT issue channel tuning
> requests to virtual tuners when the physical tuner is already tuned appropriately.


The way I was set up, I never enabled the digital side of the 950Q. I was only using the analog side. Also, I am using the 64 bit version.

I did try the 32 bit version, but had the same errors as below.. again only using the analog side, never adding the DVB ATSC tuner:


Apr 7 15:47:51 myth1204 mythbackend[1590]: I CoreContext v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0): SetInputAndFormat(1, NTSC) (v4l v2) input_switch: 0 mode_switch: 1



The messages below lead me to believe that maybe one of the ioctl calls in the v4l stuff may have had a null pointer passed to it.

Apr 7 15:47:50 myth1204 kernel: [ 18.216226] ------------[ cut here ]------------
Apr 7 15:47:50 myth1204 kernel: [ 18.216284] kernel BUG at /build/buildd/linux-3.2.0/drivers/media/video/au0828/au0828-video.c:895!
Apr 7 15:47:50 myth1204 kernel: [ 18.216357] invalid opcode: 0000 [#1] SMP
Apr 7 15:47:50 myth1204 kernel: [ 18.216394] CPU 0
Apr 7 15:47:50 myth1204 kernel: [ 18.216412] Modules linked in: xc5000 tuner au8522 ppdev snd_usb_audio snd_atiixp snd_ac97_codec ac97_bus snd_pcm snd_hwdep snd_usbmidi_lib snd_seq_midi snd_rawmidi snd_seq_midi_event au0828 psmouse dvb_core snd_seq videobuf_vmalloc videobuf_core tveeprom v4l2_common snd_timer snd_seq_device videodev serio_raw v4l2_compat_ioctl32 radeon edac_core snd k8temp edac_mce_amd soundcore ttm snd_page_alloc drm_kms_helper i2c_piix4 drm i2c_algo_bit nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc parport_pc mac_hid shpchp lp parport hid_apple usbhid hid 8139too usb_storage 8139cp pata_atiixp sata_sil floppy

Regards
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On 04/08/2012 03:43 PM, jrh wrote:
>
> On Apr 8, 2012, at 4:03 PM, Mark Lord wrote:
>
>> On 12-04-08 04:01 PM, Mark Lord wrote:
>>> On 12-04-08 02:34 AM, f-myth-users@media.mit.edu wrote:
>>>>> Date: Sat, 07 Apr 2012 20:56:23 -0400
>>>>> From: Mark Lord<mythtv@rtr.ca>
>>>>
>>>>> I should add that, even with the above workarounds, there is STILL an issue
>>>>> when mythbackend starts up: If you have "multi-rec" enabled (more than one
>>>>> virtual tuner per physical HVR-950Q), then the backend will have several
>>>>> near-simultaneous "tune to initial channel" calls into the drivers.
>>>>
>>>>> This will cause tuner failure.
>>>>
>>>> I haven't been following this thread closely (not my hardware), but
>>>> would it be possible to tune using an external tuner script that uses
>>>> a mutex and some sleeps to avoid simultaneous tunes? I have no idea
>>>> if the way multirec tunes this hardware is amenable to breaking it
>>>> out externally like that.
>>>
>>> Mythtv doesn't offer external channel change scripts for all digital tuners,
>>> dunno if it has the option for the 950Q or not.
>>>
>>> But the place for the mutex is somewhere in one of the drivers that manages
>>> the 950Q, probably in the au0828 driver. At some point I suspect I'll go in
>>> there and just fix the danged thing myself. But for now, disabling multirec
>>> keeps it working well enough.
>>
>> Another related thing might be to fix mythbackend to NOT issue channel tuning
>> requests to virtual tuners when the physical tuner is already tuned appropriately.
>
>
> The way I was set up, I never enabled the digital side of the 950Q. I was only using the analog side. Also, I am using the 64 bit version.
>
> I did try the 32 bit version, but had the same errors as below.. again only using the analog side, never adding the DVB ATSC tuner:
>
>
> Apr 7 15:47:51 myth1204 mythbackend[1590]: I CoreContext v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0): SetInputAndFormat(1, NTSC) (v4l v2) input_switch: 0 mode_switch: 1
>
>
>
> The messages below lead me to believe that maybe one of the ioctl calls in the v4l stuff may have had a null pointer passed to it.
>
> Apr 7 15:47:50 myth1204 kernel: [ 18.216226] ------------[ cut here ]------------
> Apr 7 15:47:50 myth1204 kernel: [ 18.216284] kernel BUG at /build/buildd/linux-3.2.0/drivers/media/video/au0828/au0828-video.c:895!
> Apr 7 15:47:50 myth1204 kernel: [ 18.216357] invalid opcode: 0000 [#1] SMP
> Apr 7 15:47:50 myth1204 kernel: [ 18.216394] CPU 0
> Apr 7 15:47:50 myth1204 kernel: [ 18.216412] Modules linked in: xc5000 tuner au8522 ppdev snd_usb_audio snd_atiixp snd_ac97_codec ac97_bus snd_pcm snd_hwdep snd_usbmidi_lib snd_seq_midi snd_rawmidi snd_seq_midi_event au0828 psmouse dvb_core snd_seq videobuf_vmalloc videobuf_core tveeprom v4l2_common snd_timer snd_seq_device videodev serio_raw v4l2_compat_ioctl32 radeon edac_core snd k8temp edac_mce_amd soundcore ttm snd_page_alloc drm_kms_helper i2c_piix4 drm i2c_algo_bit nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc parport_pc mac_hid shpchp lp parport hid_apple usbhid hid 8139too usb_storage 8139cp pata_atiixp sata_sil floppy

Please supply the rest of the bug message that tells what called res_free(). The
bug is because there has been an attempt to free something that seems not to
have been reserved.

Do you build your own kernels, or could you? If so, it will be easy to provide a
patch that prints a warning, but does not crash the kernel.

Larry


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On Apr 8, 2012, at 5:09 PM, Larry Finger wrote:

> On 04/08/2012 03:43 PM, jrh wrote:
>>
>> On Apr 8, 2012, at 4:03 PM, Mark Lord wrote:
>>
>>> On 12-04-08 04:01 PM, Mark Lord wrote:
>>>> On 12-04-08 02:34 AM, f-myth-users@media.mit.edu wrote:
>>>>>> Date: Sat, 07 Apr 2012 20:56:23 -0400
>>>>>> From: Mark Lord<mythtv@rtr.ca>
>>>>>
>>>>>> I should add that, even with the above workarounds, there is STILL an issue
>>>>>> when mythbackend starts up: If you have "multi-rec" enabled (more than one
>>>>>> virtual tuner per physical HVR-950Q), then the backend will have several
>>>>>> near-simultaneous "tune to initial channel" calls into the drivers.
>>>>>
>>>>>> This will cause tuner failure.
>>>>>
>>>>> I haven't been following this thread closely (not my hardware), but
>>>>> would it be possible to tune using an external tuner script that uses
>>>>> a mutex and some sleeps to avoid simultaneous tunes? I have no idea
>>>>> if the way multirec tunes this hardware is amenable to breaking it
>>>>> out externally like that.
>>>>
>>>> Mythtv doesn't offer external channel change scripts for all digital tuners,
>>>> dunno if it has the option for the 950Q or not.
>>>>
>>>> But the place for the mutex is somewhere in one of the drivers that manages
>>>> the 950Q, probably in the au0828 driver. At some point I suspect I'll go in
>>>> there and just fix the danged thing myself. But for now, disabling multirec
>>>> keeps it working well enough.
>>>
>>> Another related thing might be to fix mythbackend to NOT issue channel tuning
>>> requests to virtual tuners when the physical tuner is already tuned appropriately.
>>
>>
>> The way I was set up, I never enabled the digital side of the 950Q. I was only using the analog side. Also, I am using the 64 bit version.
>>
>> I did try the 32 bit version, but had the same errors as below.. again only using the analog side, never adding the DVB ATSC tuner:
>>
>>
>> Apr 7 15:47:51 myth1204 mythbackend[1590]: I CoreContext v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0): SetInputAndFormat(1, NTSC) (v4l v2) input_switch: 0 mode_switch: 1
>>
>>
>>
>> The messages below lead me to believe that maybe one of the ioctl calls in the v4l stuff may have had a null pointer passed to it.
>>
>> Apr 7 15:47:50 myth1204 kernel: [ 18.216226] ------------[ cut here ]------------
>> Apr 7 15:47:50 myth1204 kernel: [ 18.216284] kernel BUG at /build/buildd/linux-3.2.0/drivers/media/video/au0828/au0828-video.c:895!
>> Apr 7 15:47:50 myth1204 kernel: [ 18.216357] invalid opcode: 0000 [#1] SMP
>> Apr 7 15:47:50 myth1204 kernel: [ 18.216394] CPU 0
>> Apr 7 15:47:50 myth1204 kernel: [ 18.216412] Modules linked in: xc5000 tuner au8522 ppdev snd_usb_audio snd_atiixp snd_ac97_codec ac97_bus snd_pcm snd_hwdep snd_usbmidi_lib snd_seq_midi snd_rawmidi snd_seq_midi_event au0828 psmouse dvb_core snd_seq videobuf_vmalloc videobuf_core tveeprom v4l2_common snd_timer snd_seq_device videodev serio_raw v4l2_compat_ioctl32 radeon edac_core snd k8temp edac_mce_amd soundcore ttm snd_page_alloc drm_kms_helper i2c_piix4 drm i2c_algo_bit nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc parport_pc mac_hid shpchp lp parport hid_apple usbhid hid 8139too usb_storage 8139cp pata_atiixp sata_sil floppy
>
> Please supply the rest of the bug message that tells what called res_free(). The bug is because there has been an attempt to free something that seems not to have been reserved.
>
> Do you build your own kernels, or could you? If so, it will be easy to provide a patch that prints a warning, but does not crash the kernel.
>
> Larry
>
>


I haven't built a kernel since the 1.2 days. The kernel involved below is the stock kernel as of yesterday's ubuntu 12.04 updates.

Linux myth1204 3.2.0-22-generic #35-Ubuntu SMP Tue Apr 3 18:33:15 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

If I had a howto for building it, I could probably work out how. I do software development, just not at the kernel level.


Regards!

Here is the full kernel BUG trace:


Apr 7 15:47:50 myth1204 kernel: [ 18.216226] ------------[ cut here ]------------
Apr 7 15:47:50 myth1204 kernel: [ 18.216284] kernel BUG at /build/buildd/linux-3.2.0/drivers/media/video/au0828/au0828-video.c:895!
Apr 7 15:47:50 myth1204 kernel: [ 18.216357] invalid opcode: 0000 [#1] SMP
Apr 7 15:47:50 myth1204 kernel: [ 18.216394] CPU 0
Apr 7 15:47:50 myth1204 kernel: [ 18.216412] Modules linked in: xc5000 tuner au8522 ppdev snd_usb_audio snd_atiixp snd_ac97_codec ac97_bus snd_pcm snd_hwdep snd_usbmidi_lib snd_seq_midi snd_rawmidi snd_seq_midi_event au0828 psmouse dvb_core snd_seq videobuf_vmalloc videobuf_core tveeprom v4l2_common snd_timer snd_seq_device videodev serio_raw v4l2_compat_ioctl32 radeon edac_core snd k8temp edac_mce_amd soundcore ttm snd_page_alloc drm_kms_helper i2c_piix4 drm i2c_algo_bit nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc parport_pc mac_hid shpchp lp parport hid_apple usbhid hid 8139too usb_storage 8139cp pata_atiixp sata_sil floppy
Apr 7 15:47:50 myth1204 kernel: [ 18.216950]
Apr 7 15:47:50 myth1204 kernel: [ 18.216965] Pid: 1590, comm: mythbackend Not tainted 3.2.0-22-generic #35-Ubuntu Gateway /MS-7145
Apr 7 15:47:50 myth1204 kernel: [ 18.217042] RIP: 0010:[<ffffffffa03e810f>] [<ffffffffa03e810f>] res_free.isra.10+0x6f/0x90 [au0828]
Apr 7 15:47:50 myth1204 kernel: [ 18.217127] RSP: 0018:ffff880043181c08 EFLAGS: 00010202
Apr 7 15:47:50 myth1204 kernel: [ 18.217169] RAX: 0000000000000000 RBX: ffff880052a34000 RCX: 0000000000016ae1
Apr 7 15:47:50 myth1204 kernel: [ 18.217226] RDX: 0000000000000001 RSI: ffff880041920c08 RDI: ffff880052a34000
Apr 7 15:47:50 myth1204 kernel: [ 18.217282] RBP: ffff880043181c28 R08: ffffea000146b280 R09: ffffffff81494f17
Apr 7 15:47:50 myth1204 kernel: [ 18.217338] R10: dead000000200200 R11: 0000000000000001 R12: ffff880052a34000
Apr 7 15:47:50 myth1204 kernel: [ 18.217394] R13: ffff880041920c08 R14: 0000000000000001 R15: 0000000040045613
Apr 7 15:47:50 myth1204 kernel: [ 18.217451] FS: 00007f3432126780(0000) GS:ffff880057c00000(0000) knlGS:0000000000000000
Apr 7 15:47:50 myth1204 kernel: [ 18.217514] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Apr 7 15:47:50 myth1204 kernel: [ 18.217559] CR2: 00007f3431a11900 CR3: 000000005200f000 CR4: 00000000000006f0
Apr 7 15:47:50 myth1204 kernel: [ 18.217615] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Apr 7 15:47:50 myth1204 kernel: [ 18.217671] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Apr 7 15:47:50 myth1204 kernel: [ 18.217727] Process mythbackend (pid: 1590, threadinfo ffff880043180000, task ffff880051afade0)
Apr 7 15:47:50 myth1204 kernel: [ 18.217794] Stack:
Apr 7 15:47:50 myth1204 kernel: [ 18.217812] ffff880041920c00 ffff880052a34000 0000000000000000 ffff880052a34060
Apr 7 15:47:50 myth1204 kernel: [ 18.217877] ffff880043181c58 ffffffffa03e82a7 ffff880037134000 0000000000000000
Apr 7 15:47:50 myth1204 kernel: [ 18.217943] ffff880041832600 ffffffffa03ebe00 ffff880043181d68 ffffffffa036d7c0
Apr 7 15:47:50 myth1204 kernel: [ 18.218008] Call Trace:
Apr 7 15:47:50 myth1204 kernel: [ 18.218034] [<ffffffffa03e82a7>] vidioc_streamoff+0x177/0x1c0 [au0828]
Apr 7 15:47:50 myth1204 kernel: [ 18.218097] [<ffffffffa036d7c0>] __video_do_ioctl+0x1010/0x5560 [videodev]
Apr 7 15:47:50 myth1204 kernel: [ 18.218158] [<ffffffff81119a0e>] ? filemap_fault+0xee/0x3e0
Apr 7 15:47:50 myth1204 kernel: [ 18.218207] [<ffffffff8116de5b>] ? mem_cgroup_update_page_stat+0x2b/0x110
Apr 7 15:47:50 myth1204 kernel: [ 18.218263] [<ffffffff8111716a>] ? unlock_page+0x2a/0x40
Apr 7 15:47:50 myth1204 kernel: [ 18.218308] [<ffffffff8113a499>] ? __do_fault+0x439/0x550
Apr 7 15:47:50 myth1204 kernel: [ 18.218354] [<ffffffff815283c4>] ? do_sock_write.isra.10+0xd4/0xf0
Apr 7 15:47:50 myth1204 kernel: [ 18.218408] [<ffffffffa036c55c>] video_usercopy+0x27c/0x340 [videodev]
Apr 7 15:47:50 myth1204 kernel: [ 18.218464] [<ffffffffa036c7b0>] ? v4l2_norm_to_name+0x50/0x50 [videodev]
Apr 7 15:47:50 myth1204 kernel: [ 18.218519] [<ffffffff8113dbd8>] ? handle_mm_fault+0x1f8/0x350
Apr 7 15:47:50 myth1204 kernel: [ 18.218570] [<ffffffffa036c635>] video_ioctl2+0x15/0x20 [videodev]
Apr 7 15:47:50 myth1204 kernel: [ 18.218622] [<ffffffffa036b447>] v4l2_ioctl+0x147/0x150 [videodev]
Apr 7 15:47:50 myth1204 kernel: [ 18.218674] [<ffffffff81189cfa>] do_vfs_ioctl+0x8a/0x340
Apr 7 15:47:50 myth1204 kernel: [ 18.218720] [<ffffffff81659f1c>] ? __schedule+0x3cc/0x6f0
Apr 7 15:47:50 myth1204 kernel: [ 18.218764] [<ffffffff8118a041>] sys_ioctl+0x91/0xa0
Apr 7 15:47:50 myth1204 kernel: [ 18.218807] [<ffffffff81664a82>] system_call_fastpath+0x16/0x1b
Apr 7 15:47:50 myth1204 kernel: [ 18.218854] Code: 45 00 21 83 a4 0c 00 00 f6 05 ad 68 00 00 01 75 1c 4c 89 e7 e8 03 2e 27 e1 48 8b 5d e0 4c 8b 65 e8 4c 8b 6d f0 4c 8b 75 f8 c9 c3 <0f> 0b 44 89 f6 48 c7 c7 fd d5 3e a0 31 c0 e8 17 c0 25 e1 eb d1
Apr 7 15:47:50 myth1204 kernel: [ 18.219129] RIP [<ffffffffa03e810f>] res_free.isra.10+0x6f/0x90 [au0828]
Apr 7 15:47:50 myth1204 kernel: [ 18.219188] RSP <ffff880043181c08>
Apr 7 15:47:50 myth1204 kernel: [ 18.232124] ---[ end trace 6ad28ff06b0ab711 ]---



_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On 04/08/2012 04:38 PM, jrh wrote:
>
> On Apr 8, 2012, at 5:09 PM, Larry Finger wrote:
>
>> On 04/08/2012 03:43 PM, jrh wrote:
>>>
>>> On Apr 8, 2012, at 4:03 PM, Mark Lord wrote:
>>>
>>>> On 12-04-08 04:01 PM, Mark Lord wrote:
>>>>> On 12-04-08 02:34 AM, f-myth-users@media.mit.edu wrote:
>>>>>>> Date: Sat, 07 Apr 2012 20:56:23 -0400
>>>>>>> From: Mark Lord<mythtv@rtr.ca>
>>>>>>
>>>>>>> I should add that, even with the above workarounds, there is STILL an issue
>>>>>>> when mythbackend starts up: If you have "multi-rec" enabled (more than one
>>>>>>> virtual tuner per physical HVR-950Q), then the backend will have several
>>>>>>> near-simultaneous "tune to initial channel" calls into the drivers.
>>>>>>
>>>>>>> This will cause tuner failure.
>>>>>>
>>>>>> I haven't been following this thread closely (not my hardware), but
>>>>>> would it be possible to tune using an external tuner script that uses
>>>>>> a mutex and some sleeps to avoid simultaneous tunes? I have no idea
>>>>>> if the way multirec tunes this hardware is amenable to breaking it
>>>>>> out externally like that.
>>>>>
>>>>> Mythtv doesn't offer external channel change scripts for all digital tuners,
>>>>> dunno if it has the option for the 950Q or not.
>>>>>
>>>>> But the place for the mutex is somewhere in one of the drivers that manages
>>>>> the 950Q, probably in the au0828 driver. At some point I suspect I'll go in
>>>>> there and just fix the danged thing myself. But for now, disabling multirec
>>>>> keeps it working well enough.
>>>>
>>>> Another related thing might be to fix mythbackend to NOT issue channel tuning
>>>> requests to virtual tuners when the physical tuner is already tuned appropriately.
>>>
>>>
>>> The way I was set up, I never enabled the digital side of the 950Q. I was only using the analog side. Also, I am using the 64 bit version.
>>>
>>> I did try the 32 bit version, but had the same errors as below.. again only using the analog side, never adding the DVB ATSC tuner:
>>>
>>>
>>> Apr 7 15:47:51 myth1204 mythbackend[1590]: I CoreContext v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0): SetInputAndFormat(1, NTSC) (v4l v2) input_switch: 0 mode_switch: 1
>>>
>>>
>>>
>>> The messages below lead me to believe that maybe one of the ioctl calls in the v4l stuff may have had a null pointer passed to it.
>>>
>>> Apr 7 15:47:50 myth1204 kernel: [ 18.216226] ------------[ cut here ]------------
>>> Apr 7 15:47:50 myth1204 kernel: [ 18.216284] kernel BUG at /build/buildd/linux-3.2.0/drivers/media/video/au0828/au0828-video.c:895!
>>> Apr 7 15:47:50 myth1204 kernel: [ 18.216357] invalid opcode: 0000 [#1] SMP
>>> Apr 7 15:47:50 myth1204 kernel: [ 18.216394] CPU 0
>>> Apr 7 15:47:50 myth1204 kernel: [ 18.216412] Modules linked in: xc5000 tuner au8522 ppdev snd_usb_audio snd_atiixp snd_ac97_codec ac97_bus snd_pcm snd_hwdep snd_usbmidi_lib snd_seq_midi snd_rawmidi snd_seq_midi_event au0828 psmouse dvb_core snd_seq videobuf_vmalloc videobuf_core tveeprom v4l2_common snd_timer snd_seq_device videodev serio_raw v4l2_compat_ioctl32 radeon edac_core snd k8temp edac_mce_amd soundcore ttm snd_page_alloc drm_kms_helper i2c_piix4 drm i2c_algo_bit nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc parport_pc mac_hid shpchp lp parport hid_apple usbhid hid 8139too usb_storage 8139cp pata_atiixp sata_sil floppy
>>
>> Please supply the rest of the bug message that tells what called res_free(). The bug is because there has been an attempt to free something that seems not to have been reserved.
>>
>> Do you build your own kernels, or could you? If so, it will be easy to provide a patch that prints a warning, but does not crash the kernel.
>>
>> Larry
>>
>>
>
>
> I haven't built a kernel since the 1.2 days. The kernel involved below is the stock kernel as of yesterday's ubuntu 12.04 updates.
>
> Linux myth1204 3.2.0-22-generic #35-Ubuntu SMP Tue Apr 3 18:33:15 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>
> If I had a howto for building it, I could probably work out how. I do software development, just not at the kernel level.

It is pretty straight-forward. I do not use Ubuntu, but I have a Powerbook G4
that runs Mint 9, which is also Debian based and uses the same kind of setup.
The detailed description is at https://help.ubuntu.com/community/Kernel/Compile.
That page has not been updated recently, but the instructions for 10.04 look
correct for 12.04.

If you apply the attached patch, the system will echo some diagnostics, but will
not crash. All frees are for a single bit, thus it is safe to turn res_free()
into a no-op.

FYI, the crash comes from the statement 'res_free(fh, AU0828_RESOURCE_VIDEO);'
at roughly line 1700 of file drivers/media/video/au0828/au0828-video.c. I do not
understand why that bit is not being set.

This is clearly a kernel bug. Even if devices do not respond in the way the
driver expects, the driver should never crash the kernel with a BUG statement.
That action should be reserved for conditions that might cause irreparable
damage to the file system.

Good luck with this issue. I will submit a patch to the kernel and reference
this thread.

Larry
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On 04/08/2012 04:38 PM, jrh wrote:

As you have seen, someone did not like my patch. That frequently happens when
you try to touch a new area of the kernel. Thus, we need to find the real bug
before any patch is likely to be accepted.

To help debug the problem, I have prepared a new version of the patch. This one
will still remove the BUG_ON, but it will also dump the stack whenever the code
gets or frees AU0828_RESOURCE_VIDEO. I hope this shows where the imbalance occurs.

Larry
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On Apr 8, 2012, at 10:36 PM, Larry Finger wrote:

> On 04/08/2012 04:38 PM, jrh wrote:
>
> As you have seen, someone did not like my patch. That frequently happens when you try to touch a new area of the kernel. Thus, we need to find the real bug before any patch is likely to be accepted.
>
> To help debug the problem, I have prepared a new version of the patch. This one will still remove the BUG_ON, but it will also dump the stack whenever the code gets or frees AU0828_RESOURCE_VIDEO. I hope this shows where the imbalance occurs.
>
> Larry
> <au0828_fix.txt>

Larry, et al,

I replied to you via email with the logs from the above patch.

Hopefully it will shed some light.

Regards!

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On 04/09/2012 06:01 PM, jrh wrote:
>
> On Apr 8, 2012, at 10:36 PM, Larry Finger wrote:
>
>> On 04/08/2012 04:38 PM, jrh wrote:
>>
>> As you have seen, someone did not like my patch. That frequently happens when you try to touch a new area of the kernel. Thus, we need to find the real bug before any patch is likely to be accepted.
>>
>> To help debug the problem, I have prepared a new version of the patch. This one will still remove the BUG_ON, but it will also dump the stack whenever the code gets or frees AU0828_RESOURCE_VIDEO. I hope this shows where the imbalance occurs.
>>
>> Larry
>> <au0828_fix.txt>
>
> Larry, et al,
>
> I replied to you via email with the logs from the above patch.
>
> Hopefully it will shed some light.
>
> Regards!

I am not sure why it happens, but AU0828_RESOURCE_VIDEO is freed 3 times in the
segment you posted and never assigned. It will take a while, but I will see if I
can prepare a patch to help us.

I'm glad you were able to compile the revised patch. I hope we have as much
success in making the driver work.

Larry


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On Apr 9, 2012, at 7:48 PM, Larry Finger wrote:

> On 04/09/2012 06:01 PM, jrh wrote:
>>
>> On Apr 8, 2012, at 10:36 PM, Larry Finger wrote:
>>
>>> On 04/08/2012 04:38 PM, jrh wrote:
>>>
>>> As you have seen, someone did not like my patch. That frequently happens when you try to touch a new area of the kernel. Thus, we need to find the real bug before any patch is likely to be accepted.
>>>
>>> To help debug the problem, I have prepared a new version of the patch. This one will still remove the BUG_ON, but it will also dump the stack whenever the code gets or frees AU0828_RESOURCE_VIDEO. I hope this shows where the imbalance occurs.
>>>
>>> Larry
>>> <au0828_fix.txt>
>>
>> Larry, et al,
>>
>> I replied to you via email with the logs from the above patch.
>>
>> Hopefully it will shed some light.
>>
>> Regards!
>
> I am not sure why it happens, but AU0828_RESOURCE_VIDEO is freed 3 times in the segment you posted and never assigned. It will take a while, but I will see if I can prepare a patch to help us.
>
> I'm glad you were able to compile the revised patch. I hope we have as much success in making the driver work.
>
> Larry
>
>

Sounds like a plan!


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On Wed, Apr 11, 2012 at 9:36 AM, jrh <jharbestonus@gmail.com> wrote:
>
> On Apr 9, 2012, at 7:48 PM, Larry Finger wrote:
>
>> On 04/09/2012 06:01 PM, jrh wrote:
>>>
>>> On Apr 8, 2012, at 10:36 PM, Larry Finger wrote:
>>>
>>>> On 04/08/2012 04:38 PM, jrh wrote:
>>>>
>>>> As you have seen, someone did not like my patch. That frequently happens when you try to touch a new area of the kernel. Thus, we need to find the real bug before any patch is likely to be accepted.
>>>>
>>>> To help debug the problem, I have prepared a new version of the patch. This one will still remove the BUG_ON, but it will also dump the stack whenever the code gets or frees AU0828_RESOURCE_VIDEO. I hope this shows where the imbalance occurs.
>>>>
>>>> Larry
>>>> <au0828_fix.txt>
>>>
>>> Larry, et al,
>>>
>>> I replied to you via email with the logs from the above patch.
>>>
>>> Hopefully it will shed some light.
>>>
>>> Regards!
>>
>> I am not sure why it happens, but AU0828_RESOURCE_VIDEO is freed 3 times in the segment you posted and never assigned. It will take a while, but I will see if I can prepare a patch to help us.
>>
>> I'm glad you were able to compile the revised patch. I hope we have as much success in making the driver work.
>>
>> Larry
>>
>>
>
> Sounds like a plan!

FYI: the problem in the au0828 driver has been identified and a fix
is pending to go upstream.

http://git.kernellabs.com/?p=dheitmueller/cx23885_fixes.git;a=commit;h=226d020ff1b944f115cb075766cdeb29938431b0

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On Jun 27, 2012, at 11:27 PM, Devin Heitmueller wrote:

> On Wed, Apr 11, 2012 at 9:36 AM, jrh <jharbestonus@gmail.com> wrote:
>>
>> On Apr 9, 2012, at 7:48 PM, Larry Finger wrote:
>>
>>> On 04/09/2012 06:01 PM, jrh wrote:
>>>>
>>>> On Apr 8, 2012, at 10:36 PM, Larry Finger wrote:
>>>>
>>>>> On 04/08/2012 04:38 PM, jrh wrote:
>>>>>
>>>>> As you have seen, someone did not like my patch. That frequently happens when you try to touch a new area of the kernel. Thus, we need to find the real bug before any patch is likely to be accepted.
>>>>>
>>>>> To help debug the problem, I have prepared a new version of the patch. This one will still remove the BUG_ON, but it will also dump the stack whenever the code gets or frees AU0828_RESOURCE_VIDEO. I hope this shows where the imbalance occurs.
>>>>>
>>>>> Larry
>>>>> <au0828_fix.txt>
>>>>
>>>> Larry, et al,
>>>>
>>>> I replied to you via email with the logs from the above patch.
>>>>
>>>> Hopefully it will shed some light.
>>>>
>>>> Regards!
>>>
>>> I am not sure why it happens, but AU0828_RESOURCE_VIDEO is freed 3 times in the segment you posted and never assigned. It will take a while, but I will see if I can prepare a patch to help us.
>>>
>>> I'm glad you were able to compile the revised patch. I hope we have as much success in making the driver work.
>>>
>>> Larry
>>>
>>>
>>
>> Sounds like a plan!
>
> FYI: the problem in the au0828 driver has been identified and a fix
> is pending to go upstream.
>
> http://git.kernellabs.com/?p=dheitmueller/cx23885_fixes.git;a=commit;h=226d020ff1b944f115cb075766cdeb29938431b0
>
> Devin


Thank you! Any idea if it will be backported to kernel 3.2 and thenmigrated to ubuntu 12.04? I know, thats asking alot!

Regards!




_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Kernel Crash when starting up in au0828-video.c line 895 [ In reply to ]
On Thu, Jun 28, 2012 at 12:45 PM, jrh <jharbestonus@gmail.com> wrote:
> Thank you! Any idea if it will be backported to kernel 3.2 and thenmigrated to ubuntu 12.04? I know, thats asking alot!
>
> Regards!

It's a two line change, so I cannot imagine why it couldn't be
submitted to stable. That said though, I typically only work on the
trunk, so if somebody wants to send it to stable they are welcome to.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users