Created attachment 20794 [details] 2.6.29.1 dmesg messages, lspci -v, dmidecode, .config Since kernel 2.6.29 ivtv driver causes strange oops'es, software suspend no longer works (suspend works, but I cannot wake the PC - it just shows a black console screen and doesn't allow to do anything, SysRq isn't working). All relevant information is in the attached archive. I'm running Fedora 10 with all updates installed and vanilla kernel. SeLinux is turned off. Kernel is NOT tainted.
Created attachment 20825 [details] dmesg output for [rmmod all relevant modules; modprove ivtv] Hans Verkuil asked for kernel messages after I rmmod'ed and modprobed all modules for the second time.
The PC is not functional after resume at all except for a roaring system fan (which doesn't happen when it just works). I will subscribe linux-pm@ to this bug report and sorry, I have no possibility of using git bisect on my home PC due to limited Internet connection.
Since which kernel version is it a regression? 2.6.28? Thanks.
Since 2.6.29 as the bug says. I cannot help you with bisect'ing but I can test in which kernel release candidate the error first appeared (however I'm pretty sure the error was introduced withing 2.6.29-rc1 merge window).
Tested with a vanilla 2.6.29.1 and ivtv (with a GotView PCI DVD Lite card) and it works fine here. I notice that the errors always are associated with 'hald-probe-video', which I'm not using. Can you test what happens if you kill hald first before loading ivtv? (You can just run rmmod ivtv, then kill hald, then modprobe ivtv again). If that looks fine, then try to run 'cat /dev/video0 >/dev/null'. This triggers the firmware load as well, see if that gives the same errors. What distro are you using anyway? I ask because the alternative is that it is related to firmware loading. Can you provide me with the udevd version you are running? (udevd --version)
Created attachment 20996 [details] Miscellaneous information from /proc and two dmesg files for different boot modes These errors appear even at run level 1 (i.e. no processes running). I run fully updated Fedora 10, and I have udev-127-3.fc10.i386 and hal-0.5.12-14.20081027git.fc10.i386 installed.
I've just compiled TIP (yesterday's git snapshot) of ivtv for 2.6.28.9 and the bug occurred again - so the problem is definitely with v4l modules and not with anything else.
Can you test with the standard 2.6.28.9 ivtv drivers and attach the dmesg output? I'm beginning to suspect where the problem is but I'd like to compare what the vanilla 2.6.28 ivtv driver does with what 2.6.29 (or the tip) does. What is also interesting to test is apply the following patch: diff -r cda79523a93c linux/drivers/media/video/ivtv/ivtv-driver.c --- a/linux/drivers/media/video/ivtv/ivtv-driver.c Thu Apr 16 18:30:38 2009 +0200 +++ b/linux/drivers/media/video/ivtv/ivtv-driver.c Sat Apr 18 19:54:26 2009 +0200 @@ -1236,6 +1236,8 @@ struct v4l2_control ctrl; v4l2_subdev_call(itv->sd_video, core, load_fw); + ivtv_msleep_timeout(100, 0); + /* CX25840_CID_ENABLE_PVR150_WORKAROUND */ ctrl.id = V4L2_CID_PRIVATE_BASE; ctrl.value = itv->pvr150_workaround; See if that makes any difference.
Hans, one thing is not clear to me - should I apply this patch to TIP to run under 2.6.28? I'm asking because 2.6.28 ivtv drivers won't accept this patch: if (itv->card->hw_all & IVTV_HW_CX25840) { struct v4l2_control ctrl; /* CX25840_CID_ENABLE_PVR150_WORKAROUND */ ctrl.id = V4L2_CID_PRIVATE_BASE; ctrl.value = itv->pvr150_workaround; itv->video_dec_func(itv, VIDIOC_S_CTRL, &ctrl); }
Yes, apply this against tip. Sorry, I should have mentioned that.
Created attachment 21043 [details] dmesg on 2.6.28.1 with TIP and patch applied (second modprobe without haldaemon running) Alas, the patch has had no effect but probably you wanted to see something ;)
Too bad the patch had no effect. Can you increase the timeout from 100 to 1000 and try one more time? And I also need the dmesg using the 2.6.28 ivtv driver (so without TIP and this patch). That's very important since then I can compare against a working kernel. I'd like to know if the order of initialization has changed.
Created attachment 21044 [details] 2.6.28.9 + tip + patch + 1000ms delay /* For the sake of simplicity I've come up with a shell script which unloads all media modules: cd /lib/modules/$(uname -r)/kernel/drivers/media; for i in 1 2 3; do rmmod $(find . -type f | while read a; do echo `basename $a | sed 's/.ko//g'`; done); done */ Everything's the same. 2.6.28.9 driver and tip driver with 1000ms delay were both loaded with debug=3.
I'm getting confused. It was my understanding that the ivtv driver from 2.6.28 worked correctly. If true, then please provide me with the dmesg output of that working driver. I need to compare that with the failing one. Unless noted otherwise, please don't set the debug level. That only generates extra noise.
The last dmesg file attached here contains logs of both 2.6.28.9 original drivers and tip drivers. E.g. from line number 1291 to 1386 there's an original drivers log; from line 1387 to the end of the file - a tip driver log.
Anyway here's stable drivers log, plain and simple: ivtv: Start initialization, version 1.4.0 ivtv0: Initializing card #0 ivtv0: Autodetected Yuan PG600-2, GotView PCI DVD Lite card (cx23416 based) ivtv 0000:01:07.0: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17 ivtv0: only Composite and S-Video inputs are supported, not the tuner cx25840 2-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #0) ivtv0: Registered device video0 for encoder MPG (4096 kB) ivtv0: Registered device video32 for encoder YUV (2048 kB) ivtv0: Registered device vbi0 for encoder VBI (1024 kB) ivtv0: Registered device video24 for encoder PCM (320 kB) ivtv0: Initialized card #0: Yuan PG600-2, GotView PCI DVD Lite ivtv: End initialization ivtv 0000:01:07.0: firmware: requesting v4l-cx2341x-enc.fw ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes) ivtv0: Encoder revision: 0x02060039 cx25840 2-0044: firmware: requesting v4l-cx25840.fw cx25840 2-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
Hmm, that wasn't useful since the tuner wasn't supported under 2.6.28 so the tuner firmware isn't loaded at all. I'd forgotten about that. Can you try this instead (again with the stable 2.6.28 driver): run 'modprobe ivtv cardtype=20'. This forces the Club3D card which has a very similar setup and does have the tuner enabled. Capturing won't work, but at least in theory this should test the firmware load under 2.6.28.
Created attachment 21080 [details] 2.6.28.9 drivers + `modprobe ivtv cardtype=20` Weird, `modprobe ivtv cardtype=20` command together with stable 2.6.28.9 drivers produces just the same error as TIP or kernel 2.6.29.x.
Handled-By : Hans Verkuil <hverkuil@xs4all.nl>
OK, I now know this is unrelated to any of the v4l2 framework changes made in 2.6.30 or 2.6.29. What did change is that the tuner support was added to GotView DVD Lite in 2.6.29. That caused the tuner fw to be loaded, and that is causing you problems. I've put the same card in a different PC as well, and it just keeps working for me. You can try this tree: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ivtv Here I have removed the tuner support, just as in 2.6.28. This should allow you to use the ivtv driver again (albeit without tuner). Looking at the dmesg logs I notice that the firmware is always loaded after a modprobe ivtv. This should not happen. The firmware is only loaded on the first open of /dev/videoX. There might be something weird in your /etc/modprobe.conf or /etc/modprobe.d/* that is run whenever ivtv is loaded. Or possibly in /etc/udev/rules.d. Please take a look at this, see if there is anything weird going on with that. I haven't heard from anyone else experiencing this problem (and it should also happen for the Club3D card, since that has pretty much the same design). I've pretty much exhausted all options. The only remaining possibility is that you give me ssh access to your box. If you want to do that, then contact me directly by email.
On Monday 27 April 2009, Hans Verkuil wrote: > On Sunday 26 April 2009 11:46:28 Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.28 and 2.6.29. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.28 and 2.6.29. Please verify if it still should > > be listed and let me know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13003 > > Subject : [2.6.29 regression] ivtv driver causes strange > oops'es, > > disrupts software suspend Submitter : Artem S. Tashkinov > > <t.artem@mailcity.com> > > Date : 2009-04-03 14:57 (24 days old) > > Handled-By : Hans Verkuil <hverkuil@xs4all.nl> > > This isn't a 2.6.29 regression. It is a bug - somewhere - but it's also been > reproduced under 2.6.28 so it doesn't qualify as a regression.
It seems like your tree works for me but as for 2.6.30-rc4 your patches are still not in mainline.
Artem, can you test again with the latest v4l-dvb master repository? A patch went in this week that will hopefully fix the firmware load problems you have.
Created attachment 21335 [details] dmesg for kernel 2.6.28.10 + ivtv 8d37e8505664 ivtv revision 8d37e8505664 works fine for me. The minor nuisance is that I see some absolutely new messages while ivtv driver is being initialized - but everything works just fine. Feel free to close this bug report. Now I wonder if anyone could say something about bug 13131
Closing this bug.
hm, kernel 2.6.30 still doesn't include the patches which make system boot errors free ...
I'm reopening this bug report until patch is incorporated into the kernel tree. Even the current kernel git snapshot has zero v4l patches.
This won't be fixed in 2.6.30, but in 2.6.31. My understanding is that the pending v4l-dvb patches will go to the git tree early next week.
It's now in 2.6.31, so I'm closing this bug report.