Re: [PATCH v7 3/7] LoongArch: KVM: Add cpucfg area for kvm hypervisor
On Tue, 2024-04-02 at 11:34 +0800, maobibo wrote: > Are you sure that it's impossible to read some data used by the kernel > internally? Yes. > There is another issue, since kernel restore T0-T7 registers and user > space save T0-T7. Why T0-T7 is scratch registers rather than preserve > registers like other architecture? What is the advantage if it is > scratch registers? I'd say "MIPS legacy." Note that MIPS also does not preserve temp registers, and MIPS does not have the "info leak" issue as well (or it should have been assigned a CVE, in all these years). I do agree maybe it's the time to move away from MIPS legacy and be more similar to RISC-V etc now... In Glibc we can condition __SYSCALL_CLOBBERS with #if __LINUX_KERNEL_VERSION > xxx to take the advantage. Huacai, Xuerui, how do you think? -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH v7 3/7] LoongArch: KVM: Add cpucfg area for kvm hypervisor
On Tue, 2024-04-02 at 09:43 +0800, maobibo wrote: > > Sorry for the late reply, but I think it may be a bit non-constructive > > to repeatedly submit the same code without due explanation in our > > previous review threads. Let me try to recollect some of the details > > though... > Because your review comments about hypercall method is wrong, I need not > adopt it. Again it's unfair to say so considering the lack of LVZ documentation. /* snip */ > > 1. T0-T7 are scratch registers during SYSCALL ABI, this is what you > suggest, does there exist information leaking to user space from T0-T7 > registers? It's not a problem. When syscall returns RESTORE_ALL_AND_RET is invoked despite T0-T7 are not saved. So a "junk" value will be read from the leading PT_SIZE bytes of the kernel stack for this thread. The leading PT_SIZE bytes of the kernel stack is dedicated for storing the struct pt_regs representing the reg file of the thread in the userspace. Thus we may only read out the userspace T0-T7 value stored when the same thread was interrupted or trapped last time, or 0 (if the thread was never interrupted or trapped before). And it's impossible to read some data used by the kernel internally, or some data of another thread. But indeed there is some improvement here. Zeroing these registers seems cleaner than reading out the junk values, and also faster (move $t0, $r0 is faster than ld.d $t0, $sp, PT_R12). Not sure if it's worthy to violate Huacai's "keep things simple" aspiration though. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH v5 3/6] LoongArch: KVM: Add cpucfg area for kvm hypervisor
On Tue, 2024-02-27 at 15:09 +0800, maobibo wrote: > It is difficult to find an area unused by HW for CSR method since the > small CSR ID range. We may use IOCSR instead. In kernel/cpu-probe.c there are already some IOCSR reads. > It is difficult to find an area unused by HW for CSR method since the > small CSR ID range. However it is easy for cpucfg. Here I doubt whether > you really know about LoongArch LVZ. It's unfair to accuse the others for not knowing about LVZ considering the lack of public documentation. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH] drm/amdgpu: fix an underflow on non-4KB-page systems
On 2021-03-30 15:24 +0200, Christian König wrote: > Am 30.03.21 um 15:23 schrieb Dan Horák: > > On Tue, 30 Mar 2021 21:09:12 +0800 > > Xi Ruoyao wrote: > > > > > On 2021-03-30 21:02 +0800, Xi Ruoyao wrote: > > > > On 2021-03-30 14:55 +0200, Christian König wrote: > > > > > I rather see this as a kernel bug. Can you test if this code fragment > > > > > fixes your issue: > > > > > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > > > > > index 64beb3399604..e1260b517e1b 100644 > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > > > > > @@ -780,7 +780,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void > > > > > *data, struct drm_file *filp) > > > > > } > > > > > dev_info->virtual_address_alignment = > > > > > max((int)PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE); > > > > > dev_info->pte_fragment_size = (1 << > > > > > adev->vm_manager.fragment_size) * AMDGPU_GPU_PAGE_SIZE; > > > > > - dev_info->gart_page_size = AMDGPU_GPU_PAGE_SIZE; > > > > > + dev_info->gart_page_size = > > > > > dev_info->virtual_address_alignment; > > > > > dev_info->cu_active_number = adev- > > > > > >gfx.cu_info.number; > > > > > dev_info->cu_ao_mask = adev->gfx.cu_info.ao_cu_mask; > > > > > dev_info->ce_ram_size = adev->gfx.ce_ram_size; > > > > It works. I've seen it at > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fxen0n%2Flinux%2Fcommit%2F84ada72983838bd7ce54bc32f5d34ac5b5aae191data=04%7C01%7Cchristian.koenig%40amd.com%7Cf37fddf20a8847edf67808d8f37ef23c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637527074118791321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=DZnmee38NGpiWRMX5LmlxOhxAzBMhAusnAWNnCxXTJ0%3Dreserved=0 > > > > before (with a common sub-expression, though :). > > > Some comment: on an old version of Fedora ported by Loongson, Xorg just > > > hangs > > > without this commit. But on the system I built from source, I didn't see > > > any > > > issue before Linux 5.11. So I misbelieved that it was something already > > > fixed. > > > > > > Dan: you can try it on your PPC 64 with non-4K page as well. > > yup, looks good here as well, ppc64le (Power9) system with 64KB pages > > Mhm, as far as I can say this patch never made it to us. I think maybe its author considers it a "workaround" like me, as there is already a "virtual_address_alignment" which seems correct. > Can you please send it to the mailing list with me on CC? I've sent it, together with my patch for using ~PAGE_MASK in parameter validation. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH] drm/amdgpu: fix an underflow on non-4KB-page systems
On 2021-03-30 21:02 +0800, Xi Ruoyao wrote: > On 2021-03-30 14:55 +0200, Christian König wrote: > > > > I rather see this as a kernel bug. Can you test if this code fragment > > fixes your issue: > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > > index 64beb3399604..e1260b517e1b 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > > @@ -780,7 +780,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void > > *data, struct drm_file *filp) > > } > > dev_info->virtual_address_alignment = > > max((int)PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE); > > dev_info->pte_fragment_size = (1 << > > adev->vm_manager.fragment_size) * AMDGPU_GPU_PAGE_SIZE; > > - dev_info->gart_page_size = AMDGPU_GPU_PAGE_SIZE; > > + dev_info->gart_page_size = > > dev_info->virtual_address_alignment; > > dev_info->cu_active_number = adev->gfx.cu_info.number; > > dev_info->cu_ao_mask = adev->gfx.cu_info.ao_cu_mask; > > dev_info->ce_ram_size = adev->gfx.ce_ram_size; > > It works. I've seen it at > https://github.com/xen0n/linux/commit/84ada72983838bd7ce54bc32f5d34ac5b5aae191 > before (with a common sub-expression, though :). Some comment: on an old version of Fedora ported by Loongson, Xorg just hangs without this commit. But on the system I built from source, I didn't see any issue before Linux 5.11. So I misbelieved that it was something already fixed. Dan: you can try it on your PPC 64 with non-4K page as well. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH] drm/amdgpu: fix an underflow on non-4KB-page systems
On 2021-03-30 14:55 +0200, Christian König wrote: > Am 30.03.21 um 14:04 schrieb Xi Ruoyao: > > On 2021-03-30 03:40 +0800, Xi Ruoyao wrote: > > > On 2021-03-29 21:36 +0200, Christian König wrote: > > > > Am 29.03.21 um 21:27 schrieb Xi Ruoyao: > > > > > Hi Christian, > > > > > > > > > > I don't think there is any constraint implemented to ensure > > > > > `num_entries > > > > > % > > > > > AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0`. For example, in > > > > > `amdgpu_vm_bo_map()`: > > > > > > > > > > /* validate the parameters */ > > > > > if (saddr & AMDGPU_GPU_PAGE_MASK || offset & > > > > > AMDGPU_GPU_PAGE_MASK > > > > > size == 0 || size & AMDGPU_GPU_PAGE_MASK) > > > > > return -EINVAL; > > > > > > > > > > /* snip */ > > > > > > > > > > saddr /= AMDGPU_GPU_PAGE_SIZE; > > > > > eaddr /= AMDGPU_GPU_PAGE_SIZE; > > > > > > > > > > /* snip */ > > > > > > > > > > mapping->start = saddr; > > > > > mapping->last = eaddr; > > > > > > > > > > > > > > > If we really want to ensure (mapping->last - mapping->start + 1) % > > > > > AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0, then we should replace > > > > > "AMDGPU_GPU_PAGE_MASK" > > > > > in "validate the parameters" with "PAGE_MASK". > > It should be "~PAGE_MASK", "PAGE_MASK" has an opposite convention of > > "AMDGPU_GPU_PAGE_MASK" :(. > > > > > > Yeah, good point. > > > > > > > > > I tried it and it broke userspace: Xorg startup fails with EINVAL with > > > > > this > > > > > change. > > > > Well in theory it is possible that we always fill the GPUVM on a 4k > > > > basis while the native page size of the CPU is larger. Let me double > > > > check the code. > > On my platform, there are two issues both causing the VM corruption. One is > > fixed by agd5f/linux@fe001e7. > > What is fe001e7? A commit id? If yes then that is to short and I can't > find it. > > > Another is in Mesa from userspace: it uses > > `dev_info->gart_page_size` as the alignment, but the kernel AMDGPU driver > > expects it to use `dev_info->virtual_address_alignment`. > > Mhm, looking at the kernel code I would rather say Mesa is correct and > the kernel driver is broken. > > The gart_page_size is limited by the CPU page size, but the > virtual_address_alignment isn't. > > > If we can make the change to fill the GPUVM on a 4k basis, we can fix this > > issue > > and make virtual_address_alignment = 4K. Otherwise, we should fortify the > > parameter validation, changing "AMDGPU_GPU_PAGE_MASK" to "~PAGE_MASK". Then > > the > > userspace will just get an EINVAL, instead of a slient VM corruption. And > > someone should tell Mesa developers to fix the code in this case. > > I rather see this as a kernel bug. Can you test if this code fragment > fixes your issue: > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > index 64beb3399604..e1260b517e1b 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > @@ -780,7 +780,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void > *data, struct drm_file *filp) > } > dev_info->virtual_address_alignment = > max((int)PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE); > dev_info->pte_fragment_size = (1 << > adev->vm_manager.fragment_size) * AMDGPU_GPU_PAGE_SIZE; > - dev_info->gart_page_size = AMDGPU_GPU_PAGE_SIZE; > + dev_info->gart_page_size = > dev_info->virtual_address_alignment; > dev_info->cu_active_number = adev->gfx.cu_info.number; > dev_info->cu_ao_mask = adev->gfx.cu_info.ao_cu_mask; > dev_info->ce_ram_size = adev->gfx.ce_ram_size; It works. I've seen it at https://github.com/xen0n/linux/commit/84ada72983838bd7ce54bc32f5d34ac5b5aae191 before (with a common sub-expression, though :). -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH] drm/amdgpu: fix an underflow on non-4KB-page systems
On 2021-03-30 03:40 +0800, Xi Ruoyao wrote: > On 2021-03-29 21:36 +0200, Christian König wrote: > > Am 29.03.21 um 21:27 schrieb Xi Ruoyao: > > > Hi Christian, > > > > > > I don't think there is any constraint implemented to ensure `num_entries % > > > AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0`. For example, in `amdgpu_vm_bo_map()`: > > > > > > /* validate the parameters */ > > > if (saddr & AMDGPU_GPU_PAGE_MASK || offset & AMDGPU_GPU_PAGE_MASK > > > > > > > > size == 0 || size & AMDGPU_GPU_PAGE_MASK) > > > return -EINVAL; > > > > > > /* snip */ > > > > > > saddr /= AMDGPU_GPU_PAGE_SIZE; > > > eaddr /= AMDGPU_GPU_PAGE_SIZE; > > > > > > /* snip */ > > > > > > mapping->start = saddr; > > > mapping->last = eaddr; > > > > > > > > > If we really want to ensure (mapping->last - mapping->start + 1) % > > > AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0, then we should replace > > > "AMDGPU_GPU_PAGE_MASK" > > > in "validate the parameters" with "PAGE_MASK". It should be "~PAGE_MASK", "PAGE_MASK" has an opposite convention of "AMDGPU_GPU_PAGE_MASK" :(. > > Yeah, good point. > > > > > I tried it and it broke userspace: Xorg startup fails with EINVAL with > > > this > > > change. > > > > Well in theory it is possible that we always fill the GPUVM on a 4k > > basis while the native page size of the CPU is larger. Let me double > > check the code. On my platform, there are two issues both causing the VM corruption. One is fixed by agd5f/linux@fe001e7. Another is in Mesa from userspace: it uses `dev_info->gart_page_size` as the alignment, but the kernel AMDGPU driver expects it to use `dev_info->virtual_address_alignment`. If we can make the change to fill the GPUVM on a 4k basis, we can fix this issue and make virtual_address_alignment = 4K. Otherwise, we should fortify the parameter validation, changing "AMDGPU_GPU_PAGE_MASK" to "~PAGE_MASK". Then the userspace will just get an EINVAL, instead of a slient VM corruption. And someone should tell Mesa developers to fix the code in this case. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH] drm/amdgpu: fix an underflow on non-4KB-page systems
On 2021-03-29 21:36 +0200, Christian König wrote: > Am 29.03.21 um 21:27 schrieb Xi Ruoyao: > > Hi Christian, > > > > I don't think there is any constraint implemented to ensure `num_entries % > > AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0`. For example, in `amdgpu_vm_bo_map()`: > > > > /* validate the parameters */ > > if (saddr & AMDGPU_GPU_PAGE_MASK || offset & AMDGPU_GPU_PAGE_MASK > > || > > size == 0 || size & AMDGPU_GPU_PAGE_MASK) > > return -EINVAL; > > > > /* snip */ > > > > saddr /= AMDGPU_GPU_PAGE_SIZE; > > eaddr /= AMDGPU_GPU_PAGE_SIZE; > > > > /* snip */ > > > > mapping->start = saddr; > > mapping->last = eaddr; > > > > > > If we really want to ensure (mapping->last - mapping->start + 1) % > > AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0, then we should replace > > "AMDGPU_GPU_PAGE_MASK" > > in "validate the parameters" with "PAGE_MASK". > > Yeah, good point. > > > I tried it and it broke userspace: Xorg startup fails with EINVAL with this > > change. > > Well in theory it is possible that we always fill the GPUVM on a 4k > basis while the native page size of the CPU is larger. Let me double > check the code. > > BTW: What code base are you based on? The code your post here is quite > outdated. Linus' tree. I'll go to sleep now (it's 03:39 here :( ), when I wake up I can try to fetch drm-next or something. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH] drm/amdgpu: fix an underflow on non-4KB-page systems
Hi Christian,
I don't think there is any constraint implemented to ensure `num_entries %
AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0`. For example, in `amdgpu_vm_bo_map()`:
/* validate the parameters */
if (saddr & AMDGPU_GPU_PAGE_MASK || offset & AMDGPU_GPU_PAGE_MASK ||
size == 0 || size & AMDGPU_GPU_PAGE_MASK)
return -EINVAL;
/* snip */
saddr /= AMDGPU_GPU_PAGE_SIZE;
eaddr /= AMDGPU_GPU_PAGE_SIZE;
/* snip */
mapping->start = saddr;
mapping->last = eaddr;
If we really want to ensure (mapping->last - mapping->start + 1) %
AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0, then we should replace "AMDGPU_GPU_PAGE_MASK"
in "validate the parameters" with "PAGE_MASK".
I tried it and it broke userspace: Xorg startup fails with EINVAL with this
change.
On 2021-03-30 02:30 +0800, Xi Ruoyao wrote:
> On 2021-03-30 02:21 +0800, Xi Ruoyao wrote:
> > On 2021-03-29 20:10 +0200, Christian König wrote:
> > > You need to identify the root cause of this, most likely start or last
> > > are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE.
> >
> > I printk'ed the value of start & last, they are all a multiple of 4
> > (AMDGPU_GPU_PAGES_IN_CPU_PAGE).
> >
> > However... `num_entries = last - start + 1` so it became some irrational
> > thing... Either this line is wrong, or someone called
> > amdgpu_vm_bo_update_mapping with [start, last) instead of [start, last],
> > which
> > is unexpected.
>
> I added BUG_ON(num_entries % AMDGPU_GPU_PAGES_IN_CPU_PAGE != 0), get:
>
> > Mar 30 02:28:27 xry111-A1901 kernel: []
> > amdgpu_vm_bo_update_mapping.constprop.0+0x218/0xae8
> > Mar 30 02:28:27 xry111-A1901 kernel: []
> > amdgpu_vm_bo_update+0x270/0x4c0
> > Mar 30 02:28:27 xry111-A1901 kernel: []
> > amdgpu_gem_va_ioctl+0x40c/0x430
> > Mar 30 02:28:27 xry111-A1901 kernel: []
> > drm_ioctl_kernel+0xcc/0x120
> > Mar 30 02:28:27 xry111-A1901 kernel: []
> > drm_ioctl+0x220/0x408
> > Mar 30 02:28:27 xry111-A1901 kernel: []
> > amdgpu_drm_ioctl+0x58/0x98
> > Mar 30 02:28:27 xry111-A1901 kernel: []
> > sys_ioctl+0xcc/0xe8
> > Mar 30 02:28:27 xry111-A1901 kernel: []
> > syscall_common+0x34/0x58
> >
>
> > > > > > BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1549
> > > > > > Fixes: a39f2a8d7066 ("drm/amdgpu: nuke amdgpu_vm_bo_split_mapping
> > > > > > v2")
> > > > > > Reported-by: Xi Ruoyao
> > > > > > Reported-by: Dan Horák
> > > > > > Cc: sta...@vger.kernel.org
> > > > > > Signed-off-by: Xi Ruoyao
> > > > > > ---
> > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > > > > > index ad91c0c3c423..cee0cc9c8085 100644
> > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > > > > > @@ -1707,7 +1707,7 @@ static int amdgpu_vm_bo_update_mapping(struct
> > > > > > amdgpu_device *adev,
> > > > > > }
> > > > > > start = tmp;
> > > > > >
> > > > > > - } while (unlikely(start != last + 1));
> > > > > > + } while (unlikely(start < last + 1));
> > > > > >
> > > > > > r = vm->update_funcs->commit(, fence);
> > > > > >
> > > > > >
> > > > > > base-commit: a5e13c6df0e41702d2b2c77c8ad41677ebb065b3
> > >
> >
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Re: [PATCH] drm/amdgpu: fix an underflow on non-4KB-page systems
On 2021-03-30 02:21 +0800, Xi Ruoyao wrote:
> On 2021-03-29 20:10 +0200, Christian König wrote:
> > You need to identify the root cause of this, most likely start or last
> > are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE.
>
> I printk'ed the value of start & last, they are all a multiple of 4
> (AMDGPU_GPU_PAGES_IN_CPU_PAGE).
>
> However... `num_entries = last - start + 1` so it became some irrational
> thing... Either this line is wrong, or someone called
> amdgpu_vm_bo_update_mapping with [start, last) instead of [start, last], which
> is unexpected.
I added BUG_ON(num_entries % AMDGPU_GPU_PAGES_IN_CPU_PAGE != 0), get:
> Mar 30 02:28:27 xry111-A1901 kernel: []
> amdgpu_vm_bo_update_mapping.constprop.0+0x218/0xae8
> Mar 30 02:28:27 xry111-A1901 kernel: []
> amdgpu_vm_bo_update+0x270/0x4c0
> Mar 30 02:28:27 xry111-A1901 kernel: []
> amdgpu_gem_va_ioctl+0x40c/0x430
> Mar 30 02:28:27 xry111-A1901 kernel: []
> drm_ioctl_kernel+0xcc/0x120
> Mar 30 02:28:27 xry111-A1901 kernel: []
> drm_ioctl+0x220/0x408
> Mar 30 02:28:27 xry111-A1901 kernel: []
> amdgpu_drm_ioctl+0x58/0x98
> Mar 30 02:28:27 xry111-A1901 kernel: [] sys_ioctl+0xcc/0xe8
> Mar 30 02:28:27 xry111-A1901 kernel: []
> syscall_common+0x34/0x58
>
> > > > > BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1549
> > > > > Fixes: a39f2a8d7066 ("drm/amdgpu: nuke amdgpu_vm_bo_split_mapping v2")
> > > > > Reported-by: Xi Ruoyao
> > > > > Reported-by: Dan Horák
> > > > > Cc: sta...@vger.kernel.org
> > > > > Signed-off-by: Xi Ruoyao
> > > > > ---
> > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > > > > index ad91c0c3c423..cee0cc9c8085 100644
> > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > > > > @@ -1707,7 +1707,7 @@ static int amdgpu_vm_bo_update_mapping(struct
> > > > > amdgpu_device *adev,
> > > > > }
> > > > > start = tmp;
> > > > >
> > > > > - } while (unlikely(start != last + 1));
> > > > > + } while (unlikely(start < last + 1));
> > > > >
> > > > > r = vm->update_funcs->commit(, fence);
> > > > >
> > > > >
> > > > > base-commit: a5e13c6df0e41702d2b2c77c8ad41677ebb065b3
> >
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Re: [PATCH] drm/amdgpu: fix an underflow on non-4KB-page systems
On 2021-03-29 20:10 +0200, Christian König wrote:
> You need to identify the root cause of this, most likely start or last
> are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE.
I printk'ed the value of start & last, they are all a multiple of 4
(AMDGPU_GPU_PAGES_IN_CPU_PAGE).
However... `num_entries = last - start + 1` so it became some irrational
thing... Either this line is wrong, or someone called
amdgpu_vm_bo_update_mapping with [start, last) instead of [start, last], which
is unexpected.
> > > > BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1549
> > > > Fixes: a39f2a8d7066 ("drm/amdgpu: nuke amdgpu_vm_bo_split_mapping v2")
> > > > Reported-by: Xi Ruoyao
> > > > Reported-by: Dan Horák
> > > > Cc: sta...@vger.kernel.org
> > > > Signed-off-by: Xi Ruoyao
> > > > ---
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > > > index ad91c0c3c423..cee0cc9c8085 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > > > @@ -1707,7 +1707,7 @@ static int amdgpu_vm_bo_update_mapping(struct
> > > > amdgpu_device *adev,
> > > > }
> > > > start = tmp;
> > > >
> > > > - } while (unlikely(start != last + 1));
> > > > + } while (unlikely(start < last + 1));
> > > >
> > > > r = vm->update_funcs->commit(, fence);
> > > >
> > > >
> > > > base-commit: a5e13c6df0e41702d2b2c77c8ad41677ebb065b3
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Re: [PATCH] drm/amdgpu: fix an underflow on non-4KB-page systems
On 2021-03-29 20:04 +0200, Christian König wrote:
> Am 29.03.21 um 19:53 schrieb Xℹ Ruoyao:
> > If the initial value of `num_entires` (calculated at line 1654) is not
> > an integral multiple of `AMDGPU_GPU_PAGES_IN_CPU_PAGE`, in line 1681 a
> > value greater than the initial value will be assigned to it. That causes
> > `start > last + 1` after line 1708. Then in the next iteration an
> > underflow happens at line 1654. It causes message
> >
> > *ERROR* Couldn't update BO_VA (-12)
> >
> > printed in kernel log, and GPU hanging.
> >
> > Fortify the criteria of the loop to fix this issue.
>
> NAK the value of num_entries must always be a multiple of
> AMDGPU_GPU_PAGES_IN_CPU_PAGE or otherwise we corrupt the page tables.
>
> How do you trigger that?
Simply run "OpenGL area" from gtk3-demo (which just renders a triangle with GL)
under Xorg, on MIPS64. See the BugLink.
> Christian.
>
> >
> > BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1549
> > Fixes: a39f2a8d7066 ("drm/amdgpu: nuke amdgpu_vm_bo_split_mapping v2")
> > Reported-by: Xi Ruoyao
> > Reported-by: Dan Horák
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Xi Ruoyao
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > index ad91c0c3c423..cee0cc9c8085 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > @@ -1707,7 +1707,7 @@ static int amdgpu_vm_bo_update_mapping(struct
> > amdgpu_device *adev,
> > }
> > start = tmp;
> >
> > - } while (unlikely(start != last + 1));
> > + } while (unlikely(start < last + 1));
> >
> > r = vm->update_funcs->commit(, fence);
> >
> >
> > base-commit: a5e13c6df0e41702d2b2c77c8ad41677ebb065b3
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Re: [tip: objtool/urgent] objtool: Fix seg fault with Clang non-section symbols
Hi Greg and Nick, On 2021-02-11 10:46 -0800, Nick Desaulniers wrote: > On Thu, Feb 11, 2021 at 5:55 AM Greg Kroah-Hartman > wrote: > > > > On Thu, Feb 11, 2021 at 09:32:03PM +0800, Xi Ruoyao wrote: > > > Hi all, > > > > > > The latest GNU assembler (binutils-2.36.1) is removing unused section > > > symbols > > > like Clang [1]. So linux-5.10.15 can't be built with binutils-2.36.1 > > > now. It > > > has been reported as https://bugzilla.kernel.org/show_bug.cgi?id=211693. > > Xi, > Happy Lunar New Year to you, too, and thanks for the report. Did you > observe such segfaults for older branches of stable? We found this issue building Linux From Scratch (http://www.linuxfromscratch.org/lfs/view/development/). We use the latest stable kernel in the project so we have no report of older branches. I tried 5.4.97 with a configuration "looks like" the one triggers the segfault in 5.10.15. But 5.4.97 build does not segfault. However, I guess for "some" config older branches may segfault too. > > 2.36 of binutils fails to build the 4.4.y tree right now as well, but as > > objtool isn't there, I don't know what to do about it :( > > Greg, > There may be multiple issues in the latest binutils release for the > kernel; we should still avoid segfaults in host tools so I do > recommend considering this patch for inclusion at least into 5.10.y. I strongly agree, or it may affect "rolling-release" distros (which are likely to use binutils-2.36.1 and linux-5.10.y together) in an annoying way. > Arnd's report in https://github.com/ClangBuiltLinux/linux/issues/1207 > mentions this was found via randconfig testing, so likely some set of > configs is needed to reproduce reliably. I attached a config in https://bugzilla.kernel.org/show_bug.cgi?id=211693 (also attached in this mail). It reproduces the issue for 5.10.15 very reliably. At least three of us tried this configuration on the system personally used (with binutils-2.36.1) and we got exactly same error: objtool segfaults on apic.o. > Do you have more info about the failure you're observing? Trolling > lore, I only see: > https://lore.kernel.org/stable/yclejcqfsdisr...@kroah.com/ > (Maybe it was reported on a different list; I only searched stable ML). -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University config-segfault.gz Description: application/gzip
Re: [tip: objtool/urgent] objtool: Fix seg fault with Clang non-section symbols
f.h
> index 807f8c6..e6890cc 100644
> --- a/tools/objtool/elf.h
> +++ b/tools/objtool/elf.h
> @@ -140,6 +140,8 @@ struct reloc *find_reloc_by_dest(const struct elf *elf,
> struct section *sec, uns
> struct reloc *find_reloc_by_dest_range(const struct elf *elf, struct section
> *sec,
> unsigned long offset, unsigned int len);
> struct symbol *find_func_containing(struct section *sec, unsigned long
> offset);
> +void insn_to_reloc_sym_addend(struct section *sec, unsigned long offset,
> + struct reloc *reloc);
> int elf_rebuild_reloc_section(struct elf *elf, struct section *sec);
>
> #define for_each_sec(file,
> sec)\
> diff --git a/tools/objtool/orc_gen.c b/tools/objtool/orc_gen.c
> index 235663b..9ce68b3 100644
> --- a/tools/objtool/orc_gen.c
> +++ b/tools/objtool/orc_gen.c
> @@ -105,30 +105,11 @@ static int create_orc_entry(struct elf *elf, struct
> section *u_sec, struct secti
> }
> memset(reloc, 0, sizeof(*reloc));
>
> - if (insn_sec->sym) {
> - reloc->sym = insn_sec->sym;
> - reloc->addend = insn_off;
> - } else {
> - /*
> - * The Clang assembler doesn't produce section symbols, so we
> - * have to reference the function symbol instead:
> - */
> - reloc->sym = find_symbol_containing(insn_sec, insn_off);
> - if (!reloc->sym) {
> - /*
> - * Hack alert. This happens when we need to reference
> - * the NOP pad insn immediately after the function.
> - */
> - reloc->sym = find_symbol_containing(insn_sec,
> - insn_off - 1);
> - }
> - if (!reloc->sym) {
> - WARN("missing symbol for insn at offset 0x%lx\n",
> - insn_off);
> - return -1;
> - }
> -
> - reloc->addend = insn_off - reloc->sym->offset;
> + insn_to_reloc_sym_addend(insn_sec, insn_off, reloc);
> + if (!reloc->sym) {
> + WARN("missing symbol for insn at offset 0x%lx",
> + insn_off);
> + return -1;
> }
>
> reloc->type = R_X86_64_PC32;
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Re: [GIT PULL] x86/topology changes for v5.3
On 2019-07-10 17:13 +0200, Thomas Gleixner wrote:
> Something like the below. Builds and boots, must be perfect.
>
> Thanks,
>
> tglx
Tested-by: Xi Ruoyao
> 8<
>
> arch/x86/include/asm/processor.h |1
> arch/x86/include/asm/special_insns.h | 41 ---
> arch/x86/kernel/cpu/common.c | 72 +++
>
> arch/x86/kernel/smpboot.c| 14 --
> arch/x86/xen/smp_pv.c|1
> 5 files changed, 61 insertions(+), 68 deletions(-)
>
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -741,6 +741,7 @@ extern void load_direct_gdt(int);
> extern void load_fixmap_gdt(int);
> extern void load_percpu_segment(int);
> extern void cpu_init(void);
> +extern void cr4_init(void);
>
> static inline unsigned long get_debugctlmsr(void)
> {
> --- a/arch/x86/include/asm/special_insns.h
> +++ b/arch/x86/include/asm/special_insns.h
> @@ -18,9 +18,7 @@
> */
> extern unsigned long __force_order;
>
> -/* Starts false and gets enabled once CPU feature detection is done. */
> -DECLARE_STATIC_KEY_FALSE(cr_pinning);
> -extern unsigned long cr4_pinned_bits;
> +void native_write_cr0(unsigned long val);
>
> static inline unsigned long native_read_cr0(void)
> {
> @@ -29,24 +27,6 @@ static inline unsigned long native_read_
> return val;
> }
>
> -static inline void native_write_cr0(unsigned long val)
> -{
> - unsigned long bits_missing = 0;
> -
> -set_register:
> - asm volatile("mov %0,%%cr0": "+r" (val), "+m" (__force_order));
> -
> - if (static_branch_likely(_pinning)) {
> - if (unlikely((val & X86_CR0_WP) != X86_CR0_WP)) {
> - bits_missing = X86_CR0_WP;
> - val |= bits_missing;
> - goto set_register;
> - }
> - /* Warn after we've set the missing bits. */
> - WARN_ONCE(bits_missing, "CR0 WP bit went missing!?\n");
> - }
> -}
> -
> static inline unsigned long native_read_cr2(void)
> {
> unsigned long val;
> @@ -91,24 +71,7 @@ static inline unsigned long native_read_
> return val;
> }
>
> -static inline void native_write_cr4(unsigned long val)
> -{
> - unsigned long bits_missing = 0;
> -
> -set_register:
> - asm volatile("mov %0,%%cr4": "+r" (val), "+m" (cr4_pinned_bits));
> -
> - if (static_branch_likely(_pinning)) {
> - if (unlikely((val & cr4_pinned_bits) != cr4_pinned_bits)) {
> - bits_missing = ~val & cr4_pinned_bits;
> - val |= bits_missing;
> - goto set_register;
> - }
> - /* Warn after we've set the missing bits. */
> - WARN_ONCE(bits_missing, "CR4 bits went missing: %lx!?\n",
> - bits_missing);
> - }
> -}
> +void native_write_cr4(unsigned long val);
>
> #ifdef CONFIG_X86_64
> static inline unsigned long native_read_cr8(void)
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -366,10 +366,62 @@ static __always_inline void setup_umip(s
> cr4_clear_bits(X86_CR4_UMIP);
> }
>
> -DEFINE_STATIC_KEY_FALSE_RO(cr_pinning);
> -EXPORT_SYMBOL(cr_pinning);
> -unsigned long cr4_pinned_bits __ro_after_init;
> -EXPORT_SYMBOL(cr4_pinned_bits);
> +static DEFINE_STATIC_KEY_FALSE_RO(cr_pinning);
> +static unsigned long cr4_pinned_bits __ro_after_init;
> +
> +void native_write_cr0(unsigned long val)
> +{
> + unsigned long bits_missing = 0;
> +
> +set_register:
> + asm volatile("mov %0,%%cr0": "+r" (val), "+m" (__force_order));
> +
> + if (static_branch_likely(_pinning)) {
> + if (unlikely((val & X86_CR0_WP) != X86_CR0_WP)) {
> + bits_missing = X86_CR0_WP;
> + val |= bits_missing;
> + goto set_register;
> + }
> + /* Warn after we've set the missing bits. */
> + WARN_ONCE(bits_missing, "CR0 WP bit went missing!?\n");
> + }
> +}
> +EXPORT_SYMBOL(native_write_cr0);
> +
> +void native_write_cr4(unsigned long val)
> +{
> + unsigned long bits_missing = 0;
> +
> +set_register:
> + asm volatile("mov %0,%%cr4": "+r" (val), "+m" (cr4_pinned_bits));
> +
> + if (static_branch_likely(_pinning)) {
> + if (unlikely((val & cr4_pinned_bits) != cr4_pinned_
Re: [GIT PULL] x86/topology changes for v5.3
On 2019-07-10 16:22 +0200, Jiri Kosina wrote: > On Wed, 10 Jul 2019, Peter Zijlstra wrote: > > > If we mark the key as RO after init, and then try and modify the key to > > link module usage sites, things might go bang as described. > > > > Thanks! > > > > > > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > > index 27d7864e7252..5bf7a8354da2 100644 > > --- a/arch/x86/kernel/cpu/common.c > > +++ b/arch/x86/kernel/cpu/common.c > > @@ -366,7 +366,7 @@ static __always_inline void setup_umip(struct > > cpuinfo_x86 *c) > > cr4_clear_bits(X86_CR4_UMIP); > > } > > > > -DEFINE_STATIC_KEY_FALSE_RO(cr_pinning); > > +DEFINE_STATIC_KEY_FALSE(cr_pinning); > > Good catch, I guess that is going to fix it. Yes it works. > At the same time though, it sort of destroys the original intent of Kees' > patch, right? The exploits will just have to call static_key_disable() > prior to calling native_write_cr4() again, and the protection is gone. I think I should do some study and try to understand the full story of Kees' change... -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [GIT PULL] x86/topology changes for v5.3
On 2019-07-10 15:28 +0200, Jiri Kosina wrote: > On Wed, 10 Jul 2019, Jiri Kosina wrote: > > > > > BUG: unable to handle page fault for address: 9edc1598 > > > > > #PF: supervisor write access in kernel mode > > > > > #PF: error_code(0x0003) - permissions violation > > Hm, and it seems to explode on dereferencing the static_key* in %rsi > > ^^^ %rdi of > course > > > 21: 48 8b 37mov(%rdi),%rsi > > 24: 83 e6 03and$0x3,%esi > > 27: 48 09 c6or %rax,%rsi > > 2a:* 48 89 37mov%rsi,(%rdi) <-- trapping > > instruction > > > > which looks odd, as it derefenced it successfully just 3 instructions ago. It seems the MMU (I guess ?) allows to read it, but disallows to write it: "supervisor write access in kernel mode". -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [GIT PULL] x86/topology changes for v5.3
On 2019-07-10 14:31 +0200, Jiri Kosina wrote: > Adding Daniel to check whether this couldn't be some fallout of jumplabel > batching. I don't think so. I tried to revert Daniel's jumplabel batching commits and the issue wasn't solved. But reverting Kees' CR0 and CR4 commits can "fix" it (apprently). -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [GIT PULL] x86/topology changes for v5.3
On 2019-07-09 17:31 -0700, Kees Cook wrote:
> On Wed, Jul 10, 2019 at 01:17:11AM +0200, Thomas Gleixner wrote:
> > On Wed, 10 Jul 2019, Thomas Gleixner wrote:
> > > That still does not explain the cr4/0 issue you have. Can you send me your
> > > .config please?
> >
> > Does your machine have UMIP support? None of my test boxes has. So that'd
> > be the difference of bits enforced in CR4. Should not matter because it's
> > User mode instruction prevention, but who knows.
>
> Ew. Yeah, I don't have i9 nor i7 for testing this. I did try everything
> else I had (and hibernation). Is only Linus able to reproduce this so far?
I can, too.
> To rule out (in?) UMIP, this would remove UMIP from the pinning:
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 309b6b9b49d4..f3beedb6da8a 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -380,7 +380,7 @@ static void __init setup_cr_pinning(void)
> {
> unsigned long mask;
>
> - mask = (X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP);
> + mask = (X86_CR4_SMEP | X86_CR4_SMAP);
> cr4_pinned_bits = this_cpu_read(cpu_tlbstate.cr4) & mask;
> static_key_enable(_pinning.key);
> }
I'll try it.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
[PATCH RFC] mm: memcontrol: add cgroup v2 interface to read memory watermark
Introduce a control file memory.watermark showing the watermark
consumption of the cgroup and its descendants, in bytes.
Signed-off-by: Xi Ruoyao
---
mm/memcontrol.c | 12
1 file changed, 12 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index ba9138a4a1de..b1d968f2adcd 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5495,6 +5495,13 @@ static u64 memory_current_read(struct cgroup_subsys_state
*css,
return (u64)page_counter_read(>memory) * PAGE_SIZE;
}
+static u64 memory_watermark_read(struct cgroup_subsys_state *css,
+struct cftype *cft)
+{
+ struct mem_cgroup *memcg = mem_cgroup_from_css(css);
+ return (u64)memcg->memory.watermark * PAGE_SIZE;
+}
+
static int memory_min_show(struct seq_file *m, void *v)
{
return seq_puts_memcg_tunable(m,
@@ -5771,6 +5778,11 @@ static struct cftype memory_files[] = {
.flags = CFTYPE_NOT_ON_ROOT,
.read_u64 = memory_current_read,
},
+ {
+ .name = "watermark",
+ .flags = CFTYPE_NOT_ON_ROOT,
+ .read_u64 = memory_watermark_read,
+ },
{
.name = "min",
.flags = CFTYPE_NOT_ON_ROOT,
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Re: [PATCH] Kbuild: fix mismatched if/endif pairs
On 2018-06-17 18:16 +0800, Xi Ruoyao wrote: > In scripts/Makefile.build, there are two mismatched if/endif pairs. > They stop the generation of orc unwind table if CONFIG_FTRACE_MCOUNT_RECORD > is not set. dmesg complains: Duplication of patch 10455267 in patchwork. Sorry for noise :(. But let's fix this quickly, since the issue breaks ORC unwinder completely (at least with my configuration). -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH] Kbuild: fix mismatched if/endif pairs
On 2018-06-17 18:16 +0800, Xi Ruoyao wrote: > In scripts/Makefile.build, there are two mismatched if/endif pairs. > They stop the generation of orc unwind table if CONFIG_FTRACE_MCOUNT_RECORD > is not set. dmesg complains: Duplication of patch 10455267 in patchwork. Sorry for noise :(. But let's fix this quickly, since the issue breaks ORC unwinder completely (at least with my configuration). -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
[PATCH] Kbuild: fix mismatched if/endif pairs
In scripts/Makefile.build, there are two mismatched if/endif pairs. They stop the generation of orc unwind table if CONFIG_FTRACE_MCOUNT_RECORD is not set. dmesg complains: WARNING: WARNING: Bad or missing .orc_unwind table. Disabling unwinder. This comment moves an endif to match the if/endif pairs. Signed-off-by: Xi Ruoyao --- scripts/Makefile.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 34d9e9ce97c2..16509a038d77 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -239,6 +239,7 @@ cmd_record_mcount = \ "$(CC_FLAGS_FTRACE)" ]; then \ $(sub_cmd_record_mcount)\ fi; +endif # cc-option(-mrecord-mcount) endif # CONFIG_FTRACE_MCOUNT_RECORD ifdef CONFIG_STACK_VALIDATION @@ -263,7 +264,6 @@ ifneq ($(RETPOLINE_CFLAGS),) objtool_args += --retpoline endif endif -endif ifdef CONFIG_MODVERSIONS -- 2.16.2
[PATCH] Kbuild: fix mismatched if/endif pairs
In scripts/Makefile.build, there are two mismatched if/endif pairs. They stop the generation of orc unwind table if CONFIG_FTRACE_MCOUNT_RECORD is not set. dmesg complains: WARNING: WARNING: Bad or missing .orc_unwind table. Disabling unwinder. This comment moves an endif to match the if/endif pairs. Signed-off-by: Xi Ruoyao --- scripts/Makefile.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 34d9e9ce97c2..16509a038d77 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -239,6 +239,7 @@ cmd_record_mcount = \ "$(CC_FLAGS_FTRACE)" ]; then \ $(sub_cmd_record_mcount)\ fi; +endif # cc-option(-mrecord-mcount) endif # CONFIG_FTRACE_MCOUNT_RECORD ifdef CONFIG_STACK_VALIDATION @@ -263,7 +264,6 @@ ifneq ($(RETPOLINE_CFLAGS),) objtool_args += --retpoline endif endif -endif ifdef CONFIG_MODVERSIONS -- 2.16.2
[PATCH RESEND] Bluetooth: btusb: Modify entry to support misc devices with BT interface
In the USB device table in btusb driver, the code specify a generic Bluetooth
device by matching Device Descriptor. However, some devices with BT interface
are classified as "Miscellaneous Device" and have different Device Descriptor,
such as Realtek RTL8723AU. Then btusb wouldn't probe them.
To resolve this, specify generic Bluetooth device in the USB device table by
matching Interface Descriptor, to probe all devices with Bluetooth interface
including these "Miscellaneous" ones.
Signed-off-by: Xi Ruoyao
---
The Bluetooth USB driver changed a lot since 4.1 released. However this problem
still exists now, so I think I should resend this patch.
After apply this patch, my RTL8723AU works well. This is the info of the
RTL8723AU
USB device:
T: Bus=03 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=1724 Rev= 2.00
S: Manufacturer=Realtek
S: Product=802.11n WLAN Adapter
S: SerialNumber=00e04c01
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
drivers/bluetooth/btusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index b4cf8d9..950afda 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -63,7 +63,7 @@ static struct usb_driver btusb_driver;
static const struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
- { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+ { USB_INTERFACE_INFO(0xe0, 0x01, 0x01) },
/* Generic Bluetooth AMP device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x04), .driver_info = BTUSB_AMP },
--
1.9.1
--
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 RESEND] Bluetooth: btusb: Modify entry to support misc devices with BT interface
In the USB device table in btusb driver, the code specify a generic Bluetooth
device by matching Device Descriptor. However, some devices with BT interface
are classified as Miscellaneous Device and have different Device Descriptor,
such as Realtek RTL8723AU. Then btusb wouldn't probe them.
To resolve this, specify generic Bluetooth device in the USB device table by
matching Interface Descriptor, to probe all devices with Bluetooth interface
including these Miscellaneous ones.
Signed-off-by: Xi Ruoyao xry...@outlook.com
---
The Bluetooth USB driver changed a lot since 4.1 released. However this problem
still exists now, so I think I should resend this patch.
After apply this patch, my RTL8723AU works well. This is the info of the
RTL8723AU
USB device:
T: Bus=03 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=1724 Rev= 2.00
S: Manufacturer=Realtek
S: Product=802.11n WLAN Adapter
S: SerialNumber=00e04c01
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
drivers/bluetooth/btusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index b4cf8d9..950afda 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -63,7 +63,7 @@ static struct usb_driver btusb_driver;
static const struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
- { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+ { USB_INTERFACE_INFO(0xe0, 0x01, 0x01) },
/* Generic Bluetooth AMP device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x04), .driver_info = BTUSB_AMP },
--
1.9.1
--
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] Bluetooth: btusb: Modify entry to support misc devices with BT interface
In the USB device table in btusb driver, the code specify a generic Bluetooth
device by matching Device Descriptor. However, some devices with BT interface
are classified as "Miscellaneous Device" and have different Device Descriptor,
such as Realtek RTL8723AU. Then btusb wouldn't probe them.
To resolve this, specify generic Bluetooth device in the USB device table by
matching Interface Descriptor, to probe all devices with Bluetooth interface
including these "Miscellaneous" ones.
Signed-off-by: Xi Ruoyao
---
drivers/bluetooth/btusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3c10d4d..beb6b23 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -62,7 +62,7 @@ static struct usb_driver btusb_driver;
static const struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
- { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+ { USB_INTERFACE_INFO(0xe0, 0x01, 0x01) },
/* Generic Bluetooth AMP device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x04), .driver_info = BTUSB_AMP },
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: btusb: Add Realtek devices into module device table
On 06/22/2015 10:23 PM, Larry Finger wrote I hope that Xi's posting of the /sys file will help. Unfortunately, I do not have ready access to one of these devices, but I'm making arrangements to gain ssh access tomorrow so that I can test any suggested patches. Beside my earlier patch, I'll send a patch which would modify the generic USB BT device entry in the device table to resolve this. You can choose one of the two patches since they both make the BT works at least on my tablet. If there are other alternate patches, I can help to test them. -- Xi Ruoyao School of Aerospace Science and Technology Xidian University, Xi'an, China -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: btusb: Add Realtek devices into module device table
On 06/22/2015 06:33 PM, Marcel Holtmann wrote:
Hi Larry,
In 'commit a2698a9bf9b0 ("Bluetooth: btusb: Add Realtek
8723A/8723B/8761A/8821A support"), support of some Realtek
devices was added to the Generic Bluetooth USB driver in kernel.
However, these devices are not in the module device table of
btusb.ko, so the kernel wouldn't probe them at all.
To fix this, add four entries in the device table btusb_table,
based on code from <https://github.com/lwfinger/rtl8723au_bt>
('new' branch).
This enables bluetooth support in the Lenovo Ideapad Yoga 13
which has RTL8723AU USB device, with product ID 0bda:1724.
Signed-off-by: Xi Ruoyao
---
drivers/bluetooth/btusb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3c10d4d..dd87623 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -148,6 +148,12 @@ static const struct usb_device_id btusb_table[] = {
{ USB_DEVICE(0x8087, 0x0a5a),
.driver_info = BTUSB_INTEL_BOOT | BTUSB_BROKEN_ISOC },
+ /* Realtek Bluetooth */
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0bd5, 0xe0, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xe0, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xe0, 0x01, 0x01) },
+
I highly doubt these are needed. There is a generic entry for an USB transport
that is already covering these.
Something changed in recent kernels, and the generic USB transport entries do
not seem to be recognized in the case where a wifi and BT device share a single
USB ID. As the OP's tablet has such a case, I suggest that 0bda line be
accepted, but not the others. If I had a computer with an RTL8723AU, I would
have a chance at debugging what changed, but sadly, that is not the case.
these Realtek devices are causing the most messy setup in a generic driver. And
Bluetooth USB support has been really clean and simple for the last 10 years. I
really wonder how many ways this gets done wrong before someone gets a clue and
gets this right. At the end of the day this USB transport is 15 years old.
I agree. Not only BT, but also wifi in RTL8723AU has caused me a lot of
trouble.
Anyway, for obvious reasons the content of /sys/kernel/debug/usb/devices should
be included here so that someone can actually look at how the USB endpoints are
configured.
The contents about my RTL8723AU is here:
T: Bus=03 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=1724 Rev= 2.00
S: Manufacturer=Realtek
S: Product=802.11n WLAN Adapter
S: SerialNumber=00e04c01
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 4 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtl8723au
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=500us
Regards
Marcel
We can see, since in RTL8723AU the wifi and BT share a single USB ID,
the device
class is 0xef (misc) instead of 0xe0. And the generic entry in btusb
driver only matches
the devices with class 0xe0. That's why RTL8723AU don't work.
I think we should change the entry from USB_DEVICE_INFO to
USB_INTERFACE_INFO.
Then this entry can match all devices which have a Bluetooth interface.
It works well
in my case at least.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Bluetooth: btusb: Modify entry to support misc devices with BT interface
In the USB device table in btusb driver, the code specify a generic Bluetooth
device by matching Device Descriptor. However, some devices with BT interface
are classified as Miscellaneous Device and have different Device Descriptor,
such as Realtek RTL8723AU. Then btusb wouldn't probe them.
To resolve this, specify generic Bluetooth device in the USB device table by
matching Interface Descriptor, to probe all devices with Bluetooth interface
including these Miscellaneous ones.
Signed-off-by: Xi Ruoyao xry...@outlook.com
---
drivers/bluetooth/btusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3c10d4d..beb6b23 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -62,7 +62,7 @@ static struct usb_driver btusb_driver;
static const struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
- { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+ { USB_INTERFACE_INFO(0xe0, 0x01, 0x01) },
/* Generic Bluetooth AMP device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x04), .driver_info = BTUSB_AMP },
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: btusb: Add Realtek devices into module device table
On 06/22/2015 10:23 PM, Larry Finger wrote I hope that Xi's posting of the /sys file will help. Unfortunately, I do not have ready access to one of these devices, but I'm making arrangements to gain ssh access tomorrow so that I can test any suggested patches. Beside my earlier patch, I'll send a patch which would modify the generic USB BT device entry in the device table to resolve this. You can choose one of the two patches since they both make the BT works at least on my tablet. If there are other alternate patches, I can help to test them. -- Xi Ruoyao School of Aerospace Science and Technology Xidian University, Xi'an, China -- To unsubscribe from this list: send the line unsubscribe linux-kernel in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: btusb: Add Realtek devices into module device table
On 06/22/2015 06:33 PM, Marcel Holtmann wrote:
Hi Larry,
In 'commit a2698a9bf9b0 (Bluetooth: btusb: Add Realtek
8723A/8723B/8761A/8821A support), support of some Realtek
devices was added to the Generic Bluetooth USB driver in kernel.
However, these devices are not in the module device table of
btusb.ko, so the kernel wouldn't probe them at all.
To fix this, add four entries in the device table btusb_table,
based on code from https://github.com/lwfinger/rtl8723au_bt
('new' branch).
This enables bluetooth support in the Lenovo Ideapad Yoga 13
which has RTL8723AU USB device, with product ID 0bda:1724.
Signed-off-by: Xi Ruoyao xry...@outlook.com
---
drivers/bluetooth/btusb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3c10d4d..dd87623 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -148,6 +148,12 @@ static const struct usb_device_id btusb_table[] = {
{ USB_DEVICE(0x8087, 0x0a5a),
.driver_info = BTUSB_INTEL_BOOT | BTUSB_BROKEN_ISOC },
+ /* Realtek Bluetooth */
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0bd5, 0xe0, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xe0, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xe0, 0x01, 0x01) },
+
I highly doubt these are needed. There is a generic entry for an USB transport
that is already covering these.
Something changed in recent kernels, and the generic USB transport entries do
not seem to be recognized in the case where a wifi and BT device share a single
USB ID. As the OP's tablet has such a case, I suggest that 0bda line be
accepted, but not the others. If I had a computer with an RTL8723AU, I would
have a chance at debugging what changed, but sadly, that is not the case.
these Realtek devices are causing the most messy setup in a generic driver. And
Bluetooth USB support has been really clean and simple for the last 10 years. I
really wonder how many ways this gets done wrong before someone gets a clue and
gets this right. At the end of the day this USB transport is 15 years old.
I agree. Not only BT, but also wifi in RTL8723AU has caused me a lot of
trouble.
Anyway, for obvious reasons the content of /sys/kernel/debug/usb/devices should
be included here so that someone can actually look at how the USB endpoints are
configured.
The contents about my RTL8723AU is here:
T: Bus=03 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=1724 Rev= 2.00
S: Manufacturer=Realtek
S: Product=802.11n WLAN Adapter
S: SerialNumber=00e04c01
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 4 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtl8723au
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=500us
Regards
Marcel
We can see, since in RTL8723AU the wifi and BT share a single USB ID,
the device
class is 0xef (misc) instead of 0xe0. And the generic entry in btusb
driver only matches
the devices with class 0xe0. That's why RTL8723AU don't work.
I think we should change the entry from USB_DEVICE_INFO to
USB_INTERFACE_INFO.
Then this entry can match all devices which have a Bluetooth interface.
It works well
in my case at least.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: btusb: Add Realtek devices into module device table
On 06/21/2015 12:11 PM, Xi Ruoyao wrote:
On 06/21/2015 09:12 AM, Larry Finger wrote:
On 06/20/2015 04:58 PM, Marcel Holtmann wrote:
Hi Xi,
In 'commit a2698a9bf9b0 ("Bluetooth: btusb: Add Realtek
8723A/8723B/8761A/8821A support"), support of some Realtek
devices was added to the Generic Bluetooth USB driver in kernel.
However, these devices are not in the module device table of
btusb.ko, so the kernel wouldn't probe them at all.
To fix this, add four entries in the device table btusb_table,
based on code from <https://github.com/lwfinger/rtl8723au_bt>
('new' branch).
This enables bluetooth support in the Lenovo Ideapad Yoga 13
which has RTL8723AU USB device, with product ID 0bda:1724.
Signed-off-by: Xi Ruoyao
---
drivers/bluetooth/btusb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3c10d4d..dd87623 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -148,6 +148,12 @@ static const struct usb_device_id
btusb_table[] = {
{ USB_DEVICE(0x8087, 0x0a5a),
.driver_info = BTUSB_INTEL_BOOT | BTUSB_BROKEN_ISOC },
+/* Realtek Bluetooth */
+{ USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01) },
+{ USB_VENDOR_AND_INTERFACE_INFO(0x0bd5, 0xe0, 0x01, 0x01) },
+{ USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xe0, 0x01, 0x01) },
+{ USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xe0, 0x01, 0x01) },
+
I highly doubt these are needed. There is a generic entry for an USB
transport that is already covering these.
Something changed in recent kernels, and the generic USB transport
entries do not seem to be recognized in the case where a wifi and BT
device share a single USB ID. As the OP's tablet has such a case, I
suggest that 0bda line be accepted, but not the others. If I had a
computer with an RTL8723AU, I would have a chance at debugging what
changed, but sadly, that is not the case.
Larry
I viewed the output of 'lsusb -d 0bda:1724 -v | less', and I found
that my RTL8723AU has 'bDeviceClass' 239 (0xef, means 'Miscellaneous
Device')
but 'bInterfaceClass' 224 (0xe0, means 'Wireless').
So maybe the Generic Bluetooth USB device entry should be
'{ USB_INTERFACE_INFO(0xe0, 0x01, 0x01) },'
instead of
'{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) },'
Now I'm compiling this.
This approach works well on my tablet. So, which way is better, edit
Generic Bluetooth USB device entry, or add a new 0bda entry?
And below the Generic Bluetooth USB device entry there is Generic
Bluetooth AMP device entry. Should we use USB_INTERFACE_INFO on this too?
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: btusb: Add Realtek devices into module device table
On 06/21/2015 09:12 AM, Larry Finger wrote:
On 06/20/2015 04:58 PM, Marcel Holtmann wrote:
Hi Xi,
In 'commit a2698a9bf9b0 ("Bluetooth: btusb: Add Realtek
8723A/8723B/8761A/8821A support"), support of some Realtek
devices was added to the Generic Bluetooth USB driver in kernel.
However, these devices are not in the module device table of
btusb.ko, so the kernel wouldn't probe them at all.
To fix this, add four entries in the device table btusb_table,
based on code from <https://github.com/lwfinger/rtl8723au_bt>
('new' branch).
This enables bluetooth support in the Lenovo Ideapad Yoga 13
which has RTL8723AU USB device, with product ID 0bda:1724.
Signed-off-by: Xi Ruoyao
---
drivers/bluetooth/btusb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3c10d4d..dd87623 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -148,6 +148,12 @@ static const struct usb_device_id btusb_table[]
= {
{ USB_DEVICE(0x8087, 0x0a5a),
.driver_info = BTUSB_INTEL_BOOT | BTUSB_BROKEN_ISOC },
+/* Realtek Bluetooth */
+{ USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01) },
+{ USB_VENDOR_AND_INTERFACE_INFO(0x0bd5, 0xe0, 0x01, 0x01) },
+{ USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xe0, 0x01, 0x01) },
+{ USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xe0, 0x01, 0x01) },
+
I highly doubt these are needed. There is a generic entry for an USB
transport that is already covering these.
Something changed in recent kernels, and the generic USB transport
entries do not seem to be recognized in the case where a wifi and BT
device share a single USB ID. As the OP's tablet has such a case, I
suggest that 0bda line be accepted, but not the others. If I had a
computer with an RTL8723AU, I would have a chance at debugging what
changed, but sadly, that is not the case.
Larry
I viewed the output of 'lsusb -d 0bda:1724 -v | less', and I found that
my RTL8723AU has 'bDeviceClass' 239 (0xef, means 'Miscellaneous Device')
but 'bInterfaceClass' 224 (0xe0, means 'Wireless').
So maybe the Generic Bluetooth USB device entry should be
'{ USB_INTERFACE_INFO(0xe0, 0x01, 0x01) },'
instead of
'{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) },'
Now I'm compiling this.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Bluetooth: btusb: Add Realtek devices into module device table
In 'commit a2698a9bf9b0 ("Bluetooth: btusb: Add Realtek
8723A/8723B/8761A/8821A support"), support of some Realtek
devices was added to the Generic Bluetooth USB driver in kernel.
However, these devices are not in the module device table of
btusb.ko, so the kernel wouldn't probe them at all.
To fix this, add four entries in the device table btusb_table,
based on code from <https://github.com/lwfinger/rtl8723au_bt>
('new' branch).
This enables bluetooth support in the Lenovo Ideapad Yoga 13
which has RTL8723AU USB device, with product ID 0bda:1724.
Signed-off-by: Xi Ruoyao
---
drivers/bluetooth/btusb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3c10d4d..dd87623 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -148,6 +148,12 @@ static const struct usb_device_id btusb_table[] = {
{ USB_DEVICE(0x8087, 0x0a5a),
.driver_info = BTUSB_INTEL_BOOT | BTUSB_BROKEN_ISOC },
+ /* Realtek Bluetooth */
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0bd5, 0xe0, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xe0, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xe0, 0x01, 0x01) },
+
{ } /* Terminating entry */
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Bluetooth: btusb: Add Realtek devices into module device table
In 'commit a2698a9bf9b0 (Bluetooth: btusb: Add Realtek
8723A/8723B/8761A/8821A support), support of some Realtek
devices was added to the Generic Bluetooth USB driver in kernel.
However, these devices are not in the module device table of
btusb.ko, so the kernel wouldn't probe them at all.
To fix this, add four entries in the device table btusb_table,
based on code from https://github.com/lwfinger/rtl8723au_bt
('new' branch).
This enables bluetooth support in the Lenovo Ideapad Yoga 13
which has RTL8723AU USB device, with product ID 0bda:1724.
Signed-off-by: Xi Ruoyao xry...@outlook.com
---
drivers/bluetooth/btusb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3c10d4d..dd87623 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -148,6 +148,12 @@ static const struct usb_device_id btusb_table[] = {
{ USB_DEVICE(0x8087, 0x0a5a),
.driver_info = BTUSB_INTEL_BOOT | BTUSB_BROKEN_ISOC },
+ /* Realtek Bluetooth */
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0bd5, 0xe0, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xe0, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xe0, 0x01, 0x01) },
+
{ } /* Terminating entry */
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: btusb: Add Realtek devices into module device table
On 06/21/2015 09:12 AM, Larry Finger wrote:
On 06/20/2015 04:58 PM, Marcel Holtmann wrote:
Hi Xi,
In 'commit a2698a9bf9b0 (Bluetooth: btusb: Add Realtek
8723A/8723B/8761A/8821A support), support of some Realtek
devices was added to the Generic Bluetooth USB driver in kernel.
However, these devices are not in the module device table of
btusb.ko, so the kernel wouldn't probe them at all.
To fix this, add four entries in the device table btusb_table,
based on code from https://github.com/lwfinger/rtl8723au_bt
('new' branch).
This enables bluetooth support in the Lenovo Ideapad Yoga 13
which has RTL8723AU USB device, with product ID 0bda:1724.
Signed-off-by: Xi Ruoyao xry...@outlook.com
---
drivers/bluetooth/btusb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3c10d4d..dd87623 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -148,6 +148,12 @@ static const struct usb_device_id btusb_table[]
= {
{ USB_DEVICE(0x8087, 0x0a5a),
.driver_info = BTUSB_INTEL_BOOT | BTUSB_BROKEN_ISOC },
+/* Realtek Bluetooth */
+{ USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01) },
+{ USB_VENDOR_AND_INTERFACE_INFO(0x0bd5, 0xe0, 0x01, 0x01) },
+{ USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xe0, 0x01, 0x01) },
+{ USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xe0, 0x01, 0x01) },
+
I highly doubt these are needed. There is a generic entry for an USB
transport that is already covering these.
Something changed in recent kernels, and the generic USB transport
entries do not seem to be recognized in the case where a wifi and BT
device share a single USB ID. As the OP's tablet has such a case, I
suggest that 0bda line be accepted, but not the others. If I had a
computer with an RTL8723AU, I would have a chance at debugging what
changed, but sadly, that is not the case.
Larry
I viewed the output of 'lsusb -d 0bda:1724 -v | less', and I found that
my RTL8723AU has 'bDeviceClass' 239 (0xef, means 'Miscellaneous Device')
but 'bInterfaceClass' 224 (0xe0, means 'Wireless').
So maybe the Generic Bluetooth USB device entry should be
'{ USB_INTERFACE_INFO(0xe0, 0x01, 0x01) },'
instead of
'{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) },'
Now I'm compiling this.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: btusb: Add Realtek devices into module device table
On 06/21/2015 12:11 PM, Xi Ruoyao wrote:
On 06/21/2015 09:12 AM, Larry Finger wrote:
On 06/20/2015 04:58 PM, Marcel Holtmann wrote:
Hi Xi,
In 'commit a2698a9bf9b0 (Bluetooth: btusb: Add Realtek
8723A/8723B/8761A/8821A support), support of some Realtek
devices was added to the Generic Bluetooth USB driver in kernel.
However, these devices are not in the module device table of
btusb.ko, so the kernel wouldn't probe them at all.
To fix this, add four entries in the device table btusb_table,
based on code from https://github.com/lwfinger/rtl8723au_bt
('new' branch).
This enables bluetooth support in the Lenovo Ideapad Yoga 13
which has RTL8723AU USB device, with product ID 0bda:1724.
Signed-off-by: Xi Ruoyao xry...@outlook.com
---
drivers/bluetooth/btusb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3c10d4d..dd87623 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -148,6 +148,12 @@ static const struct usb_device_id
btusb_table[] = {
{ USB_DEVICE(0x8087, 0x0a5a),
.driver_info = BTUSB_INTEL_BOOT | BTUSB_BROKEN_ISOC },
+/* Realtek Bluetooth */
+{ USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01) },
+{ USB_VENDOR_AND_INTERFACE_INFO(0x0bd5, 0xe0, 0x01, 0x01) },
+{ USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xe0, 0x01, 0x01) },
+{ USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xe0, 0x01, 0x01) },
+
I highly doubt these are needed. There is a generic entry for an USB
transport that is already covering these.
Something changed in recent kernels, and the generic USB transport
entries do not seem to be recognized in the case where a wifi and BT
device share a single USB ID. As the OP's tablet has such a case, I
suggest that 0bda line be accepted, but not the others. If I had a
computer with an RTL8723AU, I would have a chance at debugging what
changed, but sadly, that is not the case.
Larry
I viewed the output of 'lsusb -d 0bda:1724 -v | less', and I found
that my RTL8723AU has 'bDeviceClass' 239 (0xef, means 'Miscellaneous
Device')
but 'bInterfaceClass' 224 (0xe0, means 'Wireless').
So maybe the Generic Bluetooth USB device entry should be
'{ USB_INTERFACE_INFO(0xe0, 0x01, 0x01) },'
instead of
'{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) },'
Now I'm compiling this.
This approach works well on my tablet. So, which way is better, edit
Generic Bluetooth USB device entry, or add a new 0bda entry?
And below the Generic Bluetooth USB device entry there is Generic
Bluetooth AMP device entry. Should we use USB_INTERFACE_INFO on this too?
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [git pull] drm fixes
On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote: On 03/26/2015 at 03:40 AM, Josh Boyer wrote: drm-Fixup-racy-refcounting-in-plane_force_disable.patch drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch and this patch: I hide the patch since it has been managled by Thunderbird. (BTW, who can tell me how to stop Thunderbird to replace Tabs to spaces?) which is a mash-up of: "drm/i915: Fix atomic state when reusing the firmware fb" and "drm/i915: Fixup legacy plane->crtc link for initial fb config" which you just sent out. I think that covers everything. josh I've got an HDMI device from the laboratory. I'll help to test the solution. I confirm that after applying those 3 patches, my machine boots fine mutiple times WITH OR WITHOUT HDMI plugged in and there is no WARNINGs about drm/i915 in kernel log. So I think these patches have successfully solved the problem, although maybe I am the one who makes some mistakes again.. -- Xi Ruoyao School of Aerospace Science and Technology Xidian University, Xi'an, China -- 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: [Intel-gfx] [git pull] drm fixes
On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote: On 03/26/2015 at 03:40 AM, Josh Boyer wrote: drm-Fixup-racy-refcounting-in-plane_force_disable.patch drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch and this patch: I hide the patch since it has been managled by Thunderbird. (BTW, who can tell me how to stop Thunderbird to replace Tabs to spaces?) which is a mash-up of: drm/i915: Fix atomic state when reusing the firmware fb and drm/i915: Fixup legacy plane-crtc link for initial fb config which you just sent out. I think that covers everything. josh I've got an HDMI device from the laboratory. I'll help to test the solution. I confirm that after applying those 3 patches, my machine boots fine mutiple times WITH OR WITHOUT HDMI plugged in and there is no WARNINGs about drm/i915 in kernel log. So I think these patches have successfully solved the problem, although maybe I am the one who makes some mistakes again.. -- Xi Ruoyao School of Aerospace Science and Technology Xidian University, Xi'an, China -- 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: [Intel-gfx] [git pull] drm fixes
On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote:
在 03/26/2015 03:40 AM, Josh Boyer 写道:
Sorry for these Chinese charactor. Thunderbird generated them
and I forgot to change.
On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
Yeah that fail looks like we're freeing an fb that's still in use.
Hilarity happens and since that happens under console_lock at
boot-up your
machine dies.
Does that machine die the same way in drm-intel-nightly/linux-next?
I'll try that a bit later today. Out of sheer curiosity, I folded
commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
update) into the patch above and kicked off a build. The theory is
that we're picking up a bunch of other changes right in that
range of
commits, why not try one more. I'll let you know if that fixes
anything. Otherwise, I'll try building drm-intel-nightly and/or
linux-next after that.
The drm-intel-nightly build finished first. It boots without HDMI
plugged in, but it has pretty much the same splats as the previous
kernel. Confused. Full log here:
https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
I don't have much hope for my other build.
Yeah that's at least good news for the theory I've been cooking
meanwhile.
Can you try the below diff (on top of next/nightly)? For the current
cherry-pick pile on top of 4.0-rc you'd need to prepend
intel_crtc->base.
to primary->...
Thanks, Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ceb2e61b4c91..cb508542c6ab 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
primary->fb = _config->fb->base;
primary->state->crtc = _crtc->base;
+ primary->crtc = _crtc->base;
update_state_fb(primary);
return;
@@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
drm_framebuffer_reference(c->primary->fb);
primary->fb = c->primary->fb;
primary->state->crtc = _crtc->base;
+ primary->crtc = _crtc->base;
update_state_fb(intel_crtc->base.primary);
obj->frontbuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
break;
Hey, that seems to do the trick on the NUC machine. Boots without
HDMI connected and there are no backtraces. Nice!
Let me go and munge it around for a backport on top of -rc5 with the
rest of the pile and see if both the macbook and NUC machines work
then. Will be a bit for it to build.
OK, that helped on all my machines I have. No backtraces and they all
boot again as I would expect. For the record, here is what I have on
top of -rc5:
drm-Fixup-racy-refcounting-in-plane_force_disable.patch
drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
and this patch:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 177714a9d778..778e7fa41c17 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+intel_crtc->base.primary->state->crtc = _crtc->base;
+intel_crtc->base.primary->crtc = _crtc->base;
update_state_fb(intel_crtc->base.primary);
return;
}
@@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
drm_framebuffer_reference(c->primary->fb);
intel_crtc->base.primary->fb = c->primary->fb;
+intel_crtc->base.primary->state->crtc = _crtc->base;
+intel_crtc->base.primary->crtc = _crtc->base;
obj->frontbuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
break;
}
which is a mash-up of:
"drm/i915: Fix atomic state when reusing the firmware fb"
and
"drm/i915: Fixup legacy plane->crtc link for initial fb config"
which you just sent out.
I think that covers everything.
josh
I've got an HDMI device from the laboratory. I'll help to test the
solution.
At least, my machine boots well and there is no WARNINGs
in kernel log. I will do more tests.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
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: [Intel-gfx] [git pull] drm fixes
在 03/26/2015 03:40 AM, Josh Boyer 写道:
On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
Yeah that fail looks like we're freeing an fb that's still in use.
Hilarity happens and since that happens under console_lock at boot-up your
machine dies.
Does that machine die the same way in drm-intel-nightly/linux-next?
I'll try that a bit later today. Out of sheer curiosity, I folded
commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
update) into the patch above and kicked off a build. The theory is
that we're picking up a bunch of other changes right in that range of
commits, why not try one more. I'll let you know if that fixes
anything. Otherwise, I'll try building drm-intel-nightly and/or
linux-next after that.
The drm-intel-nightly build finished first. It boots without HDMI
plugged in, but it has pretty much the same splats as the previous
kernel. Confused. Full log here:
https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
I don't have much hope for my other build.
Yeah that's at least good news for the theory I've been cooking meanwhile.
Can you try the below diff (on top of next/nightly)? For the current
cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
to primary->...
Thanks, Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ceb2e61b4c91..cb508542c6ab 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
primary->fb = _config->fb->base;
primary->state->crtc = _crtc->base;
+ primary->crtc = _crtc->base;
update_state_fb(primary);
return;
@@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
drm_framebuffer_reference(c->primary->fb);
primary->fb = c->primary->fb;
primary->state->crtc = _crtc->base;
+ primary->crtc = _crtc->base;
update_state_fb(intel_crtc->base.primary);
obj->frontbuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
break;
Hey, that seems to do the trick on the NUC machine. Boots without
HDMI connected and there are no backtraces. Nice!
Let me go and munge it around for a backport on top of -rc5 with the
rest of the pile and see if both the macbook and NUC machines work
then. Will be a bit for it to build.
OK, that helped on all my machines I have. No backtraces and they all
boot again as I would expect. For the record, here is what I have on
top of -rc5:
drm-Fixup-racy-refcounting-in-plane_force_disable.patch
drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
and this patch:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 177714a9d778..778e7fa41c17 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+ intel_crtc->base.primary->state->crtc = _crtc->base;
+ intel_crtc->base.primary->crtc = _crtc->base;
update_state_fb(intel_crtc->base.primary);
return;
}
@@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
drm_framebuffer_reference(c->primary->fb);
intel_crtc->base.primary->fb = c->primary->fb;
+ intel_crtc->base.primary->state->crtc =
_crtc->base;
+ intel_crtc->base.primary->crtc = _crtc->base;
obj->frontbuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
break;
}
which is a mash-up of:
"drm/i915: Fix atomic state when reusing the firmware fb"
and
"drm/i915: Fixup legacy plane->crtc link for initial fb config"
which you just sent out.
I think that covers everything.
josh
I've got an HDMI device from the laboratory. I'll help to test the solution.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
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: [Intel-gfx] [git pull] drm fixes
On 03/25/2015 at 10:56 PM, Xi Ruoyao wrote:
On 03/25/2015 at 10:00 PM, Daniel Vetter wrote:
On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter wrote:
commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
Author: Damien Lespiau
Date: Thu Feb 5 18:30:20 2015 +
drm/i915: Don't try to reference the fb in
get_initial_plane_config()
From linux-next?
Yes, building now. Will let you know as soon as I test it on
both machines.
OK, with that commit applied I no longer get the kref.h splat and the
NUC machine boots headless. I still see the backtrace below on both
the NUC and the macbook. I have a copy of it with drm.debug=0xff
from
the NUC here:
https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
Getting better at least :).
On top of what you currently have please also cherry-pick
commit fb9981aa675eb7b398849915364916fd98833cfa
Author: Damien Lespiau
Date: Thu Feb 5 19:24:25 2015 +
drm/i915: Fix atomic state when reusing the firmware fb
from -next. Let's hope this terminates eventually ;-)
Hm. That one doesn't apply cleanly. I think because it needs:
From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
From: Damien Lespiau
Date: Thu, 5 Feb 2015 17:22:18 +
Subject: drm/i915: Store the initial framebuffer in
initial_plane_config
first. Do you want me to grab both, or should I try and figure out
how to backport fb9981aa67 without it?
Oops missed that. The active ingredient is setting
crtc->primary->state->crtc like this:
-Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1c12262029fb..bfc14a6046ea 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+intel_crtc->base.primary->state->crtc = _crtc->base;
update_state_fb(intel_crtc->base.primary);
return;
}
@@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
drm_framebuffer_reference(c->primary->fb);
intel_crtc->base.primary->fb = c->primary->fb;
+intel_crtc->base.primary->state->crtc = _crtc->base;
obj->frontbuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
break;
}
I found a bad thing. My buggy code also affects linux-next now because of
the manual merge on 2014-03-16.
So, Daniel and Stephen please check it and end this mess...
I reviewed linux-next. Stephen has dealed with it correctly.
It's annoying to see my code caused so much trouble. I didn't test my
code
with a HDMI device or I should've found this trouble before commiting. I
apologize for that again.
I am very upset because of my error now (>_<). I think the only thing I can
help now is view linux-next and find all commits about my 319c1d420a0b,
since my commit is a cheery-picking from linux-next.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
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: [Intel-gfx] [git pull] drm fixes
On 03/25/2015 at 10:00 PM, Daniel Vetter wrote:
On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter wrote:
commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
Author: Damien Lespiau
Date: Thu Feb 5 18:30:20 2015 +
drm/i915: Don't try to reference the fb in get_initial_plane_config()
From linux-next?
Yes, building now. Will let you know as soon as I test it on both machines.
OK, with that commit applied I no longer get the kref.h splat and the
NUC machine boots headless. I still see the backtrace below on both
the NUC and the macbook. I have a copy of it with drm.debug=0xff from
the NUC here:
https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
Getting better at least :).
On top of what you currently have please also cherry-pick
commit fb9981aa675eb7b398849915364916fd98833cfa
Author: Damien Lespiau
Date: Thu Feb 5 19:24:25 2015 +
drm/i915: Fix atomic state when reusing the firmware fb
from -next. Let's hope this terminates eventually ;-)
Hm. That one doesn't apply cleanly. I think because it needs:
From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
From: Damien Lespiau
Date: Thu, 5 Feb 2015 17:22:18 +
Subject: drm/i915: Store the initial framebuffer in initial_plane_config
first. Do you want me to grab both, or should I try and figure out
how to backport fb9981aa67 without it?
Oops missed that. The active ingredient is setting crtc->primary->state->crtc
like this:
-Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1c12262029fb..bfc14a6046ea 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+ intel_crtc->base.primary->state->crtc = _crtc->base;
update_state_fb(intel_crtc->base.primary);
return;
}
@@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
drm_framebuffer_reference(c->primary->fb);
intel_crtc->base.primary->fb = c->primary->fb;
+ intel_crtc->base.primary->state->crtc =
_crtc->base;
obj->frontbuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
break;
}
I found a bad thing. My buggy code also affects linux-next now because of
the manual merge on 2014-03-16.
So, Daniel and Stephen please check it and end this mess...
It's annoying to see my code caused so much trouble. I didn't test my code
with a HDMI device or I should've found this trouble before commiting. I
apologize for that again.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
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: [Intel-gfx] [git pull] drm fixes
On 03/25/2015 at 10:56 PM, Xi Ruoyao wrote:
On 03/25/2015 at 10:00 PM, Daniel Vetter wrote:
On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
Author: Damien Lespiau damien.lesp...@intel.com
Date: Thu Feb 5 18:30:20 2015 +
drm/i915: Don't try to reference the fb in
get_initial_plane_config()
From linux-next?
Yes, building now. Will let you know as soon as I test it on
both machines.
OK, with that commit applied I no longer get the kref.h splat and the
NUC machine boots headless. I still see the backtrace below on both
the NUC and the macbook. I have a copy of it with drm.debug=0xff
from
the NUC here:
https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
Getting better at least :).
On top of what you currently have please also cherry-pick
commit fb9981aa675eb7b398849915364916fd98833cfa
Author: Damien Lespiau damien.lesp...@intel.com
Date: Thu Feb 5 19:24:25 2015 +
drm/i915: Fix atomic state when reusing the firmware fb
from -next. Let's hope this terminates eventually ;-)
Hm. That one doesn't apply cleanly. I think because it needs:
From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
From: Damien Lespiau damien.lesp...@intel.com
Date: Thu, 5 Feb 2015 17:22:18 +
Subject: drm/i915: Store the initial framebuffer in
initial_plane_config
first. Do you want me to grab both, or should I try and figure out
how to backport fb9981aa67 without it?
Oops missed that. The active ingredient is setting
crtc-primary-state-crtc like this:
-Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1c12262029fb..bfc14a6046ea 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+intel_crtc-base.primary-state-crtc = intel_crtc-base;
update_state_fb(intel_crtc-base.primary);
return;
}
@@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
drm_framebuffer_reference(c-primary-fb);
intel_crtc-base.primary-fb = c-primary-fb;
+intel_crtc-base.primary-state-crtc = intel_crtc-base;
obj-frontbuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
break;
}
I found a bad thing. My buggy code also affects linux-next now because of
the manual merge on 2014-03-16.
So, Daniel and Stephen please check it and end this mess...
I reviewed linux-next. Stephen has dealed with it correctly.
It's annoying to see my code caused so much trouble. I didn't test my
code
with a HDMI device or I should've found this trouble before commiting. I
apologize for that again.
I am very upset because of my error now (_). I think the only thing I can
help now is view linux-next and find all commits about my 319c1d420a0b,
since my commit is a cheery-picking from linux-next.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
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: [Intel-gfx] [git pull] drm fixes
On 03/25/2015 at 10:00 PM, Daniel Vetter wrote:
On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
Author: Damien Lespiau damien.lesp...@intel.com
Date: Thu Feb 5 18:30:20 2015 +
drm/i915: Don't try to reference the fb in get_initial_plane_config()
From linux-next?
Yes, building now. Will let you know as soon as I test it on both machines.
OK, with that commit applied I no longer get the kref.h splat and the
NUC machine boots headless. I still see the backtrace below on both
the NUC and the macbook. I have a copy of it with drm.debug=0xff from
the NUC here:
https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
Getting better at least :).
On top of what you currently have please also cherry-pick
commit fb9981aa675eb7b398849915364916fd98833cfa
Author: Damien Lespiau damien.lesp...@intel.com
Date: Thu Feb 5 19:24:25 2015 +
drm/i915: Fix atomic state when reusing the firmware fb
from -next. Let's hope this terminates eventually ;-)
Hm. That one doesn't apply cleanly. I think because it needs:
From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
From: Damien Lespiau damien.lesp...@intel.com
Date: Thu, 5 Feb 2015 17:22:18 +
Subject: drm/i915: Store the initial framebuffer in initial_plane_config
first. Do you want me to grab both, or should I try and figure out
how to backport fb9981aa67 without it?
Oops missed that. The active ingredient is setting crtc-primary-state-crtc
like this:
-Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1c12262029fb..bfc14a6046ea 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+ intel_crtc-base.primary-state-crtc = intel_crtc-base;
update_state_fb(intel_crtc-base.primary);
return;
}
@@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
drm_framebuffer_reference(c-primary-fb);
intel_crtc-base.primary-fb = c-primary-fb;
+ intel_crtc-base.primary-state-crtc =
intel_crtc-base;
obj-frontbuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
break;
}
I found a bad thing. My buggy code also affects linux-next now because of
the manual merge on 2014-03-16.
So, Daniel and Stephen please check it and end this mess...
It's annoying to see my code caused so much trouble. I didn't test my code
with a HDMI device or I should've found this trouble before commiting. I
apologize for that again.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
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: [Intel-gfx] [git pull] drm fixes
On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote:
在 03/26/2015 03:40 AM, Josh Boyer 写道:
Sorry for these Chinese charactor. Thunderbird generated them
and I forgot to change.
On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
Yeah that fail looks like we're freeing an fb that's still in use.
Hilarity happens and since that happens under console_lock at
boot-up your
machine dies.
Does that machine die the same way in drm-intel-nightly/linux-next?
I'll try that a bit later today. Out of sheer curiosity, I folded
commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
update) into the patch above and kicked off a build. The theory is
that we're picking up a bunch of other changes right in that
range of
commits, why not try one more. I'll let you know if that fixes
anything. Otherwise, I'll try building drm-intel-nightly and/or
linux-next after that.
The drm-intel-nightly build finished first. It boots without HDMI
plugged in, but it has pretty much the same splats as the previous
kernel. Confused. Full log here:
https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
I don't have much hope for my other build.
Yeah that's at least good news for the theory I've been cooking
meanwhile.
Can you try the below diff (on top of next/nightly)? For the current
cherry-pick pile on top of 4.0-rc you'd need to prepend
intel_crtc-base.
to primary-...
Thanks, Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ceb2e61b4c91..cb508542c6ab 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
primary-fb = plane_config-fb-base;
primary-state-crtc = intel_crtc-base;
+ primary-crtc = intel_crtc-base;
update_state_fb(primary);
return;
@@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
drm_framebuffer_reference(c-primary-fb);
primary-fb = c-primary-fb;
primary-state-crtc = intel_crtc-base;
+ primary-crtc = intel_crtc-base;
update_state_fb(intel_crtc-base.primary);
obj-frontbuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
break;
Hey, that seems to do the trick on the NUC machine. Boots without
HDMI connected and there are no backtraces. Nice!
Let me go and munge it around for a backport on top of -rc5 with the
rest of the pile and see if both the macbook and NUC machines work
then. Will be a bit for it to build.
OK, that helped on all my machines I have. No backtraces and they all
boot again as I would expect. For the record, here is what I have on
top of -rc5:
drm-Fixup-racy-refcounting-in-plane_force_disable.patch
drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
and this patch:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 177714a9d778..778e7fa41c17 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+intel_crtc-base.primary-state-crtc = intel_crtc-base;
+intel_crtc-base.primary-crtc = intel_crtc-base;
update_state_fb(intel_crtc-base.primary);
return;
}
@@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
drm_framebuffer_reference(c-primary-fb);
intel_crtc-base.primary-fb = c-primary-fb;
+intel_crtc-base.primary-state-crtc = intel_crtc-base;
+intel_crtc-base.primary-crtc = intel_crtc-base;
obj-frontbuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
break;
}
which is a mash-up of:
drm/i915: Fix atomic state when reusing the firmware fb
and
drm/i915: Fixup legacy plane-crtc link for initial fb config
which you just sent out.
I think that covers everything.
josh
I've got an HDMI device from the laboratory. I'll help to test the
solution.
At least, my machine boots well and there is no WARNINGs
in kernel log. I will do more tests.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
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: [Intel-gfx] [git pull] drm fixes
在 03/26/2015 03:40 AM, Josh Boyer 写道:
On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
Yeah that fail looks like we're freeing an fb that's still in use.
Hilarity happens and since that happens under console_lock at boot-up your
machine dies.
Does that machine die the same way in drm-intel-nightly/linux-next?
I'll try that a bit later today. Out of sheer curiosity, I folded
commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
update) into the patch above and kicked off a build. The theory is
that we're picking up a bunch of other changes right in that range of
commits, why not try one more. I'll let you know if that fixes
anything. Otherwise, I'll try building drm-intel-nightly and/or
linux-next after that.
The drm-intel-nightly build finished first. It boots without HDMI
plugged in, but it has pretty much the same splats as the previous
kernel. Confused. Full log here:
https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
I don't have much hope for my other build.
Yeah that's at least good news for the theory I've been cooking meanwhile.
Can you try the below diff (on top of next/nightly)? For the current
cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc-base.
to primary-...
Thanks, Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ceb2e61b4c91..cb508542c6ab 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
primary-fb = plane_config-fb-base;
primary-state-crtc = intel_crtc-base;
+ primary-crtc = intel_crtc-base;
update_state_fb(primary);
return;
@@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
drm_framebuffer_reference(c-primary-fb);
primary-fb = c-primary-fb;
primary-state-crtc = intel_crtc-base;
+ primary-crtc = intel_crtc-base;
update_state_fb(intel_crtc-base.primary);
obj-frontbuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
break;
Hey, that seems to do the trick on the NUC machine. Boots without
HDMI connected and there are no backtraces. Nice!
Let me go and munge it around for a backport on top of -rc5 with the
rest of the pile and see if both the macbook and NUC machines work
then. Will be a bit for it to build.
OK, that helped on all my machines I have. No backtraces and they all
boot again as I would expect. For the record, here is what I have on
top of -rc5:
drm-Fixup-racy-refcounting-in-plane_force_disable.patch
drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
and this patch:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 177714a9d778..778e7fa41c17 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+ intel_crtc-base.primary-state-crtc = intel_crtc-base;
+ intel_crtc-base.primary-crtc = intel_crtc-base;
update_state_fb(intel_crtc-base.primary);
return;
}
@@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
drm_framebuffer_reference(c-primary-fb);
intel_crtc-base.primary-fb = c-primary-fb;
+ intel_crtc-base.primary-state-crtc =
intel_crtc-base;
+ intel_crtc-base.primary-crtc = intel_crtc-base;
obj-frontbuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
break;
}
which is a mash-up of:
drm/i915: Fix atomic state when reusing the firmware fb
and
drm/i915: Fixup legacy plane-crtc link for initial fb config
which you just sent out.
I think that covers everything.
josh
I've got an HDMI device from the laboratory. I'll help to test the solution.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
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: [Intel-gfx] [git pull] drm fixes
On 03/25/2015 at 12:54 AM, Josh Boyer wrote: On Tue, Mar 24, 2015 at 12:49 PM, Daniel Vetter wrote: On Tue, Mar 24, 2015 at 05:48:31PM +0100, Daniel Vetter wrote: On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote: On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer wrote: On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter wrote: On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote: On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer wrote: On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter wrote: On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote: On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter wrote: On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote: On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer wrote: Xi Ruoyao (1): drm/i915: Ensure plane->state->fb stays in sync with plane->fb Turns out to be that commit. git bisect start 'drivers/gpu/drm/i915/' # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344 # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5 git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6 # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure plane->state->fb stays in sync with plane->fb git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure plane->state->fb stays in sync with plane->fb Doing a straight revert on top of 4.0-rc5 makes things work again, albeit with the WARN_ON(obj->frontbuffer_bits) splat still being there. Can you please test the tip of drm-fixes: commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1 Author: Daniel Vetter Date: Fri Feb 27 12:58:13 2015 +0100 drm: Fixup racy refcounting in plane_force_disable http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=8218c3f4df3bb1c637c17552405039a6dd3c1ee1 Because fumble that patch didn't make it to drm-fixes a while ago and instead landed in drm-next. That seems to have helped with totally different issues a macbook I have was seeing. However, it still doesn't fix the issue with the Celeron based NUC machine. I built a kernel based on Linus' latest tree as of this morning, without reverting 319c1d4 and adding the commit you pointed to. The NUC still won't boot without HDMI connected. With HDMI connected I still see the trace below. If I do the blacklist and then insmod dance with HDMI unplugged it shows the same spew I reported yesterday which starts with the same backtrace. I'll try building a kernel with 319c1d4 reverted + your patch. I suspect things will work fine with that combination because the two issues are unrelated. Can you please boot with drm.debug=0xff for the below case and grab complete dmesg? There'll be a lot of crap in the logs, you might need to blow up the logbuf size massively. But that log should contain everything I need to figure out where that framebuffer we're blowing up on is going. I provided both with HDMI attached and without (via insmod). If you want them emailed directly let me know, but they were large. Boot with drm.debug=0xff and HDMI connected: https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt Boot with drm.debug=0xff without HDMI connected and i915 loaded via manual insmod after boot: https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt Here's one more from the macbook I mentioned. It's showing the same kref.h splat: https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt Ok there's at least one fixup for which we've failed to apply when porting the fb refcounting fix from -next. Can you please cherry-pick commit f55548b5af87ebfc586ca75748947f1c1b1a4a52 Author: Damien Lespiau Date: Thu Feb 5 18:30:20 2015 + drm/i915: Don't try to reference the fb in get_initial_plane_config() From linux-next? Yes, building now. Will let you know as soon as I test it on both machines. OK, with that commit applied I no longer get the kref.h splat and the NUC machine boots headless. I still see the backtrace below on both the NUC and the macbook. I have a copy of it with drm.debug=0xff from the NUC here: https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt Getting better at least :). Ok thanks for testing. I'll look at that one tomorrow, wasted too much time with trying to resurrect a few machines that should have matched the common parts of what goes wrong here. Jani, can you please cherry-pick the above commit to -fixes? Actually add Jani this time around ... -Daniel One more question: Is the frontbuffer_bits splat now also gone? That was the one I have no clue about, but since somewhere around 4.0-rc it started poppping up in a few places ... Thus far it was always the canary for some other bug though. As far as I can tell, it's gone. I don't see it on any of my i915 machines running the kernel
Re: [Intel-gfx] [git pull] drm fixes
On 03/25/2015 at 12:54 AM, Josh Boyer wrote: On Tue, Mar 24, 2015 at 12:49 PM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Mar 24, 2015 at 05:48:31PM +0100, Daniel Vetter wrote: On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote: On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer jwbo...@fedoraproject.org wrote: On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote: On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer jwbo...@fedoraproject.org wrote: On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote: On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote: On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer jwbo...@fedoraproject.org wrote: snip Xi Ruoyao (1): drm/i915: Ensure plane-state-fb stays in sync with plane-fb Turns out to be that commit. git bisect start 'drivers/gpu/drm/i915/' # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344 # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5 git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6 # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure plane-state-fb stays in sync with plane-fb git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure plane-state-fb stays in sync with plane-fb Doing a straight revert on top of 4.0-rc5 makes things work again, albeit with the WARN_ON(obj-frontbuffer_bits) splat still being there. Can you please test the tip of drm-fixes: commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Fri Feb 27 12:58:13 2015 +0100 drm: Fixup racy refcounting in plane_force_disable http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixesid=8218c3f4df3bb1c637c17552405039a6dd3c1ee1 Because fumble that patch didn't make it to drm-fixes a while ago and instead landed in drm-next. That seems to have helped with totally different issues a macbook I have was seeing. However, it still doesn't fix the issue with the Celeron based NUC machine. I built a kernel based on Linus' latest tree as of this morning, without reverting 319c1d4 and adding the commit you pointed to. The NUC still won't boot without HDMI connected. With HDMI connected I still see the trace below. If I do the blacklist and then insmod dance with HDMI unplugged it shows the same spew I reported yesterday which starts with the same backtrace. I'll try building a kernel with 319c1d4 reverted + your patch. I suspect things will work fine with that combination because the two issues are unrelated. Can you please boot with drm.debug=0xff for the below case and grab complete dmesg? There'll be a lot of crap in the logs, you might need to blow up the logbuf size massively. But that log should contain everything I need to figure out where that framebuffer we're blowing up on is going. I provided both with HDMI attached and without (via insmod). If you want them emailed directly let me know, but they were large. Boot with drm.debug=0xff and HDMI connected: https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt Boot with drm.debug=0xff without HDMI connected and i915 loaded via manual insmod after boot: https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt Here's one more from the macbook I mentioned. It's showing the same kref.h splat: https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt Ok there's at least one fixup for which we've failed to apply when porting the fb refcounting fix from -next. Can you please cherry-pick commit f55548b5af87ebfc586ca75748947f1c1b1a4a52 Author: Damien Lespiau damien.lesp...@intel.com Date: Thu Feb 5 18:30:20 2015 + drm/i915: Don't try to reference the fb in get_initial_plane_config() From linux-next? Yes, building now. Will let you know as soon as I test it on both machines. OK, with that commit applied I no longer get the kref.h splat and the NUC machine boots headless. I still see the backtrace below on both the NUC and the macbook. I have a copy of it with drm.debug=0xff from the NUC here: https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt Getting better at least :). Ok thanks for testing. I'll look at that one tomorrow, wasted too much time with trying to resurrect a few machines that should have matched the common parts of what goes wrong here. Jani, can you please cherry-pick the above commit to -fixes? Actually add Jani this time around ... -Daniel One more question: Is the frontbuffer_bits splat now also gone? That was the one I have no clue about, but since somewhere around 4.0-rc it started poppping up in a few places ... Thus far
Re: linux-next: manual merge of the drm tree with the drm-intel-fixes tree
On 03/16/2015 at 10:30 AM, Stephen Rothwell wrote:
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit 2dccc9898d45
("drm/i915: Ensure plane->state->fb stays in sync with plane->fb") from
the drm-intel-fixes tree and commit afd65eb4cc05 ("drm/i915: Ensure
plane->state->fb stays in sync with plane->fb"), f55548b5af87
("drm/i915: Don't try to reference the fb in
get_initial_plane_config()") and presumably others from the drm tree.
Same patch summary, different authors, committers and added function.
I fixed it up (I effectively used the drm tree version) and can carry
the fix as necessary (no action is required).
My patch with commit 2dccc9898d45 is for Linux 4.0-rcN. It has no
relationship
with linux-next since Matt Roper's afd65eb4cc05 has solved this long
long ago.
So, 2dccc9898d45 should not be tagged with for-linux-next-fixes (in
repository
http://cgit.freedesktop.org/drm-intel/). I think it caused the mess of
version
control.
BTW, there is still one thing should be done in linux-next. We should
change
Matt's update_state_fb to use drm_atomic_set_fb_for_plane since the logic of
Matt's code is duplicated with drm_atomic_set_fb_for_plane.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
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: linux-next: manual merge of the drm tree with the drm-intel-fixes tree
On 03/16/2015 at 10:30 AM, Stephen Rothwell wrote: Hi Dave, Today's linux-next merge of the drm tree got a conflict in drivers/gpu/drm/i915/intel_display.c between commit 2dccc9898d45 (drm/i915: Ensure plane-state-fb stays in sync with plane-fb) from the drm-intel-fixes tree and commit afd65eb4cc05 (drm/i915: Ensure plane-state-fb stays in sync with plane-fb), f55548b5af87 (drm/i915: Don't try to reference the fb in get_initial_plane_config()) and presumably others from the drm tree. Same patch summary, different authors, committers and added function. I fixed it up (I effectively used the drm tree version) and can carry the fix as necessary (no action is required). My patch with commit 2dccc9898d45 is for Linux 4.0-rcN. It has no relationship with linux-next since Matt Roper's afd65eb4cc05 has solved this long long ago. So, 2dccc9898d45 should not be tagged with for-linux-next-fixes (in repository http://cgit.freedesktop.org/drm-intel/). I think it caused the mess of version control. BTW, there is still one thing should be done in linux-next. We should change Matt's update_state_fb to use drm_atomic_set_fb_for_plane since the logic of Matt's code is duplicated with drm_atomic_set_fb_for_plane. -- Xi Ruoyao School of Aerospace Science and Technology Xidian University, Xi'an, China -- 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 v2] drm/i915: Fix BUG in i915_gem.c when switch to console
On 03/12/2015 04:28 PM, Jani Nikula wrote: On Thu, 12 Mar 2015, Xi Ruoyao wrote: In intel_crtc_page_flip, intel_display.c, the code changed the framebuffer assigned to plane crtc->primary by crtc->primary->fb = fb; However, it forgot to change crtc->primary->state->fb. However, when we switch to console, some kernel code will read crtc->primary->state->fb to get the framebuffer assigned to crtc->primaty. Then a framebuffer object can be unpinned twice and a kernel BUG will be produced in i915_gem.c. So, update crtc->primary->state->fb in intel_display.c using drm_atomic_set_fb_for_plane to fix the BUG. Signed-off-by: Xi Ruoyao Fixed: Bug 93711 <https://bugzilla.kernel.org/show_bug.cgi?id=93711> Is this a problem with drm-intel-nightly? In particular see commit afd65eb4cc0578a9c07d621acdb8a570e2782bf7 Author: Matt Roper Date: Tue Feb 3 13:10:04 2015 -0800 drm/i915: Ensure plane->state->fb stays in sync with plane->fb Matt, do you think this fixes the described issue? Can we backport to drm-intel-fixes (and v4.0)? BR, Jani. --- Sorry, the previous patch is mangled by email client, so I am re-sending it. drivers/gpu/drm/i915/intel_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e730789..97083fd 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -37,6 +37,7 @@ #include #include "i915_drv.h" #include "i915_trace.h" +#include #include #include #include @@ -9816,6 +9817,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, drm_gem_object_reference(>base); crtc->primary->fb = fb; + drm_atomic_set_fb_for_plane(crtc->primary->state, fb); work->pending_flip_obj = obj; -- 1.9.1 Thank you to read my patch. Matt's patch is better than mine since it fixed more conditions causing the unsynchronize of plane->fb and plane->fb. But unfortunately, it cannot be applied to mainline kernel (Linux 4.0.0-rc3) directly. I'll try to apply Matt's changes to the mainline kernel. -- 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 v2] drm/i915: Fix BUG in i915_gem.c when switch to console
In intel_crtc_page_flip, intel_display.c, the code changed the framebuffer assigned to plane crtc->primary by crtc->primary->fb = fb; However, it forgot to change crtc->primary->state->fb. However, when we switch to console, some kernel code will read crtc->primary->state->fb to get the framebuffer assigned to crtc->primaty. Then a framebuffer object can be unpinned twice and a kernel BUG will be produced in i915_gem.c. So, update crtc->primary->state->fb in intel_display.c using drm_atomic_set_fb_for_plane to fix the BUG. Signed-off-by: Xi Ruoyao Fixed: Bug 93711 <https://bugzilla.kernel.org/show_bug.cgi?id=93711> --- Sorry, the previous patch is mangled by email client, so I am re-sending it. drivers/gpu/drm/i915/intel_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e730789..97083fd 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -37,6 +37,7 @@ #include #include "i915_drv.h" #include "i915_trace.h" +#include #include #include #include @@ -9816,6 +9817,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, drm_gem_object_reference(>base); crtc->primary->fb = fb; + drm_atomic_set_fb_for_plane(crtc->primary->state, fb); work->pending_flip_obj = obj; -- 1.9.1 -- 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 v2] drm/i915: Fix BUG in i915_gem.c when switch to console
On 03/12/2015 04:28 PM, Jani Nikula wrote: On Thu, 12 Mar 2015, Xi Ruoyao xry...@outlook.com wrote: In intel_crtc_page_flip, intel_display.c, the code changed the framebuffer assigned to plane crtc-primary by crtc-primary-fb = fb; However, it forgot to change crtc-primary-state-fb. However, when we switch to console, some kernel code will read crtc-primary-state-fb to get the framebuffer assigned to crtc-primaty. Then a framebuffer object can be unpinned twice and a kernel BUG will be produced in i915_gem.c. So, update crtc-primary-state-fb in intel_display.c using drm_atomic_set_fb_for_plane to fix the BUG. Signed-off-by: Xi Ruoyao xry...@outlook.com Fixed: Bug 93711 https://bugzilla.kernel.org/show_bug.cgi?id=93711 Is this a problem with drm-intel-nightly? In particular see commit afd65eb4cc0578a9c07d621acdb8a570e2782bf7 Author: Matt Roper matthew.d.ro...@intel.com Date: Tue Feb 3 13:10:04 2015 -0800 drm/i915: Ensure plane-state-fb stays in sync with plane-fb Matt, do you think this fixes the described issue? Can we backport to drm-intel-fixes (and v4.0)? BR, Jani. --- Sorry, the previous patch is mangled by email client, so I am re-sending it. drivers/gpu/drm/i915/intel_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e730789..97083fd 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -37,6 +37,7 @@ #include drm/i915_drm.h #include i915_drv.h #include i915_trace.h +#include drm/drm_atomic.h #include drm/drm_atomic_helper.h #include drm/drm_dp_helper.h #include drm/drm_crtc_helper.h @@ -9816,6 +9817,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, drm_gem_object_reference(obj-base); crtc-primary-fb = fb; + drm_atomic_set_fb_for_plane(crtc-primary-state, fb); work-pending_flip_obj = obj; -- 1.9.1 Thank you to read my patch. Matt's patch is better than mine since it fixed more conditions causing the unsynchronize of plane-fb and plane-fb. But unfortunately, it cannot be applied to mainline kernel (Linux 4.0.0-rc3) directly. I'll try to apply Matt's changes to the mainline kernel. -- 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 v2] drm/i915: Fix BUG in i915_gem.c when switch to console
In intel_crtc_page_flip, intel_display.c, the code changed the framebuffer assigned to plane crtc-primary by crtc-primary-fb = fb; However, it forgot to change crtc-primary-state-fb. However, when we switch to console, some kernel code will read crtc-primary-state-fb to get the framebuffer assigned to crtc-primaty. Then a framebuffer object can be unpinned twice and a kernel BUG will be produced in i915_gem.c. So, update crtc-primary-state-fb in intel_display.c using drm_atomic_set_fb_for_plane to fix the BUG. Signed-off-by: Xi Ruoyao xry...@outlook.com Fixed: Bug 93711 https://bugzilla.kernel.org/show_bug.cgi?id=93711 --- Sorry, the previous patch is mangled by email client, so I am re-sending it. drivers/gpu/drm/i915/intel_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e730789..97083fd 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -37,6 +37,7 @@ #include drm/i915_drm.h #include i915_drv.h #include i915_trace.h +#include drm/drm_atomic.h #include drm/drm_atomic_helper.h #include drm/drm_dp_helper.h #include drm/drm_crtc_helper.h @@ -9816,6 +9817,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, drm_gem_object_reference(obj-base); crtc-primary-fb = fb; + drm_atomic_set_fb_for_plane(crtc-primary-state, fb); work-pending_flip_obj = obj; -- 1.9.1 -- 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/1] drm/i915: Fix BUG in i915_gem.c when switch to console
In intel_crtc_page_flip, intel_display.c, the code changed the framebuffer assigned to plane crtc->primary by crtc->primary->fb = fb; However, it forgot to change crtc->primary->state->fb. However, when we switch to console, some kernel code will read crtc->primary->state->fb to get the framebuffer assigned to crtc->primaty. Then a framebuffer object can be unpinned twice and a kernel BUG will be produced in i915_gem.c. So, update crtc->primary->state->fb in intel_display.c using drm_atomic_set_fb_for_plane to fix the BUG. Signed-off-by: Xi Ruoyao --- drivers/gpu/drm/i915/intel_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e730789..97083fd 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -37,6 +37,7 @@ #include #include "i915_drv.h" #include "i915_trace.h" +#include #include #include #include @@ -9816,6 +9817,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, drm_gem_object_reference(>base); crtc->primary->fb = fb; +drm_atomic_set_fb_for_plane(crtc->primary->state, fb); work->pending_flip_obj = obj; -- 1.9.1 -- 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/1] drm/i915: Fix BUG in i915_gem.c when switch to console
In intel_crtc_page_flip, intel_display.c, the code changed the framebuffer assigned to plane crtc-primary by crtc-primary-fb = fb; However, it forgot to change crtc-primary-state-fb. However, when we switch to console, some kernel code will read crtc-primary-state-fb to get the framebuffer assigned to crtc-primaty. Then a framebuffer object can be unpinned twice and a kernel BUG will be produced in i915_gem.c. So, update crtc-primary-state-fb in intel_display.c using drm_atomic_set_fb_for_plane to fix the BUG. Signed-off-by: Xi Ruoyao xry...@outlook.com --- drivers/gpu/drm/i915/intel_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e730789..97083fd 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -37,6 +37,7 @@ #include drm/i915_drm.h #include i915_drv.h #include i915_trace.h +#include drm/drm_atomic.h #include drm/drm_atomic_helper.h #include drm/drm_dp_helper.h #include drm/drm_crtc_helper.h @@ -9816,6 +9817,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, drm_gem_object_reference(obj-base); crtc-primary-fb = fb; +drm_atomic_set_fb_for_plane(crtc-primary-state, fb); work-pending_flip_obj = obj; -- 1.9.1 -- 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/
