[pvrusb2] NSLU2+PVRUSB2 crashes; more info

[Mike Isely]

On Sun, 12 Feb 2006, Phil Endecott wrote:

> Dear All,
>
> I've now been able to extract the kernel panic message from my NSLU2,
> and it doesn't say anything PVRUSB2 related, so I'm not hopeful of much
> help here.  But I thought I'd post it anyway in case it means something
> to anyone.  The complete message is below, but the error is "scheduling
> while atomic" and the backtrace is:
>
> c00498d8 T run_posix_cpu_timers
> c0027d2c t ixp4xx_timer_interrupt
> c001d8c0 t __do_irq
> c001daf0 T do_level_IRQ
> c001dbac T asm_do_IRQ
> c001e4b8 T cpu_idle
> c0008628 T start_kernel
>
> IANAKH (I am not a kernel hacker) but my guess is that something, maybe
> the PVRUSB2 code or maybe something else, is not releasing a lock
> somewhere, and this is detected next time the timer interrupt causes
> rescheduling.  Any debugging ideas?

You may be on the right track there, but unfortunately things like that 
are very timing specific, so it could be just that the pvrusb2 driver is 
affecting overall system timing enough to expose an otherwise unrelated 
bug.  I know, that's not very helpful.  It's a pain to track down things 
like this.  In your shoes I would locate the two bottom-most functions on 
that backtrace and inspect the source code.  That might provide some clues 
where to look.

>
> I should say that I'm not using the latest version of the PVRUSB2
> driver; the last NSLU2 binary is from 20050911.  Are there any related
> fixes since then?

The latest version doesn't deal with any real operational bugfixes in the 
driver; just some tweaks and cleanups.  Probably the closest change in 
that snapshot is that if you're running under 2.6.16 or later the driver 
will use mutexes instead of semaphores, but neither construct has anything 
to do with running atomically.  There is IIRC exactly one place in the 
entire driver which does atomic interactions, and that's in the streaming 
logic itself.  A spinlock is used there to keep the USB core from calling 
back into the driver at an inappropriate time.  But that's it, and that 
code has remained virtually unchanged for months.  (The last change there 
was a new feature to permit optional tolerance of a certain level of USB 
errors - look at the change history to find out when that was done.)

   -Mike

-- 
                         |         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
                         |                             |