[pvrusb2] Kernel oops?

[Bill Crowell]

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