[pvrusb2] Kernel oops?

Thu Sep 15 04:42:39 CDT 2005

There was no power failure that I know of, by USV didn't turn on or
anything. I turned on the debug code now but the problem hasn't been
showing up yet.

> Mike,
>
> The power sag that I was having has stopped as the load on the local
> lines has been reduced with cooler weather. The fault seemed to be a
> stall in the processor in the hauppauge gizmo itself. I think I'll have
> to rig up an experiment to reproduce the condition. I have a Variac in
> the garage somewhere along with an oscilloscope...
>
> Having read the threads, I'm thinking that we have 2 issues: mine as an
> unexpected event issue and one more deeply tied to the overall kernel.
> I2c has been banged around quite a bit in 2.6.13. I'm going to spin up
> tests on 2.6.13.1 this week and run my Q/A suite against it.
>
> I'm glad the lirc thing was solved. I just got 2 new Lazyboy sofas -
> beige leather and am wanting to use the remote...
>
> B
>
> Mike Isely wrote:
>
>>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...
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
> --
> William G. Crowell, VP & CTO
> Crowell Systems
> 4235 South Stream Blvd Suite 100
> Charlotte NC 28217
> 704.665.2000 fax 704.665.2180
>
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>

-- 
Mit freundlichen Grüßen / With kind regards,
Andreas Korinek