Re: [pvrusb2] [PATCH] pvrusb2: Fix oops on tear-down when radio support is not present

[Gary Buhrmaster]

On Wed, Nov 20, 2019 at 5:13 PM Jan Ceuleers  wrote:

> But if Mike tags the fix for stable (and if that tag is accepted) then
> it will be backported to stable kernels as well.

True enough, I was just responding to the question
about the mainline kernel.

For that matter, if you are using a distro kernel,
you may be able to get the packager to apply
a local patch to their builds (although not entirely
likely for something that impacts single digits of
users of the distro).
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] [PATCH] pvrusb2: Fix oops on tear-down when radio support is not present

[Gary Buhrmaster]

On Tue, Nov 19, 2019 at 9:59 PM Diego Rivera  wrote:
>
> Hey! Any news on the patch making it into mainline? And how can I track 
> if/when it's been integrated
> to the core kernel?

Just to set some expectations, I think it
clearly it is not going in to 5.4, and I would
not be surprised it misses 5.5 (pull requests
are already being accepted, although as a
targeted fix, it might get pulled during the
rc fix cycle), so 5.6 could be the earliest
for mainline.  5.5 is expected (around)
March/April 2020, and 5.6 probably around
June/July 2020.  As to when any specific
distro will repackage the kernel that
includes the fix, well, that opens up
another can of bad estimation.
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] Noise

[Gary Buhrmaster]

On Sun, Apr 21, 2019 at 9:27 AM Jan Ceuleers  wrote:

> The audio defect is a clearly audible repetitive "whistling" noise, with
> a periodicity of about 1 second. This noise is not present on the audio
> signal that goes into the PVR.

Just on principal, check the power supplies
(swap between the units that work and one
of the STB ones).  And also check for ground
loops between the PC, the PVR and the
STB, which can result in all sorts of audio
artifacts (just go over the the audiophile
forums and discuss ground issues and
whines and whistles).
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device

[Gary Buhrmaster]

On Sat, Mar 16, 2019 at 5:52 PM Jan Ceuleers  wrote:

> The third most common issue is USB connectors needing reseating.

One can discuss order, but kernel USB drivers
(which change at almost every kernel release)
are also a common issue, but in the case of
the USB drivers and the cables I consider those
cases as being more that the HVR-195xs is a
victim, not directly responsible.  But they can
all result in the same symptom of hangs or
other artifacts, so yes, they should be included.
And to add to that, sometimes moving the cable
to a different PC port solves issues (because the
sharing that is happening elsewhere is not working
quite right).  The joys of layering.
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device

[Gary Buhrmaster]

On Sat, Mar 16, 2019 at 4:06 PM Diego Rivera  wrote:
>  Every so often one of the devices ceases to function and just "dies".

It has been a long long time since I touched one of
those, but I would always look at the root causes
of the hangs first.

The two most common issues with the HVR-1950
that I ran into is that it can overheat (and hang)
and the power supply can be going bad (and the
device hangs).

For the first, I found avoiding stacking them (which
I had been doing) was sufficient to avoid overheating
(although your location may vary and you may need
active airflow), and for the second, I replaced the
power adapter.  FWIW, I don't think any of the
power adapters that I ever got from Hauppauge
were of good quality, and I usually just replaced them
pro-actively with a high quality switching supply
(at the time I had a local source of delta branded
oem switching supplies that were dirt cheap and
new in box).  Note that you typically can't just use
a VOM on the adapter to test, you have to put the
adapter under load and look at the ripple.  Usually
just easier to replace the power supply.

And none of this was actually in response to
the question you asked...
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] WinTV HVR-1975 (with official drivers) failing to load firmware

[Gary Buhrmaster]

On Sun, Sep 18, 2016 at 2:30 AM,   wrote:
>
> Ian:
>
> Wait a second.  Now I'm confused.  Are you or are not using the pvrusb2
> driver?  The error you quoted was definitely phrasing that would have
> come from the pvrusb2 driver.  If you're using something else entirely
> different I'd be VERY curious know why the resemblence.
>
> Also - to others here - I'm confused about something else.  This sounds
> like we're talking about 3 drivers:
>
> 1. The pvrusb2 driver, in the kernel mainline.
>
> 2. Something on the Hauppauge web site, apparently freely accessible.
>
> 3. Something from Hauppauge that can't be acquired without an NDA.
>
> Is this correct?  Anyone, chime in.

I think part of the issue is that Hauppauge has many
different devices.

For (3), there have been rumors for years that Hauppauge
either had (or re-licensed from one of the few competent
vendors for such codes) various drivers for their devices
(some of which have nothing to do with the pvrusb2 series)
to support vendors who needed official support (not only
in Linux, but other OS's).  At one point a NDA license
was needed for any of their new chipset design devices
(and presumably payment of fees).

Hauppauge had posted some drivers for some of their
devices which clearly had proprietary licenses in the
headers.  When I saw such a license, I stopped reading
the code (and have not gone back to look at anything
newer).

At some point Hauppauge offered their "freely
downloadable" patch for some (different?) set of devices,
which from other discussions is not merge-able upstream
(at least not in the current state; I have no idea about
whether licensing is part of that).

Lastly, the 1975 is more like two devices than one.
It has both the ATSC and DVB demods on board,
and likely (although I have no personal experience)
needs two sets of firmware blobs (one for each
demod)?
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] WinTV HVR-1975 (with official drivers) failing to load firmware

[Gary Buhrmaster]

On Mon, Sep 12, 2016 at 10:35 PM,   wrote:

> I know basically nothing about the HVR-1975.

As I understand it, the HVR-1975 is essentially
a "one size fits all" redesign of the basic HVR-1900
and the HVR-1950/1955 which is compatible with
both US and DVB standards [mostly for commercial
embedded solutions that want one SKU for either
location (it actually contains two demods)].

Hauppuage (last I knew) reportedly offered an out
of tree driver on their website for the HVR-1975,
but (again, last I knew) it was never submitted
upstream (it was reported some of the code
included non-GPL copyright, and I presume
it could not be re-licensed).
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] HVR-1950 encoder appears to be stuck error messages

[Gary Buhrmaster]

On Wed, Apr 1, 2015 at 4:27 AM, J Miller gajs-f...@dea.spamcon.org wrote:
 Hi. This list seems to be somewhat dead, but when I try searching on my
 issue, results from this list always come up. So it seems worth a try to ask
 for some help here.
.
 [  411.124297] pvrusb2: ***WARNING*** device's encoder appears to be stuck
 (status=0x0003)
 [  411.124304] pvrusb2: Encoder command: 0x81
 [  411.124308] pvrusb2: Giving up on command.  This is normally recovered
 via a firmware reload and re-initialization; concern is only warranted if
 this happens repeatedly and rapidly.

FWIW, in my experience, the HVR-1950 had two common
issues.  In no particular order, the first is that they were
very susceptible to heat issues.  They need to be kept
cool (i.e. do not, as I did at one point, place one on top
of the other, and make sure the (likely minimally useful)
tiny holes on the bottom of the box have access to air).
When the device gets too hot, you see random failures.
The second issue is that the supplied power bricks tend
to go bad early (and often), and have the initial failure
mode of high ripple (I did not break any open, but I presume
the caps were either not properly rates for the temps,
failed early, or were part of the bad caps years),
which generate random failures.

Of course, your experience will vary, and you might
never experience either of these issues.  Just something
to keep in the back of your mind for the future.
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] Hauppauge HVR-1950 Not Locking Signals Less Than 60%?

[Gary Buhrmaster]

On Mon, Jan 26, 2015 at 11:56 PM, Roger rogerx@gmail.com wrote:

 Amazing.  Results almost the opposite of what one would expect!  But to those
 that understand what is going on here, easily explained but still easily
 over-looked.

Not at all surprising.  The Hauppauge devices tend to be
cost optimized solutions without all the well designed
(pre)amp front end that a higher end TV has to insure
that it can properly handle both low and high signal levels.
Those without the (expensive) RF meters have to just
try a few things to see how it works for them.

And while I would have pulled a pad (attenuator) out of the
toolbox rather than using a splitter, the result is about the
same.

Glad to hear you got it all working.
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] WinTV USB2/Tv-Viewer question

[Gary Buhrmaster]

On Wed, Aug 28, 2013 at 7:50 PM, Lorne Shantz lorne_sha...@yahoo.com wrote:
 Hmmm... so you think it is drawing more power to pull the signal from the vcr 
 machine? It is rock solid (it seems) when capturing TV signal, or watching tv.

Well, it really should not (be significantly different), but my first reaction
to flaky is always to check the power (source).  It is an old habit
from long ago lessons.

Gary
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] Re%3A%20%5Bpvrusb2%5D%20No%20data%20from%20HVR-1900%20encoderIn-Reply-To=%3C1308471515.2019.6.camel%40tyst%3E

[Gary Buhrmaster]

On Sat, Jul 13, 2013 at 6:23 PM, Roger rogerx@gmail.com wrote:
 A power volt/amp meter might suffice, because if the power supply is bad it is
 going to likely show fluctuations within either amperage or voltage.

Maybe, but

 The only thing you're likely omitting are intermittent spikes or unsufficient
 power.

The cheap (Hauppauge probably saved a few cents on each power supply)
power supplies usually end up with extremely high ripple voltages under load
due to bad caps/failed caps, although I will agree that occasionally your
bad house mains might be a contributor.  Most of the devices that I have
disassembled show the typical expanded cap that can either be caused by
a bad batch, or, by not using a high enough temperature rated cap into the
(usually sealed) block.  It can get hot in there!  In any case, if you have the
proper power analyzer (with logging) inline you can detect such failures, but
your typical VOM may not be sufficient.  As I said previously, it is often just
easier to try it with a new (high quality, if possible) power supply
than to do
the detective work.  In my particular case, I can go find a high
quality (switching)
power supply in the new-to-me piles at the local electronics surplus
stores.  it solved the problem in two different HVR-1950's for me (and while
I only opened up one of those failing supplies, the cap was blown; I had
another cable modem power supply with a blown cap, and a switch with
blown caps, and I do not know how many PC power supplies with blown caps).

As I said previously, replacing the power supply with something known
good is an easy first check.

Gary
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] Re%3A%20%5Bpvrusb2%5D%20No%20data%20from%20HVR-1900%20encoderIn-Reply-To=%3C1308471515.2019.6.camel%40tyst%3E

[Gary Buhrmaster]

On Fri, Jul 12, 2013 at 8:24 PM, Jan Brouwer j...@brewsky.nl wrote:
...
 My unit does get pretty hot... I didn't think of cooling it before, so
 maybe that would do the trick!

Certain Hauppauge devices have a history of getting hot
and resetting.  Certain Hauppauge devices also have a
history of having power supplies going (partially) bad
(especially if they are a few years old).  Either can cause
random crashes.  Since it is (usually) the easiest to
test (unless your computer is next to the refrigerator :-),
I always swap out the power supply first.

Gary
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] Some install guidance on WinTV PVR2 USB

[Gary Buhrmaster]

On Wed, Jun 12, 2013 at 8:52 PM, Lorne Shantz lorne_sha...@yahoo.com wrote:
 Dang, if I had a memory I'd be dangerous. It looks like something is missing, 
 but here is what logs:

 2013-06-12T13:50:38.048300-07:00 tigger2 kernel: [ 2159.404890] pvrusb2: 
 ***WARNING*** Device fx2 controller firmware seems to be missing.

In some distro's (include opensuse, as I recall) the ivtv-firmware package
will contain your firmware.

Gary
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] Best MPEG2 Stream Editor for Hauppauge Created MPEG2 Files

[Gary Buhrmaster]

On Wed, Dec 26, 2012 at 6:01 PM, Roger rogerx@gmail.com wrote:
 BTW, I'm not sure if I verified, but avidemux-2.6.1 works and the Hauppuage
 audio/video is now in sync while playing.

May I suggest the best place to learn about avidemux is at
the main site:  http://fixounet.free.fr/avidemux/ and/or
their wiki:  http://www.avidemux.org/admWiki/doku.php
and discussions of avidemux capabilities are likely to gain more
interaction at their forums: http://www.avidemux.org/admForum/
and to leave the pvrusb2 maillist to pvrusb2 driver discussions.

Thanks.

Gary
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] My tuners occasionally get stuck

[Gary Buhrmaster]

On Sun, Mar 25, 2012 at 19:46, Mike Isely is...@isely.net wrote:

 Another idea - if you have a portable USB hard drive, plug it in as well
 and run a repeated massive tar command to generate large amounts of I/O.
 When you next get a failure, does the hard drive survive while the
 tuners still fail?  If the hard drive fails too, then you've just
 exonerated the entire V4L subsystem and I'd then be looking really hard
 at the USB stack.

The op mentioned that he also had an APC UPS device
that hung at the same time (although if I interpreted
the posting correctly, that one recovered after the
machine reboot; maybe it was not as confused and
dazed as the pvrusb devices and was able to be
reinitialized at boot).

AFAIK the APC device does not use the V4L subsystem
(although you can never tell, APC is working at doing
entire DC management, and maybe this one takes
video/pictures of the site).

So, I am sticking with my WAG.

Gary
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] My tuners occasionally get stuck

[Gary Buhrmaster]

On Wed, Mar 21, 2012 at 06:12, Jan Ceuleers jan.ceule...@gmail.com wrote:
 Hi there.

 Does anyone have any idea as to how to begin debugging this?

conjecture

Almost certainly a kernel usb issue.  The 1900s and the
APC device are likely victims, not the cause.  These types
of bug reports (the 'clear tt' ones) with usb devices have a
tendency to reoccur on some irregular basis as the usb
subsystem in the kernel gets improved.  Usually the
problem is patched in the next kernel rev (because others
have reported it), although sometimes you have to do the
git bisect to find the patch that was special to get it fixed.

I would look to the forums that discuss Ubuntu for
assistance to find a recommended kernel that has
been reported to work with your hardware.

It seems to be an unfortunate reality that the hauppauge
devices can end up getting hung if you poke enough
bad usb data at them long enough that requires a power
cycle to reset (this happened to me on windows years
ago too, and I presume it is still true today).  My guess
is that after you reboot your linux system, the kernel is
not able to detect or enumerate the hauppauge devices
correctly (I have seen that on my current linux system
after certain power opportunities that PGE have provided),
so that the driver is unable to reset a device it does not have
access to.  It might be useful to capture the boot messages
during a normal boot and a boot in which the devices
are not started, to see what messages the driver
emits.  It is always possible that some initialization code(s)
could be improved.  But the root cause is probably still
the kernel usb subsystem.  Find a kernel that works, and
you are not likely to see the problems in the first place.

/conjecture

Gary
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] Looking for dvb-fe-tda10048-1.0.fw firmware

[Gary Buhrmaster]

On Thu, Feb 2, 2012 at 01:19, Roger rogerx@gmail.com wrote:
...
 I'm sure the majority of the public is also not aware of it at this point.

I would agree that the majority of the public is not aware of
what the script can do.  Most of the public is not aware of
the script period.  That said, when I pulled down the script
I read through it, and was able to determine its capabilities
with little effort(*) (I even emailed some new offsets for a new
version of the driver from Hauppauge (same firmwire, just
new offsets as I recall) to Mike, as the script requests).

The script really is a good work by Mike (as are his
other works).

Gary

(*) I tend to quickly scan scripts I download from the
Intertubes to verify that what they say they do
seems to be approximately what they seem to be
trying to do.
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] Looking for dvb-fe-tda10048-1.0.fw firmware

[Gary Buhrmaster]

On Thu, Feb 2, 2012 at 03:08, Mike Isely is...@isely.net wrote:

 I will be sending out an updated fwextract.pl with Gary's additional
 offsets.  Plus I will integrate a small patch he sent that allows the
 script to run in a Windows environment as well (cygwin hosted? Active
 Perl?).

I do not remember sending a patch for Windows.
I suspect it was someone else who contributed that.
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] Kernel oops in pvrusb2 driver

[Gary Buhrmaster]

On Tue, Jan 10, 2012 at 19:06, Mike Isely is...@isely.net wrote:

 Well even if it's unlikely, a kernel oops should still be chased.  Was
 this on an SMP system?

Yes, i5-2500, 4 CPUs.

 And I assume you were running the pvrusb2 driver
 that is part of the 3.1.7 kernel source tree (as opposed to compiling a
 separate driver)?

Correct.  I can test with additional debugging options, or
compile driver code if that is helpful.  I figured a reliable
reproducer was a good first step in the process...

Gary
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] failed to grab control of dtv input (code=-1)

[Gary Buhrmaster]

On Tue, Jan 10, 2012 at 19:11, Mike Isely is...@isely.net wrote:
 ... I can look into serializing this better.

Thanks for looking.  I had been occasionally receiving the
failed to grab error for quite some time, very infrequently,
at boot time on my production mythtv system, which
caused the card init on the DVB side to fail.  Even though
I never used the analog side, and AFAIK nothing else
should have tried to open the analog device, I saw what
I thought was a initialization race in the code on the DVB
side (in the code you mentioned above) as it tried to set
the input modes, so I thought I would try to provoke it
by forcing the analog side to open.  I figured a reliable
reproducer was the first step in debugging.  This case
seemed to be a reliable reproducer (I still have no idea
why something would open /dev/videox during init, but
when I added in systemd device unit initialization for all
udev video4linux subsytem (for other v4l devices), I
seemed to increase the frequency of the failed to grab
messages so I decided to try to create a reproducer).

If needed I can test with different debugging options,
or can compile (revised) driver code.

Thanks for any work you do.

And thanks for the driver itself!

Gary
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Re: [pvrusb2] failed to grab control of dtv input (code=-1)

[Gary Buhrmaster]

private reply

On Tue, Jan 10, 2012 at 22:03, Roger rogerx@gmail.com wrote:
 On Tue, Jan 10, 2012 at 07:49:42PM +, Gary Buhrmaster wrote:
On Tue, Jan 10, 2012 at 19:11, Mike Isely is...@isely.net wrote:
 ... I can look into serializing this better.

Thanks for looking.  I had been occasionally receiving the
failed to grab error for quite some time, very infrequently,

 Ditto here.  Can't remember the exact error stated within syslog, but this
 scenario describing failing to initialize /dev/dvb does fit.

Yes, I tend to not report things until I can create a mostly
reliable reproducer (I have been on the other end of the such
reports for long enough to know that if I can not reproduce
the failure, I am never going to feel I can properly validate
a fix).

I see in one of the TODO lists
  http://www.isely.net/svn/pvrusb2/tags/mci-rel-20100424/doc/notes.txt
the comment:

   o What is this all about during initialization of HVR-1950: 
  pvrusb2: failed to grab control of dtv input (code=-1) - this
  seems to randomly happen.

Sounds like Mike understands the issue, and now he just
needs to be able to find the time to address it.
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

[pvrusb2] Kernel oops in pvrusb2 driver

[Gary Buhrmaster]

While admittedly abusive (I was trying to test something else),
there may be a race in the pvrusb2 driver (I can file a fedora
bugzilla request if desired).

Environment: Fedora 16, 64 bit, 3.1.7 kernel, HVR-1950
How reproducable: 100% (well, 4 out of 4 test cases).
Importance: Low (I doubt anyone is going to be so abusive)
Result: kernel oops

Scenerio:

running a perl program doing a
   while(1) { sysopen(F,/dev/video0,O_RDWR); close(F);}
(the v4l device was instantiated as /dev/video0),
I unplugged the usb cable, and received this oops:


kernel oops:

[89096.369019] usb 2-1.8: USB disconnect, device number 5
[89096.369082] pvrusb2: Device being rendered inoperable
[89096.369154] BUG: unable to handle kernel NULL pointer dereference
at 0020
[89096.369193] pvrusb2: unregistered device video0 [mpeg]
[89096.370522] IP: [815aea38] klist_put+0x28/0xa0
[89096.371208] PGD 0
[89096.371893] Oops:  [#1] SMP
[89096.372560] CPU 1
[89096.372568] Modules linked in: s5h1411 tda18271 tda8290 tuner
cx25840 pvrusb2 dvb_core cx2341x tveeprom v4l2_common videodev media
v4l2_compat_ioctl32 tcp_lp fuse lockd bnep bluetooth rfkill
ip6t_REJECT nf_conntrack_ipv6 nf_conntrack_ipv4 nf_defrag_ipv6
w83627ehf hwmon_vid coretemp nf_defrag_ipv4 ip6table_filter xt_state
nf_conntrack ip6_tables sunrpc snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq
snd_seq_device snd_pcm snd_timer snd microcode iTCO_wdt
iTCO_vendor_support i2c_i801 e1000e soundcore snd_page_alloc serio_raw
uinput firewire_ohci firewire_core pata_acpi raid1 crc_itu_t
ata_generic megaraid_sas i915 drm_kms_helper drm i2c_algo_bit i2c_core
video [last unloaded: scsi_wait_scan]
[89096.377496]
[89096.378207] Pid: 19922, comm: pvrusb2-context Not tainted
3.1.7-1.fc16.x86_64 #1  /DQ67SW
[89096.378942] RIP: 0010:[815aea38]  [815aea38]
klist_put+0x28/0xa0
[89096.379690] RSP: 0018:8803a43ffd60  EFLAGS: 00010246
[89096.380444] RAX: 005b RBX:  RCX: 000205b8
[89096.381202] RDX: 81a9dd30 RSI: 0001 RDI: 
[89096.381932] RBP: 8803a43ffd80 R08: 81a9dd30 R09: 812aa582
[89096.382683] R10: 000a R11: 0001 R12: 8803df23f9e8
[89096.383439] R13: 8803f0c62900 R14: 0001 R15: 880407537888
[89096.384222] FS:  () GS:88043e28()
knlGS:
[89096.384968] CS:  0010 DS:  ES:  CR0: 8005003b
[89096.385763] CR2: 0020 CR3: 00040d207000 CR4: 000406e0
[89096.386549] DR0:  DR1:  DR2: 
[89096.387342] DR3:  DR6: 0ff0 DR7: 0400
[89096.388122] Process pvrusb2-context (pid: 19922, threadinfo
8803a43fe000, task 8803f0e7ae60)
[89096.388900] Stack:
[89096.389694]  8803f0e7ae60 8803df23f9e8 8803f0c62900
8803931c7098
[89096.390502]  8803a43ffd90 815aeaee 8803a43ffde0
815aec08
[89096.391293]  81a9dd30 81a9dd30 8803df23f9e8
8803f0e7ae60
[89096.392091] Call Trace:
[89096.392856]  [815aeaee] klist_del+0xe/0x10
[89096.393653]  [815aec08] klist_remove+0x58/0xa0
[89096.394451]  [81388545] device_move+0x95/0x2a0
[89096.395270]  [a03b3bf3]
pvr2_v4l2_dev_disassociate_parent+0x33/0x40 [pvrusb2]
[89096.396081]  [a03b4041]
pvr2_v4l2_internal_check+0x31/0x50 [pvrusb2]
[89096.396866]  [a03b68aa]
pvr2_context_thread_func+0xda/0x330 [pvrusb2]
[89096.397678]  [8108e6b0] ? remove_wait_queue+0x50/0x50
[89096.398488]  [a03b67d0] ? pvr2_context_destroy+0xe0/0xe0 [pvrusb2]
[89096.399303]  [8108de0c] kthread+0x8c/0xa0
[89096.400115]  [815deef4] kernel_thread_helper+0x4/0x10
[89096.400902]  [8108dd80] ? kthread_worker_fn+0x190/0x190
[89096.401750]  [815deef0] ? gs_change+0x13/0x13
[89096.402582] Code: 00 00 00 55 48 89 e5 48 83 ec 20 4c 89 65 e8 4c
89 75 f8 49 89 fc 48 89 5d e0 4c 89 6d f0 41 89 f6 48 8b 1f 48 83 e3
fe 48 89 df 4c 8b 6b 20 e8 2f 66 02 00 45 84 f6 74 10 49 8b 04 24 a8
01 75
[89096.40] RIP  [815aea38] klist_put+0x28/0xa0
[89096.405330]  RSP 8803a43ffd60
[89096.406193] CR2: 0020
[89096.689336] ---[ end trace 22154e4d0f29d294 ]---
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2