Most recent kernel where this bug did *NOT* occur: 2.6.21-rc3-mm1 Distribution: Fedora Devel Hardware Environment: AMD64 X2 on CK804 Software Environment: boot scripts Problem Description: On 2.6.21-rc3-mm2 + hot-fixes + http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl.patch Oops at boot time Steps to reproduce: Try to boot
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.