cron job: media_tree daily build: OK
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 Sep 23 04:00:17 CEST 2018 media-tree git hash:985cdcb08a0488558d1005139596b64d73bee267 media_build git hash: 44385b9c61ecc27059a651885895c8ea09cd4179 v4l-utils git hash: e03a5fe118de918b0778fea4a227db3cb18eda1c edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.17.0-3-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.119-i686: OK linux-3.18.119-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.152-i686: OK linux-4.4.152-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.124-i686: OK linux-4.9.124-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.67-i686: OK linux-4.14.67-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.5-i686: OK linux-4.18.5-x86_64: OK linux-4.19-rc1-i686: OK linux-4.19-rc1-x86_64: OK apps: OK spec-git: OK 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
Re: 4.18 regression: dvb-usb-v2: General Protection Fault shortly after boot
On Sat, 2018-09-22 at 18:31 -0400, Dan Ziemba wrote: > On Sat, 2018-09-22 at 07:21 -0300, Mauro Carvalho Chehab wrote: > > Em Thu, 20 Sep 2018 00:07:09 -0400 > > Dan Ziemba escreveu: > > > > > I reported this on bugzilla also a few days ago, but I'm not sure > > > if > > > that is actually the right place to report, so copying to the > > > mailing > > > list... > > > > I saw a report on BZ, but haven't time yet to dig into it. Those > > days, it is usually better to report via the ML. > > > > > > > > Starting with the first 4.18 RC kernel, my system experiences > > > general > > > protection faults leading to kernel panic shortly after the login > > > prompt appears on most boots. Occasionally that doesn't happen > > > and > > > instead numerous other seemingly random stack traces are printed > > > (bad > > > page map, scheduling while atomic, null pointer deref, etc), but > > > either > > > way the system is unusable. This bug remains up through the > > > latest > > > mainline kernel 4.19-rc2. > > > > > > Booting with my USB ATSC tv tuner disconnected prevents the bug > > > from > > > happening. > > > > > > > > > Kernel bisection between v4.17 and 4.18-rc1 shows problem is > > > caused > > > by: > > > > > > 1a0c10ed7bb1 media: dvb-usb-v2: stop using coherent memory for > > > URBs > > > > > > > > > Building both 4.18.6 and 4.19-rc2 with that commit reverted > > > resolves > > > the bug for me. > > > > There's something really weird on it: that patch changes a code > > that > > it is only called when the device is streaming. It shouldn't be > > causing GFP/kernel panic, depending if the machine was booted with > > or without it. > > It hadn't occurred to me to try disabled my tv software. When I > disable tvheadend so it doesn't start at boot, crash does not happen > until I later start it manually. I believe it does some scanning > through the channels at start up to update EPG data. > > > > > Perhaps it would be a side effect due to some changes at the USB > > subsystem? There are some changes happening there changing some > > locks. > > > > I see one minor issue there: it is using GFP_ATOMIC instead > > of GFP_KERNEL. > > > > Could you please try to change this line: > > > > stream->buf_list[stream->buf_num] = kzalloc(size, GFP_ATOMIC); > > > > to > > > > stream->buf_list[stream->buf_num] = kzalloc(size, GFP_KERNEL); > > I'll give this a try now. I built from mainline HEAD, currently 4.19rc4.r209.g10dc890d4228, and was able to reproduce the bug before any code changes. Stack trace from the one test is attached. I then rebuilt with the above line changed, but the problem continues. Stack traces from two tests are attached. First one was a null pointer deref instead of general protection fault, but I have seen that beforeas well. I have noticed that with this newer kernel version (with and without code change), the crash does not always happen immediately after starting tvheadend. A few times, I have been able to tune in a channel and watch for a few seconds. Then the crash would happen after flipping through 3 or 4 channels. > > > > > Also, it would be great if you could post the GPF logs. > > It's difficult to capture much, since the system often locks up > without > syncing to disk. The stack traces appear pretty random to me, but I > have attached two examples I captured by tailing dmesg over ssh while > starting tvheadend. In the first, there was actually not a complete > lock up, so it is complete. For the second one, there was a complete > lockup and quite a bit more printed on the local console that didn't > make it though the network. > > > > > > > > > > > > My DVB hardware uses driver mxl111sf: > > > > > > Bus 002 Device 003: ID 2040:c61b Hauppauge > > > Device Descriptor: > > > bLength18 > > > bDescriptorType 1 > > > bcdUSB 2.00 > > > bDeviceClass0 > > > bDeviceSubClass 0 > > > bDeviceProtocol 0 > > > bMaxPacketSize064 > > > idVendor 0x2040 Hauppauge > > > idProduct 0xc61b > > > bcdDevice0.00 > > > iManufacturer 1 Hauppauge > > > iProduct2 WinTV Aero-M > > > > > > Other system info: > > > > > > Arch Linux x86_64 > > > Intel i7-3770 > > > 16 GB ram > > > > > > Bugzilla: > > > https://bugzilla.kernel.org/show_bug.cgi?id=201055 > > > > > > Arch bug: > > > https://bugs.archlinux.org/task/59990 > > > > > > > > > Thanks, > > > Dan Ziemba > > > > > > > > > > > > > > Thanks, > > Mauro syslog:warn : [ 57.773807] systemd-journald[337]: File /var/log/journal/9ebf93d137434ec68b05472bb8d498ab/user-1337.journal corrupted or uncleanly shut down, renaming and replacing. kern :err : [ 59.912749] usb 4-1.5: dvb_usb_v2: 2nd usb_bulk_msg() failed=-110 kern :err : [ 59.912816] error writing addr: 0x8d, mask: 0x01, data: 0x01, retrying... kern :warn : [ 60.260210] usb
Re: 4.18 regression: dvb-usb-v2: General Protection Fault shortly after boot
On Sat, 2018-09-22 at 07:21 -0300, Mauro Carvalho Chehab wrote: > Em Thu, 20 Sep 2018 00:07:09 -0400 > Dan Ziemba escreveu: > > > I reported this on bugzilla also a few days ago, but I'm not sure > > if > > that is actually the right place to report, so copying to the > > mailing > > list... > > I saw a report on BZ, but haven't time yet to dig into it. Those > days, it is usually better to report via the ML. > > > > > Starting with the first 4.18 RC kernel, my system experiences > > general > > protection faults leading to kernel panic shortly after the login > > prompt appears on most boots. Occasionally that doesn't happen and > > instead numerous other seemingly random stack traces are printed > > (bad > > page map, scheduling while atomic, null pointer deref, etc), but > > either > > way the system is unusable. This bug remains up through the latest > > mainline kernel 4.19-rc2. > > > > Booting with my USB ATSC tv tuner disconnected prevents the bug > > from > > happening. > > > > > > Kernel bisection between v4.17 and 4.18-rc1 shows problem is caused > > by: > > > > 1a0c10ed7bb1 media: dvb-usb-v2: stop using coherent memory for URBs > > > > > > Building both 4.18.6 and 4.19-rc2 with that commit reverted > > resolves > > the bug for me. > > There's something really weird on it: that patch changes a code that > it is only called when the device is streaming. It shouldn't be > causing GFP/kernel panic, depending if the machine was booted with > or without it. It hadn't occurred to me to try disabled my tv software. When I disable tvheadend so it doesn't start at boot, crash does not happen until I later start it manually. I believe it does some scanning through the channels at start up to update EPG data. > > Perhaps it would be a side effect due to some changes at the USB > subsystem? There are some changes happening there changing some > locks. > > I see one minor issue there: it is using GFP_ATOMIC instead > of GFP_KERNEL. > > Could you please try to change this line: > > stream->buf_list[stream->buf_num] = kzalloc(size, GFP_ATOMIC); > > to > > stream->buf_list[stream->buf_num] = kzalloc(size, GFP_KERNEL); I'll give this a try now. > > Also, it would be great if you could post the GPF logs. It's difficult to capture much, since the system often locks up without syncing to disk. The stack traces appear pretty random to me, but I have attached two examples I captured by tailing dmesg over ssh while starting tvheadend. In the first, there was actually not a complete lock up, so it is complete. For the second one, there was a complete lockup and quite a bit more printed on the local console that didn't make it though the network. > > > > > > > My DVB hardware uses driver mxl111sf: > > > > Bus 002 Device 003: ID 2040:c61b Hauppauge > > Device Descriptor: > > bLength18 > > bDescriptorType 1 > > bcdUSB 2.00 > > bDeviceClass0 > > bDeviceSubClass 0 > > bDeviceProtocol 0 > > bMaxPacketSize064 > > idVendor 0x2040 Hauppauge > > idProduct 0xc61b > > bcdDevice0.00 > > iManufacturer 1 Hauppauge > > iProduct2 WinTV Aero-M > > > > Other system info: > > > > Arch Linux x86_64 > > Intel i7-3770 > > 16 GB ram > > > > Bugzilla: > > https://bugzilla.kernel.org/show_bug.cgi?id=201055 > > > > Arch bug: > > https://bugs.archlinux.org/task/59990 > > > > > > Thanks, > > Dan Ziemba > > > > > > > > Thanks, > Mauro kern :notice: [ 410.089420] audit: type=1130 audit(1537653893.759:73): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tvheadend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' kern :err : [ 412.638173] usb 4-1.5: dvb_usb_v2: 2nd usb_bulk_msg() failed=-110 kern :err : [ 412.638229] error writing addr: 0x8d, mask: 0x01, data: 0x01, retrying... kern :warn : [ 412.985663] usb 4-1.5: DVB: adapter 0 frontend 0 frequency 0 out of range (5400..85800) kern :err : [ 415.198280] usb 4-1.5: dvb_usb_v2: 2nd usb_bulk_msg() failed=-110 kern :err : [ 415.198342] error writing addr: 0x8d, mask: 0x01, data: 0x01, retrying... kern :warn : [ 429.186180] general protection fault: [#1] PREEMPT SMP PTI kern :warn : [ 429.186280] CPU: 2 PID: 288 Comm: md1_raid6 Not tainted 4.18.9-arch1-1-ARCH #1 kern :warn : [ 429.186328] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Extreme6, BIOS P2.80 07/01/2013 kern :warn : [ 429.186398] RIP: 0010:memcpy_erms+0x6/0x10 kern :warn : [ 429.186427] Code: 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe kern :warn : [ 429.186588] RSP: 0018:a38c03be7a70 EFLAGS: 00010206 kern :warn : [ 429.186625] RAX: 900d75115000
Re: [PATCH v6] media: add imx319 camera sensor driver
Hi Bingbu,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.19-rc4 next-20180921]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/bingbu-cao-intel-com/media-add-imx319-camera-sensor-driver/20180922-115504
base: git://linuxtv.org/media_tree.git master
config: openrisc-allmodconfig (attached as .config)
compiler: or1k-linux-gcc (GCC) 6.0.0 20160327 (experimental)
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc
All errors (new ones prefixed by >>):
drivers/media//i2c/imx319.c: In function 'imx319_set_stream':
>> drivers/media//i2c/imx319.c:2153:2: error: implicit declaration of function
>> '__v4l2_ctrl_grab' [-Werror=implicit-function-declaration]
__v4l2_ctrl_grab(imx319->vflip, enable);
^~~~
cc1: some warnings being treated as errors
vim +/__v4l2_ctrl_grab +2153 drivers/media//i2c/imx319.c
2118
2119 static int imx319_set_stream(struct v4l2_subdev *sd, int enable)
2120 {
2121 struct imx319 *imx319 = to_imx319(sd);
2122 struct i2c_client *client = v4l2_get_subdevdata(sd);
2123 int ret = 0;
2124
2125 mutex_lock(>mutex);
2126 if (imx319->streaming == enable) {
2127 mutex_unlock(>mutex);
2128 return 0;
2129 }
2130
2131 if (enable) {
2132 ret = pm_runtime_get_sync(>dev);
2133 if (ret < 0) {
2134 pm_runtime_put_noidle(>dev);
2135 goto err_unlock;
2136 }
2137
2138 /*
2139 * Apply default & customized values
2140 * and then start streaming.
2141 */
2142 ret = imx319_start_streaming(imx319);
2143 if (ret)
2144 goto err_rpm_put;
2145 } else {
2146 imx319_stop_streaming(imx319);
2147 pm_runtime_put(>dev);
2148 }
2149
2150 imx319->streaming = enable;
2151
2152 /* vflip and hflip cannot change during streaming */
> 2153 __v4l2_ctrl_grab(imx319->vflip, enable);
2154 __v4l2_ctrl_grab(imx319->hflip, enable);
2155
2156 mutex_unlock(>mutex);
2157
2158 return ret;
2159
2160 err_rpm_put:
2161 pm_runtime_put(>dev);
2162 err_unlock:
2163 mutex_unlock(>mutex);
2164
2165 return ret;
2166 }
2167
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: 4.18 regression: dvb-usb-v2: General Protection Fault shortly after boot
Em Thu, 20 Sep 2018 00:07:09 -0400 Dan Ziemba escreveu: > I reported this on bugzilla also a few days ago, but I'm not sure if > that is actually the right place to report, so copying to the mailing > list... I saw a report on BZ, but haven't time yet to dig into it. Those days, it is usually better to report via the ML. > > Starting with the first 4.18 RC kernel, my system experiences general > protection faults leading to kernel panic shortly after the login > prompt appears on most boots. Occasionally that doesn't happen and > instead numerous other seemingly random stack traces are printed (bad > page map, scheduling while atomic, null pointer deref, etc), but either > way the system is unusable. This bug remains up through the latest > mainline kernel 4.19-rc2. > > Booting with my USB ATSC tv tuner disconnected prevents the bug from > happening. > > > Kernel bisection between v4.17 and 4.18-rc1 shows problem is caused by: > > 1a0c10ed7bb1 media: dvb-usb-v2: stop using coherent memory for URBs > > > Building both 4.18.6 and 4.19-rc2 with that commit reverted resolves > the bug for me. There's something really weird on it: that patch changes a code that it is only called when the device is streaming. It shouldn't be causing GFP/kernel panic, depending if the machine was booted with or without it. Perhaps it would be a side effect due to some changes at the USB subsystem? There are some changes happening there changing some locks. I see one minor issue there: it is using GFP_ATOMIC instead of GFP_KERNEL. Could you please try to change this line: stream->buf_list[stream->buf_num] = kzalloc(size, GFP_ATOMIC); to stream->buf_list[stream->buf_num] = kzalloc(size, GFP_KERNEL); Also, it would be great if you could post the GPF logs. > > > My DVB hardware uses driver mxl111sf: > > Bus 002 Device 003: ID 2040:c61b Hauppauge > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass0 > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize064 > idVendor 0x2040 Hauppauge > idProduct 0xc61b > bcdDevice0.00 > iManufacturer 1 Hauppauge > iProduct2 WinTV Aero-M > > Other system info: > > Arch Linux x86_64 > Intel i7-3770 > 16 GB ram > > Bugzilla: > https://bugzilla.kernel.org/show_bug.cgi?id=201055 > > Arch bug: > https://bugs.archlinux.org/task/59990 > > > Thanks, > Dan Ziemba > > Thanks, Mauro
