Bug 8166

Created attachment 10676 [details]
Screenshot

Created attachment 10677 [details]
2.6.21-rc3-mm2 config

Created attachment 10678 [details]
lspci

Created attachment 10679 [details]
2.6.21-rc3-mm1 dmesg with same config

Created attachment 10681 [details]
Screeshot with http://ck.kolivas.org/patches/crap/sched-rsdl-0.28-stuff.patch

(also even with 2.6.21-rc3-mm1 rsdl seems to cause problems in ivtv initialisation)

Created attachment 10686 [details]
Screenshot 1  with http://marc.theaimsgroup.com/?l=linux-kernel&m=117357003505656&w=2

Failure mode #1

Created attachment 10687 [details]
Screenshot 2 with http://marc.theaimsgroup.com/?l=linux-kernel&m=117357003505656&w=2

Failure mode #2

Created attachment 10688 [details]
Screenshot 3 with http://marc.theaimsgroup.com/?l=linux-kernel&m=117357003505656&w=2

Failure mode #3

Just to keep the noise level down on lkml I'll repeat the requests here.
Please test v0.29 as it has some other minor changes on top of that one bugfix.
If it still oopses on rc3mm2, please try v0.29 on 2.6.20.2 with the patch
available here:
http://ck.kolivas.org/patches/staircase-deadline/2.6.20.2-rsdl-0.29.patch

I'm currently trying to reproduce this on qemu but have not reproduced the oops.
However the userspace is different and it seems to happen on init in yours.

2.6.21-rc3-mm2 +
http://ck.kolivas.org/patches/staircase-deadline/2.6.20.2-rsdl-0.29.patch boots

Oooh that sounds very good. Can you please clarify? You said a kernel and a
patch booted.

2.6.21-rc3-mm2 +
http://ck.kolivas.org/patches/staircase-deadline/2.6.20.2-rsdl-0.29.patch boots

Did you mean both 2.6.21-rc3-mm2 with rsdl 0.29, and 2.6.20.2 with rsdl 0.29
booted fine?

as with all the other RSDL kernels there are funnies with ivtv initialisation
(long firmware loading module + udev magic channel tuning). Needs several
rmmod/modprobe tries before working (or at least I hope so, that's how I got it
to work on previous rsdl kernels)

Created attachment 10690 [details]
2.6.21-rc3-mm2 + RSDL 0.29 dmesg

didn't try 2.6.20.2 and do not intend to until I have no alternative since :

Excellent. Thank you very much for your bug report and testing. I will close
this bug report now, and better yet that means there are no known outstanding
bugs for RSDL :D

I suspect there will be other reports if the ivtv bit is not fixed (no idea if
the problem is driver-side or scheduler-side though) ivtv is scheduled for
inclusion in 2.6.22 and has a huge userbase (the hardware is #1 on all Linux
HTPC sites)

Hard to see how the scheduler is directly responsible for this. If something
wants cpu time it gets it from the scheduler. Possibly some timeout related
phenomenon from the driver? Might be worth pinging the maintainer of said code
about it.

The same kernel without RSDL (aka 2.6.21-rc3-mm2) does not seem to exhibit the
problem

I understood that from your earlier comment. I'm trying to say a different cpu
scheduler should have no influence on this code unless they have timeout
settings that are failing being too sensitive to an expected behaviour which
would need to be addressed in the driver code.

The driver author is Hans Verkuil. Let's see what he thinks about it (before
ivtv & rsdl collide in the next kernel)

This is all a bit confusing: several of the screenshots show oopses before 
ivtv is even loaded (as far as I can see), so those are definitely not caused 
by ivtv.

If you DO get an oops when loading ivtv, can you tell from the kernel logging 
when the oops occurs during the load process? During a firmware load of either 
the mpeg encoder firmware or the i2c cx25840 audio firmware? Elsewhere?

Hans: the Oops part has been fixed

*however* ivtv seems to have a problem loading on a RSDL kernel. You have to
load/unload ivtv several times before getting something other than snow on video0

There are no errors/warnings in the kernel logs, as attachment #10690 [details] shows

And without the RDSL patches it is working OK?

I mean, if you get snow, then that means that everything is working, except 
for the tuner. Can you give the output of v4l2-ctl --log-status? Once when you 
get snow, and once when it is working?

What happens when you repeatedly set the frequency when you get snow the first 
time? Does that fix things?

without RSDL it's working fine (same system, same kernel except for the rsdl patch)

Created attachment 10692 [details]
2.6.21-rc3-mm2 (no RSDL) dmesg

Also I use ivtv in svideo-input mode so there should be no tuning involved

Created attachment 10693 [details]
2.6.21-rc3-mm2 (no RSDL) v4l2-ctl output

Created attachment 10695 [details]
2.6.21-rc3-mm2 + RSDL 0.29 v4l2-ctl output

Here you have a badly initialised ivtv on an RSDL kernel

I have the following in my local udev rules, so everything should be automatic
(and is on non RSDL kernels)

# Use S-VIDEO input by default for ivtv cards
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SYSFS{name}=="ivtv[0-9]*
encode
r MPEG", RUN+="/usr/bin/v4l2-ctl -d /dev/%k -i 1"

Also the failure does not happen on every boot, but most of them esp. if
booting from another non-RSDL kernel. Never seen it on a plain kernel yet

The input it set to tuner instead of the S-Video. How (and when) do you select 
the input? If you manually set the input to S-Video, does it work again?

Manual set worked this time

Switch to S-Video is normally automated with the udev rule listed before

Con: your scheduler is too fast :-)

The ivtv problem occurs because Nicolas' udev rule kicks in after ivtv has 
created the video devices, but before ivtv has fully initialized the video 
input. The udev rule selects S-Video as input, but right after that the 
tail-end of the ivtv initialization selects the tuner as input.

I'll have to investigate how to solve this properly in ivtv.