Re: [PATCH 5.2 36/37] vhost: block speculation of translated descriptors
Hi On 2019-09-14, Greg Kroah-Hartman wrote: > On Sat, Sep 14, 2019 at 02:54:11AM +0200, Stefan Lippers-Hollmann wrote: > > On 2019-09-13, Greg Kroah-Hartman wrote: > > > From: Michael S. Tsirkin > > > > > > commit a89db445fbd7f1f8457b03759aa7343fa530ef6b upstream. > > > > > > iovec addresses coming from vhost are assumed to be > > > pre-validated, but in fact can be speculated to a value > > > out of range. > > > > > > Userspace address are later validated with array_index_nospec so we can > > > be sure kernel info does not leak through these addresses, but vhost > > > must also not leak userspace info outside the allowed memory table to > > > guests. > > > > > > Following the defence in depth principle, make sure > > > the address is not validated out of node range. [...] > Do you have the same problem with Linus's tree right now? Actually, yes I do (I had not tested i386 for 5.3~ within the last ~2 weeks, only amd64). Very similar kernel config, same compiler versions but built in a slightly different environment (built directly on the bare iron, in a amd64 multilib userspace, rather than a pure-i386 chroot on an amd64 kernel). $ git describe v5.3-rc8-36-ga7f89616b737 $ LANG= make ARCH=x86 -j1 bzImage modules CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h CHK kernel/kheaders_data.tar.xz CC [M] drivers/vhost/vhost.o In file included from ./include/linux/export.h:45, from ./include/linux/linkage.h:7, from ./include/linux/kernel.h:8, from ./include/linux/list.h:9, from ./include/linux/wait.h:7, from ./include/linux/eventfd.h:13, from drivers/vhost/vhost.c:13: drivers/vhost/vhost.c: In function 'translate_desc': ./include/linux/compiler.h:350:38: error: call to '__compiletime_assert_2076' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long) 350 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) | ^ ./include/linux/compiler.h:331:4: note: in definition of macro '__compiletime_assert' 331 |prefix ## suffix();\ |^~ ./include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert' 350 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) | ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~ ./include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~ ./include/linux/nospec.h:56:2: note: in expansion of macro 'BUILD_BUG_ON' 56 | BUILD_BUG_ON(sizeof(_s) > sizeof(long)); \ | ^~~~ drivers/vhost/vhost.c:2076:5: note: in expansion of macro 'array_index_nospec' 2076 | array_index_nospec((unsigned long)(addr - node->start), | ^~ make[2]: *** [scripts/Makefile.build:281: drivers/vhost/vhost.o] Error 1 make[1]: *** [scripts/Makefile.build:497: drivers/vhost] Error 2 make: *** [Makefile:1083: drivers] Error 2 $ git revert a89db445fbd7f1f8457b03759aa7343fa530ef6b $ LANG= make ARCH=x86 -j16 bzImage modules CALLscripts/atomic/check-atomics.sh CALLscripts/checksyscalls.sh CHK include/generated/compile.h CHK kernel/kheaders_data.tar.xz Building modules, stage 2. Kernel: arch/x86/boot/bzImage is ready (#1) MODPOST 3464 modules $ echo $? 0 $ find . -name vhost\\.ko ./drivers/vhost/vhost.ko I've attached the affected kernel config for v5.3~/ i386. Regards Stefan Lippers-Hollmann config-5.3-i386.xz Description: application/xz
Re: [PATCH 5.2 36/37] vhost: block speculation of translated descriptors
Hi On 2019-09-13, Greg Kroah-Hartman wrote: > From: Michael S. Tsirkin > > commit a89db445fbd7f1f8457b03759aa7343fa530ef6b upstream. > > iovec addresses coming from vhost are assumed to be > pre-validated, but in fact can be speculated to a value > out of range. > > Userspace address are later validated with array_index_nospec so we can > be sure kernel info does not leak through these addresses, but vhost > must also not leak userspace info outside the allowed memory table to > guests. > > Following the defence in depth principle, make sure > the address is not validated out of node range. [...] This fails to compile as part of 5.2.15-rc1 on i386 (amd64 is fine), using gcc 9.2.1. Reverting just this patch results in a successful build again. > --- a/drivers/vhost/vhost.c > +++ b/drivers/vhost/vhost.c > @@ -1965,8 +1965,10 @@ static int translate_desc(struct vhost_v > _iov = iov + ret; > size = node->size - addr + node->start; > _iov->iov_len = min((u64)len - s, size); > - _iov->iov_base = (void __user *)(unsigned long) > - (node->userspace_addr + addr - node->start); > + _iov->iov_base = (void __user *) > + ((unsigned long)node->userspace_addr + > + array_index_nospec((unsigned long)(addr - node->start), > + node->size)); > s += size; > addr += size; > ++ret; > > CC [M] drivers/vhost/vhost.o In file included from /build/linux-5.2/include/linux/export.h:45, from /build/linux-5.2/include/linux/linkage.h:7, from /build/linux-5.2/include/linux/kernel.h:8, from /build/linux-5.2/include/linux/list.h:9, from /build/linux-5.2/include/linux/wait.h:7, from /build/linux-5.2/include/linux/eventfd.h:13, from /build/linux-5.2/drivers/vhost/vhost.c:13: /build/linux-5.2/drivers/vhost/vhost.c: In function 'translate_desc': /build/linux-5.2/include/linux/compiler.h:345:38: error: call to '__compiletime_assert_1970' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long) 345 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) | ^ /build/linux-5.2/include/linux/compiler.h:326:4: note: in definition of macro '__compiletime_assert' 326 |prefix ## suffix();\ |^~ /build/linux-5.2/include/linux/compiler.h:345:2: note: in expansion of macro '_compiletime_assert' 345 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) | ^~~ /build/linux-5.2/include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~ /build/linux-5.2/include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~ /build/linux-5.2/include/linux/nospec.h:56:2: note: in expansion of macro 'BUILD_BUG_ON' 56 | BUILD_BUG_ON(sizeof(_s) > sizeof(long)); \ | ^~~~ /build/linux-5.2/drivers/vhost/vhost.c:1970:5: note: in expansion of macro 'array_index_nospec' 1970 | array_index_nospec((unsigned long)(addr - node->start), | ^~ make[3]: *** [/build/linux-5.2/scripts/Makefile.build:285: drivers/vhost/vhost.o] Error 1 make[2]: *** [/build/linux-5.2/scripts/Makefile.build:489: drivers/vhost] Error 2 make[1]: *** [/build/linux-5.2/Makefile:1072: drivers] Error 2 make: *** [/build/linux-5.2/Makefile:179: sub-make] Error 2 Regards Stefan Lippers-Hollmann
Re: [PATCH 5.2 000/135] 5.2.10-stable review
Hi On 2019-08-22, Greg KH wrote: > On Fri, Aug 23, 2019 at 12:05:27AM +0200, Stefan Lippers-Hollmann wrote: > > On 2019-08-22, Greg KH wrote: > > > On Thu, Aug 22, 2019 at 01:05:56PM -0400, Sasha Levin wrote: [...] > > It might be down to kernel.org mirroring, but the patch file doesn't > > seem to be available yet (404), both in the wrong location listed > > above - and the expected one under > > > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.10-rc1.gz [...] > Ah, no, it's not a mirroring problem, Sasha and I didn't know if anyone > was actually using the patch files anymore, so it was simpler to do a > release without them to see what happens. :) > > Do you rely on these, or can you use the -rc git tree or the quilt > series? If you do rely on them, we will work to fix this, it just > involves some scripting that we didn't get done this morning. "Rely" is a strong word, I can adapt if they're going away, but I've been using them so far, as in (slightly simplified): $ cd patches/upstream/ $ wget https://cdn.kernel.org/pub/linux/kernel/v5.x/patch-5.2.9.xz $ xz -d patch-5.2.9.xz $ wget https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.10-rc1.gz $ gunzip patch-5.2.10-rc1.gz $ vim ../series $ quilt ... I can switch to importing the quilt queue with some sed magic (and I already do that, if interesting or just a larger amounts of patches are queuing up for more than a day or two), but using the -rc patches has been convenient in that semi-manual workflow, also to make sure to really get and test the formal -rc patch, rather than something inbetween. ( When testing -rc patches under e.g. OpenWrt (ipq806x (ARMv7), ath79 (mips 74Kc), lantiq (mips 24Kc)), importing larger numbers of patches (which will go away two or three days later anyways) also easily gets a little unwieldy (adding sequence numbers, as the quilt series only gets assembled later, on the fly in alphabetical order), so I'd probably have to squash them together for those purposes myself - not a problem, just less convenient for quick ad-hoc testing. ) But again, none of these procedures are set in stone and I can adapt as needed - there've been bigger changes in the past and this is mostly about retraining muscle memory (and writing some simple new scripts to partially automate things). Thanks a lot for your efforts, the whole -stable maintenance has really improved kernel quality compared to the status quo ante. I'm testing basically each -rc kernel for the current -stable release (so only v5.2 at the moment) on x86_64 and x86, a bit less regularly on ipq8064/ ath79/ lantiq (v4.19 at the moment), but only reply if I actually notice an issue. Regards Stefan Lippers-Hollmann
Re: [PATCH 5.2 000/135] 5.2.10-stable review
Hi On 2019-08-22, Greg KH wrote: > On Thu, Aug 22, 2019 at 01:05:56PM -0400, Sasha Levin wrote: > > > > This is the start of the stable review cycle for the 5.2.10 release. [...] > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-5.2.10-rc1.gz ^v5.x [...] > If anyone notices anything that we messed up, please let us know. It might be down to kernel.org mirroring, but the patch file doesn't seem to be available yet (404), both in the wrong location listed above - and the expected one under https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.10-rc1.gz or https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.10-rc1.xz The v4.x based patches can be found just fine: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.190-rc1.gz https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.190-rc1.gz https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.140-rc1.gz https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.68-rc1.gz Regards Stefan Lippers-Hollmann
Re: Patch "KVM: VMX: avoid double list add with VT-d posted interrupts" has been added to the 4.13-stable tree
Hi On 2017-10-03, Paolo Bonzini wrote: > On 03/10/2017 09:46, Stefan Lippers-Hollmann wrote: > > On 2017-10-02, gre...@linuxfoundation.org wrote: > >> This is a note to let you know that I've just added the patch titled > >> > >> KVM: VMX: avoid double list add with VT-d posted interrupts > >> > >> to the 4.13-stable tree which can be found at: > >> > >> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > >> > >> The filename of the patch is: > >> kvm-vmx-avoid-double-list-add-with-vt-d-posted-interrupts.patch > >> and it can be found in the queue-4.13 subdirectory. > > > > This patch, as part of the current queue-4.13, breaks the build on > > i386 (amd64/ x86_64 builds fine): [...] > There is another patch in the kvm tree to fix it, I'll send it to stable > immediately. Thanks, I can confirm this to work in 4.13.5-rc1 (including "KVM: VMX: use cmpxchg64") for i386 and x86_64. Unrelated to this specific, solved, issue I can confirm kernel 4.9.53-rc1 to build and boot on armhf (ipq8065) and 4.4.90-rc1 on mips (ar71xx). Thanks a lot, regards Stefan Lippers-Hollmann
Re: Patch "KVM: VMX: avoid double list add with VT-d posted interrupts" has been added to the 4.13-stable tree
Hi On 2017-10-03, Paolo Bonzini wrote: > On 03/10/2017 09:46, Stefan Lippers-Hollmann wrote: > > On 2017-10-02, gre...@linuxfoundation.org wrote: > >> This is a note to let you know that I've just added the patch titled > >> > >> KVM: VMX: avoid double list add with VT-d posted interrupts > >> > >> to the 4.13-stable tree which can be found at: > >> > >> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > >> > >> The filename of the patch is: > >> kvm-vmx-avoid-double-list-add-with-vt-d-posted-interrupts.patch > >> and it can be found in the queue-4.13 subdirectory. > > > > This patch, as part of the current queue-4.13, breaks the build on > > i386 (amd64/ x86_64 builds fine): [...] > There is another patch in the kvm tree to fix it, I'll send it to stable > immediately. Thanks, I can confirm this to work in 4.13.5-rc1 (including "KVM: VMX: use cmpxchg64") for i386 and x86_64. Unrelated to this specific, solved, issue I can confirm kernel 4.9.53-rc1 to build and boot on armhf (ipq8065) and 4.4.90-rc1 on mips (ar71xx). Thanks a lot, regards Stefan Lippers-Hollmann
Re: Patch "KVM: VMX: avoid double list add with VT-d posted interrupts" has been added to the 4.13-stable tree
xchg' __cmpxchg(ptr, old, new, sizeof(*(ptr))) ^ /build/linux-aptosid-4.13/arch/x86/kvm/vmx.c:11422:11: note: in expansion of macro 'cmpxchg' } while (cmpxchg(_desc->control, old.control, ^~~ /build/linux-aptosid-4.13/scripts/Makefile.build:302: recipe for target 'arch/x86/kvm/vmx.o' failed make[7]: *** [arch/x86/kvm/vmx.o] Error 1 Reverting just these patches from queue-4.13 kvm-vmx-avoid-double-list-add-with-vt-d-posted-interrupts.patch kvm-vmx-simplify-and-fix-vmx_vcpu_pi_load.patch fixes the problem for me (tested on i386 and x86_64); the failing config for i386 is attached (xz compressed). Regards Stefan Lippers-Hollmann config-4.13.0-4.slh.2-aptosid-686.xz Description: application/xz
Re: Patch "KVM: VMX: avoid double list add with VT-d posted interrupts" has been added to the 4.13-stable tree
xchg' __cmpxchg(ptr, old, new, sizeof(*(ptr))) ^ /build/linux-aptosid-4.13/arch/x86/kvm/vmx.c:11422:11: note: in expansion of macro 'cmpxchg' } while (cmpxchg(_desc->control, old.control, ^~~ /build/linux-aptosid-4.13/scripts/Makefile.build:302: recipe for target 'arch/x86/kvm/vmx.o' failed make[7]: *** [arch/x86/kvm/vmx.o] Error 1 Reverting just these patches from queue-4.13 kvm-vmx-avoid-double-list-add-with-vt-d-posted-interrupts.patch kvm-vmx-simplify-and-fix-vmx_vcpu_pi_load.patch fixes the problem for me (tested on i386 and x86_64); the failing config for i386 is attached (xz compressed). Regards Stefan Lippers-Hollmann config-4.13.0-4.slh.2-aptosid-686.xz Description: application/xz
Re: [PATCH v3] pty: Repair TIOCGPTPEER
Hi On 2017-08-24, Eric W. Biederman wrote: > The implementation of TIOCGPTPEER has two issues. > > When /dev/ptmx (as opposed to /dev/pts/ptmx) is opened the wrong > vfsmount is passed to dentry_open. Which results in the kernel displaying > the wrong pathname for the peer. [...] > v2: Lots of fixes to make the code actually work > v3: Suggestions by Linus > - Removed the unnecessary initialization of filp in ptm_open_peer > - Simplified devpts_ptmx_path as gotos are no longer required This version of the patch is working for me as well in all my test (including pbuilder) so far, thanks a lot. Regards Stefan Lippers-Hollmann pgpwzn2D_Gl7T.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v3] pty: Repair TIOCGPTPEER
Hi On 2017-08-24, Eric W. Biederman wrote: > The implementation of TIOCGPTPEER has two issues. > > When /dev/ptmx (as opposed to /dev/pts/ptmx) is opened the wrong > vfsmount is passed to dentry_open. Which results in the kernel displaying > the wrong pathname for the peer. [...] > v2: Lots of fixes to make the code actually work > v3: Suggestions by Linus > - Removed the unnecessary initialization of filp in ptm_open_peer > - Simplified devpts_ptmx_path as gotos are no longer required This version of the patch is working for me as well in all my test (including pbuilder) so far, thanks a lot. Regards Stefan Lippers-Hollmann pgpwzn2D_Gl7T.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name
Hi [ sorry for the re-send, this accidentally only reached you, rather than the mailing list and the other recipients as well ] On 2017-08-24, Linus Torvalds wrote: > On Thu, Aug 24, 2017 at 11:31 AM, Linus Torvalds > <torva...@linux-foundation.org> wrote: > > > > It should just do a "return ptm_open_peer(file, tty, (int)arg);" instead. > > Here's the actual tested patch. It "WorksForMe(tm)", including the > TIOCGPTPEER ioctl, and also verified that it gets the pathname right > in /proc, which was the original problem. > > But I did *not* check that pbuilder is still happy. Stefan? This patch seems to work, ssh, xterm (konsole5), real tty and pbuilder (creating- and updating the build chroots, just as well as building several fairly involved packages) are fine with this patch on top of v4.13-rc6-66-g143c97cc6529 (tested on x86_64). Thanks a lot Stefan Lippers-Hollmann
Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name
Hi [ sorry for the re-send, this accidentally only reached you, rather than the mailing list and the other recipients as well ] On 2017-08-24, Linus Torvalds wrote: > On Thu, Aug 24, 2017 at 11:31 AM, Linus Torvalds > wrote: > > > > It should just do a "return ptm_open_peer(file, tty, (int)arg);" instead. > > Here's the actual tested patch. It "WorksForMe(tm)", including the > TIOCGPTPEER ioctl, and also verified that it gets the pathname right > in /proc, which was the original problem. > > But I did *not* check that pbuilder is still happy. Stefan? This patch seems to work, ssh, xterm (konsole5), real tty and pbuilder (creating- and updating the build chroots, just as well as building several fairly involved packages) are fine with this patch on top of v4.13-rc6-66-g143c97cc6529 (tested on x86_64). Thanks a lot Stefan Lippers-Hollmann
Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name
Hi On 2017-08-23, Eric W. Biederman wrote: > Linus Torvalds <torva...@linux-foundation.org> writes: > > On Wed, Aug 23, 2017 at 6:49 PM, Linus Torvalds > > <torva...@linux-foundation.org> wrote: [...] > This is so far untested (except for compiling) but I think this will > work. > > I factor out devpts_ptmx_path out of devpts_acquire so the code > doesn't have to do unnecessary and confusing work, and add the > new function devpts_mnt. > > I revert the code to keep anything except a dentry in > tty->link->driver_data. > > And reduce the peer opening to a single function ptm_open_peer. > > It takes lines of code but the result is very straightforward code. I've given this a quick test, while it seems to fix the initial problem with umounting /dev/ptmx, it does introduce a new one - trying to open an xterm (KDE5's konsole to be exact) doesn't open a shell (the shell window remains totally empty) and trying to ssh into the system fails with "PTY allocation request failed on channel 0", logging in via a real tty and creating a new pbuilder chroot from there succeeds. Regards Stefan Lippers-Hollmann pgpI8qaz3RlGW.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name
Hi On 2017-08-23, Eric W. Biederman wrote: > Linus Torvalds writes: > > On Wed, Aug 23, 2017 at 6:49 PM, Linus Torvalds > > wrote: [...] > This is so far untested (except for compiling) but I think this will > work. > > I factor out devpts_ptmx_path out of devpts_acquire so the code > doesn't have to do unnecessary and confusing work, and add the > new function devpts_mnt. > > I revert the code to keep anything except a dentry in > tty->link->driver_data. > > And reduce the peer opening to a single function ptm_open_peer. > > It takes lines of code but the result is very straightforward code. I've given this a quick test, while it seems to fix the initial problem with umounting /dev/ptmx, it does introduce a new one - trying to open an xterm (KDE5's konsole to be exact) doesn't open a shell (the shell window remains totally empty) and trying to ssh into the system fails with "PTY allocation request failed on channel 0", logging in via a real tty and creating a new pbuilder chroot from there succeeds. Regards Stefan Lippers-Hollmann pgpI8qaz3RlGW.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name
Hi On 2017-08-16, Linus Torvalds wrote: > On Wed, Aug 16, 2017 at 4:51 PM, Eric W. Biederman > <ebied...@xmission.com> wrote: [...] > Maybe this attached patch is better anyway. It's smaller, because it > keeps more closely to the old code, and just adds a mntput() in all > the exit cases, and depends on the "path_get()" to have incremented > the mnt refcount one extra time. > > Can you find something in this one? > > ENTIRELY UNTESTED! This patch[1] as part of 4.13-rc6 (up to, at least, v4.13-rc6-45-g6470812e2226) introduces a regression for me when using pbuilder 0.228.7[2] (a helper to build Debian packages in a chroot and to create and update its chroots) when trying to umount /dev/ptmx (inside the chroot) on Debian/ unstable (full log and pbuilder configuration file[3] attached). [...] Setting up build-essential (12.3) ... Processing triggers for libc-bin (2.24-15) ... I: unmounting dev/ptmx filesystem W: Could not unmount dev/ptmx: umount: /var/cache/pbuilder/build/1340/dev/ptmx: target is busy (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1).) W: Retrying to unmount dev/ptmx in 5s umount: /var/cache/pbuilder/build/1340/dev/ptmx: target is busy (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1).) Could not unmount dev/ptmx, some programs might still be using files in /proc (klogd?). Please check and kill these processes manually so that I can unmount dev/ptmx. Last umount error was: umount: /var/cache/pbuilder/build/1340/dev/ptmx: target is busy (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1).) [...] lsof isn't revealing (but this might point towards gvfs 1.30.4-1+b1 involvement), fuser -k doesn't release the ressource. Kernel v4.13-rc5 and before (at least 4.11.x and 4.12.x) are not affected, but this problem is reliably reproducible on three different x86_64 systems running Debian/ unstable when the host is running a kernel >=4.6.13-rc6. Unfortunately I haven't really found an easier/ smaller way to reproduce this issue yet, but creating a new build chroot[4] always triggers this problem, updating an existing build chroot[5] (which also mounts and umounts /dev/ptmx) triggers most of the time, but not reliably - building a package (e.g. the kernel, also mounting and umounting /dev/ptmx) also triggered this issue at least once (but I didn't try this more often). My git bisection log is this: $ git bisect log git bisect start # good: [ef954844c7ace62f773f4f23e28d2d915adc419f] Linux 4.13-rc5 git bisect good ef954844c7ace62f773f4f23e28d2d915adc419f # bad: [14ccee78fc82f5512908f4424f541549a5705b89] Linux 4.13-rc6 git bisect bad 14ccee78fc82f5512908f4424f541549a5705b89 # bad: [cb247857f3dae0bdb843362c35027a0066b963a4] Merge tag 'sound-4.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect bad cb247857f3dae0bdb843362c35027a0066b963a4 # good: [88a5c690b66110ad255380d8f629c629cf6ca559] bpf: fix bpf_trace_printk on 32 bit archs git bisect good 88a5c690b66110ad255380d8f629c629cf6ca559 # bad: [3bc6c906eacec34f0d8dcfd3c7e4513edf152297] Merge branch 'parisc-4.13-5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux git bisect bad 3bc6c906eacec34f0d8dcfd3c7e4513edf152297 # good: [40c6d1b9e2fc4251ca19fa69398f6fa34e813e27] Merge tag 'linux-kselftest-4.13-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest git bisect good 40c6d1b9e2fc4251ca19fa69398f6fa34e813e27 # good: [ac9a40905a610fb02086a37b11ff4bf046825a88] Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi git bisect good ac9a40905a610fb02086a37b11ff4bf046825a88 # bad: [99f781b1bfc199ec8eb86d4e015920faf79d5d57] Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs git bisect bad 99f781b1bfc199ec8eb86d4e015920faf79d5d57 # good: [41e327b586762833e48b3703d53312ac32f05f24] quota: correct space limit check git bisect good 41e327b586762833e48b3703d53312ac32f05f24 Reverting just c8c03f1858331e85d397bacccd34ef409aae993c from v4.13-rc6-65-g2acf097f16ab reliably fixes the problem for me. Regards Stefan Lippers-Hollmann [1] commit c8c03f1858331e85d397bacccd34ef409aae993c (HEAD) Author: Linus Torvalds <torva...@linux-foundation.org> Date: Wed Aug 16 17:08:07 2017 -0700 Subject: pty: fix the cached path of the pty slave file descriptor in the master [2] https://packages.qa.debian.org/p/pbuilder.html https://pbuilder.alioth.debian.org/ https://anonscm.debian.org/git/pbuilder/pbuilder.git mounting/ umounting /dev/ptmx happens in https://anonscm.debian.org/git/pbuilder/pbuilder.git/tree/pbuilder-modules [3] the configuration file as attached relies on BUILDUSERN
Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name
Hi On 2017-08-16, Linus Torvalds wrote: > On Wed, Aug 16, 2017 at 4:51 PM, Eric W. Biederman > wrote: [...] > Maybe this attached patch is better anyway. It's smaller, because it > keeps more closely to the old code, and just adds a mntput() in all > the exit cases, and depends on the "path_get()" to have incremented > the mnt refcount one extra time. > > Can you find something in this one? > > ENTIRELY UNTESTED! This patch[1] as part of 4.13-rc6 (up to, at least, v4.13-rc6-45-g6470812e2226) introduces a regression for me when using pbuilder 0.228.7[2] (a helper to build Debian packages in a chroot and to create and update its chroots) when trying to umount /dev/ptmx (inside the chroot) on Debian/ unstable (full log and pbuilder configuration file[3] attached). [...] Setting up build-essential (12.3) ... Processing triggers for libc-bin (2.24-15) ... I: unmounting dev/ptmx filesystem W: Could not unmount dev/ptmx: umount: /var/cache/pbuilder/build/1340/dev/ptmx: target is busy (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1).) W: Retrying to unmount dev/ptmx in 5s umount: /var/cache/pbuilder/build/1340/dev/ptmx: target is busy (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1).) Could not unmount dev/ptmx, some programs might still be using files in /proc (klogd?). Please check and kill these processes manually so that I can unmount dev/ptmx. Last umount error was: umount: /var/cache/pbuilder/build/1340/dev/ptmx: target is busy (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1).) [...] lsof isn't revealing (but this might point towards gvfs 1.30.4-1+b1 involvement), fuser -k doesn't release the ressource. Kernel v4.13-rc5 and before (at least 4.11.x and 4.12.x) are not affected, but this problem is reliably reproducible on three different x86_64 systems running Debian/ unstable when the host is running a kernel >=4.6.13-rc6. Unfortunately I haven't really found an easier/ smaller way to reproduce this issue yet, but creating a new build chroot[4] always triggers this problem, updating an existing build chroot[5] (which also mounts and umounts /dev/ptmx) triggers most of the time, but not reliably - building a package (e.g. the kernel, also mounting and umounting /dev/ptmx) also triggered this issue at least once (but I didn't try this more often). My git bisection log is this: $ git bisect log git bisect start # good: [ef954844c7ace62f773f4f23e28d2d915adc419f] Linux 4.13-rc5 git bisect good ef954844c7ace62f773f4f23e28d2d915adc419f # bad: [14ccee78fc82f5512908f4424f541549a5705b89] Linux 4.13-rc6 git bisect bad 14ccee78fc82f5512908f4424f541549a5705b89 # bad: [cb247857f3dae0bdb843362c35027a0066b963a4] Merge tag 'sound-4.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect bad cb247857f3dae0bdb843362c35027a0066b963a4 # good: [88a5c690b66110ad255380d8f629c629cf6ca559] bpf: fix bpf_trace_printk on 32 bit archs git bisect good 88a5c690b66110ad255380d8f629c629cf6ca559 # bad: [3bc6c906eacec34f0d8dcfd3c7e4513edf152297] Merge branch 'parisc-4.13-5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux git bisect bad 3bc6c906eacec34f0d8dcfd3c7e4513edf152297 # good: [40c6d1b9e2fc4251ca19fa69398f6fa34e813e27] Merge tag 'linux-kselftest-4.13-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest git bisect good 40c6d1b9e2fc4251ca19fa69398f6fa34e813e27 # good: [ac9a40905a610fb02086a37b11ff4bf046825a88] Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi git bisect good ac9a40905a610fb02086a37b11ff4bf046825a88 # bad: [99f781b1bfc199ec8eb86d4e015920faf79d5d57] Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs git bisect bad 99f781b1bfc199ec8eb86d4e015920faf79d5d57 # good: [41e327b586762833e48b3703d53312ac32f05f24] quota: correct space limit check git bisect good 41e327b586762833e48b3703d53312ac32f05f24 Reverting just c8c03f1858331e85d397bacccd34ef409aae993c from v4.13-rc6-65-g2acf097f16ab reliably fixes the problem for me. Regards Stefan Lippers-Hollmann [1] commit c8c03f1858331e85d397bacccd34ef409aae993c (HEAD) Author: Linus Torvalds Date: Wed Aug 16 17:08:07 2017 -0700 Subject: pty: fix the cached path of the pty slave file descriptor in the master [2] https://packages.qa.debian.org/p/pbuilder.html https://pbuilder.alioth.debian.org/ https://anonscm.debian.org/git/pbuilder/pbuilder.git mounting/ umounting /dev/ptmx happens in https://anonscm.debian.org/git/pbuilder/pbuilder.git/tree/pbuilder-modules [3] the configuration file as attached relies on BUILDUSERNAME="pbuilder" and BUILDUSERID="$(getent
Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
Hi On 2016-07-22, Arnd Bergmann wrote: > On Friday, July 22, 2016 7:55:36 AM CEST Jes Sorensen wrote: > > Stefan Lippers-Hollmann <s@gmx.de> writes: > > > On 2016-07-20, Arnd Bergmann wrote: > > >> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: > > >> > Arnd Bergmann <a...@arndb.de> writes: > > >> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > > >> > >> Arnd Bergmann <a...@arndb.de> writes: [...] > > > While probably not overly common, it was/ is (hardware-wise) a pretty > > > interesting device due to its support for 5 GHz[1] - actually I hoped > > > it to be a (supported-) RTL8192CU variant when I bought it. > > > Unfortunately no driver[2] made it to staging or the proper kernel. > > > > I actually have one of those in my USB dongle box, but as you say, not > > overly common so not sure if/when I'll get to it. > > > > Adding 8192du support for 2.4GHz to rtl8xxxu probably wouldn't be too > > complicated. > > My guess is that these devices have largely been replaced by > 802.11ac devices on the market, and whoever has one of the old ones > probably bought it because of the 5GHz support, so adding 2.4GHz-only > support for it may not help all that much either. Talking purely for myself, I've certainly bought the rtl8192du device because of its 5 GHz support, as I've made it a fairly hard policy for me not to buy 2.4 GHz only devices anymore. But this doesn't mean that a mainline driver only supporting 2.4 GHz for the time being would not be appreciated dearly, given that the current state of the device is pretty much being a doorstop[1] - especially considering that 5 GHz support might even become a possibility at a later time, when 802.11ac devices start demanding most of the functionality for potentially more common newer chipset generations. So even with my current personal policy of only buying 5 GHz capable devices, in practice you probably won't find 5 GHz only AP installations (aside from long range/ outdoor point-to-point connections), be it because of the plethora of existing 2.4 GHz only devices or just because of the longer indoor (walls) range of the 2.4 GHz band. In practice, by far most of my existing wireless devices don't support 5 GHz (the router does, of course) because of the reasons mentioned above, but replacing older devices takes its time. Regards Stefan Lippers-Hollmann [1] yes, I know about https://github.com/lwfinger/rtl8192du/ and even have a couple of clean-up patches pending[2] for the kernel-version branch, but those need some further testing. [2] http://aptosid.com/slh/rtl8192du/kernel-version/
Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
Hi On 2016-07-22, Arnd Bergmann wrote: > On Friday, July 22, 2016 7:55:36 AM CEST Jes Sorensen wrote: > > Stefan Lippers-Hollmann writes: > > > On 2016-07-20, Arnd Bergmann wrote: > > >> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: > > >> > Arnd Bergmann writes: > > >> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > > >> > >> Arnd Bergmann writes: [...] > > > While probably not overly common, it was/ is (hardware-wise) a pretty > > > interesting device due to its support for 5 GHz[1] - actually I hoped > > > it to be a (supported-) RTL8192CU variant when I bought it. > > > Unfortunately no driver[2] made it to staging or the proper kernel. > > > > I actually have one of those in my USB dongle box, but as you say, not > > overly common so not sure if/when I'll get to it. > > > > Adding 8192du support for 2.4GHz to rtl8xxxu probably wouldn't be too > > complicated. > > My guess is that these devices have largely been replaced by > 802.11ac devices on the market, and whoever has one of the old ones > probably bought it because of the 5GHz support, so adding 2.4GHz-only > support for it may not help all that much either. Talking purely for myself, I've certainly bought the rtl8192du device because of its 5 GHz support, as I've made it a fairly hard policy for me not to buy 2.4 GHz only devices anymore. But this doesn't mean that a mainline driver only supporting 2.4 GHz for the time being would not be appreciated dearly, given that the current state of the device is pretty much being a doorstop[1] - especially considering that 5 GHz support might even become a possibility at a later time, when 802.11ac devices start demanding most of the functionality for potentially more common newer chipset generations. So even with my current personal policy of only buying 5 GHz capable devices, in practice you probably won't find 5 GHz only AP installations (aside from long range/ outdoor point-to-point connections), be it because of the plethora of existing 2.4 GHz only devices or just because of the longer indoor (walls) range of the 2.4 GHz band. In practice, by far most of my existing wireless devices don't support 5 GHz (the router does, of course) because of the reasons mentioned above, but replacing older devices takes its time. Regards Stefan Lippers-Hollmann [1] yes, I know about https://github.com/lwfinger/rtl8192du/ and even have a couple of clean-up patches pending[2] for the kernel-version branch, but those need some further testing. [2] http://aptosid.com/slh/rtl8192du/kernel-version/
Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
Hi On 2016-07-20, Arnd Bergmann wrote: > On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: > > Arnd Bergmann <a...@arndb.de> writes: > > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > > >> Arnd Bergmann <a...@arndb.de> writes: [...] > Yes, I was just agreeing here that it's not worth doing that one. > As far as I can see, the evolution of these devices is > > RTL81xxU (2008) > RTL81xxSU (2009) > RTL81xxCU (2010) There is also RTL81xxDU, apparently from 2011, a dualband device coming in several variants (single MAC + single PHY, double MAC + double PHY and double PHY); e.g. 0bda:8194 (single PHY + single MAC). While probably not overly common, it was/ is (hardware-wise) a pretty interesting device due to its support for 5 GHz[1] - actually I hoped it to be a (supported-) RTL8192CU variant when I bought it. Unfortunately no driver[2] made it to staging or the proper kernel. > RTL81xxEU (2013) Regards Stefan Lippers-Hollmann [1] apparently even concurrent operations for the double MAC + double PHY variants [2] https://github.com/lwfinger/rtl8192du pgpOruvwcTbts.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
Hi On 2016-07-20, Arnd Bergmann wrote: > On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: > > Arnd Bergmann writes: > > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > > >> Arnd Bergmann writes: [...] > Yes, I was just agreeing here that it's not worth doing that one. > As far as I can see, the evolution of these devices is > > RTL81xxU (2008) > RTL81xxSU (2009) > RTL81xxCU (2010) There is also RTL81xxDU, apparently from 2011, a dualband device coming in several variants (single MAC + single PHY, double MAC + double PHY and double PHY); e.g. 0bda:8194 (single PHY + single MAC). While probably not overly common, it was/ is (hardware-wise) a pretty interesting device due to its support for 5 GHz[1] - actually I hoped it to be a (supported-) RTL8192CU variant when I bought it. Unfortunately no driver[2] made it to staging or the proper kernel. > RTL81xxEU (2013) Regards Stefan Lippers-Hollmann [1] apparently even concurrent operations for the double MAC + double PHY variants [2] https://github.com/lwfinger/rtl8192du pgpOruvwcTbts.pgp Description: Digitale Signatur von OpenPGP
Re: [GIT PULL for v4.6-rc1] media updates
Hi On 2016-05-05, Mauro Carvalho Chehab wrote: > Em Thu, 5 May 2016 01:00:51 +0200 > Stefan Lippers-Hollmann <s@gmx.de> escreveu: [...] > Oh, in this case, it should be using IS_ENABLED() macro instead. > The following patch should fix it. I tested here with some different > setups, as described in the patch, and with your .i686 .config. > > Please double-check and ack if it is ok for you. > > Regards, > Mauro > > > [PATCH v2] [media] media-device: fix builds when USB or PCI is compiled > as module > > Just checking ifdef CONFIG_USB is not enough, if the USB is compiled > as module. The same applies to PCI. [...] This patch works for me, both on amd64 and i386, tested with dvb_usb_dw2102, dvb_usb_af9015 and dvb_usb_rtl28xxu. > Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com> Feel free to add Tested-by: Stefan Lippers-Hollmann <s@gmx.de> Thanks a lot. Regards Stefan Lippers-Hollmann pgpYD5Wrf24CA.pgp Description: Digitale Signatur von OpenPGP
Re: [GIT PULL for v4.6-rc1] media updates
Hi On 2016-05-05, Mauro Carvalho Chehab wrote: > Em Thu, 5 May 2016 01:00:51 +0200 > Stefan Lippers-Hollmann escreveu: [...] > Oh, in this case, it should be using IS_ENABLED() macro instead. > The following patch should fix it. I tested here with some different > setups, as described in the patch, and with your .i686 .config. > > Please double-check and ack if it is ok for you. > > Regards, > Mauro > > > [PATCH v2] [media] media-device: fix builds when USB or PCI is compiled > as module > > Just checking ifdef CONFIG_USB is not enough, if the USB is compiled > as module. The same applies to PCI. [...] This patch works for me, both on amd64 and i386, tested with dvb_usb_dw2102, dvb_usb_af9015 and dvb_usb_rtl28xxu. > Signed-off-by: Mauro Carvalho Chehab Feel free to add Tested-by: Stefan Lippers-Hollmann Thanks a lot. Regards Stefan Lippers-Hollmann pgpYD5Wrf24CA.pgp Description: Digitale Signatur von OpenPGP
Re: [GIT PULL for v4.6-rc1] media updates
Hi
On 2016-05-04, Mauro Carvalho Chehab wrote:
> Em Wed, 4 May 2016 13:49:52 -0700
> Linus Torvalds <torva...@linux-foundation.org> escreveu:
> > On Wed, May 4, 2016 at 12:28 PM, Stefan Lippers-Hollmann <s@gmx.de>
> > wrote:
[...]
> Stefan,
>
> Could you please test the enclosed patch?
>
> Regards,
> Mauro
>
> [media] media-device: fix builds when USB or PCI is compiled as module
>
> Just checking ifdef CONFIG_USB is not enough, if the USB is compiled
> as module. The same applies to PCI.
>
> Compile-tested only.
>
> So, change the logic to use, instead, IS_REACHABLE.
>
> Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com>
>
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index b84825715f98..8c1f80ff33e3 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -842,11 +842,11 @@ struct media_device *media_device_find_devres(struct
> device *dev)
> }
> EXPORT_SYMBOL_GPL(media_device_find_devres);
>
> +#if IS_REACHABLE(CONFIG_PCI)
> void media_device_pci_init(struct media_device *mdev,
> struct pci_dev *pci_dev,
> const char *name)
> {
> -#ifdef CONFIG_PCI
> mdev->dev = _dev->dev;
>
> if (name)
> @@ -862,16 +862,16 @@ void media_device_pci_init(struct media_device *mdev,
> mdev->driver_version = LINUX_VERSION_CODE;
>
> media_device_init(mdev);
> -#endif
> }
> EXPORT_SYMBOL_GPL(media_device_pci_init);
> +#endif
>
> +#if IS_REACHABLE(CONFIG_USB)
> void __media_device_usb_init(struct media_device *mdev,
>struct usb_device *udev,
>const char *board_name,
>const char *driver_name)
> {
> -#ifdef CONFIG_USB
> mdev->dev = >dev;
>
> if (driver_name)
> @@ -891,9 +891,9 @@ void __media_device_usb_init(struct media_device *mdev,
> mdev->driver_version = LINUX_VERSION_CODE;
>
> media_device_init(mdev);
> -#endif
> }
> EXPORT_SYMBOL_GPL(__media_device_usb_init);
> +#endif
>
>
> #endif /* CONFIG_MEDIA_CONTROLLER */
>
>
This fails to build for me with:
[...]
Setup is 16348 bytes (padded to 16384 bytes).
System is 3319 kB
CRC a9178215
Kernel: arch/x86/boot/bzImage is ready (#1)
ERROR: "__media_device_usb_init" [drivers/media/usb/siano/smsusb.ko] undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/em28xx/em28xx.ko] undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/dvb-usb/dvb-usb.ko]
undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/dvb-usb-v2/dvb_usb_v2.ko]
undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/cx231xx/cx231xx.ko]
undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/au0828/au0828.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[6]: *** [__modpost] Error 1
Makefile:1147: recipe for target 'modules' failed
[...]
I've attached my gzipped kernel configs for amd64 and i386.
Regards
Stefan Lippers-Hollmann
config-686.gz
Description: application/gzip
config-amd64.gz
Description: application/gzip
pgpqsajuSDcvI.pgp
Description: Digitale Signatur von OpenPGP
Re: [GIT PULL for v4.6-rc1] media updates
Hi
On 2016-05-04, Mauro Carvalho Chehab wrote:
> Em Wed, 4 May 2016 13:49:52 -0700
> Linus Torvalds escreveu:
> > On Wed, May 4, 2016 at 12:28 PM, Stefan Lippers-Hollmann
> > wrote:
[...]
> Stefan,
>
> Could you please test the enclosed patch?
>
> Regards,
> Mauro
>
> [media] media-device: fix builds when USB or PCI is compiled as module
>
> Just checking ifdef CONFIG_USB is not enough, if the USB is compiled
> as module. The same applies to PCI.
>
> Compile-tested only.
>
> So, change the logic to use, instead, IS_REACHABLE.
>
> Signed-off-by: Mauro Carvalho Chehab
>
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index b84825715f98..8c1f80ff33e3 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -842,11 +842,11 @@ struct media_device *media_device_find_devres(struct
> device *dev)
> }
> EXPORT_SYMBOL_GPL(media_device_find_devres);
>
> +#if IS_REACHABLE(CONFIG_PCI)
> void media_device_pci_init(struct media_device *mdev,
> struct pci_dev *pci_dev,
> const char *name)
> {
> -#ifdef CONFIG_PCI
> mdev->dev = _dev->dev;
>
> if (name)
> @@ -862,16 +862,16 @@ void media_device_pci_init(struct media_device *mdev,
> mdev->driver_version = LINUX_VERSION_CODE;
>
> media_device_init(mdev);
> -#endif
> }
> EXPORT_SYMBOL_GPL(media_device_pci_init);
> +#endif
>
> +#if IS_REACHABLE(CONFIG_USB)
> void __media_device_usb_init(struct media_device *mdev,
>struct usb_device *udev,
>const char *board_name,
>const char *driver_name)
> {
> -#ifdef CONFIG_USB
> mdev->dev = >dev;
>
> if (driver_name)
> @@ -891,9 +891,9 @@ void __media_device_usb_init(struct media_device *mdev,
> mdev->driver_version = LINUX_VERSION_CODE;
>
> media_device_init(mdev);
> -#endif
> }
> EXPORT_SYMBOL_GPL(__media_device_usb_init);
> +#endif
>
>
> #endif /* CONFIG_MEDIA_CONTROLLER */
>
>
This fails to build for me with:
[...]
Setup is 16348 bytes (padded to 16384 bytes).
System is 3319 kB
CRC a9178215
Kernel: arch/x86/boot/bzImage is ready (#1)
ERROR: "__media_device_usb_init" [drivers/media/usb/siano/smsusb.ko] undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/em28xx/em28xx.ko] undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/dvb-usb/dvb-usb.ko]
undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/dvb-usb-v2/dvb_usb_v2.ko]
undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/cx231xx/cx231xx.ko]
undefined!
ERROR: "__media_device_usb_init" [drivers/media/usb/au0828/au0828.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[6]: *** [__modpost] Error 1
Makefile:1147: recipe for target 'modules' failed
[...]
I've attached my gzipped kernel configs for amd64 and i386.
Regards
Stefan Lippers-Hollmann
config-686.gz
Description: application/gzip
config-amd64.gz
Description: application/gzip
pgpqsajuSDcvI.pgp
Description: Digitale Signatur von OpenPGP
Re: [GIT PULL for v4.6-rc1] media updates
Hi
On 2016-05-04, Linus Torvalds wrote:
> On Wed, May 4, 2016 at 12:28 PM, Stefan Lippers-Hollmann <s@gmx.de> wrote:
> >
> > --- a/drivers/media/media-device.c
> > +++ b/drivers/media/media-device.c
> > @@ -875,7 +875,7 @@ void __media_device_usb_init(struct medi
> > const char *board_name,
> > const char *driver_name)
> > {
> > -#ifdef CONFIG_USB
> > +#if defined(CONFIG_USB) || defined(CONFIG_USB_MODULE)
>
> Ok, that should be fine. Can you verify that it builds and works even
> if USB isn't compiled in, but the media core code is?
>
> IOW, can you test the
>
> CONFIG_USB=m
> CONFIG_MEDIA_CONTROLLER=y
> CONFIG_MEDIA_SUPPORT=y
Builds (without warnings in drivers/media/media-device.*) and works fine
as well.
> case? Judging by your oops stack trace, I think you currently have
> MEDIA_SUPPORT=m.
My usual configuration (which, as mentioned in the previous mail, now
builds and works as well) is:
CONFIG_MEDIA_SUPPORT=m
CONFIG_MEDIA_CONTROLLER=y
CONFIG_USB=m
> Also, I do wonder if we should move that #if to _outside_ the
> function. Because inside the function, things will compile but
> silently not work (like you found), if it is ever mis-used. Outside
> that function, you'll get link-errors if you try to misuse that
> function.
That would probably be the best approach.
Regards
Stefan Lippers-Hollmann
Re: [GIT PULL for v4.6-rc1] media updates
Hi
On 2016-05-04, Linus Torvalds wrote:
> On Wed, May 4, 2016 at 12:28 PM, Stefan Lippers-Hollmann wrote:
> >
> > --- a/drivers/media/media-device.c
> > +++ b/drivers/media/media-device.c
> > @@ -875,7 +875,7 @@ void __media_device_usb_init(struct medi
> > const char *board_name,
> > const char *driver_name)
> > {
> > -#ifdef CONFIG_USB
> > +#if defined(CONFIG_USB) || defined(CONFIG_USB_MODULE)
>
> Ok, that should be fine. Can you verify that it builds and works even
> if USB isn't compiled in, but the media core code is?
>
> IOW, can you test the
>
> CONFIG_USB=m
> CONFIG_MEDIA_CONTROLLER=y
> CONFIG_MEDIA_SUPPORT=y
Builds (without warnings in drivers/media/media-device.*) and works fine
as well.
> case? Judging by your oops stack trace, I think you currently have
> MEDIA_SUPPORT=m.
My usual configuration (which, as mentioned in the previous mail, now
builds and works as well) is:
CONFIG_MEDIA_SUPPORT=m
CONFIG_MEDIA_CONTROLLER=y
CONFIG_USB=m
> Also, I do wonder if we should move that #if to _outside_ the
> function. Because inside the function, things will compile but
> silently not work (like you found), if it is ever mis-used. Outside
> that function, you'll get link-errors if you try to misuse that
> function.
That would probably be the best approach.
Regards
Stefan Lippers-Hollmann
Re: [GIT PULL for v4.6-rc1] media updates
Hi
On 2016-05-04, Linus Torvalds wrote:
> On Tue, May 3, 2016 at 9:39 PM, Stefan Lippers-Hollmann <s@gmx.de> wrote:
> >
> > Just as a cross-check, this (incomplete, but au0828, cx231xx and em28xx
> > aren't needed/ loaded on my system) crude revert avoids the problem for
> > me on v4.6-rc6-113-g83858a7.
>
> Hmm.
>
> That just open-codes __media_device_usb_init().
>
> The main difference seems to be that __media_device_usb_init() ends up
> having that
>
> #ifdef CONFIG_USB
> #endif
>
> around it.
>
> I think that is bogus.
>
> What happens if you replace that #ifdef CONFIG_USB in
> __media_device_usb_init() with
>
> #if CONFIG_USB || (MODULE && CONFIG_USB_MODULE)
[...]
that throws
drivers/media/media-device.c: In function '__media_device_usb_init':
drivers/media/media-device.c:878:5: warning: "CONFIG_USB" is not defined
[-Wundef]
#if CONFIG_USB || (MODULE && CONFIG_USB_MODULE)
^
however, taking arch/arm/mach-omap1/include/mach/usb.h as example,
changing it to
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -875,7 +875,7 @@ void __media_device_usb_init(struct medi
const char *board_name,
const char *driver_name)
{
-#ifdef CONFIG_USB
+#if defined(CONFIG_USB) || defined(CONFIG_USB_MODULE)
mdev->dev = >dev;
if (driver_name)
indeed fixes the problem for me
Thanks a lot!
Regards
Stefan Lippers-Hollmann
pgpirgaIpu401.pgp
Description: Digitale Signatur von OpenPGP
Re: [GIT PULL for v4.6-rc1] media updates
Hi
On 2016-05-04, Linus Torvalds wrote:
> On Tue, May 3, 2016 at 9:39 PM, Stefan Lippers-Hollmann wrote:
> >
> > Just as a cross-check, this (incomplete, but au0828, cx231xx and em28xx
> > aren't needed/ loaded on my system) crude revert avoids the problem for
> > me on v4.6-rc6-113-g83858a7.
>
> Hmm.
>
> That just open-codes __media_device_usb_init().
>
> The main difference seems to be that __media_device_usb_init() ends up
> having that
>
> #ifdef CONFIG_USB
> #endif
>
> around it.
>
> I think that is bogus.
>
> What happens if you replace that #ifdef CONFIG_USB in
> __media_device_usb_init() with
>
> #if CONFIG_USB || (MODULE && CONFIG_USB_MODULE)
[...]
that throws
drivers/media/media-device.c: In function '__media_device_usb_init':
drivers/media/media-device.c:878:5: warning: "CONFIG_USB" is not defined
[-Wundef]
#if CONFIG_USB || (MODULE && CONFIG_USB_MODULE)
^
however, taking arch/arm/mach-omap1/include/mach/usb.h as example,
changing it to
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -875,7 +875,7 @@ void __media_device_usb_init(struct medi
const char *board_name,
const char *driver_name)
{
-#ifdef CONFIG_USB
+#if defined(CONFIG_USB) || defined(CONFIG_USB_MODULE)
mdev->dev = >dev;
if (driver_name)
indeed fixes the problem for me
Thanks a lot!
Regards
Stefan Lippers-Hollmann
pgpirgaIpu401.pgp
Description: Digitale Signatur von OpenPGP
Re: [GIT PULL for v4.6-rc1] media updates
Hi On 2016-05-03, Linus Torvalds wrote: > On Tue, May 3, 2016 at 2:38 PM, Stefan Lippers-Hollmann <s@gmx.de> wrote: > > Hi > > [...] > >> Mauro Carvalho Chehab (95): > > [...] > >> [media] use v4l2_mc_usb_media_device_init() on most USB devices > > [...] > > > > This change, as part of v4.6-rc6-85-g1248ded, breaks two systems, each > > equipped with a TeVii s480 (dvb_usb_dw2102) DVB-S2 card, for me (kernel > > v4.5.3-rc1 is fine): > > From the oops it looks like the "->prev" pointer in one of the list > heads in 'mdev' is NULL. > > > [5.041915] BUG: unable to handle kernel NULL pointer dereference at > > (null) > > [5.041921] IP: [] media_gobj_create+0xb8/0x100 > > [media] > > I can't tell *which* list head it is, but it looks like there's a > missing call to media_device_init() which is what should have > initialized those list heads. > > Of course, maybe that list pointer got initialized but then > overwritten by NULL for some other reason. Just as a cross-check, this (incomplete, but au0828, cx231xx and em28xx aren't needed/ loaded on my system) crude revert avoids the problem for me on v4.6-rc6-113-g83858a7. --- a/drivers/media/usb/dvb-usb/dvb-usb-dvb.c +++ b/drivers/media/usb/dvb-usb/dvb-usb-dvb.c @@ -107,7 +107,15 @@ static int dvb_usb_media_device_init(str if (!mdev) return -ENOMEM; - media_device_usb_init(mdev, udev, d->desc->name); + mdev->dev = >dev; + strlcpy(mdev->model, d->desc->name, sizeof(mdev->model)); + if (udev->serial) + strlcpy(mdev->serial, udev->serial, sizeof(mdev->serial)); + strcpy(mdev->bus_info, udev->devpath); + mdev->hw_revision = le16_to_cpu(udev->descriptor.bcdDevice); + mdev->driver_version = LINUX_VERSION_CODE; + + media_device_init(mdev); dvb_register_media_controller(>dvb_adap, mdev); --- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c +++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c @@ -412,7 +412,15 @@ static int dvb_usbv2_media_device_init(s if (!mdev) return -ENOMEM; - media_device_usb_init(mdev, udev, d->name); + mdev->dev = >dev; + strlcpy(mdev->model, d->name, sizeof(mdev->model)); + if (udev->serial) + strlcpy(mdev->serial, udev->serial, sizeof(mdev->serial)); + strcpy(mdev->bus_info, udev->devpath); + mdev->hw_revision = le16_to_cpu(udev->descriptor.bcdDevice); + mdev->driver_version = LINUX_VERSION_CODE; + + media_device_init(mdev); dvb_register_media_controller(>dvb_adap, mdev); While testing this, I also noticed that not just the dvb_usb based dvb_usb_dw2102 is affected, but that also the dvb_usb_v2 based rtl2832 triggers this Oops on its own (given that just reverting drivers/media/usb/dvb-usb/dvb-usb-dvb.c wasn't enough). Regards Stefan Lippers-Hollmann
Re: [GIT PULL for v4.6-rc1] media updates
Hi On 2016-05-03, Linus Torvalds wrote: > On Tue, May 3, 2016 at 2:38 PM, Stefan Lippers-Hollmann wrote: > > Hi > > [...] > >> Mauro Carvalho Chehab (95): > > [...] > >> [media] use v4l2_mc_usb_media_device_init() on most USB devices > > [...] > > > > This change, as part of v4.6-rc6-85-g1248ded, breaks two systems, each > > equipped with a TeVii s480 (dvb_usb_dw2102) DVB-S2 card, for me (kernel > > v4.5.3-rc1 is fine): > > From the oops it looks like the "->prev" pointer in one of the list > heads in 'mdev' is NULL. > > > [5.041915] BUG: unable to handle kernel NULL pointer dereference at > > (null) > > [5.041921] IP: [] media_gobj_create+0xb8/0x100 > > [media] > > I can't tell *which* list head it is, but it looks like there's a > missing call to media_device_init() which is what should have > initialized those list heads. > > Of course, maybe that list pointer got initialized but then > overwritten by NULL for some other reason. Just as a cross-check, this (incomplete, but au0828, cx231xx and em28xx aren't needed/ loaded on my system) crude revert avoids the problem for me on v4.6-rc6-113-g83858a7. --- a/drivers/media/usb/dvb-usb/dvb-usb-dvb.c +++ b/drivers/media/usb/dvb-usb/dvb-usb-dvb.c @@ -107,7 +107,15 @@ static int dvb_usb_media_device_init(str if (!mdev) return -ENOMEM; - media_device_usb_init(mdev, udev, d->desc->name); + mdev->dev = >dev; + strlcpy(mdev->model, d->desc->name, sizeof(mdev->model)); + if (udev->serial) + strlcpy(mdev->serial, udev->serial, sizeof(mdev->serial)); + strcpy(mdev->bus_info, udev->devpath); + mdev->hw_revision = le16_to_cpu(udev->descriptor.bcdDevice); + mdev->driver_version = LINUX_VERSION_CODE; + + media_device_init(mdev); dvb_register_media_controller(>dvb_adap, mdev); --- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c +++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c @@ -412,7 +412,15 @@ static int dvb_usbv2_media_device_init(s if (!mdev) return -ENOMEM; - media_device_usb_init(mdev, udev, d->name); + mdev->dev = >dev; + strlcpy(mdev->model, d->name, sizeof(mdev->model)); + if (udev->serial) + strlcpy(mdev->serial, udev->serial, sizeof(mdev->serial)); + strcpy(mdev->bus_info, udev->devpath); + mdev->hw_revision = le16_to_cpu(udev->descriptor.bcdDevice); + mdev->driver_version = LINUX_VERSION_CODE; + + media_device_init(mdev); dvb_register_media_controller(>dvb_adap, mdev); While testing this, I also noticed that not just the dvb_usb based dvb_usb_dw2102 is affected, but that also the dvb_usb_v2 based rtl2832 triggers this Oops on its own (given that just reverting drivers/media/usb/dvb-usb/dvb-usb-dvb.c wasn't enough). Regards Stefan Lippers-Hollmann
Re: [GIT PULL for v4.6-rc1] media updates
it.kernel.org/pub/scm/linux/kernel/git/tj/cgroup git bisect bad 6b5f04b6cf8ebab9a65d9c0026c650bb2538fd0f # bad: [96b9b1c95660d4bc5510c5d798d3817ae9f0b391] Merge tag 'tty-4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty git bisect bad 96b9b1c95660d4bc5510c5d798d3817ae9f0b391 # good: [277edbabf6fece057b14fb6db5e3a34e00f42f42] Merge tag 'pm+acpi-4.6-rc1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm git bisect good 277edbabf6fece057b14fb6db5e3a34e00f42f42 # bad: [bace3db5da970c4d4f80a1ffa988ec66c7f6a8f5] Merge tag 'media/v4.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media git bisect bad bace3db5da970c4d4f80a1ffa988ec66c7f6a8f5 # good: [8759957b77ac1b5b5bdfac5ba049789107e85190] Merge tag 'libnvdimm-for-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm git bisect good 8759957b77ac1b5b5bdfac5ba049789107e85190 # good: [eee7d353a19032b48c0f71504081de84a0ee79d8] [media] v4l2-mc: add a routine to create USB media_device git bisect good eee7d353a19032b48c0f71504081de84a0ee79d8 # bad: [182dde7c5d4cd9fcac007c0798c9906fc5ea6889] [media] media: au0828 change to use Managed Media Controller API git bisect bad 182dde7c5d4cd9fcac007c0798c9906fc5ea6889 # bad: [f6acfcdc5b8cdc9ddd53a459361820b9efe958c4] [media] v4l: vsp1: Set the SRU CTRL0 register when starting the stream git bisect bad f6acfcdc5b8cdc9ddd53a459361820b9efe958c4 # bad: [3e71da19f9dc22e39a755d6ae9678661abb66adc] [media] saa7134: Fix bytesperline not being set correctly for planar formats git bisect bad 3e71da19f9dc22e39a755d6ae9678661abb66adc # bad: [c43875f66140f5457f90fc5f6f6840c74b2762cd] [media] tvp5150: replace MEDIA_ENT_F_CONN_TEST by a control git bisect bad c43875f66140f5457f90fc5f6f6840c74b2762cd # bad: [8b0a81c73326af2defaa0d8a4494c7def83928bd] [media] si2157: register as a tuner entity git bisect bad 8b0a81c73326af2defaa0d8a4494c7def83928bd # bad: [67873d4e751e400149df7ab61ba04cbb4cc0d449] [media] use v4l2_mc_usb_media_device_init() on most USB devices git bisect bad 67873d4e751e400149df7ab61ba04cbb4cc0d449 # good: [bb07bd6b6851120ac9b25bb315d62d9782d2c345] [media] allow overriding the driver name git bisect good bb07bd6b6851120ac9b25bb315d62d9782d2c345 # first bad commit: [67873d4e751e400149df7ab61ba04cbb4cc0d449] [media] use v4l2_mc_usb_media_device_init() on most USB devices Regards Stefan Lippers-Hollmann
Re: [GIT PULL for v4.6-rc1] media updates
it.kernel.org/pub/scm/linux/kernel/git/tj/cgroup git bisect bad 6b5f04b6cf8ebab9a65d9c0026c650bb2538fd0f # bad: [96b9b1c95660d4bc5510c5d798d3817ae9f0b391] Merge tag 'tty-4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty git bisect bad 96b9b1c95660d4bc5510c5d798d3817ae9f0b391 # good: [277edbabf6fece057b14fb6db5e3a34e00f42f42] Merge tag 'pm+acpi-4.6-rc1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm git bisect good 277edbabf6fece057b14fb6db5e3a34e00f42f42 # bad: [bace3db5da970c4d4f80a1ffa988ec66c7f6a8f5] Merge tag 'media/v4.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media git bisect bad bace3db5da970c4d4f80a1ffa988ec66c7f6a8f5 # good: [8759957b77ac1b5b5bdfac5ba049789107e85190] Merge tag 'libnvdimm-for-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm git bisect good 8759957b77ac1b5b5bdfac5ba049789107e85190 # good: [eee7d353a19032b48c0f71504081de84a0ee79d8] [media] v4l2-mc: add a routine to create USB media_device git bisect good eee7d353a19032b48c0f71504081de84a0ee79d8 # bad: [182dde7c5d4cd9fcac007c0798c9906fc5ea6889] [media] media: au0828 change to use Managed Media Controller API git bisect bad 182dde7c5d4cd9fcac007c0798c9906fc5ea6889 # bad: [f6acfcdc5b8cdc9ddd53a459361820b9efe958c4] [media] v4l: vsp1: Set the SRU CTRL0 register when starting the stream git bisect bad f6acfcdc5b8cdc9ddd53a459361820b9efe958c4 # bad: [3e71da19f9dc22e39a755d6ae9678661abb66adc] [media] saa7134: Fix bytesperline not being set correctly for planar formats git bisect bad 3e71da19f9dc22e39a755d6ae9678661abb66adc # bad: [c43875f66140f5457f90fc5f6f6840c74b2762cd] [media] tvp5150: replace MEDIA_ENT_F_CONN_TEST by a control git bisect bad c43875f66140f5457f90fc5f6f6840c74b2762cd # bad: [8b0a81c73326af2defaa0d8a4494c7def83928bd] [media] si2157: register as a tuner entity git bisect bad 8b0a81c73326af2defaa0d8a4494c7def83928bd # bad: [67873d4e751e400149df7ab61ba04cbb4cc0d449] [media] use v4l2_mc_usb_media_device_init() on most USB devices git bisect bad 67873d4e751e400149df7ab61ba04cbb4cc0d449 # good: [bb07bd6b6851120ac9b25bb315d62d9782d2c345] [media] allow overriding the driver name git bisect good bb07bd6b6851120ac9b25bb315d62d9782d2c345 # first bad commit: [67873d4e751e400149df7ab61ba04cbb4cc0d449] [media] use v4l2_mc_usb_media_device_init() on most USB devices Regards Stefan Lippers-Hollmann
Re: [git pull] drm for 4.4-rc1
Hi On 2015-12-10, Daniel Vetter wrote: > On Thu, Dec 10, 2015 at 04:04:20AM +0100, Stefan Lippers-Hollmann wrote: > > On 2015-11-09, Dave Airlie wrote: [...] > > This patch seems to introduce a regression for i915 in Linus' > > v4.4-rc4-60-g9a0f76f, relative to v4.3 (and 4.3.1), on a sandy-bridge > > (Intel DH67CL) system with a single HDMI connected monitor (Medion MD20094) > > attached. Immediately after the modeswitch, the monitor switches off and > > stays off. Nothing catches my eyes in dmesg or Xorg.0.log, but bisecting > > the issue points me at: > > > > 237ed86c693d8a8e4db476976aeb30df4deac74b is the first bad commit > > commit 237ed86c693d8a8e4db476976aeb30df4deac74b > > Author: Sonika Jindal > > Date: Tue Sep 15 09:44:20 2015 +0530 > > > > drm/i915: Check live status before reading edid [...] This is strange, after connecting a different monitor (Fujitsu-Siemens Scaleoview D19-1) as a second screen via DVI, both monitors came up fine and even after removing it (and reverting everything to the status quo ante), this HDMI connected Medion MD20094 monitor continues to work on the previously broken sandy-bridge DH67CL mainboard. Despite this problem being 100% reproducable and bisectable before, including multiple power cycles and replacing the HDMI cable, I have not been able to reproduce the issue again. > A few things to test: > - How does that screen fare on a working machine? Would tell us if the > issue is with the sink or the source. It is working fine on a Baytrail-D (ASRock Q1900DC-ITX) and an ivy-bridge (Gigabyte GA-H77M-D3H r1.1) system - and now on the previously affected sandy-bridge system (Intel DH67CL) as well. > - Please boot up with drm.debug=0xe on a working and broken kernel, grab > dmesg for both. dmesg-v4.4-rc4-113-g0bd0f1e-working.gz is attached, unfortunately I'm no longer able to reproduce the previous failure (tested with easy of the bisection steps, identical kernel binaries as before, and v4.4-rc5 as well), so I can't provide a broken trace. > - Extending the timeout magic might be worth a shot like in the below > patch. Crank up retry if it doesn't help. [...] I can only imagine that it was right beyond the brink of the timeout before and something had a lasting, but probably subtile, effect on the timing after temporarily connecting the second screen; it is working now. On 2015-12-10, Jani Nikula wrote: [...] > The very first thing to do is to ensure you've tried v4.4-rc4, which > contains I tested both plain v4.4-rc4 and v4.4-rc4-60-g9a0f76f > commit 0f5a9be15797f78c9a34e432f26c796165b6e49a > Author: Imre Deak > Date: Fri Nov 27 18:55:29 2015 +0200 > > drm/i915: take a power domain reference while checking the HDMI live > status both containing this patch. Thanks a lot and sorry for your trouble, I'll report back if anything changes - or if I can reproduce the problem again. Regards Stefan Lippers-Hollmann dmesg-v4.4-rc4-113-g0bd0f1e-working.gz Description: application/gzip
Re: [git pull] drm for 4.4-rc1
Hi On 2015-12-10, Daniel Vetter wrote: > On Thu, Dec 10, 2015 at 04:04:20AM +0100, Stefan Lippers-Hollmann wrote: > > On 2015-11-09, Dave Airlie wrote: [...] > > This patch seems to introduce a regression for i915 in Linus' > > v4.4-rc4-60-g9a0f76f, relative to v4.3 (and 4.3.1), on a sandy-bridge > > (Intel DH67CL) system with a single HDMI connected monitor (Medion MD20094) > > attached. Immediately after the modeswitch, the monitor switches off and > > stays off. Nothing catches my eyes in dmesg or Xorg.0.log, but bisecting > > the issue points me at: > > > > 237ed86c693d8a8e4db476976aeb30df4deac74b is the first bad commit > > commit 237ed86c693d8a8e4db476976aeb30df4deac74b > > Author: Sonika Jindal <sonika.jin...@intel.com> > > Date: Tue Sep 15 09:44:20 2015 +0530 > > > > drm/i915: Check live status before reading edid [...] This is strange, after connecting a different monitor (Fujitsu-Siemens Scaleoview D19-1) as a second screen via DVI, both monitors came up fine and even after removing it (and reverting everything to the status quo ante), this HDMI connected Medion MD20094 monitor continues to work on the previously broken sandy-bridge DH67CL mainboard. Despite this problem being 100% reproducable and bisectable before, including multiple power cycles and replacing the HDMI cable, I have not been able to reproduce the issue again. > A few things to test: > - How does that screen fare on a working machine? Would tell us if the > issue is with the sink or the source. It is working fine on a Baytrail-D (ASRock Q1900DC-ITX) and an ivy-bridge (Gigabyte GA-H77M-D3H r1.1) system - and now on the previously affected sandy-bridge system (Intel DH67CL) as well. > - Please boot up with drm.debug=0xe on a working and broken kernel, grab > dmesg for both. dmesg-v4.4-rc4-113-g0bd0f1e-working.gz is attached, unfortunately I'm no longer able to reproduce the previous failure (tested with easy of the bisection steps, identical kernel binaries as before, and v4.4-rc5 as well), so I can't provide a broken trace. > - Extending the timeout magic might be worth a shot like in the below > patch. Crank up retry if it doesn't help. [...] I can only imagine that it was right beyond the brink of the timeout before and something had a lasting, but probably subtile, effect on the timing after temporarily connecting the second screen; it is working now. On 2015-12-10, Jani Nikula wrote: [...] > The very first thing to do is to ensure you've tried v4.4-rc4, which > contains I tested both plain v4.4-rc4 and v4.4-rc4-60-g9a0f76f > commit 0f5a9be15797f78c9a34e432f26c796165b6e49a > Author: Imre Deak <imre.d...@intel.com> > Date: Fri Nov 27 18:55:29 2015 +0200 > > drm/i915: take a power domain reference while checking the HDMI live > status both containing this patch. Thanks a lot and sorry for your trouble, I'll report back if anything changes - or if I can reproduce the problem again. Regards Stefan Lippers-Hollmann dmesg-v4.4-rc4-113-g0bd0f1e-working.gz Description: application/gzip
Re: [git pull] drm for 4.4-rc1
git/gregkh/char-misc
git bisect good 8e483ed1342a4ea45b70f0f33ac54eff7a33d918
# bad: [3e82806b97398d542a5e03bd94861f79ce10ecee] Merge branch 'drm-next' of
git://people.freedesktop.org/~airlied/linux
git bisect bad 3e82806b97398d542a5e03bd94861f79ce10ecee
# good: [0280d1a099da1d211e76ec47cc0944c993a36316] Merge tag 'sound-4.4-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect good 0280d1a099da1d211e76ec47cc0944c993a36316
# good: [123a28d8b522b03dd97c1f791245924088616ac0] Merge branch 'for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
git bisect good 123a28d8b522b03dd97c1f791245924088616ac0
# bad: [b10f1b20171945b49988b2b1fe68cb312cc36d32] drm/i915/skl: Prevent
unclaimed register writes on skylake.
git bisect bad b10f1b20171945b49988b2b1fe68cb312cc36d32
# bad: [89e3e1427629027dc33e576fc002880a02a7e50c] drm/i915: Support NV12 in
rotated GGTT mapping
git bisect bad 89e3e1427629027dc33e576fc002880a02a7e50c
# good: [0b2eb33e5e2b4aaeaa786d551a1b5f08904a9bfc] drm/i915: LPT:LP needs port
A HPD enabled in both north and south
git bisect good 0b2eb33e5e2b4aaeaa786d551a1b5f08904a9bfc
# good: [eb120ef6a3e18780e7464e7de70221d06dfe5845] drm/i915: add more debug
info for when atomic updates fail v3
git bisect good eb120ef6a3e18780e7464e7de70221d06dfe5845
# bad: [7aefe2b50a0be5c85e7702bff110e5e187fbe4b5] drm/i915: Fix fastboot
scalers for skylake.
git bisect bad 7aefe2b50a0be5c85e7702bff110e5e187fbe4b5
# good: [83e3337204b2385d20e149c8fe91bb2719978df2] drm/i915: Increase maximum
polling time to 50ms for forcewake request/clear ack
git bisect good 83e3337204b2385d20e149c8fe91bb2719978df2
# bad: [9eca6832f7254d49d25494da7d47c0f8a24f7862] drm/i915: Move
scanline_offset and timestamping constant setup to
intel_modeset_readout_hw_state()
git bisect bad 9eca6832f7254d49d25494da7d47c0f8a24f7862
# good: [d2e08c0f34438af791482de8abf2c8e4e573b1d3] drm/i915/bxt: DSI prepare
changes for BXT
git bisect good d2e08c0f34438af791482de8abf2c8e4e573b1d3
# bad: [7f4c62840cc416986f983a8c68f7010c97e06daf] drm/i915: Assign hwmode after
encoder state readout
git bisect bad 7f4c62840cc416986f983a8c68f7010c97e06daf
# bad: [237ed86c693d8a8e4db476976aeb30df4deac74b] drm/i915: Check live status
before reading edid
git bisect bad 237ed86c693d8a8e4db476976aeb30df4deac74b
# first bad commit: [237ed86c693d8a8e4db476976aeb30df4deac74b] drm/i915: Check
live status before reading edid
Unfortunately reverting only this patch on top of v4.4-rc4-60-g9a0f76f
doesn't appear to be quite straight forward. What is the best approach
to debug this further?
The very same kernel works fine on two ivy-bridge systems (different
monitors, one connected via HDMI, one via DVI) and an Atom N270 based
system (Intel D945GSEJT, monitor connected via DVI).
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm for 4.4-rc1
d7861] Linux 4.3 git bisect start 'HEAD' 'v4.3' # good: [8e483ed1342a4ea45b70f0f33ac54eff7a33d918] Merge tag 'char-misc-4.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc git bisect good 8e483ed1342a4ea45b70f0f33ac54eff7a33d918 # bad: [3e82806b97398d542a5e03bd94861f79ce10ecee] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux git bisect bad 3e82806b97398d542a5e03bd94861f79ce10ecee # good: [0280d1a099da1d211e76ec47cc0944c993a36316] Merge tag 'sound-4.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect good 0280d1a099da1d211e76ec47cc0944c993a36316 # good: [123a28d8b522b03dd97c1f791245924088616ac0] Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs git bisect good 123a28d8b522b03dd97c1f791245924088616ac0 # bad: [b10f1b20171945b49988b2b1fe68cb312cc36d32] drm/i915/skl: Prevent unclaimed register writes on skylake. git bisect bad b10f1b20171945b49988b2b1fe68cb312cc36d32 # bad: [89e3e1427629027dc33e576fc002880a02a7e50c] drm/i915: Support NV12 in rotated GGTT mapping git bisect bad 89e3e1427629027dc33e576fc002880a02a7e50c # good: [0b2eb33e5e2b4aaeaa786d551a1b5f08904a9bfc] drm/i915: LPT:LP needs port A HPD enabled in both north and south git bisect good 0b2eb33e5e2b4aaeaa786d551a1b5f08904a9bfc # good: [eb120ef6a3e18780e7464e7de70221d06dfe5845] drm/i915: add more debug info for when atomic updates fail v3 git bisect good eb120ef6a3e18780e7464e7de70221d06dfe5845 # bad: [7aefe2b50a0be5c85e7702bff110e5e187fbe4b5] drm/i915: Fix fastboot scalers for skylake. git bisect bad 7aefe2b50a0be5c85e7702bff110e5e187fbe4b5 # good: [83e3337204b2385d20e149c8fe91bb2719978df2] drm/i915: Increase maximum polling time to 50ms for forcewake request/clear ack git bisect good 83e3337204b2385d20e149c8fe91bb2719978df2 # bad: [9eca6832f7254d49d25494da7d47c0f8a24f7862] drm/i915: Move scanline_offset and timestamping constant setup to intel_modeset_readout_hw_state() git bisect bad 9eca6832f7254d49d25494da7d47c0f8a24f7862 # good: [d2e08c0f34438af791482de8abf2c8e4e573b1d3] drm/i915/bxt: DSI prepare changes for BXT git bisect good d2e08c0f34438af791482de8abf2c8e4e573b1d3 # bad: [7f4c62840cc416986f983a8c68f7010c97e06daf] drm/i915: Assign hwmode after encoder state readout git bisect bad 7f4c62840cc416986f983a8c68f7010c97e06daf # bad: [237ed86c693d8a8e4db476976aeb30df4deac74b] drm/i915: Check live status before reading edid git bisect bad 237ed86c693d8a8e4db476976aeb30df4deac74b # first bad commit: [237ed86c693d8a8e4db476976aeb30df4deac74b] drm/i915: Check live status before reading edid Unfortunately reverting only this patch on top of v4.4-rc4-60-g9a0f76f doesn't appear to be quite straight forward. What is the best approach to debug this further? The very same kernel works fine on two ivy-bridge systems (different monitors, one connected via HDMI, one via DVI) and an Atom N270 based system (Intel D945GSEJT, monitor connected via DVI). Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages
Hi
On 2015-11-15, Dave Young wrote:
> cfg80211 module prints a lot of messages like below. Actually printing
> once is acceptable but sometimes it will print again and again, it looks
> very annoying. It is better to change these detail messages to debugging
> only.
It is a lot of info, easily repeated 3 times on boot, but it's also the
only real chance to determine why you ended up with the regulatory
domain settings you got, rather than just the values itself. Given that
a lot (most?) of officially shipping wireless devices are misconfigured
(wrong EEPROM regdom settings for the region they're sold in) and
considering that the limits can even change at runtime (IEEE 802.11d),
it is imho quite important not just to be able what the current
restrictions (iw reg get) are, but also why the kernel settled on those.
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages
Hi
On 2015-11-15, Dave Young wrote:
> cfg80211 module prints a lot of messages like below. Actually printing
> once is acceptable but sometimes it will print again and again, it looks
> very annoying. It is better to change these detail messages to debugging
> only.
It is a lot of info, easily repeated 3 times on boot, but it's also the
only real chance to determine why you ended up with the regulatory
domain settings you got, rather than just the values itself. Given that
a lot (most?) of officially shipping wireless devices are misconfigured
(wrong EEPROM regdom settings for the region they're sold in) and
considering that the limits can even change at runtime (IEEE 802.11d),
it is imho quite important not just to be able what the current
restrictions (iw reg get) are, but also why the kernel settled on those.
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 39/39] Update the buildsystem for KConfig finding Qt
Hi
On 2015-10-16, Stefan Lippers-Hollmann wrote:
> On 2015-09-22, Thiago Macieira wrote:
[...]
> + QT_SELECT=5 qmake -query QT_VERSION >/dev/null 2>&1 && export
> QT_SELECT=5 ||: ; \
Apparently this fails if qmake isn't guarded by qtchooser, but the
following should work (although I'm still not confident if that would
be the best approach):
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -227,6 +227,7 @@ $(obj)/.tmp_qtcheck: $(src)/Makefile
# Qt needs some extra effort...
$(obj)/.tmp_qtcheck:
@set -e; $(kecho) " CHECK qt"; \
+ qtchooser --list-versions | grep -q ^5$ && export QT_SELECT=5 ||: ; \
qtver=`qmake -query QT_VERSION` || { \
echo >&2 "*"; \
echo >&2 "* qmake failed."; \
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 39/39] Update the buildsystem for KConfig finding Qt
Hi
On 2015-09-22, Thiago Macieira wrote:
> The buildsystem will now only search for Qt 4 and Qt 5. Support for Qt 2
> and 3 was dropped in the previous commits (Qt 3 was EOL'ed in 2010 or
> so...).
>
> For Qt 5, to be future-proof with the future direction notice appearing
> in the 5.5 release, C++11 support is automatically enabled.
[...]
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
[...]
> + @set -e; $(kecho) " CHECK qt"; \
> + qtver=`qmake -query QT_VERSION` || { \
> + echo >&2 "*"; \
> + echo >&2 "* qmake failed."; \
> + echo >&2 "*"; \
> + exit 1; \
> + }; \
[...]
"qmake -query QT_VERSION" appears to be a little fragile on Debian
with both qt4-qmake and qt5-qmake installed, as it reports back
"4.8.7" by default. The actual qmake is hiding behind qtchooser
(/usr/bin/qmake -> qtchooser) and will report different environments
based on the chosen personality:
$ qmake -query QT_VERSION
4.8.7
$ QT_SELECT=5 qmake -query QT_VERSION
5.4.2
While I'm not quite sure what would be the best kind of test
here (and if qtchooser can be commonly expected), the following
might provide another approach to query the most recent installed
qt version:
$ qtchooser --list-versions | grep ^[0-9]*$ | sort | tac | head -n1
5
(and then exporting QT_SELECT=5 to the rest of the build).
Another approach which appears to work for me (with both qt4 and qt5)
would be this, but I'm not quite sure if this would be a good solution:
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -227,6 +227,7 @@ $(obj)/.tmp_qtcheck: $(src)/Makefile
# Qt needs some extra effort...
$(obj)/.tmp_qtcheck:
@set -e; $(kecho) " CHECK qt"; \
+ QT_SELECT=5 qmake -query QT_VERSION >/dev/null 2>&1 && export
QT_SELECT=5 ||: ; \
qtver=`qmake -query QT_VERSION` || { \
echo >&2 "*"; \
echo >&2 "* qmake failed."; \
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 39/39] Update the buildsystem for KConfig finding Qt
Hi
On 2015-09-22, Thiago Macieira wrote:
> The buildsystem will now only search for Qt 4 and Qt 5. Support for Qt 2
> and 3 was dropped in the previous commits (Qt 3 was EOL'ed in 2010 or
> so...).
>
> For Qt 5, to be future-proof with the future direction notice appearing
> in the 5.5 release, C++11 support is automatically enabled.
[...]
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
[...]
> + @set -e; $(kecho) " CHECK qt"; \
> + qtver=`qmake -query QT_VERSION` || { \
> + echo >&2 "*"; \
> + echo >&2 "* qmake failed."; \
> + echo >&2 "*"; \
> + exit 1; \
> + }; \
[...]
"qmake -query QT_VERSION" appears to be a little fragile on Debian
with both qt4-qmake and qt5-qmake installed, as it reports back
"4.8.7" by default. The actual qmake is hiding behind qtchooser
(/usr/bin/qmake -> qtchooser) and will report different environments
based on the chosen personality:
$ qmake -query QT_VERSION
4.8.7
$ QT_SELECT=5 qmake -query QT_VERSION
5.4.2
While I'm not quite sure what would be the best kind of test
here (and if qtchooser can be commonly expected), the following
might provide another approach to query the most recent installed
qt version:
$ qtchooser --list-versions | grep ^[0-9]*$ | sort | tac | head -n1
5
(and then exporting QT_SELECT=5 to the rest of the build).
Another approach which appears to work for me (with both qt4 and qt5)
would be this, but I'm not quite sure if this would be a good solution:
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -227,6 +227,7 @@ $(obj)/.tmp_qtcheck: $(src)/Makefile
# Qt needs some extra effort...
$(obj)/.tmp_qtcheck:
@set -e; $(kecho) " CHECK qt"; \
+ QT_SELECT=5 qmake -query QT_VERSION >/dev/null 2>&1 && export
QT_SELECT=5 ||: ; \
qtver=`qmake -query QT_VERSION` || { \
echo >&2 "*"; \
echo >&2 "* qmake failed."; \
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 39/39] Update the buildsystem for KConfig finding Qt
Hi
On 2015-10-16, Stefan Lippers-Hollmann wrote:
> On 2015-09-22, Thiago Macieira wrote:
[...]
> + QT_SELECT=5 qmake -query QT_VERSION >/dev/null 2>&1 && export
> QT_SELECT=5 ||: ; \
Apparently this fails if qmake isn't guarded by qtchooser, but the
following should work (although I'm still not confident if that would
be the best approach):
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -227,6 +227,7 @@ $(obj)/.tmp_qtcheck: $(src)/Makefile
# Qt needs some extra effort...
$(obj)/.tmp_qtcheck:
@set -e; $(kecho) " CHECK qt"; \
+ qtchooser --list-versions | grep -q ^5$ && export QT_SELECT=5 ||: ; \
qtver=`qmake -query QT_VERSION` || { \
echo >&2 "*"; \
echo >&2 "* qmake failed."; \
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: git pull] drm for v4.1-rc1
Hi On 2015-06-08, Ander Conselvan De Oliveira wrote: > On Mon, 2015-06-08 at 11:06 +0300, Ander Conselvan De Oliveira wrote: > > On Sun, 2015-06-07 at 04:32 +0200, Stefan Lippers-Hollmann wrote: > > > On 2015-06-07, Ville Syrjälä wrote: > > > > On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Lippers-Hollmann wrote: > > > > > On 2015-04-20, Dave Airlie wrote: [...] > > > > > > Ander Conselvan de Oliveira (28): > > > > > [...] > > > > > > drm/i915: Allocate connector state together with the > > > > > > connectors > > > > > [...] > > > > > > > > > > This commit introduces a regression relative to v4.0 on an Intel > > > > > D945GCLF2 mainboard[1] (Atom 330) with Intel 82945G/GZ onboard > > > > > graphics > > > > > using its (only-) VGA connector for me. > > > > > > > > > > v4.1-rc6-52-gff25ea8: > > > > > [ 13.265699] BUG: unable to handle kernel NULL pointer dereference > > > > > at 0010 > > > > > [ 13.265723] IP: [] > > > > > intel_modeset_update_connector_atomic_state+0x61/0x90 [i915] > > > > > > > > Hmm. Smells like a connector with a NULL state pointer, and the bad > > > > commit touched exactly the part that sets it up. I can't immediately > > > > spot any place where we'd forget to set it up though. > > > > > > > > Can you try with something like this so we'd at least find out which > > > > connector(s) is/are at fault here? > > > > > > With the patch applied, the kernel (v4.1-rc6-104-g4b17069) locks up even > > > harder, so I had to switch to a serial console in order to fetch the > > > boot messages: > > > > > > [ 13.492784] connector = 880079bb8000 > > > [ 13.910439] connector = 8800795b5800 > > > [ 14.463114] connector = 8800795b6000 > > > [ 14.700707] connector = 8800795b6800 > > > [ 14.869418] connector = 8800795b7000 > > > [ 14.923848] connector = 8800795b7000 > > > > > > Full, gzipped, bootlog attached - thanks a lot for your efforts. > > > > Could you repeat the process with drm.debug=0xe in your kernel command > > line and send the logs again? > > Never mind, Ville's patch produced all the information necessary. Please > give the patch I just sent a try. Thanks a lot, as already reported as a response to your patch, your change "drm/i915: Allocate connector state together with the connectors" fixes the problem for me. Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git pull] drm for v4.1-rc1
Hi On 2015-06-08, Ander Conselvan De Oliveira wrote: On Mon, 2015-06-08 at 11:06 +0300, Ander Conselvan De Oliveira wrote: On Sun, 2015-06-07 at 04:32 +0200, Stefan Lippers-Hollmann wrote: On 2015-06-07, Ville Syrjälä wrote: On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Lippers-Hollmann wrote: On 2015-04-20, Dave Airlie wrote: [...] Ander Conselvan de Oliveira (28): [...] drm/i915: Allocate connector state together with the connectors [...] This commit introduces a regression relative to v4.0 on an Intel D945GCLF2 mainboard[1] (Atom 330) with Intel 82945G/GZ onboard graphics using its (only-) VGA connector for me. v4.1-rc6-52-gff25ea8: [ 13.265699] BUG: unable to handle kernel NULL pointer dereference at 0010 [ 13.265723] IP: [a0556f01] intel_modeset_update_connector_atomic_state+0x61/0x90 [i915] Hmm. Smells like a connector with a NULL state pointer, and the bad commit touched exactly the part that sets it up. I can't immediately spot any place where we'd forget to set it up though. Can you try with something like this so we'd at least find out which connector(s) is/are at fault here? With the patch applied, the kernel (v4.1-rc6-104-g4b17069) locks up even harder, so I had to switch to a serial console in order to fetch the boot messages: [ 13.492784] connector = 880079bb8000 [ 13.910439] connector = 8800795b5800 [ 14.463114] connector = 8800795b6000 [ 14.700707] connector = 8800795b6800 [ 14.869418] connector = 8800795b7000 [ 14.923848] connector = 8800795b7000 Full, gzipped, bootlog attached - thanks a lot for your efforts. Could you repeat the process with drm.debug=0xe in your kernel command line and send the logs again? Never mind, Ville's patch produced all the information necessary. Please give the patch I just sent a try. Thanks a lot, as already reported as a response to your patch, your change drm/i915: Allocate connector state together with the connectors fixes the problem for me. Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git pull] drm for v4.1-rc1
Hi On 2015-06-07, Ville Syrjälä wrote: > On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Lippers-Hollmann wrote: > > Hi > > > > On 2015-04-20, Dave Airlie wrote: > > [...] > > > The following changes since commit > > > 09d51602cf84a1264946711dd4ea0dddbac599a1: > > > > > > Merge branch 'turbostat' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux (2015-04-19 > > > 14:31:41 -0700) > > > > > > are available in the git repository at: > > > > > > git://people.freedesktop.org/~airlied/linux drm-next-merged > > > > > > for you to fetch changes up to 2c33ce009ca2389dbf0535d0672214d09738e35e: > > > > > > Merge Linus master into drm-next (2015-04-20 13:05:20 +1000) > > [...] > > > Ander Conselvan de Oliveira (28): > > [...] > > > drm/i915: Allocate connector state together with the connectors > > [...] > > > > This commit introduces a regression relative to v4.0 on an Intel > > D945GCLF2 mainboard[1] (Atom 330) with Intel 82945G/GZ onboard graphics > > using its (only-) VGA connector for me. > > > > v4.1-rc6-52-gff25ea8: > > [ 13.265699] BUG: unable to handle kernel NULL pointer dereference at > > 0010 > > [ 13.265723] IP: [] > > intel_modeset_update_connector_atomic_state+0x61/0x90 [i915] > > Hmm. Smells like a connector with a NULL state pointer, and the bad > commit touched exactly the part that sets it up. I can't immediately > spot any place where we'd forget to set it up though. > > Can you try with something like this so we'd at least find out which > connector(s) is/are at fault here? With the patch applied, the kernel (v4.1-rc6-104-g4b17069) locks up even harder, so I had to switch to a serial console in order to fetch the boot messages: [ 13.492784] connector = 880079bb8000 [ 13.910439] connector = 8800795b5800 [ 14.463114] connector = 8800795b6000 [ 14.700707] connector = 8800795b6800 [ 14.869418] connector = 8800795b7000 [ 14.923848] connector = 8800795b7000 Full, gzipped, bootlog attached - thanks a lot for your efforts. Regards Stefan Lippers-Hollmann D945GCLF2.dmesg.gz Description: application/gzip pgpeIZABbWx4C.pgp Description: Digitale Signatur von OpenPGP
Re: git pull] drm for v4.1-rc1
Hi On 2015-06-07, Ville Syrjälä wrote: On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Lippers-Hollmann wrote: Hi On 2015-04-20, Dave Airlie wrote: [...] The following changes since commit 09d51602cf84a1264946711dd4ea0dddbac599a1: Merge branch 'turbostat' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux (2015-04-19 14:31:41 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-next-merged for you to fetch changes up to 2c33ce009ca2389dbf0535d0672214d09738e35e: Merge Linus master into drm-next (2015-04-20 13:05:20 +1000) [...] Ander Conselvan de Oliveira (28): [...] drm/i915: Allocate connector state together with the connectors [...] This commit introduces a regression relative to v4.0 on an Intel D945GCLF2 mainboard[1] (Atom 330) with Intel 82945G/GZ onboard graphics using its (only-) VGA connector for me. v4.1-rc6-52-gff25ea8: [ 13.265699] BUG: unable to handle kernel NULL pointer dereference at 0010 [ 13.265723] IP: [a0556f01] intel_modeset_update_connector_atomic_state+0x61/0x90 [i915] Hmm. Smells like a connector with a NULL state pointer, and the bad commit touched exactly the part that sets it up. I can't immediately spot any place where we'd forget to set it up though. Can you try with something like this so we'd at least find out which connector(s) is/are at fault here? With the patch applied, the kernel (v4.1-rc6-104-g4b17069) locks up even harder, so I had to switch to a serial console in order to fetch the boot messages: [ 13.492784] connector = 880079bb8000 [ 13.910439] connector = 8800795b5800 [ 14.463114] connector = 8800795b6000 [ 14.700707] connector = 8800795b6800 [ 14.869418] connector = 8800795b7000 [ 14.923848] connector = 8800795b7000 Full, gzipped, bootlog attached - thanks a lot for your efforts. Regards Stefan Lippers-Hollmann D945GCLF2.dmesg.gz Description: application/gzip pgpeIZABbWx4C.pgp Description: Digitale Signatur von OpenPGP
Re: git pull] drm for v4.1-rc1
7dc58 # bad: [08d9bc920d465d762cac9383249c19bf69a2] drm/i915: Allocate connector state together with the connectors git bisect bad 08d9bc920d465d762cac9383249c19bf69a2 # first bad commit: [08d9bc920d465d762cac9383249c19bf69a2] drm/i915: Allocate connector state together with the connectors Reverting just this commit on top of yesterday evening's v4.1-rc6-52-gff25ea8 avoids the problem for me. Using the very same kernel, other i915 based systems are fine for me: DP && HDMI: 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09) DVI:00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0152] (rev 09) headless: 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0152] (rev 09) headless: 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e) HDMI: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0122] (rev 09) LVDS: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller [8086:27ae] (rev 03) headless: 00:02.0 VGA compatible controller [0300]: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device [8086:2562] (rev 01) Regards Stefan Lippers-Hollmann [1] http://www.intel.com/support/motherboards/desktop/d945gclf2/sb/CS-029540.htm pgpiKKgeBUwzS.pgp Description: Digitale Signatur von OpenPGP
Re: git pull] drm for v4.1-rc1
good bb1dc08c94ead1b98e750caf535422f79363c1a2 # good: [89025bd458a572f15e30f59d1ac5acb599cb53bc] drm/nouveau/fifo/gm204: initial support git bisect good 89025bd458a572f15e30f59d1ac5acb599cb53bc # good: [52139bdea1558e854123d7a07e7648f5a8c77a5c] Merge branch 'drm-dwhdmi-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm into drm-next git bisect good 52139bdea1558e854123d7a07e7648f5a8c77a5c # good: [16bb079e45f2c3a795b6b0546535cd6466275ec5] drm/radeon: constify more struct drm_*_helper funcs pointers git bisect good 16bb079e45f2c3a795b6b0546535cd6466275ec5 # bad: [37ef01ab5d24d1d520dc79f6a98099d451c2a901] drm/i915: Dont enable CS_PARSER_ERROR interrupts at all git bisect bad 37ef01ab5d24d1d520dc79f6a98099d451c2a901 # good: [af8fcb9c58f1b2f02ddc04ba64710aaa52da00db] drm/i915/chv: Remove DPIO force latency causing interpair skew issue git bisect good af8fcb9c58f1b2f02ddc04ba64710aaa52da00db # bad: [e0d6149b3debce1a7e17dfda7c2829935917dc58] drm/i915: Move drm_framebuffer_unreference out of struct_mutex for takeover git bisect bad e0d6149b3debce1a7e17dfda7c2829935917dc58 # bad: [08d9bc920d465d762cac9383249c19bf69a2] drm/i915: Allocate connector state together with the connectors git bisect bad 08d9bc920d465d762cac9383249c19bf69a2 # first bad commit: [08d9bc920d465d762cac9383249c19bf69a2] drm/i915: Allocate connector state together with the connectors Reverting just this commit on top of yesterday evening's v4.1-rc6-52-gff25ea8 avoids the problem for me. Using the very same kernel, other i915 based systems are fine for me: DP HDMI: 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09) DVI:00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0152] (rev 09) headless: 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0152] (rev 09) headless: 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics Display [8086:0f31] (rev 0e) HDMI: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0122] (rev 09) LVDS: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller [8086:27ae] (rev 03) headless: 00:02.0 VGA compatible controller [0300]: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device [8086:2562] (rev 01) Regards Stefan Lippers-Hollmann [1] http://www.intel.com/support/motherboards/desktop/d945gclf2/sb/CS-029540.htm pgpiKKgeBUwzS.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH 4.0 000/220] 4.0.2-stable review
Hi On 2015-05-06, Greg Kroah-Hartman wrote: > On Sat, May 02, 2015 at 08:58:35PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.0.2 release. > > There are 220 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Mon May 4 18:58:12 UTC 2015. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc1.gz > > and the diffstat can be found below. > > -rc2 is out that should not have any issues: > > kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc2.gz Please change your script to use kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.0.2-rc2.gz instead. As reported before, there is no v4.0/ directory (symlink), while using v3.x/ is safe either way. Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.0 000/220] 4.0.2-stable review
Hi On 2015-05-06, Greg Kroah-Hartman wrote: On Sat, May 02, 2015 at 08:58:35PM +0200, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.0.2 release. There are 220 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc1.gz and the diffstat can be found below. -rc2 is out that should not have any issues: kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc2.gz Please change your script to use kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.0.2-rc2.gz instead. As reported before, there is no v4.0/ directory (symlink), while using v3.x/ is safe either way. Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.0 219/220] netfilter: x_tables: fix cgroup matching on non-full sks
Hi
On 2015-05-02, Greg Kroah-Hartman wrote:
> 4.0-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Daniel Borkmann
>
> commit afb7718016fcb0370ac29a83b2839c78b76c2960 upstream.
>
> While originally only being intended for outgoing traffic, commit
> a00e76349f35 ("netfilter: x_tables: allow to use cgroup match for
> LOCAL_IN nf hooks") enabled xt_cgroups for the NF_INET_LOCAL_IN hook
> as well, in order to allow for nfacct accounting.
>
> Besides being currently limited to early demuxes only, commit
> a00e76349f35 forgot to add a check if we deal with full sockets,
> i.e. in this case not with time wait sockets. TCP time wait sockets
> do not have the same memory layout as full sockets, a lower memory
> footprint and consequently also don't have a sk_classid member;
> probing for sk_classid member there could potentially lead to a
> crash.
This introduces the same build failure into queue-4.0, as previously
reported by Thomas Backlund for queue-3.19 in
http://lkml.kernel.org/r/<554545e5.8020...@mageia.org>
/tmp/buildd/linux-aptosid-4.0/net/netfilter/xt_cgroup.c: In function
'cgroup_mt':
/tmp/buildd/linux-aptosid-4.0/net/netfilter/xt_cgroup.c:42:2: error: implicit
declaration of function 'sk_fullsock' [-Werror=implicit-function-declaration]
if (skb->sk == NULL || !sk_fullsock(skb->sk))
^
cc1: some warnings being treated as errors
/tmp/buildd/linux-aptosid-4.0/scripts/Makefile.build:264: recipe for target
'net/netfilter/xt_cgroup.o' failed
make[7]: *** [net/netfilter/xt_cgroup.o] Error 1
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.0 000/220] 4.0.2-stable review
Hi On 2015-05-02, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.0.2 release. > There are 220 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Mon May 4 18:58:12 UTC 2015. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc1.gz [...] This file doesn't exist(404). While I'm aware that the mirroring probably hasn't caught up yet, the URL seems to have multiple issues besides just that. http://kernel.org/pub/linux/kernel/v4.0/ doesn't exist, there doesn't appear to be a symlink from v4.x to v4.0 (imho for good reasons), while such a smylink did exist for v3.x --> v3.0. So fixing the obvious problem and adapting the URL to http://kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.0.2-rc1.gz doesn't work either, as there is no "stable-review" directory under http://kernel.org/pub/linux/kernel/v4.x/ yet (which probably should be created). Your previous, "[PATCH 4.0 0/7] 4.0.1-stable review"[1], mail referenced kernel.org/pub/linux/kernel/v3.0/stable-review/patch-4.0.1-rc1.gz which does exist. However patch-4.0.2-rc1.gz is still missing there or at the more sensible location at http://kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.0.2-rc1.gz Given that the patch files of the other stable-review patches posted today are already available[2], I assume that it's not just a problem with the mirroring. Regards Stefan Lippers-Hollmann [1] http://lkml.kernel.org/r/<20150426120018.032351...@linuxfoundation.org> [2] https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc1.gz https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.41-rc1.gz https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc1.gz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.0 000/220] 4.0.2-stable review
Hi On 2015-05-02, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.0.2 release. There are 220 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.0/stable-review/patch-4.0.2-rc1.gz [...] This file doesn't exist(404). While I'm aware that the mirroring probably hasn't caught up yet, the URL seems to have multiple issues besides just that. http://kernel.org/pub/linux/kernel/v4.0/ doesn't exist, there doesn't appear to be a symlink from v4.x to v4.0 (imho for good reasons), while such a smylink did exist for v3.x -- v3.0. So fixing the obvious problem and adapting the URL to http://kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.0.2-rc1.gz doesn't work either, as there is no stable-review directory under http://kernel.org/pub/linux/kernel/v4.x/ yet (which probably should be created). Your previous, [PATCH 4.0 0/7] 4.0.1-stable review[1], mail referenced kernel.org/pub/linux/kernel/v3.0/stable-review/patch-4.0.1-rc1.gz which does exist. However patch-4.0.2-rc1.gz is still missing there or at the more sensible location at http://kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.0.2-rc1.gz Given that the patch files of the other stable-review patches posted today are already available[2], I assume that it's not just a problem with the mirroring. Regards Stefan Lippers-Hollmann [1] http://lkml.kernel.org/r/20150426120018.032351...@linuxfoundation.org [2] https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc1.gz https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.41-rc1.gz https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc1.gz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.0 219/220] netfilter: x_tables: fix cgroup matching on non-full sks
Hi On 2015-05-02, Greg Kroah-Hartman wrote: 4.0-stable review patch. If anyone has any objections, please let me know. -- From: Daniel Borkmann dan...@iogearbox.net commit afb7718016fcb0370ac29a83b2839c78b76c2960 upstream. While originally only being intended for outgoing traffic, commit a00e76349f35 (netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf hooks) enabled xt_cgroups for the NF_INET_LOCAL_IN hook as well, in order to allow for nfacct accounting. Besides being currently limited to early demuxes only, commit a00e76349f35 forgot to add a check if we deal with full sockets, i.e. in this case not with time wait sockets. TCP time wait sockets do not have the same memory layout as full sockets, a lower memory footprint and consequently also don't have a sk_classid member; probing for sk_classid member there could potentially lead to a crash. This introduces the same build failure into queue-4.0, as previously reported by Thomas Backlund for queue-3.19 in http://lkml.kernel.org/r/554545e5.8020...@mageia.org /tmp/buildd/linux-aptosid-4.0/net/netfilter/xt_cgroup.c: In function 'cgroup_mt': /tmp/buildd/linux-aptosid-4.0/net/netfilter/xt_cgroup.c:42:2: error: implicit declaration of function 'sk_fullsock' [-Werror=implicit-function-declaration] if (skb-sk == NULL || !sk_fullsock(skb-sk)) ^ cc1: some warnings being treated as errors /tmp/buildd/linux-aptosid-4.0/scripts/Makefile.build:264: recipe for target 'net/netfilter/xt_cgroup.o' failed make[7]: *** [net/netfilter/xt_cgroup.o] Error 1 Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/urgent] x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk
Commit-ID: 80313b3078fcd2ca51970880d90757f05879a193
Gitweb: http://git.kernel.org/tip/80313b3078fcd2ca51970880d90757f05879a193
Author: Stefan Lippers-Hollmann
AuthorDate: Mon, 30 Mar 2015 22:44:27 +0200
Committer: Ingo Molnar
CommitDate: Wed, 1 Apr 2015 14:08:09 +0200
x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk
The ASRock Q1900DC-ITX mainboard (Baytrail-D) hangs randomly in
both BIOS and UEFI mode while rebooting unless reboot=pci is
used. Add a quirk to reboot via the pci method.
The problem is very intermittent and hard to debug, it might succeed
rebooting just fine 40 times in a row - but fails half a dozen times
the next day. It seems to be slightly less common in BIOS CSM mode
than native UEFI (with the CSM disabled), but it does happen in either
mode. Since I've started testing this patch in late january, rebooting
has been 100% reliable.
Most of the time it already hangs during POST, but occasionally it
might even make it through the bootloader and the kernel might even
start booting, but then hangs before the mode switch. The same symptoms
occur with grub-efi, gummiboot and grub-pc, just as well as (at least)
kernel 3.16-3.19 and 4.0-rc6 (I haven't tried older kernels than 3.16).
Upgrading to the most current mainboard firmware of the ASRock
Q1900DC-ITX, version 1.20, does not improve the situation.
( Searching the web seems to suggest that other Bay Trail-D mainboards
might be affected as well. )
--
Signed-off-by: Stefan Lippers-Hollmann
Cc:
Cc: Matt Fleming
Link: http://lkml.kernel.org/r/20150330224427.0fb58e42@mir
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/reboot.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index bae6c60..86db4bc 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -183,6 +183,16 @@ static struct dmi_system_id __initdata reboot_dmi_table[]
= {
},
},
+ /* ASRock */
+ { /* Handle problems with rebooting on ASRock Q1900DC-ITX */
+ .callback = set_pci_reboot,
+ .ident = "ASRock Q1900DC-ITX",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "ASRock"),
+ DMI_MATCH(DMI_BOARD_NAME, "Q1900DC-ITX"),
+ },
+ },
+
/* ASUS */
{ /* Handle problems with rebooting on ASUS P4S800 */
.callback = set_bios_reboot,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/urgent] x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk
Commit-ID: 80313b3078fcd2ca51970880d90757f05879a193
Gitweb: http://git.kernel.org/tip/80313b3078fcd2ca51970880d90757f05879a193
Author: Stefan Lippers-Hollmann s@gmx.de
AuthorDate: Mon, 30 Mar 2015 22:44:27 +0200
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed, 1 Apr 2015 14:08:09 +0200
x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk
The ASRock Q1900DC-ITX mainboard (Baytrail-D) hangs randomly in
both BIOS and UEFI mode while rebooting unless reboot=pci is
used. Add a quirk to reboot via the pci method.
The problem is very intermittent and hard to debug, it might succeed
rebooting just fine 40 times in a row - but fails half a dozen times
the next day. It seems to be slightly less common in BIOS CSM mode
than native UEFI (with the CSM disabled), but it does happen in either
mode. Since I've started testing this patch in late january, rebooting
has been 100% reliable.
Most of the time it already hangs during POST, but occasionally it
might even make it through the bootloader and the kernel might even
start booting, but then hangs before the mode switch. The same symptoms
occur with grub-efi, gummiboot and grub-pc, just as well as (at least)
kernel 3.16-3.19 and 4.0-rc6 (I haven't tried older kernels than 3.16).
Upgrading to the most current mainboard firmware of the ASRock
Q1900DC-ITX, version 1.20, does not improve the situation.
( Searching the web seems to suggest that other Bay Trail-D mainboards
might be affected as well. )
--
Signed-off-by: Stefan Lippers-Hollmann s@gmx.de
Cc: sta...@vger.kernel.org
Cc: Matt Fleming matt.flem...@intel.com
Link: http://lkml.kernel.org/r/20150330224427.0fb58e42@mir
Signed-off-by: Ingo Molnar mi...@kernel.org
---
arch/x86/kernel/reboot.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index bae6c60..86db4bc 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -183,6 +183,16 @@ static struct dmi_system_id __initdata reboot_dmi_table[]
= {
},
},
+ /* ASRock */
+ { /* Handle problems with rebooting on ASRock Q1900DC-ITX */
+ .callback = set_pci_reboot,
+ .ident = ASRock Q1900DC-ITX,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, ASRock),
+ DMI_MATCH(DMI_BOARD_NAME, Q1900DC-ITX),
+ },
+ },
+
/* ASUS */
{ /* Handle problems with rebooting on ASUS P4S800 */
.callback = set_bios_reboot,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add ASRock Q1900DC-ITX mainboard reboot quirk
Hi
On 2015-03-31, Ingo Molnar wrote:
> * Stefan Lippers-Hollmann wrote:
[...]
> > Searching the web seems to suggest that other Bay Trail-D mainboards
> > might be affected as well.
>
> Is the pattern:
>
> > + .ident = "ASRock Q1900DC-ITX",
> > + .matches = {
> > + DMI_MATCH(DMI_BOARD_VENDOR, "ASRock"),
> > + DMI_MATCH(DMI_BOARD_NAME, "Q1900DC-ITX"),
>
> generic enough to cover all ASRock Bay Trail-D boards?
[...]
No, it covers only the one I can personally test and confirm to require
this quirk, beyond my own ASRock Q1900DC-ITX[1], there are at least:
Celeron J1800:
- ASRock D1800B-ITX, http://www.asrock.com/mb/Intel/D1800B-ITX/
- ASRock D1800M, http://www.asrock.com/mb/Intel/D1800M/
Celeron J1900:
- ASRock Q1900B-ITX, http://www.asrock.com/mb/Intel/Q1900B-ITX/
- ASRock Q1900-ITX, http://www.asrock.com/mb/Intel/Q1900-ITX/
- ASRock Q1900TM-ITX, http://www.asrock.com/mb/Intel/Q1900TM-ITX/
- ASRock Q1900M Pro3, http://www.asrock.com/mb/Intel/Q1900M%20Pro3/
- ASRock Q1900M, http://www.asrock.com/mb/Intel/Q1900M/
Pentium J2900:
- ASRock Q2900M, http://www.asrock.com/mb/Intel/Q2900M/
- ASRock Q2900-ITX, http://www.asrock.com/mb/Intel/Q2900-ITX/
All very similar boards, but their BIOS state might differ.
However I've never had access to any of those and could only do an
educated guess about their DMI identification[2]. While researching my
problem on the web, it seems that Baytrail-D boards from several vendors
might be affected (e.g. Gigabyte). Sometimes apparently fixed by later
BIOS updates, but I can only confirm the problem and workaround for my
own ASRock Q1900DC-ITX mainboard (where all published BIOS versions are
affected).
Regards
Stefan Lippers-Hollmann
[1] http://www.asrock.com/mb/Intel/Q1900DC-ITX/
[2] I know that the very similar ASRock Q1900-ITX board uses
DMI_MATCH(DMI_BOARD_VENDOR, "ASRock"),
DMI_MATCH(DMI_BOARD_NAME, "Q1900-ITX"),
but I don't have direct access to that board and can't
check if it is also affected by this problem.
pgp5Y1Ch2BBKv.pgp
Description: Digitale Signatur von OpenPGP
Re: [PATCH] x86: add ASRock Q1900DC-ITX mainboard reboot quirk
Hi
On 2015-03-31, Ingo Molnar wrote:
* Stefan Lippers-Hollmann s@gmx.de wrote:
[...]
Searching the web seems to suggest that other Bay Trail-D mainboards
might be affected as well.
Is the pattern:
+ .ident = ASRock Q1900DC-ITX,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, ASRock),
+ DMI_MATCH(DMI_BOARD_NAME, Q1900DC-ITX),
generic enough to cover all ASRock Bay Trail-D boards?
[...]
No, it covers only the one I can personally test and confirm to require
this quirk, beyond my own ASRock Q1900DC-ITX[1], there are at least:
Celeron J1800:
- ASRock D1800B-ITX, http://www.asrock.com/mb/Intel/D1800B-ITX/
- ASRock D1800M, http://www.asrock.com/mb/Intel/D1800M/
Celeron J1900:
- ASRock Q1900B-ITX, http://www.asrock.com/mb/Intel/Q1900B-ITX/
- ASRock Q1900-ITX, http://www.asrock.com/mb/Intel/Q1900-ITX/
- ASRock Q1900TM-ITX, http://www.asrock.com/mb/Intel/Q1900TM-ITX/
- ASRock Q1900M Pro3, http://www.asrock.com/mb/Intel/Q1900M%20Pro3/
- ASRock Q1900M, http://www.asrock.com/mb/Intel/Q1900M/
Pentium J2900:
- ASRock Q2900M, http://www.asrock.com/mb/Intel/Q2900M/
- ASRock Q2900-ITX, http://www.asrock.com/mb/Intel/Q2900-ITX/
All very similar boards, but their BIOS state might differ.
However I've never had access to any of those and could only do an
educated guess about their DMI identification[2]. While researching my
problem on the web, it seems that Baytrail-D boards from several vendors
might be affected (e.g. Gigabyte). Sometimes apparently fixed by later
BIOS updates, but I can only confirm the problem and workaround for my
own ASRock Q1900DC-ITX mainboard (where all published BIOS versions are
affected).
Regards
Stefan Lippers-Hollmann
[1] http://www.asrock.com/mb/Intel/Q1900DC-ITX/
[2] I know that the very similar ASRock Q1900-ITX board uses
DMI_MATCH(DMI_BOARD_VENDOR, ASRock),
DMI_MATCH(DMI_BOARD_NAME, Q1900-ITX),
but I don't have direct access to that board and can't
check if it is also affected by this problem.
pgp5Y1Ch2BBKv.pgp
Description: Digitale Signatur von OpenPGP
[PATCH] x86: add ASRock Q1900DC-ITX mainboard reboot quirk
The ASRock Q1900DC-ITX mainboard (Baytrail-D) hangs randomly in both
BIOS and UEFI mode while rebooting unless reboot=pci is used. Add a
quirk to reboot via the pci method.
Signed-off-by: Stefan Lippers-Hollmann
Cc:
---
The problem is very intermittent and hard to debug, it might succeed
rebooting just fine 40 times in a row - but fails half a dozen times
the next day. It seems to be slightly less common in BIOS CSM mode
than native UEFI (with the CSM disabled), but it does happen in either
mode. Since I've started testing this patch in late january, rebooting
has been 100% reliable.
Most of the time it already hangs during POST, but occassionally it
might even make it through the bootloader and the kernel might even
start booting, but then hangs before the mode switch. The same symptoms
occur with grub-efi, gummiboot and grub-pc, just as well as (at least)
kernel 3.16-3.19 and 4.0-rc6 (I haven't tried older kernels than 3.16).
Upgrading to the most current mainboard firmware of the ASRock
Q1900DC-ITX, version 1.20, does not improve the situation.
Searching the web seems to suggest that other Bay Trail-D mainboards
might be affected as well.
The patch applies without problems against 3.19, 4.0-rc and linux-next.
arch/x86/kernel/reboot.c | 10 ++
1 file changed, 10 insertions(+)
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -183,6 +183,16 @@ static struct dmi_system_id __initdata r
},
},
+ /* ASRock */
+ { /* Handle problems with rebooting on ASRock Q1900DC-ITX */
+ .callback = set_pci_reboot,
+ .ident = "ASRock Q1900DC-ITX",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "ASRock"),
+ DMI_MATCH(DMI_BOARD_NAME, "Q1900DC-ITX"),
+ },
+ },
+
/* ASUS */
{ /* Handle problems with rebooting on ASUS P4S800 */
.callback = set_bios_reboot,
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mceusb: sysfs: cannot create duplicate filename '/class/rc/rc0' (race condition between multiple RC_CORE devices)
Hi On 2015-03-30, David Härdeman wrote: > On 2015-03-30 17:30, Stefan Lippers-Hollmann wrote: > > Hi > > > > This is a follow-up for: > > http://lkml.kernel.org/r/<201412181916.18051.s@gmx.de> > > http://lkml.kernel.org/r/<201412302211.40801.s@gmx.de> > > I can't swear that it's the case but I'm guessing this might be fixed by > the patches I posted earlier (in particular the one that converted > rc-core to use the IDA infrastructure for keeping track of registered > minor device numbers). Do you have a pointer to that patch (-queue) or a tree containing it? So far I've only found https://patchwork.linuxtv.org/patch/23370/ with those keywords, respectively the thread at http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/76514 which seems to be partially applied, anything I could test (reproducing the problem takes its time, probably 4-10 weeks to be really sure, but I'd be happy to try or forward port the required parts). Thanks a lot Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mceusb: sysfs: cannot create duplicate filename '/class/rc/rc0' (race condition between multiple RC_CORE devices)
Hi This is a follow-up for: http://lkml.kernel.org/r/<201412181916.18051.s@gmx.de> http://lkml.kernel.org/r/<201412302211.40801.s@gmx.de> On 2014-12-30, Stefan Lippers-Hollmann wrote: > On Thursday 18 December 2014, Stefan Lippers-Hollmann wrote: > > Occassionally, but not readily reproducably, I hit a race condition > > between mceusb and other connected RC_CORE devices when mceusb tries > > to create /class/rc/rc0, which is -by then- already taken by another > > RC_CORE device. The other involved IR devices (physically only one) > > are part of a PCIe TeVii s480 s2.1 twin-tuner DVB-S2 card and aren't > > actually supposed to receive IR signals (IR receiver not connected): > > > > mceusb device transceiver: > > Bus 002 Device 004: ID 0609:0334 SMK Manufacturing, Inc. eHome Infrared > > Receiver > > > > DVB-T receiver (no RC_CORE device) > > Bus 001 Device 004: ID 0ccd:0069 TerraTec Electronic GmbH Cinergy T XE > > (Version 2, AF9015) > > > > twin-tuner DVB-S2 PCIe device, TeVii s480 v2.1 (physically one IR > > receiver (NEC protocol), logically recognized as two RC_CORE devices): > [...] > > Bus 006 Device 003: ID 9022:d660 TeVii Technology Ltd. DVB-S2 S660 > > Bus 003 Device 003: ID 9022:d660 TeVii Technology Ltd. DVB-S2 S660 > Today I got a new, similar, trace with kernel 3.18.1, but this is not a > regression and randomly happens with older kernels as well. The > frequency of this occuring differs vastly, this time it was 12 days > with probably 20 (re-)boots, before that it didn't happen for multiple > weeks. I can not totally rule out if it ever happened in the reverse > detection/ initialisation order, as I wouldn't notice the consequences > of dvb_usb_dw2102's RC_CORE devices failing to initialise, but I think > the problem might be seated in the common core of rc-main.c. This remains to be a re-occuring issue with kernel 3.19 and 4.0-rc6, not happening on every boot, but every few weeks. [1.837215] Registered IR keymap rc-rc6-mce [1.837225] [ cut here ] [1.837229] WARNING: CPU: 3 PID: 277 at /tmp/buildd/linux-aptosid-4.0~rc6/fs/sysfs/dir.c:31 sysfs_warn_dup+0x55/0x70() [1.837230] sysfs: cannot create duplicate filename '/class/rc/rc0' [1.837231] Modules linked in: rt2800usb(+) rt2x00usb rt2800lib rt2x00lib mac80211 cfg80211 rc_rc6_mce crc_ccitt mceusb(+) rc_tevii_nec ds3000 btusb dvb_usb_af9015 dvb_usb_v2 bluetooth nls_utf8 nls_cp437 vfat fat snd_hda_codec_hdmi iTCO_wdt eeepc_wmi iTCO_vendor_support asus_wmi sparse_keymap intel_rapl rfkill iosf_mbi x86_pkg_temp_thermal intel_powerclamp evdev coretemp snd_hda_codec_realtek snd_hda_codec_generic kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel dvb_usb_dw2102 dvb_usb aesni_intel aes_x86_64 lrw dvb_core gf128mul rc_core snd_hda_intel glue_helper i915 ablk_helper snd_hda_controller cryptd snd_hda_codec i2c_algo_bit psmouse snd_hwdep drm_kms_helper snd_pcm serio_raw pcspkr i2c_i801 drm snd_timer lpc_ich snd i2c_core mfd_core soundcore intel_gtt mei_me battery ie31200_edac [1.837253] mei 8250_fintek edac_core tpm_infineon video wmi processor button nct6775 hwmon_vid fuse parport_pc ppdev lp parport autofs4 ext4 crc16 jbd2 mbcache dm_mod sg sd_mod ohci_pci crc32c_intel ahci libahci libata xhci_pci scsi_mod ohci_hcd ehci_pci xhci_hcd ehci_hcd r8169 mii usbcore usb_common fan thermal [1.837267] CPU: 3 PID: 277 Comm: systemd-udevd Not tainted 4.0.0-rc6-aptosid-amd64 #1 aptosid 4.0~rc6-1~git0.slh.1 [1.837268] Hardware name: System manufacturer System Product Name/P8H77-M PRO, BIOS 1503 03/17/2014 [1.837269] 816236d0 54e7a09b 816236d0 814fb0ee [1.837271] 8807fb643880 81060627 8807fbe5c000 8807fbe2ee78 [1.837272] 8807f93a07f8 8807f93a07f8 ffef 810606b8 [1.837273] Call Trace: [1.837277] [] ? dump_stack+0x47/0x67 [1.837279] [] ? warn_slowpath_common+0x77/0xb0 [1.837280] [] ? warn_slowpath_fmt+0x58/0x80 [1.837282] [] ? kernfs_path+0x42/0x50 [1.837284] [] ? sysfs_warn_dup+0x55/0x70 [1.837286] [] ? sysfs_do_create_link_sd.isra.2+0xbe/0xd0 [1.837287] [] ? device_add+0x264/0x640 [1.837291] [] ? rc_register_device+0x1bc/0x610 [rc_core] [1.837293] [] ? mceusb_dev_probe+0x405/0xadd [mceusb] [1.837296] [] ? ida_get_new_above+0x1f8/0x220 [1.837298] [] ? ida_simple_get+0x99/0x120 [1.837304] [] ? usb_probe_interface+0x193/0x290 [usbcore] [1.837306] [] ? driver_probe_device+0x87/0x260 [1.837309] [] ? __driver_attach+0x7b/0x80 [1.837311] [] ? __device_attach+0x50/0x50 [1.837312] [] ? bus_for_each_dev+0x6b/0xc0 [1.837313] [] ? bus_add_driver+0x178/0x230 [1.837315] [] ? driver_register+0x5e/0xf0
Re: mceusb: sysfs: cannot create duplicate filename '/class/rc/rc0' (race condition between multiple RC_CORE devices)
Hi This is a follow-up for: http://lkml.kernel.org/r/201412181916.18051.s@gmx.de http://lkml.kernel.org/r/201412302211.40801.s@gmx.de On 2014-12-30, Stefan Lippers-Hollmann wrote: On Thursday 18 December 2014, Stefan Lippers-Hollmann wrote: Occassionally, but not readily reproducably, I hit a race condition between mceusb and other connected RC_CORE devices when mceusb tries to create /class/rc/rc0, which is -by then- already taken by another RC_CORE device. The other involved IR devices (physically only one) are part of a PCIe TeVii s480 s2.1 twin-tuner DVB-S2 card and aren't actually supposed to receive IR signals (IR receiver not connected): mceusb device transceiver: Bus 002 Device 004: ID 0609:0334 SMK Manufacturing, Inc. eHome Infrared Receiver DVB-T receiver (no RC_CORE device) Bus 001 Device 004: ID 0ccd:0069 TerraTec Electronic GmbH Cinergy T XE (Version 2, AF9015) twin-tuner DVB-S2 PCIe device, TeVii s480 v2.1 (physically one IR receiver (NEC protocol), logically recognized as two RC_CORE devices): [...] Bus 006 Device 003: ID 9022:d660 TeVii Technology Ltd. DVB-S2 S660 Bus 003 Device 003: ID 9022:d660 TeVii Technology Ltd. DVB-S2 S660 Today I got a new, similar, trace with kernel 3.18.1, but this is not a regression and randomly happens with older kernels as well. The frequency of this occuring differs vastly, this time it was 12 days with probably 20 (re-)boots, before that it didn't happen for multiple weeks. I can not totally rule out if it ever happened in the reverse detection/ initialisation order, as I wouldn't notice the consequences of dvb_usb_dw2102's RC_CORE devices failing to initialise, but I think the problem might be seated in the common core of rc-main.c. This remains to be a re-occuring issue with kernel 3.19 and 4.0-rc6, not happening on every boot, but every few weeks. [1.837215] Registered IR keymap rc-rc6-mce [1.837225] [ cut here ] [1.837229] WARNING: CPU: 3 PID: 277 at /tmp/buildd/linux-aptosid-4.0~rc6/fs/sysfs/dir.c:31 sysfs_warn_dup+0x55/0x70() [1.837230] sysfs: cannot create duplicate filename '/class/rc/rc0' [1.837231] Modules linked in: rt2800usb(+) rt2x00usb rt2800lib rt2x00lib mac80211 cfg80211 rc_rc6_mce crc_ccitt mceusb(+) rc_tevii_nec ds3000 btusb dvb_usb_af9015 dvb_usb_v2 bluetooth nls_utf8 nls_cp437 vfat fat snd_hda_codec_hdmi iTCO_wdt eeepc_wmi iTCO_vendor_support asus_wmi sparse_keymap intel_rapl rfkill iosf_mbi x86_pkg_temp_thermal intel_powerclamp evdev coretemp snd_hda_codec_realtek snd_hda_codec_generic kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel dvb_usb_dw2102 dvb_usb aesni_intel aes_x86_64 lrw dvb_core gf128mul rc_core snd_hda_intel glue_helper i915 ablk_helper snd_hda_controller cryptd snd_hda_codec i2c_algo_bit psmouse snd_hwdep drm_kms_helper snd_pcm serio_raw pcspkr i2c_i801 drm snd_timer lpc_ich snd i2c_core mfd_core soundcore intel_gtt mei_me battery ie31200_edac [1.837253] mei 8250_fintek edac_core tpm_infineon video wmi processor button nct6775 hwmon_vid fuse parport_pc ppdev lp parport autofs4 ext4 crc16 jbd2 mbcache dm_mod sg sd_mod ohci_pci crc32c_intel ahci libahci libata xhci_pci scsi_mod ohci_hcd ehci_pci xhci_hcd ehci_hcd r8169 mii usbcore usb_common fan thermal [1.837267] CPU: 3 PID: 277 Comm: systemd-udevd Not tainted 4.0.0-rc6-aptosid-amd64 #1 aptosid 4.0~rc6-1~git0.slh.1 [1.837268] Hardware name: System manufacturer System Product Name/P8H77-M PRO, BIOS 1503 03/17/2014 [1.837269] 816236d0 54e7a09b 816236d0 814fb0ee [1.837271] 8807fb643880 81060627 8807fbe5c000 8807fbe2ee78 [1.837272] 8807f93a07f8 8807f93a07f8 ffef 810606b8 [1.837273] Call Trace: [1.837277] [814fb0ee] ? dump_stack+0x47/0x67 [1.837279] [81060627] ? warn_slowpath_common+0x77/0xb0 [1.837280] [810606b8] ? warn_slowpath_fmt+0x58/0x80 [1.837282] [811ea562] ? kernfs_path+0x42/0x50 [1.837284] [811ed975] ? sysfs_warn_dup+0x55/0x70 [1.837286] [811edcce] ? sysfs_do_create_link_sd.isra.2+0xbe/0xd0 [1.837287] [813887a4] ? device_add+0x264/0x640 [1.837291] [a09c38dc] ? rc_register_device+0x1bc/0x610 [rc_core] [1.837293] [a0861f55] ? mceusb_dev_probe+0x405/0xadd [mceusb] [1.837296] [81271aa8] ? ida_get_new_above+0x1f8/0x220 [1.837298] [81271b69] ? ida_simple_get+0x99/0x120 [1.837304] [a0036763] ? usb_probe_interface+0x193/0x290 [usbcore] [1.837306] [8138b647] ? driver_probe_device+0x87/0x260 [1.837309] [8138b8eb] ? __driver_attach+0x7b/0x80 [1.837311] [8138b870] ? __device_attach+0x50/0x50 [1.837312] [813896fb] ? bus_for_each_dev+0x6b/0xc0 [1.837313] [8138ade8
Re: mceusb: sysfs: cannot create duplicate filename '/class/rc/rc0' (race condition between multiple RC_CORE devices)
Hi On 2015-03-30, David Härdeman wrote: On 2015-03-30 17:30, Stefan Lippers-Hollmann wrote: Hi This is a follow-up for: http://lkml.kernel.org/r/201412181916.18051.s@gmx.de http://lkml.kernel.org/r/201412302211.40801.s@gmx.de I can't swear that it's the case but I'm guessing this might be fixed by the patches I posted earlier (in particular the one that converted rc-core to use the IDA infrastructure for keeping track of registered minor device numbers). Do you have a pointer to that patch (-queue) or a tree containing it? So far I've only found https://patchwork.linuxtv.org/patch/23370/ with those keywords, respectively the thread at http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/76514 which seems to be partially applied, anything I could test (reproducing the problem takes its time, probably 4-10 weeks to be really sure, but I'd be happy to try or forward port the required parts). Thanks a lot Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: add ASRock Q1900DC-ITX mainboard reboot quirk
The ASRock Q1900DC-ITX mainboard (Baytrail-D) hangs randomly in both
BIOS and UEFI mode while rebooting unless reboot=pci is used. Add a
quirk to reboot via the pci method.
Signed-off-by: Stefan Lippers-Hollmann s@gmx.de
Cc: sta...@vger.kernel.org
---
The problem is very intermittent and hard to debug, it might succeed
rebooting just fine 40 times in a row - but fails half a dozen times
the next day. It seems to be slightly less common in BIOS CSM mode
than native UEFI (with the CSM disabled), but it does happen in either
mode. Since I've started testing this patch in late january, rebooting
has been 100% reliable.
Most of the time it already hangs during POST, but occassionally it
might even make it through the bootloader and the kernel might even
start booting, but then hangs before the mode switch. The same symptoms
occur with grub-efi, gummiboot and grub-pc, just as well as (at least)
kernel 3.16-3.19 and 4.0-rc6 (I haven't tried older kernels than 3.16).
Upgrading to the most current mainboard firmware of the ASRock
Q1900DC-ITX, version 1.20, does not improve the situation.
Searching the web seems to suggest that other Bay Trail-D mainboards
might be affected as well.
The patch applies without problems against 3.19, 4.0-rc and linux-next.
arch/x86/kernel/reboot.c | 10 ++
1 file changed, 10 insertions(+)
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -183,6 +183,16 @@ static struct dmi_system_id __initdata r
},
},
+ /* ASRock */
+ { /* Handle problems with rebooting on ASRock Q1900DC-ITX */
+ .callback = set_pci_reboot,
+ .ident = ASRock Q1900DC-ITX,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, ASRock),
+ DMI_MATCH(DMI_BOARD_NAME, Q1900DC-ITX),
+ },
+ },
+
/* ASUS */
{ /* Handle problems with rebooting on ASUS P4S800 */
.callback = set_bios_reboot,
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mceusb: sysfs: cannot create duplicate filename '/class/rc/rc0' (race condition between multiple RC_CORE devices)
Hi Adding the maintainers for drivers/media/rc/rc-main.c into the loop. This is a follow-up for: http://lkml.kernel.org/r/<201412181916.18051.s@gmx.de> On Thursday 18 December 2014, Stefan Lippers-Hollmann wrote: > Occassionally, but not readily reproducably, I hit a race condition > between mceusb and other connected RC_CORE devices when mceusb tries > to create /class/rc/rc0, which is -by then- already taken by another > RC_CORE device. The other involved IR devices (physically only one) > are part of a PCIe TeVii s480 s2.1 twin-tuner DVB-S2 card and aren't > actually supposed to receive IR signals (IR receiver not connected): > > mceusb device transceiver: > Bus 002 Device 004: ID 0609:0334 SMK Manufacturing, Inc. eHome Infrared > Receiver > > DVB-T receiver (no RC_CORE device) > Bus 001 Device 004: ID 0ccd:0069 TerraTec Electronic GmbH Cinergy T XE > (Version 2, AF9015) > > twin-tuner DVB-S2 PCIe device, TeVii s480 v2.1 (physically one IR > receiver (NEC protocol), logically recognized as two RC_CORE devices): [...] > Bus 006 Device 003: ID 9022:d660 TeVii Technology Ltd. DVB-S2 S660 > Bus 003 Device 003: ID 9022:d660 TeVii Technology Ltd. DVB-S2 S660 Today I got a new, similar, trace with kernel 3.18.1, but this is not a regression and randomly happens with older kernels as well. The frequency of this occuring differs vastly, this time it was 12 days with probably 20 (re-)boots, before that it didn't happen for multiple weeks. I can not totally rule out if it ever happened in the reverse detection/ initialisation order, as I wouldn't notice the consequences of dvb_usb_dw2102's RC_CORE devices failing to initialise, but I think the problem might be seated in the common core of rc-main.c. usb 1-1.5: New USB device found, idVendor=0ccd, idProduct=0069 usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.5: Product: Cinergy T USB XE Ver.2 usb 1-1.5: Manufacturer: TerraTec usb 1-1.5: SerialNumber: 10012007 [...] dvb-usb: found a 'TeVii S480.1 USB' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' dw2102: start downloading DW210X firmware usb 1-1.5: dvb_usb_v2: found a 'TerraTec Cinergy T USB XE' in cold state usb 1-1.5: dvb_usb_v2: downloading firmware from file 'dvb-usb-af9015.fw' [...] usb 2-1.6: New USB device found, idVendor=0609, idProduct=0334 usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1.6: Product: MCE TRANCEIVR Emulator Device 2006 usb 2-1.6: Manufacturer: SMK CORPORATION usb 2-1.6: SerialNumber: PA070620045513C [...] usb 3-1: USB disconnect, device number 2 usb 2-1.8: new full-speed USB device number 5 using ehci-pci usb 1-1.5: dvb_usb_v2: found a 'TerraTec Cinergy T USB XE' in warm state [...] dvb-usb: found a 'TeVii S480.1 USB' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TeVii S480.1 USB) dvb-usb: MAC address: 70:70:70:70:70:70 Invalid probe, probably not a DS3000 dvb-usb: no frontend was attached by 'TeVii S480.1 USB' [...] Registered IR keymap rc-tevii-nec input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1c.5/:04:00.1/usb3/3-1/rc/rc0/input18 rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1c.5/:04:00.1/usb3/3-1/rc/rc0 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: TeVii S480.1 USB successfully initialized and connected. dvb-usb: found a 'TeVii S480.2 USB' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' dw2102: start downloading DW210X firmware [...] Registered IR keymap rc-rc6-mce [ cut here ] WARNING: CPU: 1 PID: 311 at /tmp/buildd/linux-aptosid-3.18/fs/sysfs/dir.c:31 sysfs_warn_dup+0x55/0x70() sysfs: cannot create duplicate filename '/class/rc/rc0' Modules linked in: rt2800usb(+) rt2x00usb rt2800lib rt2x00lib mac80211 cfg80211 crc_ccitt rc_rc6_mce mceusb(+) rc_tevii_nec ds3000 nls_utf8 nls_cp437 vfat fat iTCO_wdt iTCO_vendor_support eeepc_wmi asus_wmi intel_rapl sparse_keymap rfkill x86_pkg_temp_thermal evdev intel_powerclamp coretemp kvm_intel kvm snd_hda_codec_hdmi crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper dvb_usb_af9015(+) cryptd dvb_usb_v2 dvb_usb_dw2102(+) dvb_usb dvb_core rc_core psmouse snd_hda_intel pcspkr snd_hda_controller serio_raw i2c_i801 snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore lpc_ich mfd_core battery tpm_infineon i915 video i2c_algo_bit drm_kms_helper drm i2c_core intel_gtt ie31200_edac mei_me edac_core mei wmi button processor nct6775 hwmon_vid fuse parport_pc ppdev lp parport autofs4 ext4 crc16 jbd2 mbcache dm_mod sg sd_mod ohci_pci crc32c_intel ahci libahci libata scsi_mod xhci_pci ohci_h
Re: mceusb: sysfs: cannot create duplicate filename '/class/rc/rc0' (race condition between multiple RC_CORE devices)
Hi Adding the maintainers for drivers/media/rc/rc-main.c into the loop. This is a follow-up for: http://lkml.kernel.org/r/201412181916.18051.s@gmx.de On Thursday 18 December 2014, Stefan Lippers-Hollmann wrote: Occassionally, but not readily reproducably, I hit a race condition between mceusb and other connected RC_CORE devices when mceusb tries to create /class/rc/rc0, which is -by then- already taken by another RC_CORE device. The other involved IR devices (physically only one) are part of a PCIe TeVii s480 s2.1 twin-tuner DVB-S2 card and aren't actually supposed to receive IR signals (IR receiver not connected): mceusb device transceiver: Bus 002 Device 004: ID 0609:0334 SMK Manufacturing, Inc. eHome Infrared Receiver DVB-T receiver (no RC_CORE device) Bus 001 Device 004: ID 0ccd:0069 TerraTec Electronic GmbH Cinergy T XE (Version 2, AF9015) twin-tuner DVB-S2 PCIe device, TeVii s480 v2.1 (physically one IR receiver (NEC protocol), logically recognized as two RC_CORE devices): [...] Bus 006 Device 003: ID 9022:d660 TeVii Technology Ltd. DVB-S2 S660 Bus 003 Device 003: ID 9022:d660 TeVii Technology Ltd. DVB-S2 S660 Today I got a new, similar, trace with kernel 3.18.1, but this is not a regression and randomly happens with older kernels as well. The frequency of this occuring differs vastly, this time it was 12 days with probably 20 (re-)boots, before that it didn't happen for multiple weeks. I can not totally rule out if it ever happened in the reverse detection/ initialisation order, as I wouldn't notice the consequences of dvb_usb_dw2102's RC_CORE devices failing to initialise, but I think the problem might be seated in the common core of rc-main.c. usb 1-1.5: New USB device found, idVendor=0ccd, idProduct=0069 usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.5: Product: Cinergy T USB XE Ver.2 usb 1-1.5: Manufacturer: TerraTec usb 1-1.5: SerialNumber: 10012007 [...] dvb-usb: found a 'TeVii S480.1 USB' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' dw2102: start downloading DW210X firmware usb 1-1.5: dvb_usb_v2: found a 'TerraTec Cinergy T USB XE' in cold state usb 1-1.5: dvb_usb_v2: downloading firmware from file 'dvb-usb-af9015.fw' [...] usb 2-1.6: New USB device found, idVendor=0609, idProduct=0334 usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1.6: Product: MCE TRANCEIVR Emulator Device 2006 usb 2-1.6: Manufacturer: SMK CORPORATION usb 2-1.6: SerialNumber: PA070620045513C [...] usb 3-1: USB disconnect, device number 2 usb 2-1.8: new full-speed USB device number 5 using ehci-pci usb 1-1.5: dvb_usb_v2: found a 'TerraTec Cinergy T USB XE' in warm state [...] dvb-usb: found a 'TeVii S480.1 USB' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TeVii S480.1 USB) dvb-usb: MAC address: 70:70:70:70:70:70 Invalid probe, probably not a DS3000 dvb-usb: no frontend was attached by 'TeVii S480.1 USB' [...] Registered IR keymap rc-tevii-nec input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1c.5/:04:00.1/usb3/3-1/rc/rc0/input18 rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1c.5/:04:00.1/usb3/3-1/rc/rc0 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: TeVii S480.1 USB successfully initialized and connected. dvb-usb: found a 'TeVii S480.2 USB' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' dw2102: start downloading DW210X firmware [...] Registered IR keymap rc-rc6-mce [ cut here ] WARNING: CPU: 1 PID: 311 at /tmp/buildd/linux-aptosid-3.18/fs/sysfs/dir.c:31 sysfs_warn_dup+0x55/0x70() sysfs: cannot create duplicate filename '/class/rc/rc0' Modules linked in: rt2800usb(+) rt2x00usb rt2800lib rt2x00lib mac80211 cfg80211 crc_ccitt rc_rc6_mce mceusb(+) rc_tevii_nec ds3000 nls_utf8 nls_cp437 vfat fat iTCO_wdt iTCO_vendor_support eeepc_wmi asus_wmi intel_rapl sparse_keymap rfkill x86_pkg_temp_thermal evdev intel_powerclamp coretemp kvm_intel kvm snd_hda_codec_hdmi crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper dvb_usb_af9015(+) cryptd dvb_usb_v2 dvb_usb_dw2102(+) dvb_usb dvb_core rc_core psmouse snd_hda_intel pcspkr snd_hda_controller serio_raw i2c_i801 snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore lpc_ich mfd_core battery tpm_infineon i915 video i2c_algo_bit drm_kms_helper drm i2c_core intel_gtt ie31200_edac mei_me edac_core mei wmi button processor nct6775 hwmon_vid fuse parport_pc ppdev lp parport autofs4 ext4 crc16 jbd2 mbcache dm_mod sg sd_mod ohci_pci crc32c_intel ahci libahci libata scsi_mod xhci_pci ohci_hcd ehci_pci xhci_hcd ehci_hcd r8169 mii usbcore usb_common fan thermal CPU: 1 PID: 311
mceusb: sysfs: cannot create duplicate filename '/class/rc/rc0' (race condition between multiple RC_CORE devices)
USB device found, idVendor=9022, idProduct=d660 usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-1: Product: DVBS2BOX usb 3-1: Manufacturer: TBS-Tech dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' dw2102: start downloading DW210X firmware usb 6-1: new high-speed USB device number 3 using ehci-pci dvb-usb: found a 'TeVii S660 USB' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TeVii S660 USB) usb 6-1: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 2 [...] usb 6-1: New USB device found, idVendor=9022, idProduct=d660 usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 6-1: Product: DVBS2BOX usb 6-1: Manufacturer: TBS-Tech dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' dw2102: start downloading DW210X firmware dvb-usb: found a 'TeVii S660 USB' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TeVii S660 USB) dvb-usb: MAC address: 00:18:bd:5a:be:8b DS3000 chip version: 0.192 attached. ts2020_attach: Find tuner TS2020! dw2102: Attached ds3000+ts2020! usb 3-1: DVB: registering adapter 1 frontend 0 (Montage Technology DS3000)... Registered IR keymap rc-tevii-nec input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1c.5/:04:00.1/usb3/3-1/rc/rc0/input25 rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1c.5/:04:00.1/usb3/3-1/rc/rc0 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: TeVii S660 USB successfully initialized and connected. dvb-usb: MAC address: 00:18:bd:5a:be:8c DS3000 chip version: 0.192 attached. ts2020_attach: Find tuner TS2020! dw2102: Attached ds3000+ts2020! usb 6-1: DVB: registering adapter 2 frontend 0 (Montage Technology DS3000)... Registered IR keymap rc-tevii-nec input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1c.5/:04:00.3/usb6/6-1/rc/rc1/input26 rc1: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1c.5/:04:00.3/usb6/6-1/rc/rc1 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: TeVii S660 USB successfully initialized and connected. [...] ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)... ds3000_firmware_ondemand: Waiting for firmware upload(2)... ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)... ds3000_firmware_ondemand: Waiting for firmware upload(2)... [...] This can be recovered by reloading mceusb # modprobe -r mceusb # modprobe mceusb usbcore: deregistering interface driver mceusb Registered IR keymap rc-rc6-mce input: Media Center Ed. eHome Infrared Remote Transceiver (0609:0334) as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/rc/rc2/input27 rc2: Media Center Ed. eHome Infrared Remote Transceiver (0609:0334) as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/rc/rc2 IR RC5(x/sz) protocol handler initialized IR NEC protocol handler initialized IR RC6 protocol handler initialized IR Sony protocol handler initialized IR JVC protocol handler initialized IR SANYO protocol handler initialized IR Sharp protocol handler initialized input: MCE IR Keyboard/Mouse (mceusb) as /devices/virtual/input/input28 lirc_dev: IR Remote Control driver registered, major 249 IR MCE Keyboard/mouse protocol handler initialized IR XMP protocol handler initialized rc rc2: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0 IR LIRC bridge handler initialized mceusb 2-1.6:1.0: Registered SMK CORPORATION MCE TRANCEIVR Emulator Device 2006 with mce emulator interface version 1 mceusb 2-1.6:1.0: 2 tx ports (0x0 cabled) and 2 rx sensors (0x1 active) usbcore: registered new interface driver mceusb Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mceusb: sysfs: cannot create duplicate filename '/class/rc/rc0' (race condition between multiple RC_CORE devices)
: DVB: registering adapter 0 frontend 0 (Afatech AF9013)... mc44s803: successfully identified (ID = 14) usb 1-1.5: dvb_usb_v2: 'TerraTec Cinergy T USB XE' successfully initialized and connected usbcore: registered new interface driver dvb_usb_af9015 [...] usb 3-1: new high-speed USB device number 3 using ehci-pci usb 3-1: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 2 usb 3-1: New USB device found, idVendor=9022, idProduct=d660 usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-1: Product: DVBS2BOX usb 3-1: Manufacturer: TBS-Tech dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' dw2102: start downloading DW210X firmware usb 6-1: new high-speed USB device number 3 using ehci-pci dvb-usb: found a 'TeVii S660 USB' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TeVii S660 USB) usb 6-1: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 2 [...] usb 6-1: New USB device found, idVendor=9022, idProduct=d660 usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 6-1: Product: DVBS2BOX usb 6-1: Manufacturer: TBS-Tech dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' dw2102: start downloading DW210X firmware dvb-usb: found a 'TeVii S660 USB' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TeVii S660 USB) dvb-usb: MAC address: 00:18:bd:5a:be:8b DS3000 chip version: 0.192 attached. ts2020_attach: Find tuner TS2020! dw2102: Attached ds3000+ts2020! usb 3-1: DVB: registering adapter 1 frontend 0 (Montage Technology DS3000)... Registered IR keymap rc-tevii-nec input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1c.5/:04:00.1/usb3/3-1/rc/rc0/input25 rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1c.5/:04:00.1/usb3/3-1/rc/rc0 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: TeVii S660 USB successfully initialized and connected. dvb-usb: MAC address: 00:18:bd:5a:be:8c DS3000 chip version: 0.192 attached. ts2020_attach: Find tuner TS2020! dw2102: Attached ds3000+ts2020! usb 6-1: DVB: registering adapter 2 frontend 0 (Montage Technology DS3000)... Registered IR keymap rc-tevii-nec input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1c.5/:04:00.3/usb6/6-1/rc/rc1/input26 rc1: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1c.5/:04:00.3/usb6/6-1/rc/rc1 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: TeVii S660 USB successfully initialized and connected. [...] ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)... ds3000_firmware_ondemand: Waiting for firmware upload(2)... ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)... ds3000_firmware_ondemand: Waiting for firmware upload(2)... [...] This can be recovered by reloading mceusb # modprobe -r mceusb # modprobe mceusb usbcore: deregistering interface driver mceusb Registered IR keymap rc-rc6-mce input: Media Center Ed. eHome Infrared Remote Transceiver (0609:0334) as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/rc/rc2/input27 rc2: Media Center Ed. eHome Infrared Remote Transceiver (0609:0334) as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/rc/rc2 IR RC5(x/sz) protocol handler initialized IR NEC protocol handler initialized IR RC6 protocol handler initialized IR Sony protocol handler initialized IR JVC protocol handler initialized IR SANYO protocol handler initialized IR Sharp protocol handler initialized input: MCE IR Keyboard/Mouse (mceusb) as /devices/virtual/input/input28 lirc_dev: IR Remote Control driver registered, major 249 IR MCE Keyboard/mouse protocol handler initialized IR XMP protocol handler initialized rc rc2: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0 IR LIRC bridge handler initialized mceusb 2-1.6:1.0: Registered SMK CORPORATION MCE TRANCEIVR Emulator Device 2006 with mce emulator interface version 1 mceusb 2-1.6:1.0: 2 tx ports (0x0 cabled) and 2 rx sensors (0x1 active) usbcore: registered new interface driver mceusb Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8187se: Fix warning symbol should be static
Hi On Sunday 06 April 2014, Josh Triplett wrote: > On Sun, Apr 06, 2014 at 05:46:04PM +0200, Jonas Hahnfeld wrote: > > This patch solves some sparse warnings about "symbol [...] was not > > declared. Should it be static?" by including the correct header files. > > > > Signed-off-by: Jonas Hahnfeld > > Reviewed-by: Josh Triplett [...] Given that that rtl8187se support has already been merged mainline (for 3.15-rc1) into the existing rtl8180 (soon to be renamed to rtl818x) driver, wouldn't it make more sense to remove drivers/staging/rtl8187se/ rather than trying to fixing it? commit 1eba648f998ef9c31b8cf062754a4a7b4ab9001f Author: Andrea Merello Date: Wed Mar 26 21:04:23 2014 +0100 rtl8180: enable rtl8187se support Finally make rtl8187se works (hopefylly). This patch adds PCI ID for rtl8187, updates copyright notes and updates MODULE_DESCRIPTION. Signed-off-by: Andrea Merello Signed-off-by: John W. Linville Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8187se: Fix warning symbol should be static
Hi On Sunday 06 April 2014, Josh Triplett wrote: On Sun, Apr 06, 2014 at 05:46:04PM +0200, Jonas Hahnfeld wrote: This patch solves some sparse warnings about symbol [...] was not declared. Should it be static? by including the correct header files. Signed-off-by: Jonas Hahnfeld hah...@hahnjo.de Reviewed-by: Josh Triplett j...@joshtriplett.org [...] Given that that rtl8187se support has already been merged mainline (for 3.15-rc1) into the existing rtl8180 (soon to be renamed to rtl818x) driver, wouldn't it make more sense to remove drivers/staging/rtl8187se/ rather than trying to fixing it? commit 1eba648f998ef9c31b8cf062754a4a7b4ab9001f Author: Andrea Merello andrea.mere...@gmail.com Date: Wed Mar 26 21:04:23 2014 +0100 rtl8180: enable rtl8187se support Finally make rtl8187se works (hopefylly). This patch adds PCI ID for rtl8187, updates copyright notes and updates MODULE_DESCRIPTION. Signed-off-by: Andrea Merello andrea.mere...@gmail.com Signed-off-by: John W. Linville linvi...@tuxdriver.com Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 072/149] ACPI / resources: ignore invalid ACPI device resources
Hi
On Friday 21 March 2014, Greg Kroah-Hartman wrote:
> 3.13-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Zhang Rui
>
> commit b355cee88e3b1a193f0e9a81db810f6f83ad728b upstream.
>
> ACPI table may export resource entry with 0 length.
> But the current code interprets this kind of resource in a wrong way.
> It will create a resource structure with
> res->end = acpi_resource->start + acpi_resource->len - 1;
>
> This patch fixes a problem on my machine that a platform device fails
> to be created because one of its ACPI IO resource entry (start = 0,
> end = 0, length = 0) is translated into a generic resource with
> start = 0, end = 0x.
>
> Signed-off-by: Zhang Rui
> Signed-off-by: Rafael J. Wysocki
> Signed-off-by: Greg Kroah-Hartman
[...]
This patch should probably be dropped from -stable (3.13 and 3.10) for
the time being, it causes this warning:
pnp 00:01: unknown resource type 4 in _CRS
pnp 00:01: can't evaluate _CRS: 1
on all systems I've tested it on so far (~12 systems of vastly varying
components and age, covering amd64 and i386).
This also seems to affect others as well:
http://www.spinics.net/lists/linux-acpi/msg49431.html
http://www.spinics.net/lists/linux-acpi/msg49438.html
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 072/149] ACPI / resources: ignore invalid ACPI device resources
Hi On Friday 21 March 2014, Greg Kroah-Hartman wrote: 3.13-stable review patch. If anyone has any objections, please let me know. -- From: Zhang Rui rui.zh...@intel.com commit b355cee88e3b1a193f0e9a81db810f6f83ad728b upstream. ACPI table may export resource entry with 0 length. But the current code interprets this kind of resource in a wrong way. It will create a resource structure with res-end = acpi_resource-start + acpi_resource-len - 1; This patch fixes a problem on my machine that a platform device fails to be created because one of its ACPI IO resource entry (start = 0, end = 0, length = 0) is translated into a generic resource with start = 0, end = 0x. Signed-off-by: Zhang Rui rui.zh...@intel.com Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org [...] This patch should probably be dropped from -stable (3.13 and 3.10) for the time being, it causes this warning: pnp 00:01: unknown resource type 4 in _CRS pnp 00:01: can't evaluate _CRS: 1 on all systems I've tested it on so far (~12 systems of vastly varying components and age, covering amd64 and i386). This also seems to affect others as well: http://www.spinics.net/lists/linux-acpi/msg49431.html http://www.spinics.net/lists/linux-acpi/msg49438.html Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-rc: /proc/acpi/battery gone?
Hi On Saturday 15 March 2014, Lan Tianyu wrote: > On 03/14/2014 10:17 PM, Stefan Lippers-Hollmann wrote: > > Hi > > > > On Saturday 15 March 2014, Rafael J. Wysocki wrote: > >> On Friday, March 14, 2014 06:14:12 PM Ilia Mirkin wrote: > >>> On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek wrote: > >>>> On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote: > >>>>> On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek wrote: [...] > Hi Stefan: > I just glance wmbattery code. I find the code in the acpi.c is already > using the new sysfs battery interfaces, right? By default, wmbattery appears to default to using upower as abstraction level, instead of querying sysfs itself directly. http://git.kitenet.net/?p=wmbattery.git;a=blob;f=autoconf/makeinfo.in;hb=HEAD which sets USE_UPOWER=1 by default. If USE_UPOWER=0 is set explicitly for the build, it reverts back to direct sysfs parsing - and yes, it does appear to adhere to the current sysfs API properly. The last remains, and the ability to parse procfs (which hasn't been default for quite some time already, in favour of using hal as abstraction layer) has finally been removed in http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=833eb63a5ce4f2fb712a201b1db4f2db1700fddb The switch from procfs parsing to hal (by default at least) in turn happened with http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=63c3d1a0b11e8ade1a5612bb5baa3d92e153bbbe in 2008 (before Debian squeeze/ oldstable). I have not investigated if hal then read from procfs or sysfs, but wmbattery at least didn't read from procfs itself, unless explicitly told to do so (USE_HAL=0) during the build since mid 2008. The current version of wmbattery however will never try to access /proc/acpi, the current version no longer knows of its existence. [Again, I'm not familiar with wmbattery myself and have never run it] Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-rc: /proc/acpi/battery gone?
Hi On Saturday 15 March 2014, Lan Tianyu wrote: On 03/14/2014 10:17 PM, Stefan Lippers-Hollmann wrote: Hi On Saturday 15 March 2014, Rafael J. Wysocki wrote: On Friday, March 14, 2014 06:14:12 PM Ilia Mirkin wrote: On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek pa...@ucw.cz wrote: On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote: On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek pa...@ucw.cz wrote: [...] Hi Stefan: I just glance wmbattery code. I find the code in the acpi.c is already using the new sysfs battery interfaces, right? By default, wmbattery appears to default to using upower as abstraction level, instead of querying sysfs itself directly. http://git.kitenet.net/?p=wmbattery.git;a=blob;f=autoconf/makeinfo.in;hb=HEAD which sets USE_UPOWER=1 by default. If USE_UPOWER=0 is set explicitly for the build, it reverts back to direct sysfs parsing - and yes, it does appear to adhere to the current sysfs API properly. The last remains, and the ability to parse procfs (which hasn't been default for quite some time already, in favour of using hal as abstraction layer) has finally been removed in http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=833eb63a5ce4f2fb712a201b1db4f2db1700fddb The switch from procfs parsing to hal (by default at least) in turn happened with http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=63c3d1a0b11e8ade1a5612bb5baa3d92e153bbbe in 2008 (before Debian squeeze/ oldstable). I have not investigated if hal then read from procfs or sysfs, but wmbattery at least didn't read from procfs itself, unless explicitly told to do so (USE_HAL=0) during the build since mid 2008. The current version of wmbattery however will never try to access /proc/acpi, the current version no longer knows of its existence. [Again, I'm not familiar with wmbattery myself and have never run it] Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-rc: /proc/acpi/battery gone?
Hi On Saturday 15 March 2014, Rafael J. Wysocki wrote: > On Friday, March 14, 2014 06:14:12 PM Ilia Mirkin wrote: > > On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek wrote: > > > On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote: > > >> On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek wrote: [...] > > wmbattery > > > > They have attempted to use the sysfs api, but apparently that > > integration was done with an older version of that API. There's also > > some attempt to get it to work with upower, but I couldn't figure out > > how to make that work either on my (up-to-date gentoo) box. (TBH I > > didn't spend more than an hour or two on it, so it may not be > > impossible.) > > Tianyu, can you please have a look at this? Disclaimer, I've never used wmbattery so far. The current upstream version (2.42, released in early december 2013) of wmbattery[1] no longer reads from /proc/acpi/ at all. Apparently it changed to using upower by default, with non-default fall-backs for reading from sysfs. The only change required for building upower with wmbattery 2.42 appears to be a new build-dependency on libupower-glib-dev (at least on Debian, built from the upower source package). Given that this version is present in Debian testing and unstable, I'd assume that it's supposed to work using upower, although I haven't confirmed that myself. Judging from the Gentoo ebuild, you probably just have to add "sys-power/upower" to the RDEPEND variable and make sure to build wmbattery 2.42; this is untested. Regards Stefan Lippers-Hollmann [1] Homepage: http://kitenet.net/~joey/code/wmbattery/ Vcs-Git: git://git.kitenet.net/wmbattery -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-rc: /proc/acpi/battery gone?
Hi On Saturday 15 March 2014, Rafael J. Wysocki wrote: On Friday, March 14, 2014 06:14:12 PM Ilia Mirkin wrote: On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek pa...@ucw.cz wrote: On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote: On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek pa...@ucw.cz wrote: [...] wmbattery They have attempted to use the sysfs api, but apparently that integration was done with an older version of that API. There's also some attempt to get it to work with upower, but I couldn't figure out how to make that work either on my (up-to-date gentoo) box. (TBH I didn't spend more than an hour or two on it, so it may not be impossible.) Tianyu, can you please have a look at this? Disclaimer, I've never used wmbattery so far. The current upstream version (2.42, released in early december 2013) of wmbattery[1] no longer reads from /proc/acpi/ at all. Apparently it changed to using upower by default, with non-default fall-backs for reading from sysfs. The only change required for building upower with wmbattery 2.42 appears to be a new build-dependency on libupower-glib-dev (at least on Debian, built from the upower source package). Given that this version is present in Debian testing and unstable, I'd assume that it's supposed to work using upower, although I haven't confirmed that myself. Judging from the Gentoo ebuild, you probably just have to add sys-power/upower to the RDEPEND variable and make sure to build wmbattery 2.42; this is untested. Regards Stefan Lippers-Hollmann [1] Homepage: http://kitenet.net/~joey/code/wmbattery/ Vcs-Git: git://git.kitenet.net/wmbattery -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 39/40] intel_pstate: Take core C0 time into account for core busy calculation
Hi On Tuesday 18 February 2014, Greg Kroah-Hartman wrote: > 3.13-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Dirk Brandewie > > commit fcb6a15c2e7e76d493e6f91ea889ab40e1c643a4 upstream. > > Take non-idle time into account when calculating core busy time. > This ensures that intel_pstate will notice a decrease in load. > > References: https://bugzilla.kernel.org/show_bug.cgi?id=66581 > Cc: 3.10+ # 3.10+ > Signed-off-by: Dirk Brandewie > Signed-off-by: Rafael J. Wysocki > Signed-off-by: Greg Kroah-Hartman This patch, as part of v3.13.4-rc1 causes a kernel package very early during the boot on at least sandy-bridge (H67) and ivy-bridge (H77), the call trace (slightly cut on top, as it doesn't fit on the screen; copied by hand - so it might contains typos, especially in the heaxdecimal values) is: RDX: RSI: 6000 RDI: 2200 RBP: 0009efce4c2b R08: 000a3e90e95c R09: 00017700 R10: 0026 R11: 002a R12: R13: 880408ac4c2b R14: 88041f20c388 R15: FS: () GS:88041f20() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: fff88041f5ff000 CR3: 0d51 CR4: 000407f0 Stack: fffd 880408ac4a00 880408ac4800 81294b82 880408ac4800 812925b3 0011 81578e70 880408ca9de8 Call Trace: [] ? intel_pstate_cpu_init+0x107/0x1c2 [] ? __cpufreq_add_dev.isra.23+0x30c/0x676 [] ? subsys_interface_register+0xab/0xdf [] ? arch_local_irq_save+0x11/0x17 [] ? cpufreq_register_driver+0x9e/0x143 [] ? core_get_min_pstate+0x19/0x19 [] ? intel_pstate_init+0x269/0x397 [] ? intel_pstate_setup+0x29/0x29 [] ? do_one_initcall+0x88/0x123 [] ? parse_args+0x182/0x236 [] ? kernel_init_freeable+0x183/0x208 [] ? do_early_param+0x81/0x81 [] ? rest_init+0x7c/0x7c [] ? kernel_init+0x5/0xfa [] ? ret_from_fork+0x7c/0x7c [] ? rest_init+0x7c/0x7c Code: 00 48 6b 41 08 64 48 8b 79 10 49 c1 e1 08 48 f7 f7 31 d2 48 89 c6 48 6b c7 64 49 63 f9 4c 69 ce e8 03 00 00 48 c1 e6 08 48 63 f6 <48> f7 71 18 49 c1 e1 09 4d 63 c9 49 0f af f9 48 8d 50 01 48 c1 RIP [] intel_pstate_sample+0xb6/0x104 RSP ---[ end trace 682f24c8e98de9df ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b Reverting just this patch from 3.13.4-rc1 fixes the regression. Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 39/40] intel_pstate: Take core C0 time into account for core busy calculation
Hi On Tuesday 18 February 2014, Greg Kroah-Hartman wrote: 3.13-stable review patch. If anyone has any objections, please let me know. -- From: Dirk Brandewie dirk.j.brande...@intel.com commit fcb6a15c2e7e76d493e6f91ea889ab40e1c643a4 upstream. Take non-idle time into account when calculating core busy time. This ensures that intel_pstate will notice a decrease in load. References: https://bugzilla.kernel.org/show_bug.cgi?id=66581 Cc: 3.10+ sta...@vger.kernel.org # 3.10+ Signed-off-by: Dirk Brandewie dirk.j.brande...@intel.com Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org This patch, as part of v3.13.4-rc1 causes a kernel package very early during the boot on at least sandy-bridge (H67) and ivy-bridge (H77), the call trace (slightly cut on top, as it doesn't fit on the screen; copied by hand - so it might contains typos, especially in the heaxdecimal values) is: RDX: RSI: 6000 RDI: 2200 RBP: 0009efce4c2b R08: 000a3e90e95c R09: 00017700 R10: 0026 R11: 002a R12: R13: 880408ac4c2b R14: 88041f20c388 R15: FS: () GS:88041f20() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: fff88041f5ff000 CR3: 0d51 CR4: 000407f0 Stack: fffd 880408ac4a00 880408ac4800 81294b82 880408ac4800 812925b3 0011 81578e70 880408ca9de8 Call Trace: [81294b82] ? intel_pstate_cpu_init+0x107/0x1c2 [812925b3] ? __cpufreq_add_dev.isra.23+0x30c/0x676 [81269174] ? subsys_interface_register+0xab/0xdf [8106d2df] ? arch_local_irq_save+0x11/0x17 [81291279] ? cpufreq_register_driver+0x9e/0x143 [8129438d] ? core_get_min_pstate+0x19/0x19 [815df06e] ? intel_pstate_init+0x269/0x397 [815dee05] ? intel_pstate_setup+0x29/0x29 [810020da] ? do_one_initcall+0x88/0x123 [81057794] ? parse_args+0x182/0x236 [815adee1] ? kernel_init_freeable+0x183/0x208 [815ad721] ? do_early_param+0x81/0x81 [8136d288] ? rest_init+0x7c/0x7c [8136d28d] ? kernel_init+0x5/0xfa [8137e1cc] ? ret_from_fork+0x7c/0x7c [8136d288] ? rest_init+0x7c/0x7c Code: 00 48 6b 41 08 64 48 8b 79 10 49 c1 e1 08 48 f7 f7 31 d2 48 89 c6 48 6b c7 64 49 63 f9 4c 69 ce e8 03 00 00 48 c1 e6 08 48 63 f6 48 f7 71 18 49 c1 e1 09 4d 63 c9 49 0f af f9 48 8d 50 01 48 c1 RIP [812947c4] intel_pstate_sample+0xb6/0x104 RSP 880408ca9d28 ---[ end trace 682f24c8e98de9df ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b Reverting just this patch from 3.13.4-rc1 fixes the regression. Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rtl8821ae.
Hi [ CC'ing the relevant parties ] On Sunday 02 February 2014, Dave Jones wrote: > On Sun, Feb 02, 2014 at 03:41:27AM -0800, scan-ad...@coverity.com wrote: > > > > Please find the latest report on new defect(s) introduced to Linux found > with Coverity Scan. > > > > Defect(s) Reported-by: Coverity Scan > > Showing 20 of 83 defect(s) > > Ugh, this is even worse than the usual realtek drivers. (With the exception > of rtl8188eu) > All 83 of those new defects came from this new driver, and while there's > a bunch of "who cares" type things in there, there's a load of stuff that > needs fixing a lot more urgently than CodingStyle issues or anything else in > the TODO > for that driver. > > A bigger problem though, is what is the plan for these realtek drivers ? > They've been in staging forever. rtl8187se has been there for _five_ years > with > no indication it's ever getting promoted to first class status. Actually rtl8187se (aka rtl8185b) seems to have gotten some attention recently: http://lkml.kernel.org/r/can8yu5pgkx9s9dewpfto_ztdr-+wdd5cx2jrv1zd1m1q0bp...@mail.gmail.com > The git logs are littered mostly with CodingStyle cleanups, sparse cleanups > and such, > meanwhile for five years they've had out of bounds reads, overflows, and such > for this whole time. Even worse, when one of the drivers gets fixes for > actual > problems like this, they never make it back to Realtek, who clone the same > old shitty driver they shipped last time, and reintroduce new variants of the > same damn bugs, and then we import the new turd into staging and start all > over again. > > I get the whole "a shit driver is better than no driver", but there's no > discernable > effort to ever improve this pile, just to keep adding to it. > > Dave I think there are mostly two major problems with these drivers, besides RealTek still working on a non-mac80211 codebase for USB based devices. The sheer number of slightly different RealTek drivers for similar chipsets, for which RealTek as forked off a dedicated driver each, rather than extending the existing ones. With the other, probably even larger, problem being that it isn't possible to port wireless drivers from non-mac80111 to mac80211 in a gradual fashion, it's always a parallel re-implementation. Just look at the recent history of staging wireless drivers: the successful ones: - csr --> /dev/null - otus --> ar9170 --> carl9170 - ( rt2870 && rt3070 ) --> rt2800usb - rt2870 --> rt2800pci - [ at76c503a --> ] at76_usb --> at76c50x-usb [*] not in staging the pending ones - rtl8187se [ --> rtl8180 ] [*] hopefully soon - rtl8188eu --> ? - [ rtl8192du --> ? ] [*] not in staging, [1] - rtl8192e --> ? - rtl8192u --> ? - rtl8192su --> rtl8712 --> ? [ r92su[2] would add cfg80211 support, but it being a fullmac like re-implementation doesn't get it anywhere ] - rtl8821ae [ --> mac80211 port planned for 3.15[3]? ] these devices are, besides rtl8187se (802.11g) and rtl8821ae (802.11ac), all 802.11n compatible, but were quickly EOLed by the vendor, probably making it hard to get enough traction for a proper mac80211 port. Coincidentally these chipsets are also very popular, rtl8187se being the chipset of the early netbook craze, rtl8188eu pretty ubiquitous on embedded platforms, the others making the bulk of aftermarket USB devices. ancient hardware, probably not going anywhere: - vt6655 --> ? - vt6656 --> ? - wlags49_h2 --> ? - wlags49_h25 --> ? - wlan-ng --> ? This likely leaves staging wireless drivers to small corrections and bugfixes. In the hope that the devices will get enough traction that someone takes up the effort of doing a parallel re-implementation of a proper mac80211 based driver, using the staging source only as reference. Regards Stefan Lippers-Hollmann [1] https://github.com/lwfinger/rtl8192du [2] https://github.com/chunkeey/rtl8192su/tree/master/r92su [3] http://lkml.kernel.org/r/52e066a1.9010...@lwfinger.net http://lkml.kernel.org/r/52e7d9f6.5070...@lwfinger.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rtl8821ae.
Hi [ CC'ing the relevant parties ] On Sunday 02 February 2014, Dave Jones wrote: On Sun, Feb 02, 2014 at 03:41:27AM -0800, scan-ad...@coverity.com wrote: Please find the latest report on new defect(s) introduced to Linux found with Coverity Scan. Defect(s) Reported-by: Coverity Scan Showing 20 of 83 defect(s) Ugh, this is even worse than the usual realtek drivers. (With the exception of rtl8188eu) All 83 of those new defects came from this new driver, and while there's a bunch of who cares type things in there, there's a load of stuff that needs fixing a lot more urgently than CodingStyle issues or anything else in the TODO for that driver. A bigger problem though, is what is the plan for these realtek drivers ? They've been in staging forever. rtl8187se has been there for _five_ years with no indication it's ever getting promoted to first class status. Actually rtl8187se (aka rtl8185b) seems to have gotten some attention recently: http://lkml.kernel.org/r/can8yu5pgkx9s9dewpfto_ztdr-+wdd5cx2jrv1zd1m1q0bp...@mail.gmail.com The git logs are littered mostly with CodingStyle cleanups, sparse cleanups and such, meanwhile for five years they've had out of bounds reads, overflows, and such for this whole time. Even worse, when one of the drivers gets fixes for actual problems like this, they never make it back to Realtek, who clone the same old shitty driver they shipped last time, and reintroduce new variants of the same damn bugs, and then we import the new turd into staging and start all over again. I get the whole a shit driver is better than no driver, but there's no discernable effort to ever improve this pile, just to keep adding to it. Dave I think there are mostly two major problems with these drivers, besides RealTek still working on a non-mac80211 codebase for USB based devices. The sheer number of slightly different RealTek drivers for similar chipsets, for which RealTek as forked off a dedicated driver each, rather than extending the existing ones. With the other, probably even larger, problem being that it isn't possible to port wireless drivers from non-mac80111 to mac80211 in a gradual fashion, it's always a parallel re-implementation. Just look at the recent history of staging wireless drivers: the successful ones: - csr -- /dev/null - otus -- ar9170 -- carl9170 - ( rt2870 rt3070 ) -- rt2800usb - rt2870 -- rt2800pci - [ at76c503a -- ] at76_usb -- at76c50x-usb [*] not in staging the pending ones - rtl8187se [ -- rtl8180 ] [*] hopefully soon - rtl8188eu -- ? - [ rtl8192du -- ? ] [*] not in staging, [1] - rtl8192e -- ? - rtl8192u -- ? - rtl8192su -- rtl8712 -- ? [ r92su[2] would add cfg80211 support, but it being a fullmac like re-implementation doesn't get it anywhere ] - rtl8821ae [ -- mac80211 port planned for 3.15[3]? ] these devices are, besides rtl8187se (802.11g) and rtl8821ae (802.11ac), all 802.11n compatible, but were quickly EOLed by the vendor, probably making it hard to get enough traction for a proper mac80211 port. Coincidentally these chipsets are also very popular, rtl8187se being the chipset of the early netbook craze, rtl8188eu pretty ubiquitous on embedded platforms, the others making the bulk of aftermarket USB devices. ancient hardware, probably not going anywhere: - vt6655 -- ? - vt6656 -- ? - wlags49_h2 -- ? - wlags49_h25 -- ? - wlan-ng -- ? This likely leaves staging wireless drivers to small corrections and bugfixes. In the hope that the devices will get enough traction that someone takes up the effort of doing a parallel re-implementation of a proper mac80211 based driver, using the staging source only as reference. Regards Stefan Lippers-Hollmann [1] https://github.com/lwfinger/rtl8192du [2] https://github.com/chunkeey/rtl8192su/tree/master/r92su [3] http://lkml.kernel.org/r/52e066a1.9010...@lwfinger.net http://lkml.kernel.org/r/52e7d9f6.5070...@lwfinger.net -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/bochs: new driver
Hi
On Thursday 12 December 2013, Gerd Hoffmann wrote:
> DRM driver for (virtual) vga cards using the bochs dispi
> interface, such as the qemu standard vga (qemu -vga std).
>
> Don't bother supporting anything but 32bpp for now, even
> though the virtual hardware is able to do that.
>
> Known issue: mmap(/dev/fb0) doesn't work.
>
> Signed-off-by: Gerd Hoffmann
> ---
[…]
> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
> b/drivers/gpu/drm/bochs/bochs_mm.c
> new file mode 100644
> index 000..afe104f
> --- /dev/null
> +++ b/drivers/gpu/drm/bochs/bochs_mm.c
[…]
> +int bochs_gem_create(struct drm_device *dev, u32 size, bool iskernel,
> + struct drm_gem_object **obj)
> +{
> + struct bochs_bo *bochsbo;
> + int ret;
> +
> + *obj = NULL;
> +
> + size = roundup(size, PAGE_SIZE);
[…]
Using roundup() this way will fail to build in 32 bit architectures/
i386:
ERROR: "__udivdi3" [drivers/gpu/drm/bochs/bochs-drm.ko] undefined!
ERROR: "__umoddi3" [drivers/gpu/drm/bochs/bochs-drm.ko] undefined!
[drm/bochs works pretty nicely for me on amd64]
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/bochs: new driver
Hi
On Thursday 12 December 2013, Gerd Hoffmann wrote:
DRM driver for (virtual) vga cards using the bochs dispi
interface, such as the qemu standard vga (qemu -vga std).
Don't bother supporting anything but 32bpp for now, even
though the virtual hardware is able to do that.
Known issue: mmap(/dev/fb0) doesn't work.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
[…]
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
b/drivers/gpu/drm/bochs/bochs_mm.c
new file mode 100644
index 000..afe104f
--- /dev/null
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
[…]
+int bochs_gem_create(struct drm_device *dev, u32 size, bool iskernel,
+ struct drm_gem_object **obj)
+{
+ struct bochs_bo *bochsbo;
+ int ret;
+
+ *obj = NULL;
+
+ size = roundup(size, PAGE_SIZE);
[…]
Using roundup() this way will fail to build in 32 bit architectures/
i386:
ERROR: __udivdi3 [drivers/gpu/drm/bochs/bochs-drm.ko] undefined!
ERROR: __umoddi3 [drivers/gpu/drm/bochs/bochs-drm.ko] undefined!
[drm/bochs works pretty nicely for me on amd64]
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
Hi On Wednesday 27 November 2013, Ilia Mirkin wrote: > On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann wrote: > > Hi > > > > On Tuesday 26 November 2013, Ilia Mirkin wrote: > >> On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann > >> wrote: > >> > v3.11 is fine, with and without monitor attached. > >> > v3.12 is fine as long as X.org isn't started (but may fail to reboot > >> > cleanly). If a monitor is connected I don't observe any problems, > >> > it freezes without a monitor connected. > >> > v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore > >> > (I didn't confirm that it's fine with a monitor attached), but I > >> > end up with the following Oops (this is before X.org is started). > > One more idea -- try it with nouveau.runpm=0 -- I've had some odd > results with it on my older cards (but I don't remember hangs, but I > also didn't spend a lot of time on it, just plopped the option in and > moved on). This is a feature that got in in 3.12, and is really the > only major nouveau-affecting change in that kernel for your card > revision. You're spot on, that does the trick. # cat /sys/module/nouveau/parameters/agpmode -1 # cat /sys/module/nouveau/parameters/runpm 0 v3.13-rc1-95-gb975dc3 + http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba + nouveau.runpm=0 is now stable, with and without a monitor attached; as is 3.12.1 || v3.12.1-62-g4615252 (stable-queue.git) + nouveau.runpm=0 I don't need to override the agpmode parameter. Thanks a lot! Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
Hi On Tuesday 26 November 2013, Ilia Mirkin wrote: > On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann wrote: > > v3.11 is fine, with and without monitor attached. > > v3.12 is fine as long as X.org isn't started (but may fail to reboot > > cleanly). If a monitor is connected I don't observe any problems, > > it freezes without a monitor connected. > > v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore > > (I didn't confirm that it's fine with a monitor attached), but I > > end up with the following Oops (this is before X.org is started). […] > > BUG: unable to handle kernel NULL pointer dereference at (null) > > IP: [] _nouveau_clock_init+0x2a/0xaf [nouveau] […] > The oops in 3.13-rc1 should be fixed by applying the equivalent of > http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba As you expected, the Oops is gone after applying the afforementioned patch, 3.13~ now behaves as 3.12 (it freezes, if X.org is started without a monitor attached). > . Also note that libdrm had a bug when compiled with gcc-4.8 for > pre-nv50 cards, not sure if the fixes have made it to Debian/unstable, > but you need libdrm-2.4.48+ (or compile it with gcc-4.7/clang). The libdrm2 version is 2.4.49-2, which -although it has been compiled with gcc 4.8.2-5[1]- should be unaffected by this issue. According to the ChangeLog the version is at 7ddc98f92f92560e2b52287ae8cf816ca4a057de and no significant patches[2] have been applied. > Lastly, another thing to try if you're getting random hangs is booting > with nouveau.agpmode=0 (and if that helps, seeing if =1 or =2 still > work ok). If that helps, it can be added to the quirks list. Unfortunately this doesn't appear to have an effect, with 3.13~ and the previous patch applied: # cat /sys/module/nouveau/parameters/agpmode 0 # init 5 [ 73.708490] nouveau W[ PTIMER][:01:00.0] unknown input clock freq system frozen. Regards Stefan Lippers-Hollmann [1] https://buildd.debian.org/status/fetch.php?pkg=libdrm=i386=2.4.49-2=1385480211 [2] http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/libdrm.git;a=blob;f=debian/patches/01_default_perms.diff;h=cdba93e19edf40b2b0b56d951a6416c68a0af6f0;hb=HEAD http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/libdrm.git;a=blob;f=debian/patches/02_kbsd_modeset.diff;h=260260925fc692c71d955d6490dabf87905abb51;hb=HEAD -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
Hi On Tuesday 26 November 2013, Ilia Mirkin wrote: On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann s@gmx.de wrote: v3.11 is fine, with and without monitor attached. v3.12 is fine as long as X.org isn't started (but may fail to reboot cleanly). If a monitor is connected I don't observe any problems, it freezes without a monitor connected. v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore (I didn't confirm that it's fine with a monitor attached), but I end up with the following Oops (this is before X.org is started). […] BUG: unable to handle kernel NULL pointer dereference at (null) IP: [e0ecaa4e] _nouveau_clock_init+0x2a/0xaf [nouveau] […] The oops in 3.13-rc1 should be fixed by applying the equivalent of http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba As you expected, the Oops is gone after applying the afforementioned patch, 3.13~ now behaves as 3.12 (it freezes, if X.org is started without a monitor attached). . Also note that libdrm had a bug when compiled with gcc-4.8 for pre-nv50 cards, not sure if the fixes have made it to Debian/unstable, but you need libdrm-2.4.48+ (or compile it with gcc-4.7/clang). The libdrm2 version is 2.4.49-2, which -although it has been compiled with gcc 4.8.2-5[1]- should be unaffected by this issue. According to the ChangeLog the version is at 7ddc98f92f92560e2b52287ae8cf816ca4a057de and no significant patches[2] have been applied. Lastly, another thing to try if you're getting random hangs is booting with nouveau.agpmode=0 (and if that helps, seeing if =1 or =2 still work ok). If that helps, it can be added to the quirks list. Unfortunately this doesn't appear to have an effect, with 3.13~ and the previous patch applied: # cat /sys/module/nouveau/parameters/agpmode 0 # init 5 [ 73.708490] nouveau W[ PTIMER][:01:00.0] unknown input clock freq system frozen. Regards Stefan Lippers-Hollmann [1] https://buildd.debian.org/status/fetch.php?pkg=libdrmarch=i386ver=2.4.49-2stamp=1385480211 [2] http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/libdrm.git;a=blob;f=debian/patches/01_default_perms.diff;h=cdba93e19edf40b2b0b56d951a6416c68a0af6f0;hb=HEAD http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/libdrm.git;a=blob;f=debian/patches/02_kbsd_modeset.diff;h=260260925fc692c71d955d6490dabf87905abb51;hb=HEAD -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
Hi On Wednesday 27 November 2013, Ilia Mirkin wrote: On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann s@gmx.de wrote: Hi On Tuesday 26 November 2013, Ilia Mirkin wrote: On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann s@gmx.de wrote: v3.11 is fine, with and without monitor attached. v3.12 is fine as long as X.org isn't started (but may fail to reboot cleanly). If a monitor is connected I don't observe any problems, it freezes without a monitor connected. v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore (I didn't confirm that it's fine with a monitor attached), but I end up with the following Oops (this is before X.org is started). One more idea -- try it with nouveau.runpm=0 -- I've had some odd results with it on my older cards (but I don't remember hangs, but I also didn't spend a lot of time on it, just plopped the option in and moved on). This is a feature that got in in 3.12, and is really the only major nouveau-affecting change in that kernel for your card revision. You're spot on, that does the trick. # cat /sys/module/nouveau/parameters/agpmode -1 # cat /sys/module/nouveau/parameters/runpm 0 v3.13-rc1-95-gb975dc3 + http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba + nouveau.runpm=0 is now stable, with and without a monitor attached; as is 3.12.1 || v3.12.1-62-g4615252 (stable-queue.git) + nouveau.runpm=0 I don't need to override the agpmode parameter. Thanks a lot! Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/16] 3.11.1-stable review
Hi On Thursday 12 September 2013, Greg Kroah-Hartman wrote: > On Thu, Sep 12, 2013 at 11:22:40AM -0700, Greg Kroah-Hartman wrote: > > On Thu, Sep 12, 2013 at 11:18:40AM -0700, Linus Torvalds wrote: > > > On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds > > > wrote: > > > > Your script may be a bit buggered... > > > > > > Or maybe I should take that as a sign that 3.11 is doing really well? > > > > > > I'll be optimistic. > > > > Hm, something went wrong here, let me track it down... > > Ok, that was my fault, was working off of a 'master' branch in a repo > that expected it to be on the linux-3.11.y branch. Here's the real > pseudo-shortlog below. […] This unfortunately affects the linked patch files as well, which are as empty as the shortlog (compressed zero byte files); the sha256sum are correct: $ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.gz | gzip -d $ $ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.bz2 | bzip2 -d $ $ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.xz | xz -d xz: (stdin): File format not recognized $ Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/16] 3.11.1-stable review
Hi On Thursday 12 September 2013, Greg Kroah-Hartman wrote: On Thu, Sep 12, 2013 at 11:22:40AM -0700, Greg Kroah-Hartman wrote: On Thu, Sep 12, 2013 at 11:18:40AM -0700, Linus Torvalds wrote: On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds torva...@linux-foundation.org wrote: Your script may be a bit buggered... Or maybe I should take that as a sign that 3.11 is doing really well? I'll be optimistic. Hm, something went wrong here, let me track it down... Ok, that was my fault, was working off of a 'master' branch in a repo that expected it to be on the linux-3.11.y branch. Here's the real pseudo-shortlog below. […] This unfortunately affects the linked patch files as well, which are as empty as the shortlog (compressed zero byte files); the sha256sum are correct: $ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.gz | gzip -d $ $ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.bz2 | bzip2 -d $ $ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.xz | xz -d xz: (stdin): File format not recognized $ Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/34] 3.4.59-stable review
Hi On Monday 19 August 2013, Greg Kroah-Hartman wrote: > On Mon, Aug 19, 2013 at 12:02:17PM -0600, Shuah Khan wrote: > > On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote: […] > > and the following traces in dmesg: > > [ 124.802169] init: udevtrigger post-stop process (353) terminated > > with status 1 > > [ 243.439212] INFO: task crda:723 blocked for more than 120 seconds. > > What is "crda"? > > Any luck with bisection? It should go fast as the majority of patches > here are non-x86. crda is a userspace helper, invoked by udev events, which sets -and intersects as needed- the regulatory domain settings for (modern, cfg80211 based) wlan hardware based on the device's EEPROM regdom hint, local configuration (country code) and eventual IEEE 802.11d hints (country IEs) beaconed by access points nearby. It hooks into udev with these udev rules (Debian/ 1.1.2-1): $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/60-crda.rules SUBSYSTEM=="ieee80211", ACTION=="add", RUN+="/lib/crda/setregdomain" $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/85-regulatory.rules KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/crda" Full source is at [2], it should be installed on pretty much every distro/ system released with wlan support for the last >>3 years. There are two iwl4965 patches in this series, which might be among the first ones to check - /if/ you actually have that hardware, the second one (iwl4965: reset firmware after rfkill off) might also indirectly have an effect on blutetooth (via rfkill). Regards Stefan Lippers-Hollmann [1] http://wireless.kernel.org/en/developers/Regulatory/CRDA [2] https://github.com/mcgrof/crda -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/34] 3.4.59-stable review
Hi On Monday 19 August 2013, Greg Kroah-Hartman wrote: On Mon, Aug 19, 2013 at 12:02:17PM -0600, Shuah Khan wrote: On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote: […] and the following traces in dmesg: [ 124.802169] init: udevtrigger post-stop process (353) terminated with status 1 [ 243.439212] INFO: task crda:723 blocked for more than 120 seconds. What is crda? Any luck with bisection? It should go fast as the majority of patches here are non-x86. crda is a userspace helper, invoked by udev events, which sets -and intersects as needed- the regulatory domain settings for (modern, cfg80211 based) wlan hardware based on the device's EEPROM regdom hint, local configuration (country code) and eventual IEEE 802.11d hints (country IEs) beaconed by access points nearby. It hooks into udev with these udev rules (Debian/ 1.1.2-1): $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/60-crda.rules SUBSYSTEM==ieee80211, ACTION==add, RUN+=/lib/crda/setregdomain $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/85-regulatory.rules KERNEL==regulatory*, ACTION==change, SUBSYSTEM==platform, RUN+=/sbin/crda Full source is at [2], it should be installed on pretty much every distro/ system released with wlan support for the last 3 years. There are two iwl4965 patches in this series, which might be among the first ones to check - /if/ you actually have that hardware, the second one (iwl4965: reset firmware after rfkill off) might also indirectly have an effect on blutetooth (via rfkill). Regards Stefan Lippers-Hollmann [1] http://wireless.kernel.org/en/developers/Regulatory/CRDA [2] https://github.com/mcgrof/crda -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] wistron_btns: mark the Medion MD96500 keymap as tested
DMI: MEDIONPC WIM 2040/WIM 2040, BIOS R01-A0O11/04/2005
wistron_btns: BIOS signature found at c00f6b00, entry point 000FDD50
input: Wistron laptop buttons as /devices/platform/wistron-bios/input/input5
Signed-off-by: Stefan Lippers-Hollmann
---
drivers/input/misc/wistron_btns.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/input/misc/wistron_btns.c
+++ b/drivers/input/misc/wistron_btns.c
@@ -562,7 +562,7 @@ static struct key_entry keymap_wistron_m
{ KE_KEY, 0x36, {KEY_WWW} },
{ KE_WIFI, 0x30 },
{ KE_BLUETOOTH, 0x44 },
- { KE_END, FE_UNTESTED }
+ { KE_END, 0 }
};
static struct key_entry keymap_wistron_generic[] __initdata = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] wistron_btns: add MODULE_DEVICE_TABLE
This allows the wistron_btns module to be autoloaded on boot, its functionality
is required to support the hardware rfkill switches on most of the supported
notebooks, in order to unblock the hard blocked rfkill state for wireless and
bluetooth devices.
Tested on a Medion MD96500:
alias: dmi*:svn*MEDIONPC*:pn*WIM2040*:
Signed-off-by: Stefan Lippers-Hollmann
---
This patch may be considered RFC, while it is certainly the right thing to do,
some of the DMI matches might be a bit wide, e.g.:
dmi*:svn*FUJITSUSIEMENS*:pn*AMILOD*:
dmi*:svn*FUJITSUSIEMENS*:pn*AmiloD*:
dmi*:svn*FUJITSUSIEMENS*:pn*AMILOM*:
all others are very targetted - and I haven't noticed any issues by forcing
wistron_btns on system not requiring it so far.
drivers/input/misc/wistron_btns.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/input/misc/wistron_btns.c
+++ b/drivers/input/misc/wistron_btns.c
@@ -971,6 +971,7 @@ static const struct dmi_system_id __init
},
{ NULL, }
};
+MODULE_DEVICE_TABLE(dmi, dmi_ids);
/* Copy the good keymap, as the original ones are free'd */
static int __init copy_keymap(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] wistron_btns: drop bogus MODULE_VERSION macro
MODULE_VERSION is pointless for an in-kernel module and git log confirms that
it has never been actually maintained as well (bumped a single time, despite
quite major feature additions later on, which haven't been reflected in
MODULE_VERSION).
Signed-off-by: Stefan Lippers-Hollmann
---
drivers/input/misc/wistron_btns.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/input/misc/wistron_btns.c
+++ b/drivers/input/misc/wistron_btns.c
@@ -46,7 +46,6 @@
MODULE_AUTHOR("Miloslav Trmac ");
MODULE_DESCRIPTION("Wistron laptop button driver");
MODULE_LICENSE("GPL v2");
-MODULE_VERSION("0.3");
static bool force; /* = 0; */
module_param(force, bool, 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] wistron_btns: drop bogus MODULE_VERSION macro
MODULE_VERSION is pointless for an in-kernel module and git log confirms that it has never been actually maintained as well (bumped a single time, despite quite major feature additions later on, which haven't been reflected in MODULE_VERSION). Signed-off-by: Stefan Lippers-Hollmann s@gmx.de --- drivers/input/misc/wistron_btns.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/input/misc/wistron_btns.c +++ b/drivers/input/misc/wistron_btns.c @@ -46,7 +46,6 @@ MODULE_AUTHOR(Miloslav Trmac m...@volny.cz); MODULE_DESCRIPTION(Wistron laptop button driver); MODULE_LICENSE(GPL v2); -MODULE_VERSION(0.3); static bool force; /* = 0; */ module_param(force, bool, 0); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] wistron_btns: add MODULE_DEVICE_TABLE
This allows the wistron_btns module to be autoloaded on boot, its functionality
is required to support the hardware rfkill switches on most of the supported
notebooks, in order to unblock the hard blocked rfkill state for wireless and
bluetooth devices.
Tested on a Medion MD96500:
alias: dmi*:svn*MEDIONPC*:pn*WIM2040*:
Signed-off-by: Stefan Lippers-Hollmann s@gmx.de
---
This patch may be considered RFC, while it is certainly the right thing to do,
some of the DMI matches might be a bit wide, e.g.:
dmi*:svn*FUJITSUSIEMENS*:pn*AMILOD*:
dmi*:svn*FUJITSUSIEMENS*:pn*AmiloD*:
dmi*:svn*FUJITSUSIEMENS*:pn*AMILOM*:
all others are very targetted - and I haven't noticed any issues by forcing
wistron_btns on system not requiring it so far.
drivers/input/misc/wistron_btns.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/input/misc/wistron_btns.c
+++ b/drivers/input/misc/wistron_btns.c
@@ -971,6 +971,7 @@ static const struct dmi_system_id __init
},
{ NULL, }
};
+MODULE_DEVICE_TABLE(dmi, dmi_ids);
/* Copy the good keymap, as the original ones are free'd */
static int __init copy_keymap(void)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] wistron_btns: mark the Medion MD96500 keymap as tested
DMI: MEDIONPC WIM 2040/WIM 2040, BIOS R01-A0O11/04/2005
wistron_btns: BIOS signature found at c00f6b00, entry point 000FDD50
input: Wistron laptop buttons as /devices/platform/wistron-bios/input/input5
Signed-off-by: Stefan Lippers-Hollmann s@gmx.de
---
drivers/input/misc/wistron_btns.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/input/misc/wistron_btns.c
+++ b/drivers/input/misc/wistron_btns.c
@@ -562,7 +562,7 @@ static struct key_entry keymap_wistron_m
{ KE_KEY, 0x36, {KEY_WWW} },
{ KE_WIFI, 0x30 },
{ KE_BLUETOOTH, 0x44 },
- { KE_END, FE_UNTESTED }
+ { KE_END, 0 }
};
static struct key_entry keymap_wistron_generic[] __initdata = {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 008/102] ARM: make vectors page inaccessible from userspace
On Friday 09 August 2013, Greg Kroah-Hartman wrote: > 3.10-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Russell King > > commit a5463cd3435475386cbbe7b06e01292ac169d36f upstream. > > If kuser helpers are not provided by the kernel, disable user access to > the vectors page. With the kuser helpers gone, there is no reason for > this page to be visible to userspace. > > Signed-off-by: Russell King > Signed-off-by: Greg Kroah-Hartman If I read Russell King's response in http://www.spinics.net/lists/stable/msg16792.html Message-ID: <20130804105241.gg23...@n2100.arm.linux.org.uk> correctly, this patch might not be wanted for -stable; this only affects queue-3.10 at the moment. Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 000/102] 3.10.6-stable review
Hi
On Friday 09 August 2013, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.6 release.
[…]
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
[…]
There appears to be a problem with the mirroring (not pushed?):
$ LANG= wget kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
--2013-08-09 06:05:02--
http://kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
Resolving kernel.org (kernel.org)... 149.20.4.69, 198.145.20.140
Connecting to kernel.org (kernel.org)|149.20.4.69|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location:
https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
[following]
--2013-08-09 06:05:02--
https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
Resolving www.kernel.org (www.kernel.org)... 198.145.20.140, 149.20.4.69
Connecting to www.kernel.org (www.kernel.org)|198.145.20.140|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2013-08-09 06:05:06 ERROR 404: Not Found.
The other -stable patches of this round
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.57-rc1.gz
and
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.90-rc1.gz
appear to be missing as well.
Using the current queue-3.10/series from
git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
builds and works fine on x86_64 and i386.
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 000/102] 3.10.6-stable review
Hi On Friday 09 August 2013, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.6 release. […] The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz […] There appears to be a problem with the mirroring (not pushed?): $ LANG= wget kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz --2013-08-09 06:05:02-- http://kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz Resolving kernel.org (kernel.org)... 149.20.4.69, 198.145.20.140 Connecting to kernel.org (kernel.org)|149.20.4.69|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz [following] --2013-08-09 06:05:02-- https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz Resolving www.kernel.org (www.kernel.org)... 198.145.20.140, 149.20.4.69 Connecting to www.kernel.org (www.kernel.org)|198.145.20.140|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2013-08-09 06:05:06 ERROR 404: Not Found. The other -stable patches of this round kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.57-rc1.gz and kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.90-rc1.gz appear to be missing as well. Using the current queue-3.10/series from git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git builds and works fine on x86_64 and i386. Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 008/102] ARM: make vectors page inaccessible from userspace
On Friday 09 August 2013, Greg Kroah-Hartman wrote: 3.10-stable review patch. If anyone has any objections, please let me know. -- From: Russell King rmk+ker...@arm.linux.org.uk commit a5463cd3435475386cbbe7b06e01292ac169d36f upstream. If kuser helpers are not provided by the kernel, disable user access to the vectors page. With the kuser helpers gone, there is no reason for this page to be visible to userspace. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org If I read Russell King's response in http://www.spinics.net/lists/stable/msg16792.html Message-ID: 20130804105241.gg23...@n2100.arm.linux.org.uk correctly, this patch might not be wanted for -stable; this only affects queue-3.10 at the moment. Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
