[PULL] remove drm_sman and some i815 fixes
On Fri, Dec 23, 2011 at 03:36:25PM +, James Simmons wrote: > > > > > > Last attempt at your branch still had problem. Start I didn't have > > > > > time > > > > > track down the exact issue. I'm cloning the below branch and will > > > > > test it. > > > > > Thanks for cleanup. > > > > > > > > Jakob Bornecrantz quickly tested my attempt at fixing the deadlock > > > > you've > > > > reported and noticed that the X server fails to start up (and that the > > > > kernel hangs). Is that the same you're seeing? > > > > > > What was just merged to drm-next works fine. Its the reclaim buffer > > > patches that cause the problem. In my case the X server starts but I get > > > a blank screen. I have full debug on so this is what happens. > > > > Thanks for testing and gathering the logs. > > > > Judging from the dmesg you've attached the via driver opens and closes the > > via drm node at least twice while starting X. Which explains why things > > blow up for you and Jakob already at startup. But ... > > > Can you please retest with that and again grab the dmesg with full > > logging? Jakob reported that this still blows up, so there's a problem > > left somewhere. But I've rechecked the patches and couldn't see it. > > Done. Using your latest branch. Ok, I've noticed another problem that might or might not be the issue here. Updated my kill-with-fire branch. Direct link to the new patch: http://cgit.freedesktop.org/~danvet/drm/patch/?id=b22d66d226aeb22371175b7f7d69b408bc4c1ef7 Thanks a lot for testing all this crap. Cheers, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PULL] remove drm_sman and some i815 fixes
> > > > Last attempt at your branch still had problem. Start I didn't have time > > > > track down the exact issue. I'm cloning the below branch and will test > > > > it. > > > > Thanks for cleanup. > > > > > > Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've > > > reported and noticed that the X server fails to start up (and that the > > > kernel hangs). Is that the same you're seeing? > > > > What was just merged to drm-next works fine. Its the reclaim buffer > > patches that cause the problem. In my case the X server starts but I get > > a blank screen. I have full debug on so this is what happens. > > Thanks for testing and gathering the logs. > > Judging from the dmesg you've attached the via driver opens and closes the > via drm node at least twice while starting X. Which explains why things > blow up for you and Jakob already at startup. But ... > Can you please retest with that and again grab the dmesg with full > logging? Jakob reported that this still blows up, so there's a problem > left somewhere. But I've rechecked the patches and couldn't see it. Done. Using your latest branch. Initializing cgroup subsys cpu Linux version 3.2.0-rc6-openchrome+ (jsimmons at debian) (gcc version 4.6.2 (Debian 4.6.2-7) ) #42 SMP Fri Dec 23 10:16:38 EST 2011 Command line: BOOT_IMAGE=/boot/vmlinuz-test root=UUID=2539cb3b-47b9-47fc-81c1-97dabc51b2b2 ro drm.debug=255 BIOS-provided physical RAM map: BIOS-e820: - 0009f400 (usable) BIOS-e820: 0009f400 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 7bef (usable) BIOS-e820: 7bef - 7bef3000 (ACPI NVS) BIOS-e820: 7bef3000 - 7bf0 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) NX (Execute Disable) protection: active DMI 2.3 present. DMI: MICRO-STAR INTERNATIONAL CO., LTD MS-7312/MS-7312, BIOS V1.2 01/25/2007 e820 update range: - 0001 (usable) ==> (reserved) e820 remove range: 000a - 0010 (usable) AGP bridge at 00:00:00 Aperture from AGP @ e800 old size 32 MB Aperture from AGP @ e800 size 128 MB (APSIZE f20) last_pfn = 0x7bef0 max_arch_pfn = 0x4 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-B uncachable C-C7FFF write-protect C8000-CBFFF uncachable CC000-D3FFF write-back D4000-F uncachable MTRR variable ranges enabled: 0 base 00 mask FFC000 write-back 1 base 004000 mask FFE000 write-back 2 base 006000 mask FFF000 write-back 3 base 007000 mask FFF800 write-back 4 base 007800 mask FFFC00 write-back 5 base 007BF0 mask F0 uncachable 6 base 00E800 mask FFF800 write-combining 7 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 initial memory mapped : 0 - 2000 Base memory trampoline at [8809d000] 9d000 size 8192 init_memory_mapping: -7bef 00 - 007be0 page 2M 007be0 - 007bef page 4k kernel direct mapping tables up to 7bef @ 1fffc000-2000 RAMDISK: 37aba000 - 37d55000 ACPI: RSDP 000f78c0 00014 (v00 VIAK8M) ACPI: RSDT 7bef3040 0002C (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: FACP 7bef30c0 00074 (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: DSDT 7bef3180 05396 (v01 VIAK8M AWRDACPI 1000 MSFT 010E) ACPI: FACS 7bef 00040 ACPI: APIC 7bef8580 00068 (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: Local APIC address 0xfee0 [ea00-ea0001bf] PMD -> [88007960-88007b1f] on node 0 Zone PFN ranges: DMA 0x0010 -> 0x1000 DMA320x1000 -> 0x0010 Normal empty Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x0010 -> 0x009f 0: 0x0100 -> 0x0007bef0 On node 0 totalpages: 507519 DMA zone: 56 pages used for memmap DMA zone: 2 pages reserved DMA zone: 3925 pages, LIFO batch:0 DMA32 zone: 6885 pages used for memmap DMA32 zone: 496651 pages, LIFO batch:31 Detected use of extended apic ids on hypertransport bus ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information SMP: Allowing 2 CPUs, 0 hotplug CPUs
[PULL] remove drm_sman and some i815 fixes
On Thu, Dec 22, 2011 at 11:22:00PM +, James Simmons wrote:
>
> > > > Hi Dave,
> > > >
> > > > I've failed to correctly fix the via hang in the reclaim buffers rework
> > > > till now, so I'm only submitting the drm_sman removal of my drm cruft
> > > > removal series.
> > >
> > > Last attempt at your branch still had problem. Start I didn't have time
> > > track down the exact issue. I'm cloning the below branch and will test it.
> > > Thanks for cleanup.
> >
> > Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've
> > reported and noticed that the X server fails to start up (and that the
> > kernel hangs). Is that the same you're seeing?
>
> What was just merged to drm-next works fine. Its the reclaim buffer
> patches that cause the problem. In my case the X server starts but I get
> a blank screen. I have full debug on so this is what happens.
Thanks for testing and gathering the logs.
Judging from the dmesg you've attached the via driver opens and closes the
via drm node at least twice while starting X. Which explains why things
blow up for you and Jakob already at startup. But ...
[snip]
> diff --git a/drivers/gpu/drm/via/via_mm.c b/drivers/gpu/drm/via/via_mm.c
> index bedb23d..f29d0c5 100644
> --- a/drivers/gpu/drm/via/via_mm.c
> +++ b/drivers/gpu/drm/via/via_mm.c
> @@ -215,6 +215,10 @@ void via_reclaim_buffers_locked(struct drm_device *dev,
> {
> struct via_file_private *file_priv = file->driver_priv;
> struct via_memblock *entry, *next;
> + int release_idlelock = 0;
> +
> + if (file->master && file->master->lock.hw_lock)
> + drm_idlelock_take(>master->lock);
This is still the old version of the patch, which doesn't set
release_idlelock properly. I've made double-sure that my branch a
http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire
contains the right patches (now rebased onto drm-next). Alternatively you
can just apply the via reclaim_buffers patch on top of drm-next:
http://cgit.freedesktop.org/~danvet/drm/commit/?h=kill-with-fire=a00a2f313d6e99f6c35d2abed094aa4ec94431e2
Can you please retest with that and again grab the dmesg with full
logging? Jakob reported that this still blows up, so there's a problem
left somewhere. But I've rechecked the patches and couldn't see it.
I'll be offline next week.
Yours, Daniel
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
Re: [PULL] remove drm_sman and some i815 fixes
On Thu, Dec 22, 2011 at 11:22:00PM +, James Simmons wrote:
Hi Dave,
I've failed to correctly fix the via hang in the reclaim buffers rework
till now, so I'm only submitting the drm_sman removal of my drm cruft
removal series.
Last attempt at your branch still had problem. Start I didn't have time
track down the exact issue. I'm cloning the below branch and will test it.
Thanks for cleanup.
Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've
reported and noticed that the X server fails to start up (and that the
kernel hangs). Is that the same you're seeing?
What was just merged to drm-next works fine. Its the reclaim buffer
patches that cause the problem. In my case the X server starts but I get
a blank screen. I have full debug on so this is what happens.
Thanks for testing and gathering the logs.
Judging from the dmesg you've attached the via driver opens and closes the
via drm node at least twice while starting X. Which explains why things
blow up for you and Jakob already at startup. But ...
[snip]
diff --git a/drivers/gpu/drm/via/via_mm.c b/drivers/gpu/drm/via/via_mm.c
index bedb23d..f29d0c5 100644
--- a/drivers/gpu/drm/via/via_mm.c
+++ b/drivers/gpu/drm/via/via_mm.c
@@ -215,6 +215,10 @@ void via_reclaim_buffers_locked(struct drm_device *dev,
{
struct via_file_private *file_priv = file-driver_priv;
struct via_memblock *entry, *next;
+ int release_idlelock = 0;
+
+ if (file-master file-master-lock.hw_lock)
+ drm_idlelock_take(file-master-lock);
This is still the old version of the patch, which doesn't set
release_idlelock properly. I've made double-sure that my branch a
http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire
contains the right patches (now rebased onto drm-next). Alternatively you
can just apply the via reclaim_buffers patch on top of drm-next:
http://cgit.freedesktop.org/~danvet/drm/commit/?h=kill-with-fireid=a00a2f313d6e99f6c35d2abed094aa4ec94431e2
Can you please retest with that and again grab the dmesg with full
logging? Jakob reported that this still blows up, so there's a problem
left somewhere. But I've rechecked the patches and couldn't see it.
I'll be offline next week.
Yours, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] remove drm_sman and some i815 fixes
Last attempt at your branch still had problem. Start I didn't have time track down the exact issue. I'm cloning the below branch and will test it. Thanks for cleanup. Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've reported and noticed that the X server fails to start up (and that the kernel hangs). Is that the same you're seeing? What was just merged to drm-next works fine. Its the reclaim buffer patches that cause the problem. In my case the X server starts but I get a blank screen. I have full debug on so this is what happens. Thanks for testing and gathering the logs. Judging from the dmesg you've attached the via driver opens and closes the via drm node at least twice while starting X. Which explains why things blow up for you and Jakob already at startup. But ... Can you please retest with that and again grab the dmesg with full logging? Jakob reported that this still blows up, so there's a problem left somewhere. But I've rechecked the patches and couldn't see it. Done. Using your latest branch. Initializing cgroup subsys cpu Linux version 3.2.0-rc6-openchrome+ (jsimmons@debian) (gcc version 4.6.2 (Debian 4.6.2-7) ) #42 SMP Fri Dec 23 10:16:38 EST 2011 Command line: BOOT_IMAGE=/boot/vmlinuz-test root=UUID=2539cb3b-47b9-47fc-81c1-97dabc51b2b2 ro drm.debug=255 BIOS-provided physical RAM map: BIOS-e820: - 0009f400 (usable) BIOS-e820: 0009f400 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 7bef (usable) BIOS-e820: 7bef - 7bef3000 (ACPI NVS) BIOS-e820: 7bef3000 - 7bf0 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) NX (Execute Disable) protection: active DMI 2.3 present. DMI: MICRO-STAR INTERNATIONAL CO., LTD MS-7312/MS-7312, BIOS V1.2 01/25/2007 e820 update range: - 0001 (usable) == (reserved) e820 remove range: 000a - 0010 (usable) AGP bridge at 00:00:00 Aperture from AGP @ e800 old size 32 MB Aperture from AGP @ e800 size 128 MB (APSIZE f20) last_pfn = 0x7bef0 max_arch_pfn = 0x4 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-B uncachable C-C7FFF write-protect C8000-CBFFF uncachable CC000-D3FFF write-back D4000-F uncachable MTRR variable ranges enabled: 0 base 00 mask FFC000 write-back 1 base 004000 mask FFE000 write-back 2 base 006000 mask FFF000 write-back 3 base 007000 mask FFF800 write-back 4 base 007800 mask FFFC00 write-back 5 base 007BF0 mask F0 uncachable 6 base 00E800 mask FFF800 write-combining 7 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 initial memory mapped : 0 - 2000 Base memory trampoline at [8809d000] 9d000 size 8192 init_memory_mapping: -7bef 00 - 007be0 page 2M 007be0 - 007bef page 4k kernel direct mapping tables up to 7bef @ 1fffc000-2000 RAMDISK: 37aba000 - 37d55000 ACPI: RSDP 000f78c0 00014 (v00 VIAK8M) ACPI: RSDT 7bef3040 0002C (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: FACP 7bef30c0 00074 (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: DSDT 7bef3180 05396 (v01 VIAK8M AWRDACPI 1000 MSFT 010E) ACPI: FACS 7bef 00040 ACPI: APIC 7bef8580 00068 (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: Local APIC address 0xfee0 [ea00-ea0001bf] PMD - [88007960-88007b1f] on node 0 Zone PFN ranges: DMA 0x0010 - 0x1000 DMA320x1000 - 0x0010 Normal empty Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x0010 - 0x009f 0: 0x0100 - 0x0007bef0 On node 0 totalpages: 507519 DMA zone: 56 pages used for memmap DMA zone: 2 pages reserved DMA zone: 3925 pages, LIFO batch:0 DMA32 zone: 6885 pages used for memmap DMA32 zone: 496651 pages, LIFO batch:31 Detected use of extended apic ids on hypertransport bus ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information SMP: Allowing 2 CPUs, 0 hotplug CPUs nr_irqs_gsi: 40 Allocating PCI resources starting at 7bf0
Re: [PULL] remove drm_sman and some i815 fixes
On Fri, Dec 23, 2011 at 03:36:25PM +, James Simmons wrote: Last attempt at your branch still had problem. Start I didn't have time track down the exact issue. I'm cloning the below branch and will test it. Thanks for cleanup. Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've reported and noticed that the X server fails to start up (and that the kernel hangs). Is that the same you're seeing? What was just merged to drm-next works fine. Its the reclaim buffer patches that cause the problem. In my case the X server starts but I get a blank screen. I have full debug on so this is what happens. Thanks for testing and gathering the logs. Judging from the dmesg you've attached the via driver opens and closes the via drm node at least twice while starting X. Which explains why things blow up for you and Jakob already at startup. But ... Can you please retest with that and again grab the dmesg with full logging? Jakob reported that this still blows up, so there's a problem left somewhere. But I've rechecked the patches and couldn't see it. Done. Using your latest branch. Ok, I've noticed another problem that might or might not be the issue here. Updated my kill-with-fire branch. Direct link to the new patch: http://cgit.freedesktop.org/~danvet/drm/patch/?id=b22d66d226aeb22371175b7f7d69b408bc4c1ef7 Thanks a lot for testing all this crap. Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] remove drm_sman and some i815 fixes
> > > Hi Dave, > > > > > > I've failed to correctly fix the via hang in the reclaim buffers rework > > > till now, so I'm only submitting the drm_sman removal of my drm cruft > > > removal series. > > > > Last attempt at your branch still had problem. Start I didn't have time > > track down the exact issue. I'm cloning the below branch and will test it. > > Thanks for cleanup. > > Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've > reported and noticed that the X server fails to start up (and that the > kernel hangs). Is that the same you're seeing? What was just merged to drm-next works fine. Its the reclaim buffer patches that cause the problem. In my case the X server starts but I get a blank screen. I have full debug on so this is what happens. Initializing cgroup subsys cpu Linux version 3.2.0-rc6-openchrome+ (jsimmons at debian) (gcc version 4.6.2 (Debian 4.6.2-7) ) #41 SMP Thu Dec 22 17:37:42 EST 2011 Command line: BOOT_IMAGE=/boot/vmlinuz-test root=UUID=2539cb3b-47b9-47fc-81c1-97dabc51b2b2 ro drm.debug=255 BIOS-provided physical RAM map: BIOS-e820: - 0009f400 (usable) BIOS-e820: 0009f400 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 7bef (usable) BIOS-e820: 7bef - 7bef3000 (ACPI NVS) BIOS-e820: 7bef3000 - 7bf0 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) NX (Execute Disable) protection: active DMI 2.3 present. DMI: MICRO-STAR INTERNATIONAL CO., LTD MS-7312/MS-7312, BIOS V1.2 01/25/2007 e820 update range: - 0001 (usable) ==> (reserved) e820 remove range: 000a - 0010 (usable) AGP bridge at 00:00:00 Aperture from AGP @ e800 old size 32 MB Aperture from AGP @ e800 size 128 MB (APSIZE f20) last_pfn = 0x7bef0 max_arch_pfn = 0x4 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-B uncachable C-C7FFF write-protect C8000-CBFFF uncachable CC000-D3FFF write-back D4000-F uncachable MTRR variable ranges enabled: 0 base 00 mask FFC000 write-back 1 base 004000 mask FFE000 write-back 2 base 006000 mask FFF000 write-back 3 base 007000 mask FFF800 write-back 4 base 007800 mask FFFC00 write-back 5 base 007BF0 mask F0 uncachable 6 base 00E800 mask FFF800 write-combining 7 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 initial memory mapped : 0 - 2000 Base memory trampoline at [8809d000] 9d000 size 8192 init_memory_mapping: -7bef 00 - 007be0 page 2M 007be0 - 007bef page 4k kernel direct mapping tables up to 7bef @ 1fffc000-2000 RAMDISK: 37aba000 - 37d55000 ACPI: RSDP 000f78c0 00014 (v00 VIAK8M) ACPI: RSDT 7bef3040 0002C (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: FACP 7bef30c0 00074 (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: DSDT 7bef3180 05396 (v01 VIAK8M AWRDACPI 1000 MSFT 010E) ACPI: FACS 7bef 00040 ACPI: APIC 7bef8580 00068 (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: Local APIC address 0xfee0 [ea00-ea0001bf] PMD -> [88007960-88007b1f] on node 0 Zone PFN ranges: DMA 0x0010 -> 0x1000 DMA320x1000 -> 0x0010 Normal empty Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x0010 -> 0x009f 0: 0x0100 -> 0x0007bef0 On node 0 totalpages: 507519 DMA zone: 56 pages used for memmap DMA zone: 2 pages reserved DMA zone: 3925 pages, LIFO batch:0 DMA32 zone: 6885 pages used for memmap DMA32 zone: 496651 pages, LIFO batch:31 Detected use of extended apic ids on hypertransport bus ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information SMP: Allowing 2 CPUs, 0 hotplug CPUs nr_irqs_gsi: 40 Allocating PCI resources starting at 7bf0 (gap: 7bf0:82d0) setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 PERCPU: Embedded 25 pages/cpu @88007bc0 s70592 r8192 d23616 u1048576 pcpu-alloc: s70592 r8192 d23616 u1048576 alloc=1*2097152 pcpu-alloc: [0] 0 1 Built 1 zonelists in Zone order, mobility grouping
[PULL] remove drm_sman and some i815 fixes
On Thu, Dec 22, 2011 at 09:48:35PM +, James Simmons wrote: > > > Hi Dave, > > > > I've failed to correctly fix the via hang in the reclaim buffers rework > > till now, so I'm only submitting the drm_sman removal of my drm cruft > > removal series. > > Last attempt at your branch still had problem. Start I didn't have time > track down the exact issue. I'm cloning the below branch and will test it. > Thanks for cleanup. Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've reported and noticed that the X server fails to start up (and that the kernel hangs). Is that the same you're seeing? -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PULL] remove drm_sman and some i815 fixes
> Hi Dave, > > I've failed to correctly fix the via hang in the reclaim buffers rework > till now, so I'm only submitting the drm_sman removal of my drm cruft > removal series. Last attempt at your branch still had problem. Start I didn't have time track down the exact issue. I'm cloning the below branch and will test it. Thanks for cleanup. > While beating on this stuff with my i815 I've discovered a preexisting > use-after free issue in lastclose (which is new compared to what I've > submitted to dri-devel) and a reclaim buffers locking problem. Also added > these two patches. > > Please pull for 3.3. > > Thanks, Daniel > > -- > The following changes since commit 4cf73129cbe001b41be2f8b56f763fbf3acaa4ce: > > Merge remote-tracking branch 'pfdo/drm-fixes' into drm-core-next > (2011-12-21 09:50:56 +) > > are available in the git repository at: > > git://people.freedesktop.org/~danvet/drm for-airlied > > Daniel Vetter (12): > drm/sis: track obj->drm_fd relations in the driver > drm/via: track obj->drm_fd relations in the driver > drm/sman: kill owner tracking interface functions > drm/sman: rip out owner tracking > drm/via: track user->memblock mapping with idr > drm/sis: track user->memblock mapping with idr > drm/sman: kill user_hash_tab > drm/via: use drm_mm instead of drm_sman > drm/sis: use drm_mm instead of drm_sman > drm: kill drm_sman > drm/i810: cleanup reclaim_buffers > drm/i810: don't acces hw regs in lastclose > > drivers/gpu/drm/Makefile|2 +- > drivers/gpu/drm/drm_sman.c | 351 > --- > drivers/gpu/drm/i810/i810_dma.c | 19 ++- > drivers/gpu/drm/i810/i810_drv.c |1 - > drivers/gpu/drm/i810/i810_drv.h |6 +- > drivers/gpu/drm/sis/sis_drv.c | 33 - > drivers/gpu/drm/sis/sis_drv.h |7 +- > drivers/gpu/drm/sis/sis_mm.c| 196 +-- > drivers/gpu/drm/via/via_drv.c | 25 +++ > drivers/gpu/drm/via/via_drv.h |7 +- > drivers/gpu/drm/via/via_map.c | 10 +- > drivers/gpu/drm/via/via_mm.c| 132 ++- > include/drm/drm_sman.h | 176 > include/drm/sis_drm.h |4 + > include/drm/via_drm.h |4 + > 15 files changed, 289 insertions(+), 684 deletions(-) > delete mode 100644 drivers/gpu/drm/drm_sman.c > delete mode 100644 include/drm/drm_sman.h > -- > Daniel Vetter > Mail: daniel at ffwll.ch > Mobile: +41 (0)79 365 57 48 > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PULL] remove drm_sman and some i815 fixes
Hi Dave, I've failed to correctly fix the via hang in the reclaim buffers rework till now, so I'm only submitting the drm_sman removal of my drm cruft removal series. While beating on this stuff with my i815 I've discovered a preexisting use-after free issue in lastclose (which is new compared to what I've submitted to dri-devel) and a reclaim buffers locking problem. Also added these two patches. Please pull for 3.3. Thanks, Daniel -- The following changes since commit 4cf73129cbe001b41be2f8b56f763fbf3acaa4ce: Merge remote-tracking branch 'pfdo/drm-fixes' into drm-core-next (2011-12-21 09:50:56 +) are available in the git repository at: git://people.freedesktop.org/~danvet/drm for-airlied Daniel Vetter (12): drm/sis: track obj->drm_fd relations in the driver drm/via: track obj->drm_fd relations in the driver drm/sman: kill owner tracking interface functions drm/sman: rip out owner tracking drm/via: track user->memblock mapping with idr drm/sis: track user->memblock mapping with idr drm/sman: kill user_hash_tab drm/via: use drm_mm instead of drm_sman drm/sis: use drm_mm instead of drm_sman drm: kill drm_sman drm/i810: cleanup reclaim_buffers drm/i810: don't acces hw regs in lastclose drivers/gpu/drm/Makefile|2 +- drivers/gpu/drm/drm_sman.c | 351 --- drivers/gpu/drm/i810/i810_dma.c | 19 ++- drivers/gpu/drm/i810/i810_drv.c |1 - drivers/gpu/drm/i810/i810_drv.h |6 +- drivers/gpu/drm/sis/sis_drv.c | 33 - drivers/gpu/drm/sis/sis_drv.h |7 +- drivers/gpu/drm/sis/sis_mm.c| 196 +-- drivers/gpu/drm/via/via_drv.c | 25 +++ drivers/gpu/drm/via/via_drv.h |7 +- drivers/gpu/drm/via/via_map.c | 10 +- drivers/gpu/drm/via/via_mm.c| 132 ++- include/drm/drm_sman.h | 176 include/drm/sis_drm.h |4 + include/drm/via_drm.h |4 + 15 files changed, 289 insertions(+), 684 deletions(-) delete mode 100644 drivers/gpu/drm/drm_sman.c delete mode 100644 include/drm/drm_sman.h -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PULL] remove drm_sman and some i815 fixes
Hi Dave, I've failed to correctly fix the via hang in the reclaim buffers rework till now, so I'm only submitting the drm_sman removal of my drm cruft removal series. While beating on this stuff with my i815 I've discovered a preexisting use-after free issue in lastclose (which is new compared to what I've submitted to dri-devel) and a reclaim buffers locking problem. Also added these two patches. Please pull for 3.3. Thanks, Daniel -- The following changes since commit 4cf73129cbe001b41be2f8b56f763fbf3acaa4ce: Merge remote-tracking branch 'pfdo/drm-fixes' into drm-core-next (2011-12-21 09:50:56 +) are available in the git repository at: git://people.freedesktop.org/~danvet/drm for-airlied Daniel Vetter (12): drm/sis: track obj-drm_fd relations in the driver drm/via: track obj-drm_fd relations in the driver drm/sman: kill owner tracking interface functions drm/sman: rip out owner tracking drm/via: track user-memblock mapping with idr drm/sis: track user-memblock mapping with idr drm/sman: kill user_hash_tab drm/via: use drm_mm instead of drm_sman drm/sis: use drm_mm instead of drm_sman drm: kill drm_sman drm/i810: cleanup reclaim_buffers drm/i810: don't acces hw regs in lastclose drivers/gpu/drm/Makefile|2 +- drivers/gpu/drm/drm_sman.c | 351 --- drivers/gpu/drm/i810/i810_dma.c | 19 ++- drivers/gpu/drm/i810/i810_drv.c |1 - drivers/gpu/drm/i810/i810_drv.h |6 +- drivers/gpu/drm/sis/sis_drv.c | 33 - drivers/gpu/drm/sis/sis_drv.h |7 +- drivers/gpu/drm/sis/sis_mm.c| 196 +-- drivers/gpu/drm/via/via_drv.c | 25 +++ drivers/gpu/drm/via/via_drv.h |7 +- drivers/gpu/drm/via/via_map.c | 10 +- drivers/gpu/drm/via/via_mm.c| 132 ++- include/drm/drm_sman.h | 176 include/drm/sis_drm.h |4 + include/drm/via_drm.h |4 + 15 files changed, 289 insertions(+), 684 deletions(-) delete mode 100644 drivers/gpu/drm/drm_sman.c delete mode 100644 include/drm/drm_sman.h -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] remove drm_sman and some i815 fixes
Hi Dave, I've failed to correctly fix the via hang in the reclaim buffers rework till now, so I'm only submitting the drm_sman removal of my drm cruft removal series. Last attempt at your branch still had problem. Start I didn't have time track down the exact issue. I'm cloning the below branch and will test it. Thanks for cleanup. While beating on this stuff with my i815 I've discovered a preexisting use-after free issue in lastclose (which is new compared to what I've submitted to dri-devel) and a reclaim buffers locking problem. Also added these two patches. Please pull for 3.3. Thanks, Daniel -- The following changes since commit 4cf73129cbe001b41be2f8b56f763fbf3acaa4ce: Merge remote-tracking branch 'pfdo/drm-fixes' into drm-core-next (2011-12-21 09:50:56 +) are available in the git repository at: git://people.freedesktop.org/~danvet/drm for-airlied Daniel Vetter (12): drm/sis: track obj-drm_fd relations in the driver drm/via: track obj-drm_fd relations in the driver drm/sman: kill owner tracking interface functions drm/sman: rip out owner tracking drm/via: track user-memblock mapping with idr drm/sis: track user-memblock mapping with idr drm/sman: kill user_hash_tab drm/via: use drm_mm instead of drm_sman drm/sis: use drm_mm instead of drm_sman drm: kill drm_sman drm/i810: cleanup reclaim_buffers drm/i810: don't acces hw regs in lastclose drivers/gpu/drm/Makefile|2 +- drivers/gpu/drm/drm_sman.c | 351 --- drivers/gpu/drm/i810/i810_dma.c | 19 ++- drivers/gpu/drm/i810/i810_drv.c |1 - drivers/gpu/drm/i810/i810_drv.h |6 +- drivers/gpu/drm/sis/sis_drv.c | 33 - drivers/gpu/drm/sis/sis_drv.h |7 +- drivers/gpu/drm/sis/sis_mm.c| 196 +-- drivers/gpu/drm/via/via_drv.c | 25 +++ drivers/gpu/drm/via/via_drv.h |7 +- drivers/gpu/drm/via/via_map.c | 10 +- drivers/gpu/drm/via/via_mm.c| 132 ++- include/drm/drm_sman.h | 176 include/drm/sis_drm.h |4 + include/drm/via_drm.h |4 + 15 files changed, 289 insertions(+), 684 deletions(-) delete mode 100644 drivers/gpu/drm/drm_sman.c delete mode 100644 include/drm/drm_sman.h -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] remove drm_sman and some i815 fixes
On Thu, Dec 22, 2011 at 09:48:35PM +, James Simmons wrote: Hi Dave, I've failed to correctly fix the via hang in the reclaim buffers rework till now, so I'm only submitting the drm_sman removal of my drm cruft removal series. Last attempt at your branch still had problem. Start I didn't have time track down the exact issue. I'm cloning the below branch and will test it. Thanks for cleanup. Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've reported and noticed that the X server fails to start up (and that the kernel hangs). Is that the same you're seeing? -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] remove drm_sman and some i815 fixes
Hi Dave, I've failed to correctly fix the via hang in the reclaim buffers rework till now, so I'm only submitting the drm_sman removal of my drm cruft removal series. Last attempt at your branch still had problem. Start I didn't have time track down the exact issue. I'm cloning the below branch and will test it. Thanks for cleanup. Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've reported and noticed that the X server fails to start up (and that the kernel hangs). Is that the same you're seeing? What was just merged to drm-next works fine. Its the reclaim buffer patches that cause the problem. In my case the X server starts but I get a blank screen. I have full debug on so this is what happens. Initializing cgroup subsys cpu Linux version 3.2.0-rc6-openchrome+ (jsimmons@debian) (gcc version 4.6.2 (Debian 4.6.2-7) ) #41 SMP Thu Dec 22 17:37:42 EST 2011 Command line: BOOT_IMAGE=/boot/vmlinuz-test root=UUID=2539cb3b-47b9-47fc-81c1-97dabc51b2b2 ro drm.debug=255 BIOS-provided physical RAM map: BIOS-e820: - 0009f400 (usable) BIOS-e820: 0009f400 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 7bef (usable) BIOS-e820: 7bef - 7bef3000 (ACPI NVS) BIOS-e820: 7bef3000 - 7bf0 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) NX (Execute Disable) protection: active DMI 2.3 present. DMI: MICRO-STAR INTERNATIONAL CO., LTD MS-7312/MS-7312, BIOS V1.2 01/25/2007 e820 update range: - 0001 (usable) == (reserved) e820 remove range: 000a - 0010 (usable) AGP bridge at 00:00:00 Aperture from AGP @ e800 old size 32 MB Aperture from AGP @ e800 size 128 MB (APSIZE f20) last_pfn = 0x7bef0 max_arch_pfn = 0x4 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-B uncachable C-C7FFF write-protect C8000-CBFFF uncachable CC000-D3FFF write-back D4000-F uncachable MTRR variable ranges enabled: 0 base 00 mask FFC000 write-back 1 base 004000 mask FFE000 write-back 2 base 006000 mask FFF000 write-back 3 base 007000 mask FFF800 write-back 4 base 007800 mask FFFC00 write-back 5 base 007BF0 mask F0 uncachable 6 base 00E800 mask FFF800 write-combining 7 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 initial memory mapped : 0 - 2000 Base memory trampoline at [8809d000] 9d000 size 8192 init_memory_mapping: -7bef 00 - 007be0 page 2M 007be0 - 007bef page 4k kernel direct mapping tables up to 7bef @ 1fffc000-2000 RAMDISK: 37aba000 - 37d55000 ACPI: RSDP 000f78c0 00014 (v00 VIAK8M) ACPI: RSDT 7bef3040 0002C (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: FACP 7bef30c0 00074 (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: DSDT 7bef3180 05396 (v01 VIAK8M AWRDACPI 1000 MSFT 010E) ACPI: FACS 7bef 00040 ACPI: APIC 7bef8580 00068 (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: Local APIC address 0xfee0 [ea00-ea0001bf] PMD - [88007960-88007b1f] on node 0 Zone PFN ranges: DMA 0x0010 - 0x1000 DMA320x1000 - 0x0010 Normal empty Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x0010 - 0x009f 0: 0x0100 - 0x0007bef0 On node 0 totalpages: 507519 DMA zone: 56 pages used for memmap DMA zone: 2 pages reserved DMA zone: 3925 pages, LIFO batch:0 DMA32 zone: 6885 pages used for memmap DMA32 zone: 496651 pages, LIFO batch:31 Detected use of extended apic ids on hypertransport bus ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information SMP: Allowing 2 CPUs, 0 hotplug CPUs nr_irqs_gsi: 40 Allocating PCI resources starting at 7bf0 (gap: 7bf0:82d0) setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 PERCPU: Embedded 25 pages/cpu @88007bc0 s70592 r8192 d23616 u1048576 pcpu-alloc: s70592 r8192 d23616 u1048576 alloc=1*2097152 pcpu-alloc: [0] 0 1 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 500576 Kernel
