Re: BUG: sleeping function called from invalid context at drivers/gpu/drm/i915/gem/i915_gem_pages.c:526

2024-03-25 Thread Ville Syrjälä
On Mon, Mar 25, 2024 at 06:54:44PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 25, 2024 at 05:33:42PM +0100, Borislav Petkov wrote:
> > On Tue, Feb 27, 2024 at 12:58:08PM +0200, Jani Nikula wrote:
> > > Let's see what Ville says, but in the end bisection might be the
> > > quickest way to find the regression. Though I understand it can be
> > > tedious for you personally.
> > 
> > That still fires with 6.-9-rc1. Does Ville have any suggestions or
> > should I bisect?
> 
> Sorry, completely missed this. The culprit is going to be
> commit 1de63528e728 ("drm/i915: Perform vblank evasion around legacy
> cursor updates")

Hmm. Actually should be commit 0225a90981c8 ("drm/i915: Make
cursor plane registers unlocked") already.

Apprently I had CONFIG_DEBUG_ATOMIC_SLEEP=n in my config
for most of my old machines.

-- 
Ville Syrjälä
Intel


Re: BUG: sleeping function called from invalid context at drivers/gpu/drm/i915/gem/i915_gem_pages.c:526

2024-03-25 Thread Ville Syrjälä
On Mon, Mar 25, 2024 at 05:33:42PM +0100, Borislav Petkov wrote:
> On Tue, Feb 27, 2024 at 12:58:08PM +0200, Jani Nikula wrote:
> > Let's see what Ville says, but in the end bisection might be the
> > quickest way to find the regression. Though I understand it can be
> > tedious for you personally.
> 
> That still fires with 6.-9-rc1. Does Ville have any suggestions or
> should I bisect?

Sorry, completely missed this. The culprit is going to be
commit 1de63528e728 ("drm/i915: Perform vblank evasion around legacy
cursor updates")

I'll cook up a fix.

-- 
Ville Syrjälä
Intel


Re: BUG: sleeping function called from invalid context at drivers/gpu/drm/i915/gem/i915_gem_pages.c:526

2024-03-25 Thread Borislav Petkov
On Tue, Feb 27, 2024 at 12:58:08PM +0200, Jani Nikula wrote:
> Let's see what Ville says, but in the end bisection might be the
> quickest way to find the regression. Though I understand it can be
> tedious for you personally.

That still fires with 6.-9-rc1. Does Ville have any suggestions or
should I bisect?

Thx.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette


Re: BUG: sleeping function called from invalid context at drivers/gpu/drm/i915/gem/i915_gem_pages.c:526

2024-02-27 Thread Borislav Petkov
On Tue, Feb 27, 2024 at 12:58:08PM +0200, Jani Nikula wrote:
> Let's see what Ville says, but in the end bisection might be the
> quickest way to find the regression. Though I understand it can be
> tedious for you personally.

Ha, I can do it in parallel with the gazillion other things. :-)

It'll take a lot longer, though.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette


Re: BUG: sleeping function called from invalid context at drivers/gpu/drm/i915/gem/i915_gem_pages.c:526

2024-02-27 Thread Jani Nikula
On Tue, 27 Feb 2024, Borislav Petkov  wrote:
> On Tue, Feb 27, 2024 at 12:37:02PM +0200, Jani Nikula wrote:
>> Is this a recent regression?
>
> Yeah, no clue. Hadn't booted that machine since 6.7-rc1... I can bisect
> if you want me to.

Let's see what Ville says, but in the end bisection might be the
quickest way to find the regression. Though I understand it can be
tedious for you personally.

BR,
Jani.



-- 
Jani Nikula, Intel


Re: BUG: sleeping function called from invalid context at drivers/gpu/drm/i915/gem/i915_gem_pages.c:526

2024-02-27 Thread Borislav Petkov
On Tue, Feb 27, 2024 at 12:37:02PM +0200, Jani Nikula wrote:
> Is this a recent regression?

Yeah, no clue. Hadn't booted that machine since 6.7-rc1... I can bisect
if you want me to.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette


Re: BUG: sleeping function called from invalid context at drivers/gpu/drm/i915/gem/i915_gem_pages.c:526

2024-02-27 Thread Jani Nikula
On Tue, 27 Feb 2024, Borislav Petkov  wrote:
> Hi all,
>
> this lockdep splat at the end is from an old Atom 32-bit laptop with the
> latest Linus + tip lineup:

Is this a recent regression?

At a glance, I couldn't quite pinpoint the root cause. It depends on
cursor_needs_physical == true, which means quite a limited set of
platforms.

Ville probably has a better idea here.


BR,
Jani.

>
> [0.00] Linux version 6.8.0-rc6+ (boris@zn) (gcc (Debian 13.2.0-9) 
> 13.2.0, GNU ld (GNU Binutils for Debian) 2.41.50.20231227) #1 SMP 
> PREEMPT_DYNAMIC Tue Feb 27 10:43:15 CET 2024
> [0.00] Disabled fast string operations
> [0.00] BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
> [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0x3f375fff] usable
> [0.00] BIOS-e820: [mem 0x3f376000-0x3f3befff] reserved
> [0.00] BIOS-e820: [mem 0x3f3bf000-0x3f46cfff] usable
> [0.00] BIOS-e820: [mem 0x3f46d000-0x3f4befff] ACPI NVS
> [0.00] BIOS-e820: [mem 0x3f4bf000-0x3f4e] usable
> [0.00] BIOS-e820: [mem 0x3f4f-0x3f4fefff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0x3f4ff000-0x3f4f] usable
> [0.00] BIOS-e820: [mem 0x3f50-0x3fff] reserved
> [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
> [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
> [0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved
> [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
> [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
> [0.00] BIOS-e820: [mem 0xfff0-0x] reserved
> [0.00] printk: debug: ignoring loglevel setting.
> [0.00] Notice: NX (Execute Disable) protection missing in CPU!
> [0.00] APIC: Static calls initialized
> [0.00] SMBIOS 2.4 present.
> [0.00] DMI: Acer AOA150/, BIOS v0.3309 10/06/2008
> [0.00] tsc: Fast TSC calibration using PIT
> [0.00] tsc: Detected 1595.973 MHz processor
> [0.006006] e820: update [mem 0x-0x0fff] usable ==> reserved
> [0.006046] e820: remove [mem 0x000a-0x000f] usable
> [0.006089] last_pfn = 0x3f500 max_arch_pfn = 0x10
> [0.006112] MTRR map: 9 entries (5 fixed + 4 variable; max 21), built from 
> 8 variable MTRRs
> [0.006125] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
> [0.006307] initial memory mapped: [mem 0x-0x033f]
> [0.006444] RAMDISK: [mem 0x36eeb000-0x3776cfff]
> [0.006458] Allocated new RAMDISK: [mem 0x36669000-0x36eea545]
> [0.017353] Move RAMDISK from [mem 0x36eeb000-0x3776c545] to [mem 
> 0x36669000-0x36eea545]
> [0.017396] ACPI: Early table checksum verification disabled
> [0.017418] ACPI: RSDP 0x000FE020 24 (v02 ACRSYS)
> [0.017452] ACPI: XSDT 0x3F4FE120 64 (v01 ACRSYS ACRPRDCT 
> 0001  0113)
> [0.017489] ACPI: FACP 0x3F4FC000 F4 (v04 ACRSYS ACRPRDCT 
> 0001 1025 0113)
> [0.017526] ACPI: DSDT 0x3F4F2000 005DE6 (v01 ACRSYS ACRPRDCT 
> 0001 1025 0113)
> [0.017557] ACPI: FACS 0x3F488000 40
> [0.017584] ACPI: FACS 0x3F488000 40
> [0.017611] ACPI: SSDT 0x3F4FD000 0004C4 (v02 PmRef  CpuPm
> 3000 INTL 20051117)
> [0.017643] ACPI: HPET 0x3F4FB000 38 (v01 ACRSYS ACRPRDCT 
> 0001 1025 0113)
> [0.017672] ACPI: APIC 0x3F4FA000 68 (v02 ACRSYS ACRPRDCT 
> 0001 1025 0113)
> [0.017702] ACPI: MCFG 0x3F4F9000 3C (v01 ACRSYS ACRPRDCT 
> 0001 1025 0113)
> [0.017731] ACPI: ASF! 0x3F4F8000 A5 (v32 ACRSYS ACRPRDCT 
> 0001 1025 0113)
> [0.017761] ACPI: SLIC 0x3F4F1000 000176 (v01 ACRSYS ACRPRDCT 
> 0001 1025 0113)
> [0.017790] ACPI: BOOT 0x3F4F 28 (v01 ACRSYS ACRPRDCT 
> 0001 1025 0113)
> [0.017818] ACPI: Reserving FACP table memory at [mem 
> 0x3f4fc000-0x3f4fc0f3]
> [0.017830] ACPI: Reserving DSDT table memory at [mem 
> 0x3f4f2000-0x3f4f7de5]
> [0.017840] ACPI: Reserving FACS table memory at [mem 
> 0x3f488000-0x3f48803f]
> [0.017850] ACPI: Reserving FACS table memory at [mem 
> 0x3f488000-0x3f48803f]
> [0.017860] ACPI: Reserving SSDT table memory at [mem 
> 0x3f4fd000-0x3f4fd4c3]
> [0.017870] ACPI: Reserving HPET table memory at [mem 
> 0x3f4fb000-0x3f4fb037]
> [0.017880] ACPI: Reserving APIC table memory at [mem 
> 0x3f4fa000-0x3f4fa067]
> [0.017890] ACPI: Reserving