cron job: media_tree daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Sun Jan 15 05:00:16 CET 2017
media-tree git hash:40eca140c404505c09773d1c6685d818cb55ab1a
media_build git hash:   3c6ce4ff75f19adf45869e34b376c5b9dee4d50a
v4l-utils git hash: aded25f433113e022adc375629c8e17eb3a5c64f
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.8.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: OK
linux-3.12.67-i686: OK
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-4.10-rc3-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: OK
linux-3.12.67-x86_64: OK
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: OK
linux-4.9-x86_64: OK
linux-4.10-rc3-x86_64: OK
apps: WARNINGS
spec-git: ERRORS
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Staging: media: davinci_vpfe: style fix, using octal file permissions

[Derek Robson]

Change file permissions to octal style.
Found using checkpatch.

Signed-off-by: Derek Robson 
---
 drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c 
b/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
index bf077f8342f6..32109cdd73a6 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
@@ -74,7 +74,7 @@
 static bool debug;
 static bool interface;
 
-module_param(interface, bool, S_IRUGO);
+module_param(interface, bool, 0444);
 module_param(debug, bool, 0644);
 
 /**
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with Hauppauge WinTV-HVR-1250

[Justin Husted]

On Sat, Jan 14, 2017 at 8:01 AM, Michael Ira Krufky  wrote:
>
> On Fri, Jan 13, 2017 at 11:56 PM, Justin Husted  wrote:
> > Hi!
> >
> > I recently got one of these cards on ebay to do some analog video capturing,
> > and I'm having a few problems with it on the 4.4.0 kernel.
> >
> > I wasn't really sure who the maintainer is for this stuff, but I saw your
> > name in the Linux MAINTAINERS file for the tda18271, which seems to be one
> > of the relevant drivers. :-)
> >
> > Are you the person to talk to, or do you know who is?
>
> Justin,
>
> Better to email the linux-media mailing list on kernel.org with this
> type of question (cc added)

Ok, thanks!

> What is the problem that you're having in the 4.4.0 kernel?

There are two fundamental problems. Note that I'm just attempting to
use this card as an analog video capture card, using the RCA plug.

== Sleep / Reference Leak ==

The first problem is less important, but is clearly annoying: the card
does not work after sleep/resume, and I can't try the typical approach
of adding a special module unload/reload rule because it appears to
have a reference leak.

I'm seeing that there is (usually) one reference to cx25840 and
cx23885 at all times, plus extra references if a capture is actually
going on. However, it is also somewhat unreliable, so occasionally
there isn't a reference to the driver and I'm able to unload/reload it
(but it still doesn't work).

== Interlaced Video Capture ==

The second problem is the more important one: It seems like the
interlaced video capture I'm receiving via various tools has something
wrong with it. I'm not sure precisely how to characterize this.

Basically, what I first noticed was that after deinterlacing, it
looked as if each pair of lines in the output was reversed, leading to
an extremely vertically pixelated result. I attempted to investigate,
and basically what I'm seeing is that the interlaced video frames
(720x480 @ 29.97 fps) appear as if they're in an inverted pattern in
the output, like 214365

Ok! I think, maybe they're in bff rather than tff format. I then
attempted to change my capture settings (I've been using vlc, ffmpeg,
mplayer, and cheese to try to debug), and found that occasionally this
seemed to help, but it would invariably not work reliably.

I then attempted capturing with a variety of different deinterlacing
schemes. I found with a bob deinterlacer that it seemed like the video
would switch modes, jumping every few seconds up and down a little.

The next thing I tried was to extract the interlaced fields and
produce a 59.94 hz stream, so I could frame by frame it. What was most
notable about this was that it seemed like in high-motion scenes, the
motion would actually jump backwards in time by a few frames, instead
of the fields each showing an A-B-C-D-E-F or B-A-D-C-F-E pattern like
I expected.

So, basically, it seemed to me almost like this driver is mis-managing
its video buffers. I don't know how the internal hardware interface
works (I mean seriously, I wasn't even sure which driver programs the
analog video chip...), so I wasn't sure if it was plausible that
perhaps the driver is reading the video stream one field at a time and
then composing them in the wrong order or something crazy like that.

Regardless, the card doesn't really seem to be usable for NTSC video
capture with this driver.

> Which is the most recent kernel that works for you correctly?

I just picked up this card recently (I need to transfer old video
tape), and haven't tried it with any other kernel series. I did check
the kernel changelog to see if there had been commits recently to the
cx23885 or cx25840 drivers, and didn't see anything relevant.

> Do you have logs that illustrate your problem?

I've attached the result of lsmod, showing the refcounts. I'm not
really sure what the most useful data regarding the actual video
capture problem is.

Alternatively, do you know a good reliable PCIe or USB analog video
capture card that produces good results? It's seemed quite difficult
to find something these days given that it's basically a dead
technology... (and for the low end USB cards, we seem to be in
counterfeit hell).

Thanks,
Justin


hauppage_lsmod_pre2
Description: Binary data

Re: [PATCH v3 16/24] media: Add i.MX media core driver

[Steve Longerbeam]

(sorry sending again w/o html)


On 01/13/2017 07:20 AM, Philipp Zabel wrote:

Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:

+For image capture, the IPU contains the following internal subunits:
+
+- Image DMA Controller (IDMAC)
+- Camera Serial Interface (CSI)
+- Image Converter (IC)
+- Sensor Multi-FIFO Controller (SMFC)
+- Image Rotator (IRT)
+- Video De-Interlace Controller (VDIC)

Nitpick: Video De-Interlacing or Combining Block (VDIC)


done.


+
+The IDMAC is the DMA controller for transfer of image frames to and from
+memory. Various dedicated DMA channels exist for both video capture and
+display paths.
+
+The CSI is the frontend capture unit that interfaces directly with
+capture sensors over Parallel, BT.656/1120, and MIPI CSI-2 busses.
+
+The IC handles color-space conversion, resizing, and rotation
+operations.

And horizontal flipping.


done.



There are three independent "tasks" within the IC that can
+carry out conversions concurrently: pre-processing encoding,
+pre-processing preview, and post-processing.

s/preview/viewfinder/ seems to be the commonly used name.


replaced everywhere in the doc.


This paragraph could mention that a single hardware unit is used
transparently time multiplexed by the three tasks at different
granularity for the downsizing, main processing, and rotation sections.
The downscale unit switches between tasks at 8-pixel burst granularity,
the main processing unit at line granularity. The rotation units switch
only at frame granularity.


I've added that info.


+The SMFC is composed of four independent channels that each can transfer
+captured frames from sensors directly to memory concurrently.
+
+The IRT carries out 90 and 270 degree image rotation operations.

... on 8x8 pixel blocks, supported by the IDMAC which handles block
transfers, block reordering, and vertical flipping.


done.


+The VDIC handles the conversion of interlaced video to progressive, with
+support for different motion compensation modes (low, medium, and high
+motion). The deinterlaced output frames from the VDIC can be sent to the
+IC pre-process preview task for further conversions.
+
+In addition to the IPU internal subunits, there are also two units
+outside the IPU that are also involved in video capture on i.MX:
+
+- MIPI CSI-2 Receiver for camera sensors with the MIPI CSI-2 bus
+  interface. This is a Synopsys DesignWare core.
+- A video multiplexer for selecting among multiple sensor inputs to
+  send to a CSI.

Two of them, actually.


done.


+
+- Includes a Frame Interval Monitor (FIM) that can correct vertical sync
+  problems with the ADV718x video decoders. See below for a description
+  of the FIM.

Could this also be used to calculate more precise capture timestamps?


An input capture function could do that, triggered off a VSYNC or FIELD
signal such as on the ADV718x. The FIM is only used to calculate
frame intervals at this point, but its input capture method could be
used to also record more accurate timestamps.



+Capture Pipelines
+-
+
+The following describe the various use-cases supported by the pipelines.
+
+The links shown do not include the frontend sensor, video mux, or mipi
+csi-2 receiver links. This depends on the type of sensor interface
+(parallel or mipi csi-2). So in all cases, these pipelines begin with:
+
+sensor -> ipu_csi_mux -> ipu_csi -> ...
+
+for parallel sensors, or:
+
+sensor -> imx-mipi-csi2 -> (ipu_csi_mux) -> ipu_csi -> ...
+
+for mipi csi-2 sensors. The imx-mipi-csi2 receiver may need to route
+to the video mux (ipu_csi_mux) before sending to the CSI, depending
+on the mipi csi-2 virtual channel, hence ipu_csi_mux is shown in
+parenthesis.
+
+Unprocessed Video Capture:
+--
+
+Send frames directly from sensor to camera interface, with no
+conversions:
+
+-> ipu_smfc -> camif

I'd call this capture interface, this is not just for cameras. Or maybe
idmac if you want to mirror hardware names?


Camif is so named because it is the V4L2 user interface for video
capture. I suppose it could be named "capif", but that doesn't role
off the tongue quite as well.


+Note the ipu_smfc can do pixel reordering within the same colorspace.

That isn't a feature of the SMFC, but of the IDMAC (FCW & FCR).


yes, the doc is re-worded to make that more clear.


+For example, its sink pad can take UYVY2X8, but its source pad can
+output YUYV2X8.

I don't think this is correct. Re-reading "37.4.3.7 Packing to memory"
in the CSI chapter, for 8-bit per component data, the internal format
between CSI, SMFC, and IDMAC is always some 32-bit RGBx/YUVx variant
(or "bayer/generic data"). In either case, the internal format does not
change along the way.


these are pixels in memory buffers, not the IPU internal formats.



+IC Direct Conversions:
+--
+
+This pipeline uses the preprocess encode entity to route frames directly
+from the CSI to the IC (bypassing the SMFC), to carry out 

Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support

[Steve Longerbeam]

On 01/13/2017 03:05 AM, Philipp Zabel wrote:

Hi Steve,

Am Donnerstag, den 12.01.2017, 15:22 -0800 schrieb Steve Longerbeam:

Hi Philipp, JM,

First, let me say that you both have convinced me that we need a VDIC
entity. I've implemented that in the branch imx-media-staging-md-vdic.
At this point it only implements the M/C de-interlacing function, not the
plane Combiner. So it has only one input and one output pad.

Excellent.


  I would
imagine it will need two additional inputs and another output to support
the Combiner (two pads for each plane to be combined, and a combiner
output pad).

If I accept for a moment that IDMAC/FSU channel links are described as
media entity links, that would be right, I guess.


Hi Philipp,

Let me start by asking, why you are averse to the idea that a media
driver passes video frames from source to sink using memory
buffers? There is no hard-and-fast rule in the media framework that
states this should not be done, AFAIK.

I agree this overlaps with the mem2mem device idea somewhat, but
IMHO a media device should be allowed to use internal memory
buffers to pass video frames between pads, if that's what it needs to
do to implement some functionality.

Can anyone else listening on this thread, chime in on this topic?



Is there even a reason for the user to switch between direct and via
memory paths manually, or could this be inferred from other state
(formats, active links)?

a CSI -> VDIC link doesn't convey whether that is a direct link using
the FSU, or whether it is via SMFC and memory buffers.

If you'll recall, the VDIC has three motion modes: low, medium, and
high.

When VDIC receives directly from CSI, it can only operate in
high motion mode (it processes a single field F(n-1) sent directly
from the CSI using the FSU). The reference manual refers to this
as "real time mode".

In my opinion this is the only mode that should be supported in the
capture driver.


I have to disagree on that.


  But that may be wishful thinking to a certain degree -
see below.


The low and medium motion modes require processing all three
fields F(n-1), F(n), and F(n+1). These fields must come from IDMAC
channels 8, 9, and 10 respectively.

So in order to support low and medium motion modes, there needs to
be a pipeline where the VDIC receives F(n-1), F(n), and F(n+1) from
memory buffers.

In the cases where the VDIC reads all three fields from memory, I'd
prefer that to be implemented as a separate mem2mem device.



I prefer that there be a single VDIC media entity, that makes use of its
dma read channels in order to support all of its motion compensation
modes.




  While useful
on its own, there could be an API to link together the capture and
output of different video4linux devices, and that could get a backend to
implement IDMAC/FSU channel linking where supported.


An interesting idea, but it also sounds a lot like what can already be
provided by a pipeline in the media framework, by linking an entity
that is a video source to an entity that is a video sink.





How about this: we can do away with SMFC entities by having two
output pads from the CSI: a "direct" output pad that can link to PRP and
VDIC, and a "IDMAC via SMFC" output pad that links to the entities that
require memory buffers (VDIC in low/medium motion mode, camif, and
PP). Only one of those output pads can be active at a time. I'm not sure if
that allowed by the media framework, do two source pads imply that the
entity can activate both of those pads simultaneously, or is allowed that
only one source pad of two or more can be activated at a time? It's not
clear to me.

Let me know if you agree with this proposal.

In my opinion that is better than having the SMFC as a separate entity,
even better would be not to have to describe the memory paths as media
links.


Ok, I'll go ahead and implement this idea then.



[...]

Here also, I'd prefer to keep distinct PRPENC and PRPVF entities. You
are correct that PRPENC and PRPVF do share an input channel (the CSIs).
But the PRPVF has an additional input channel from the VDIC,

Wait, that is a VDIC -> PRP connection, not a VDIC -> PRPVF connection,
or am I mistaken?

The FSU only sends VDIC output to PRPVF, not PRPENC. It's not
well documented, but see "IPU main flows" section in the manual.
All listed pipelines that route VDIC to IC go to IC (PRP VF).

Sorry to be a bit pedantic, the FSU does not send output. It just
triggers a DMA read channel (IDMAC or DMAIC) whenever signalled by
another write channel's EOF.


Right, poor choice of wording on my part, thanks for the
clarification.



Since the read channel of PRPVF and PRPENC is the same (IC direct, cb7),
I don't yet understand how the VDIC output can be sent to one but not
the other. As you said, the documentation is a bit confusing in this
regard.


agreed.


Which suggests that when IC receives from VDIC, PRPENC can
receive no data and is effectively unusable.


The VDIC direct input is enabled with 

[no subject]

[John Dan]

 My greeting to you.I'm John Dan ,i want to know if you have read my
sent letter to you?.
Best regards
John Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with Hauppauge WinTV-HVR-1250

[Michael Ira Krufky]

On Fri, Jan 13, 2017 at 11:56 PM, Justin Husted  wrote:
> Hi!
>
> I recently got one of these cards on ebay to do some analog video capturing,
> and I'm having a few problems with it on the 4.4.0 kernel.
>
> I wasn't really sure who the maintainer is for this stuff, but I saw your
> name in the Linux MAINTAINERS file for the tda18271, which seems to be one
> of the relevant drivers. :-)
>
> Are you the person to talk to, or do you know who is?
>
> Thanks!
> -Justin
>


Justin,

Better to email the linux-media mailing list on kernel.org with this
type of question (cc added)

What is the problem that you're having in the 4.4.0 kernel?

Which is the most recent kernel that works for you correctly?

Do you have logs that illustrate your problem?

Best regards,

Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[OOPS] EM28xx with 4.9.x kernel

[Chris Rankin]

Hi,

This oops has appeared for my PCTV T2 290e adapter when I switched to
the 4.9.x kernel. It does not happen with the 4.8.x kernel.

I believe the problem is that "priv" is NULL in cxd2820r_gpio().

Jan 13 11:19:45 endgame kernel: em28174 #0: EEPROM ID = 26 00 01 00,
EEPROM hash = 0x1eb936d2
Jan 13 11:19:45 endgame kernel: em28174 #0: EEPROM info:
Jan 13 11:19:45 endgame kernel: em28174 #0: #011microcode start
address = 0x0004, boot configuration = 0x01
Jan 13 11:19:45 endgame kernel: em28174 #0: #011No audio on board.
Jan 13 11:19:45 endgame kernel: em28174 #0: #011500mA max power
Jan 13 11:19:45 endgame kernel: em28174 #0: #011Table at offset 0x39,
strings=0x1aa0, 0x14ba, 0x1ace
Jan 13 11:19:45 endgame kernel: em28174 #0: Identified as PCTV
nanoStick T2 290e (card=78)
Jan 13 11:19:45 endgame kernel: em28174 #0: dvb set to isoc mode.
Jan 13 11:19:45 endgame kernel: usbcore: registered new interface driver em28xx
Jan 13 11:19:45 endgame kernel: em28174 #0: Binding DVB extension
Jan 13 11:19:45 endgame kernel: BUG: unable to handle kernel NULL
pointer dereference at 0549
Jan 13 11:19:45 endgame kernel: IP: [] memcmp+0xb/0x1d
Jan 13 11:19:47 endgame kernel: PGD 0
Jan 13 11:19:47 endgame kernel:
Jan 13 11:19:47 endgame kernel: Oops:  [#1] PREEMPT SMP
Jan 13 11:19:47 endgame kernel: Modules linked in: cxd2820r
em28xx_dvb(+) dvb_core btbcm snd_rawmidi snd_hda_core joydev coretemp
btintel snd_seq kvm_intel snd_seq_device bluetooth kvm snd_pcm rfkill
snd_hrtimer em28xx tveeprom snd_timer v4l2_common videodev irqbypass
iTCO_wdt psmouse mxm_wmi pcspkr lpc_ich snd r8169 i7core_edac i2c_i801
i2c_smbus button wmi mfd_core mii edac_core acpi_cpufreq soundcore
processor binfmt_misc nfsd auth_rpcgss oid_registry nfs_acl lockd
grace sunrpc ip_tables x_tables ext4 crc16 jbd2 mbcache sr_mod cdrom
sd_mod usbhid radeon i2c_algo_bit uhci_hcd crc32c_intel ehci_pci
drm_kms_helper serio_raw ehci_hcd ahci xhci_pci cfbfillrect
syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops pata_jmicron
libahci cfbcopyarea libata firewire_ohci ttm scsi_mod xhci_hcd
firewire_core crc_itu_t drm
Jan 13 11:19:47 endgame kernel: usbcore usb_common ipv6
Jan 13 11:19:47 endgame kernel: CPU: 5 PID: 639 Comm: modprobe
Tainted: G  I4.9.2 #2
Jan 13 11:19:47 endgame kernel: Hardware name: Gigabyte Technology
Co., Ltd. EX58-UD3R/EX58-UD3R, BIOS FB  05/04/2009
Jan 13 11:19:47 endgame kernel: task: 8801c34acec0 task.stack:
c94f8000
Jan 13 11:19:47 endgame kernel: RIP: 0010:[]
[] memcmp+0xb/0x1d
Jan 13 11:19:47 endgame kernel: RSP: 0018:c94fb888  EFLAGS: 00010206
Jan 13 11:19:47 endgame kernel: RAX: 0001 RBX:
8801c1ef2800 RCX: 
Jan 13 11:19:47 endgame kernel: RDX: 0003 RSI:
0549 RDI: c94fb8b9
Jan 13 11:19:47 endgame kernel: RBP:  R08:
8801c80fc8c0 R09: 
Jan 13 11:19:47 endgame kernel: R10: c94fb708 R11:
00018ca0 R12: 0549
Jan 13 11:19:47 endgame kernel: R13: c94fb8b9 R14:
8801c1ef2828 R15: c94fba68
Jan 13 11:19:47 endgame kernel: FS:  7f3c74c195c0()
GS:8801cfd4() knlGS:
Jan 13 11:19:47 endgame kernel: CS:  0010 DS:  ES:  CR0:
80050033
Jan 13 11:19:47 endgame kernel: CR2: 0549 CR3:
0001c35a7000 CR4: 06e0
Jan 13 11:19:47 endgame kernel: Stack:
Jan 13 11:19:47 endgame kernel: a04f344c 8801c1ef2800
8801c4bef000 
Jan 13 11:19:47 endgame kernel: 8801c324bd64 a04f3662
00e101ed a04f5280
Jan 13 11:19:47 endgame kernel: 8801c4bef020 8801c4bef000
8801c4bef004 a04f3514
Jan 13 11:19:47 endgame kernel: Call Trace:
Jan 13 11:19:47 endgame kernel: [] ?
cxd2820r_gpio+0x27/0xef [cxd2820r]
Jan 13 11:19:47 endgame kernel: [] ?
cxd2820r_probe+0x14e/0x1df [cxd2820r]
Jan 13 11:19:47 endgame kernel: [] ?
cxd2820r_gpio+0xef/0xef [cxd2820r]
Jan 13 11:19:47 endgame kernel: [] ?
i2c_device_probe+0xc6/0xfa
Jan 13 11:19:47 endgame kernel: [] ?
driver_probe_device+0x10b/0x249
Jan 13 11:19:47 endgame kernel: [] ?
driver_allows_async_probing+0x24/0x24
Jan 13 11:19:47 endgame kernel: [] ?
bus_for_each_drv+0x6c/0x7b
Jan 13 11:19:47 endgame kernel: [] ? __device_attach+0x96/0xf5
Jan 13 11:19:47 endgame kernel: [] ?
bus_probe_device+0x28/0x84
Jan 13 11:19:47 endgame kernel: [] ? device_add+0x2ad/0x51e
Jan 13 11:19:47 endgame kernel: [] ?
_raw_spin_unlock_irqrestore+0xf/0x20
Jan 13 11:19:47 endgame kernel: [] ?
i2c_new_device+0x172/0x1c9
Jan 13 11:19:47 endgame kernel: [] ?
cxd2820r_attach+0x8a/0xc0 [cxd2820r]
Jan 13 11:19:47 endgame kernel: [] ?
em28xx_dvb_init.part.3+0xa01/0x2d20 [em28xx_dvb]
Jan 13 11:19:47 endgame kernel: [] ?
check_preempt_curr+0x41/0x5e
Jan 13 11:19:47 endgame kernel: [] ? ttwu_do_wakeup+0xd/0x81
Jan 13 11:19:47 endgame kernel: [] ?
_raw_spin_unlock_irqrestore+0xf/0x20
Jan 13 11:19:47 endgame kernel: [] ?

Oops with 4.9.x kernel and em28xx DVB device

[Chris Rankin]

Hi,

This oops has appeared for my PCTV T2 290e adapter when I switched to
the 4.9.x kernel. It does not happen with the 4.8.x kernel.

Jan 13 11:19:45 endgame kernel: em28174 #0: EEPROM ID = 26 00 01 00,
EEPROM hash = 0x1eb936d2
Jan 13 11:19:45 endgame kernel: em28174 #0: EEPROM info:
Jan 13 11:19:45 endgame kernel: em28174 #0: #011microcode start
address = 0x0004, boot configuration = 0x01
Jan 13 11:19:45 endgame kernel: em28174 #0: #011No audio on board.
Jan 13 11:19:45 endgame kernel: em28174 #0: #011500mA max power
Jan 13 11:19:45 endgame kernel: em28174 #0: #011Table at offset 0x39,
strings=0x1aa0, 0x14ba, 0x1ace
Jan 13 11:19:45 endgame kernel: em28174 #0: Identified as PCTV
nanoStick T2 290e (card=78)
Jan 13 11:19:45 endgame kernel: em28174 #0: dvb set to isoc mode.
Jan 13 11:19:45 endgame kernel: usbcore: registered new interface driver em28xx
Jan 13 11:19:45 endgame kernel: em28174 #0: Binding DVB extension
Jan 13 11:19:45 endgame kernel: BUG: unable to handle kernel NULL
pointer dereference at 0549
Jan 13 11:19:45 endgame kernel: IP: [] memcmp+0xb/0x1d
Jan 13 11:19:47 endgame kernel: PGD 0
Jan 13 11:19:47 endgame kernel:
Jan 13 11:19:47 endgame kernel: Oops:  [#1] PREEMPT SMP
Jan 13 11:19:47 endgame kernel: Modules linked in: cxd2820r
em28xx_dvb(+) dvb_core btbcm snd_rawmidi snd_hda_core joydev coretemp
btintel snd_seq kvm_intel snd_seq_device bluetooth kvm snd_pcm rfkill
snd_hrtimer em28xx tveeprom snd_timer v4l2_common videodev irqbypass
iTCO_wdt psmouse mxm_wmi pcspkr lpc_ich snd r8169 i7core_edac i2c_i801
i2c_smbus button wmi mfd_core mii edac_core acpi_cpufreq soundcore
processor binfmt_misc nfsd auth_rpcgss oid_registry nfs_acl lockd
grace sunrpc ip_tables x_tables ext4 crc16 jbd2 mbcache sr_mod cdrom
sd_mod usbhid radeon i2c_algo_bit uhci_hcd crc32c_intel ehci_pci
drm_kms_helper serio_raw ehci_hcd ahci xhci_pci cfbfillrect
syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops pata_jmicron
libahci cfbcopyarea libata firewire_ohci ttm scsi_mod xhci_hcd
firewire_core crc_itu_t drm
Jan 13 11:19:47 endgame kernel: usbcore usb_common ipv6
Jan 13 11:19:47 endgame kernel: CPU: 5 PID: 639 Comm: modprobe
Tainted: G  I4.9.2 #2
Jan 13 11:19:47 endgame kernel: Hardware name: Gigabyte Technology
Co., Ltd. EX58-UD3R/EX58-UD3R, BIOS FB  05/04/2009
Jan 13 11:19:47 endgame kernel: task: 8801c34acec0 task.stack:
c94f8000
Jan 13 11:19:47 endgame kernel: RIP: 0010:[]
[] memcmp+0xb/0x1d
Jan 13 11:19:47 endgame kernel: RSP: 0018:c94fb888  EFLAGS: 00010206
Jan 13 11:19:47 endgame kernel: RAX: 0001 RBX:
8801c1ef2800 RCX: 
Jan 13 11:19:47 endgame kernel: RDX: 0003 RSI:
0549 RDI: c94fb8b9
Jan 13 11:19:47 endgame kernel: RBP:  R08:
8801c80fc8c0 R09: 
Jan 13 11:19:47 endgame kernel: R10: c94fb708 R11:
00018ca0 R12: 0549
Jan 13 11:19:47 endgame kernel: R13: c94fb8b9 R14:
8801c1ef2828 R15: c94fba68
Jan 13 11:19:47 endgame kernel: FS:  7f3c74c195c0()
GS:8801cfd4() knlGS:
Jan 13 11:19:47 endgame kernel: CS:  0010 DS:  ES:  CR0:
80050033
Jan 13 11:19:47 endgame kernel: CR2: 0549 CR3:
0001c35a7000 CR4: 06e0
Jan 13 11:19:47 endgame kernel: Stack:
Jan 13 11:19:47 endgame kernel: a04f344c 8801c1ef2800
8801c4bef000 
Jan 13 11:19:47 endgame kernel: 8801c324bd64 a04f3662
00e101ed a04f5280
Jan 13 11:19:47 endgame kernel: 8801c4bef020 8801c4bef000
8801c4bef004 a04f3514
Jan 13 11:19:47 endgame kernel: Call Trace:
Jan 13 11:19:47 endgame kernel: [] ?
cxd2820r_gpio+0x27/0xef [cxd2820r]
Jan 13 11:19:47 endgame kernel: [] ?
cxd2820r_probe+0x14e/0x1df [cxd2820r]
Jan 13 11:19:47 endgame kernel: [] ?
cxd2820r_gpio+0xef/0xef [cxd2820r]
Jan 13 11:19:47 endgame kernel: [] ?
i2c_device_probe+0xc6/0xfa
Jan 13 11:19:47 endgame kernel: [] ?
driver_probe_device+0x10b/0x249
Jan 13 11:19:47 endgame kernel: [] ?
driver_allows_async_probing+0x24/0x24
Jan 13 11:19:47 endgame kernel: [] ?
bus_for_each_drv+0x6c/0x7b
Jan 13 11:19:47 endgame kernel: [] ? __device_attach+0x96/0xf5
Jan 13 11:19:47 endgame kernel: [] ?
bus_probe_device+0x28/0x84
Jan 13 11:19:47 endgame kernel: [] ? device_add+0x2ad/0x51e
Jan 13 11:19:47 endgame kernel: [] ?
_raw_spin_unlock_irqrestore+0xf/0x20
Jan 13 11:19:47 endgame kernel: [] ?
i2c_new_device+0x172/0x1c9
Jan 13 11:19:47 endgame kernel: [] ?
cxd2820r_attach+0x8a/0xc0 [cxd2820r]
Jan 13 11:19:47 endgame kernel: [] ?
em28xx_dvb_init.part.3+0xa01/0x2d20 [em28xx_dvb]
Jan 13 11:19:47 endgame kernel: [] ?
check_preempt_curr+0x41/0x5e
Jan 13 11:19:47 endgame kernel: [] ? ttwu_do_wakeup+0xd/0x81
Jan 13 11:19:47 endgame kernel: [] ?
_raw_spin_unlock_irqrestore+0xf/0x20
Jan 13 11:19:47 endgame kernel: [] ?
try_to_wake_up+0x1f7/0x208
Jan 13 11:19:47 endgame kernel: [] ?