[pvrusb2] Kernel oops?

[Mike Isely]

In addition to turning on SANITY_CHECK_BUFFERS as previously described, I
have a question for you as well.

The other report of this oops was coincident with a power glitch to the
PVR USB2 hardware.  I think he said his A/C compressor turned on at the
same instant that mplayer shut down and he got this oops.  That would
suggest that something went wrong with the hardware during a USB
transaction which might have caused the USB core to misbehave and set the
driver up for this failure.

Do you remember noticing any kind of power line sag or power glitch when
this took place?  Even if you didn't, try to observe if there might be a
correlation.

So far I've been completely unable to reproduce this problem, but I've got
pretty clean power here.  And right now I'm not sure how I can set up a
condition to duplicate such a glitch without risking damage to my tuner
hardware :-( (I've already tried just power cycling the device while it is
streaming and so far - using the 20050911 snapshot - everything has shut
down cleanly each time.)  I'd like to understand what the USB core is
doing in this case so I can construct a defense against it, if that is in
fact what is happening here.

  -Mike


On Wed, 14 Sep 2005, Mike Isely wrote:

> On Wed, 14 Sep 2005, Andreas Korinek wrote:
>
> > On Tuesday 13 September 2005 22:22, Mike Isely wrote:
> > > Can you please post entries from your system log leading up to this?
> > > Thanks.
> > >
> > > Obviously the oops involved the driver, but it would be far more helpful
> > > to see the circumstances as well.
> > >
> > > If you can reproduce the crash at will and isolate the key actions that
> > > lead to it, that would also be quite helpful.
> >
> > This is the full log, my kernel is 2.6.13.1 with Gentoo patchset. I could not
> > reproduce this so far, it just happened after running xawtv for a while.
> >
>
> OK, this helps a lot.  See further:
>
> >
> > Sep 13 21:54:13 [kernel] pvrusb2 subsys mask changing
> > 0x7fff:0xffffffffffffffff from 0x7ff to 0x7fff
> > Sep 13 21:54:13 [kernel] pvrusb2 /*---TRACE_CTL----*/ pvr2_encoder_configure
> > Sep 13 21:54:13 [kernel] pvrusb2 /*---TRACE_CTL----*/
> > pvr2_decoder_enable_output(1)
> > Sep 13 21:54:13 [kernel] pvrusb2 /*---TRACE_CTL----*/
> > pvr2_hdw_cmd_usbstream(1)
> > Sep 13 21:54:13 [kernel] pvrusb2 /*---TRACE_CTL----*/ pvr2_encoder_start
> > Sep 13 21:54:13 [kernel] pvrusb2 /*---TRACE_READ---*/ pvr2_ioread_start
> > id=ffff810031763600
> > Sep 13 22:00:01 [cron] (root) CMD (test -x /usr/sbin/run-crons
> > && /usr/sbin/run-crons )
> > Sep 13 22:00:01 [cron] (root) CMD (rm -f /var/spool/cron/lastrun/cron.hourly)
> > Sep 13 22:10:01 [cron] (root) CMD (test -x /usr/sbin/run-crons
> > && /usr/sbin/run-crons )
> > Sep 13 22:10:20 [kernel] pvrusb2 /*---TRACE_READ---*/ pvr2_ioread_stop
> > id=ffff810031763600
> > Sep 13 22:10:20 [kernel] Unable to handle kernel NULL pointer dereference at
> > 0000000000000038 RIP:
> > Sep 13 22:10:20 [kernel] <ffffffff884e9669>{:pvrusb2:pvr2_buffer_set_idle+121}
> > Sep 13 22:10:20 [kernel] PGD 269c5067 PUD 269f4067 PMD 0
> > Sep 13 22:10:20 [kernel] CPU 0
> > Sep 13 22:10:20 [kernel] Modules linked in: saa7115 msp3400 tuner pvrusb2
> > v4l2_common v4l1_compat videodev tveeprom nvnet i2c_nforce2 snd_seq
> > snd_ice1724 snd_ice17xx_ak4xxx snd_ac97_codec snd_ak4114 snd_pcm snd_timer
> > snd_page_alloc snd_ak4xxx_adda snd_mpu401_uart snd_rawmidi snd_seq_device snd
> > soundcore lirc_i2c lirc_dev nvidia
> > Sep 13 22:10:20 [kernel] Pid: 12930, comm: xawtv Tainted: P
> > 2.6.13-gentoo-r1
> > Sep 13 22:10:20 [kernel] RIP: 0010:[<ffffffff884e9669>]
>
>
> > <ffffffff884e9669>{:pvrusb2:pvr2_buffer_set_idle+121}
>
> This is the key.  This is the point where the problem started.
> Interestingly enough, this appears to be the place where one other person
> reported an oops - that I had posted here about a week ago.
>
> Here's what I want you to do (and anyone else who suspects they are
> getting had by this problem):  Edit pvrusb2-io.c and uncomment line 31
> which defines SANITY_CHECK_BUFFERS.  This will enable a bunch of sanity
> checking that hopefully should be able to trap this problem and report
> additional useful information.  Please turn that on and run again until
> you get another failure.  Turning this on will generate additional log
> output during stream start / stop but nothing else new will be logged
> until a problem is found, i.e. don't worry about this filling up your log.
>
>    [...]
>
>
>
> > Sep 13 22:10:20 [kernel] scheduling while atomic: xawtv/0x00000001/12930
>
> OK, now this is also interesting, but not nearly as much as above.  This
> is a second trap, but it's probably collateral damage from the first trap.
> This probably happened because xawtv runs by repeatedly opening
> /dev/video0 (or whatever), doing something to it and closing it again.
> It's very possible that in spite of the earlier kernel oops that xawtv
> kept on going and forced an action that caused something else illegal to
> take place.
>
> In the other instance of the above oops that I know about, mplayer was
> being used instead of xawtv.  In that case mplayer just died right away
> and so there wasn't any more "shrapnel" being tossed around through the
> kernel.
>
> So let's not worry about this subsequent traps and focus on the first one,
> the one that start things failing...
>
>
>
>

-- 
                        |         Mike Isely          |     PGP fingerprint
     Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                        |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                        |                             |