udl 1-3.4:1.1: [drm] Cannot find any crtc or sizes
[379964.084865] udl 1-3.4:1.0: [drm] Cannot find any crtc or sizes
[379964.089921] udl 1-3.4:1.1: [drm] Cannot find any crtc or sizes
--
Meelis Roos
___
dri-devel mailing list
dri-de
Looks like the shift and mask are reversed. Does this patch fix it?
Yes, the warning is gone and it still works. Thank you!
Tested-by: Meelis Roos
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman
I tried latest (5.4) custom kernel (with UBSAN) on my Dell D600 laptop and
found that it exhibits a
UBSAN warning triggered by userspace ioctl. Here is dmesg with anything
radeon-related + the warning, and config:
[ 17.659534] [drm] radeon kernel modesetting enabled.
[ 17.659607] radeon 000
I can get some older kernel and test with that if that is of any help.
Just tested Debianis 4.19.0-4 package (4.19.28) and it exhibits the same
symptoms.
Slight additional detail: chenaging between fbcon vt-s does not fix it,
only changing between fbcon and X fixes it.
--
Meelis
https://bugzilla.kernel.org/show_bug.cgi?id=198123
No, I just put the card in and tested with only the current kernels I had.
I can get some older kernel and test with that if that is of any help.
--
Meelis Roos
___
dri-devel mailing list
dri-
ff EBP: f5471940 ESP: df79439c
[ 7.938578] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 EFLAGS: 00210086
[ 7.938579] CR0: 80050033 CR2: 00f80c53 CR3: 354cf000 CR4: 06d0
[ 8.201765] Adding 2096124k swap on /dev/sda5. Priority:-2 extents:1
across:2096124k
--
Meelis Roos
_
eon]] *ERROR* Failed to
allocate GEM object (0, 6, 4096, -22)
[4.858340] failed to allocate framebuffer (0)
[4.858385] [drm:radeonfb_create [radeon]] *ERROR* failed to create fbcon
object -12
[4.858416] [drm] Initialized radeon 2.50.0 20080528 for :01:01.0 on
minor 0
--
ECX: 00f80c53 EDX: 0704
[7.938577] ESI: df7a0fa0 EDI: EBP: f5471940 ESP: df79439c
[7.938578] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 EFLAGS: 00210086
[7.938579] CR0: 80050033 CR2: 00f80c53 CR3: 354cf000 CR4: 06d0
[8.201765] Adding 2096124k swap on /dev/sda
Got UBSAN warning from Dell D600 running 5.0.0-rc4-00218-g12491ed354d2.
The warning did not happen on bootup but during xfce session start or console
switch.
[ 15.323113] radeon :01:00.0: putting AGP V2 device into 4x mode
[ 15.323134] radeon :01:00.0: GTT: 128M 0xE000 - 0xE7
(fb0) is primary device
[8.193959] Console: switching to colour frame buffer device 160x64
[8.195378] nouveau :00:0d.0: fb0: nouveaufb frame buffer device
[8.212083] [drm] Initialized nouveau 1.3.1 20120801 for :00:0d.0 on
minor 0
--
Meelis Roos (mr...@linux.ee
DRM: MM: using M2MF for buffer copies
[1.517930] nouveau :04:05.0: DRM: allocated 1024x768 fb: 0x4000, bo
a09f4d1f
[1.519294] nouveau :04:05.0: fb1: nouveaufb frame buffer device
[1.519313] [drm] Initialized nouveau 1.3.1 20120801 for :04:05.0 on
minor 1
--
Meel
> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15:
NV5 in another PC (secondary card in x86-64) made the systrem crash on
boot, in nvkm_therm_clkgate_fini.
--
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-de
erm_clkgate_fini+0x15/0x174 [nouveau] SS:ESP:
0068:f6155834
[7.423899] CR2:
[7.424033] ---[ end trace cad535783d11d7b9 ]---
--
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists
y, I can not reproduce it, so it looks like random noise from an old
computer. About 10 reboots later, I have not managed to reproduce this
problem.
--
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-devel@lists.freedeskt
t find any crtc or sizes
--
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
e:
> > Lyude, this is due to
> >
> > commit 87660502f1a4d51fb043e89a45d30c9917787c22
> > Author: Lyude
> > Date: Wed Aug 17 15:55:53 2016 -0400
> >
> > drm/i915/gen6+: Interpret mailbox error flags
> >
> > and on its way to stable.
> >
> &g
/0x660
[ 15.847469] [] ? process_one_work+0x480/0x480
[ 15.847472] [] ? kthread+0xbd/0xe0
[ 15.847475] [] ? ret_from_fork+0x1f/0x40
[ 15.847478] [] ? kthread_worker_fn+0x160/0x160
[ 15.847487] ---[ end trace ad9e991297d99be1 ]---
--
Meelis Roos (mroos at linux.ee)
m:__intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun
>
> Other than the annoying underrun, is everything else as expected? i.e.
> no connected outputs? Have we lost dvo detection?
Yes, as expected - there is no monitor connected.
--
Meelis Roos (mroos at linux.ee)
8] fbcon: inteldrmfb (fb0) is primary device
[ 11.448292] Console: switching to colour frame buffer device 128x48
[ 11.458643] i915 :00:02.0: fb0: inteldrmfb frame buffer device
--
Meelis Roos (mroos at linux.ee)
10.067180] EIP: [] mutex_lock+0xa/0x15 SS:ESP 0068:f5971b58
[ 10.067190] CR2: 0104
[ 10.067222] ---[ end trace 049f1f09da45a856 ]---
[ 283.840252] random: crng init done
--
Meelis Roos (mroos at linux.ee)
+0x40/0x6a
[9.376135]
--
Meelis Roos (mroos at linux.ee)
switching to colour frame buffer device 128x48
[8.998095] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[8.998181] [drm] Initialized radeon 2.43.0 20080528 for :01:00.0 on
minor 0
--
Meelis Roos (mroos at linux.ee)
> since it's only needed by the modeset code.
>
> v5: Move even close to the actual user, right next to the comment that
> states where we really need gmbus (and interrupts!).
>
> Cc: Ville Syrjälä
> Cc: Patrik Jakobsson
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc
> since it's only needed by the modeset code.
>
> v5: Move even close to the actual user, right next to the comment that
> states where we really need gmbus (and interrupts!).
>
> Cc: Ville Syrjälä
> Cc: Patrik Jakobsson
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc
> No matter what, userspace can access the adapter right away when we
> register it, so this needs to be fixed along the lines of [1].
>
> BR,
> Jani.
>
>
> [1]
> http://patchwork.freedesktop.org/patch/msgid/1452157856-27360-1-git-send-email-daniel.vetter
> at ffwll.ch
--
Meelis Roos (mroos at linux.ee)
ster the i2c controllers someone can use them.
>
> Cc: Ville Syrjälä
> Cc: Patrik Jakobsson
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc: Meelis Roos
> Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
> Cc: stable at vger.kernel.org
> References:
> On Mon, Dec 14, 2015 at 03:31:09PM +0200, Meelis Roos wrote:
> > Between 4.4-rc3 and 4.4-rc4, i915 modesetting broke on my i5-2400 PC.
>
> That would seem to be SNB.
Yes.
> > Instead of seeing the new dense graphics mode, I see the last VGA text
> > li
Signed-off-by: Jani Nikula
:04 04 39379146d7e6dda8a4d5f8781ee3d307cce8c47e
f4f09fae0485ad6263d31d425296fa9cd7de343b M drivers
--
Meelis Roos (mroos at linux.ee)
t;
> Runtime pm shouldn't be a thing for these GPUs... can you see if
> booting with nouveau.runpm=0 fixes it? Sounds like we reintroduced
> some problem for GPUs that don't have optimus-style acpi power off
> hooks.
Yes, nouveau.runpm=0 makes the hang go away, and reboot and lspci also
started working without hangs.
--
Meelis Roos (mroos at linux.ee)
-rc2
dmesg from 4.2.0, drm.debug=0xe
http://kodu.ut.ee/~mroos/download/dm-nouveau-4.2
lspci -vvv
http://kodu.ut.ee/~mroos/download/lspci.nouveau
config:
http://kodu.ut.ee/~mroos/download/nouveau-config
Is there anything else I can provide?
--
Meelis Roos (mroos at linux.ee)
e first crash seems to be related to radeon_hotplug_work_func during
> > radeon initialization.
>
> Looks like a race at startup, I've sent a fix to dri-devel that should work.
It works. Applied on top of 4.2.0-rc7-00071-g0bad909 and everything
seems to work fine, no crash.
--
Meelis Roos (mroos at linux.ee)
> On 19 August 2015 at 00:28, Meelis Roos wrote:
> > Hi, I tried 4.2-rc7 and todays 4.2-rc7+git on a P4 PC with Intel 850
> > chipset and old Radeon graphics. The machine crashes during boot and
> > starts spamming dmesg as fast as it scrolls. Netconsole caught the
> &g
Hi, I tried 4.2-rc7 and todays 4.2-rc7+git on a P4 PC with Intel 850
chipset and old Radeon graphics. The machine crashes during boot and
starts spamming dmesg as fast as it scrolls. Netconsole caught the
dmesg. 4.1.0 worked fine.
The first crash seems to be related to radeon_hotplug_work_func
then.
> >>
> >> Yes, it is doing direct readl() there. But what does this hang mean?
> >
> > I'm not sure if the read can hang because of the GPU, or if indicates a more
> > fundamental PCI issue. Dave?
[...]
> Just a short question regarding the test setup.
> Is the video card a Sun XVR-100 or is it a vanilla ATI RV100 ?
> (If it is a vanilla RV100 there might be some kind of initialization issue
> as the video ROM is not executed during boot?)
It,s SUNW,XVR-100 with F-code ROM.
--
Meelis Roos (mroos at linux.ee)
rm/radeon/r100.c:3149:63: note: ?crit_point_ff.full? was declared
here
drivers/gpu/drm/radeon/r100.c:3573:42: warning: ?disp_drain_rate.full? may be
used uninitialized in this function [-Wuninitialized]
--
Meelis Roos (mroos at linux.ee)
after radeon_scratch_get, r=d
[drm] r100_ring_test before radeon_ring_lock
[drm] radeon_ring_lock start
[drm] radeon_ring_lock got mutex
[drm] radeon_ring_alloc start
[drm] radeon_ring_alloc before radeon_ring_free_size
[drm] radeon_ring_free_size before radeon_ring_get_rptr
[drm] r100_gfx_get_rpt
se gpu addr 0x01ff0c00 and
cpu addr 0xff003c90c000
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Loading R100 Microcode
[drm] radeon: ring at 0x01FF0C002000
[drm] r100_ring_test: 1
[drm] r100_ring_test: 2, r=15e4d
[drm] r100_ring_test: 3
--
Meelis Roos (mroos at linux.ee)
> On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos wrote:
> > To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
> > from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
> > detection to move on to next problem.
>
> NACK. All this
To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
detection to move on to next problem.
Signed-off-by: Meelis Roos
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
b/drivers/gpu/drm/radeon
0
parse addresses (40 bytes) @ f8003fedc1c0
start: 1ff2000, end: 1ff20ff, i: 14
start: 1ff0001, end: 1ff0001, i: 30
adding to system ...
adding to system refers to pci_device_add(dev, bus) and that does not
modify the PCI bus available windows in any way, at least by my reafin
bus resource [mem 0x1ff-0x1ff] (bus
address [0x-0x])
pci_bus :00: root bus resource [bus 00-02]
To me it looks like we get the PCI bus ranges and store them and nobody
uses them until now, and then we insert PCI devices with allocations
from OF and do not up
_bios: pci_resource_start(ROM)=01FF1002
radeon :02:02.0: BAR 6: assigned [mem 0x1ff-0x1ff0001]
after pci_map_rom:
[drm] radeon_read_bios, bios=01ff,
pci_resource_start(ROM)=01F
> That looks quite strange. I guess the kernel should map the ROM at the
> address OpenBoot/OF assigned to it. ( 1002 ).
DaveM already explained about the phys/virt mapping.
> Are pci devices located beneatch pci@1f,0 not reserving resources
> correctly ? (Thus the reuse of addresses when the
> >> Tried 3.11-rc7 on Thinkpad X30 (first 3-11-rc tried on this hw). Works
> >> but i915 gives strange assertion failure with WARNING stack trace. This
> >> is new since 3.10.
> >
> > It is still there with 3.12-rc1 but now I git around to bisecting it.
> > This is the commit that introduces the w
> Tried 3.11-rc7 on Thinkpad X30 (first 3-11-rc tried on this hw). Works
> but i915 gives strange assertion failure with WARNING stack trace. This
> is new since 3.10.
It is still there with 3.12-rc1 but now I git around to bisecting it.
This is the commit that introduces the warning.
commit 9
> Reported-by: Meelis Roos
> Signed-off-by: Sergey Senozhatsky
It works, thank you for quick response!
Tested-by: Meelis Roos
> drivers/gpu/drm/radeon/radeon_irq_kms.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/driv
> > Just got this WARNING while loading radeon driver on a test PC that was
> > running 3.10 fine (full dmesg below). The machine is a Intel 850 chipst
> > PC with AGP Radeon 7000 and no monitor attached. lspci and config are
> > also below.
>
> Still there with 3.11-rc6 and fully reproducible.
> Reported-by: Meelis Roos
> Signed-off-by: Sergey Senozhatsky
It works, thank you for quick response!
Tested-by: Meelis Roos
> drivers/gpu/drm/radeon/radeon_irq_kms.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/driv
Subsystem: IBM ThinkPad A/T/X Series [1014:0209]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR-
Kernel driver in use: e100
--
Meelis Roos (mroos at ut.ee) http://www.cs.ut.ee/~mroos/
Subsystem: IBM ThinkPad A/T/X Series [1014:0209]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR-
Kernel drive
> Just got this WARNING while loading radeon driver on a test PC that was
> running 3.10 fine (full dmesg below). The machine is a Intel 850 chipst
> PC with AGP Radeon 7000 and no monitor attached. lspci and config are
> also below.
Still there with 3.11-rc6 and fully reproducible.
> Linux ve
orked fine.
--
Meelis Roos (mroos at linux.ee)
orked fine.
--
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Just got this WARNING while loading radeon driver on a test PC that was
running 3.10 fine (full dmesg below). The machine is a Intel 850 chipst
PC with AGP Radeon 7000 and no monitor attached. lspci and config are
also below.
Linux version 3.11.0-rc3 (mroos at d850) (gcc version 4.8.1 (Debian 4
other PCI devices.
> >> > /proc/interrupts obviously does not contain the irq since we do not
> >> > register any yet.
> >> >
> >> > There is no BIOS option of "Enable IRQ for VGA" or similar (BIOS is
> >> > latest). Could t
other PCI devices.
> >> > /proc/interrupts obviously does not contain the irq since we do not
> >> > register any yet.
> >> >
> >> > There is no BIOS option of "Enable IRQ for VGA" or similar (BIOS is
> >> > latest). Coul
other PCI devices.
> >> > /proc/interrupts obviously does not contain the irq since we do not
> >> > register any yet.
> >> >
> >> > There is no BIOS option of "Enable IRQ for VGA" or similar (BIOS is
> >> > latest). Could t
s obviously does not contain the irq since we do not
> > register any yet.
> >
> > There is no BIOS option of "Enable IRQ for VGA" or similar (BIOS is
> > latest). Could this be the problem?
> >
> > What can I do to get KMS working on this computer?
>
oes not show Interrupt like on some other PCI devices.
/proc/interrupts obviously does not contain the irq since we do not
register any yet.
There is no BIOS option of "Enable IRQ for VGA" or similar (BIOS is
latest). Could this be the problem?
What can I do to get KMS working on this comp
other PCI devices.
> >> > /proc/interrupts obviously does not contain the irq since we do not
> >> > register any yet.
> >> >
> >> > There is no BIOS option of "Enable IRQ for VGA" or similar (BIOS is
> >> > latest). Coul
s obviously does not contain the irq since we do not
> > register any yet.
> >
> > There is no BIOS option of "Enable IRQ for VGA" or similar (BIOS is
> > latest). Could this be the problem?
> >
> > What can I do to get KMS working on this computer?
> &
oes not show Interrupt like on some other PCI devices.
/proc/interrupts obviously does not contain the irq since we do not
register any yet.
There is no BIOS option of "Enable IRQ for VGA" or similar (BIOS is
latest). Could this be the problem?
What can I do to get KMS working on this comp
While testing out 3.8.0-rc4-00071-g9a92841 on a PC where I have
ironlake_crtc_disable warning
(https://bugzilla.kernel.org/show_bug.cgi?id=52061), I saw a new warning
today that was not there with 3.8.0-rc3-00074. The previous warning is
also still there.
EDID is occasionally wrong on this PC,
> >> I tried 3.7-rc5 on an ironlale PC and got the warning in subject. The
> >> computer last ran 3.6.0 without any warnings. Second reboot showed the
> >> same warning plus a couple of EDID warnings (also below).
> >
> > Still there with 3.7.0-rc7-00113-gcc19528 and 100% reproducible:
>
> Hm, can
0.646645] [] ? ret_from_fork+0x7c/0xb0
[0.646646] [] ? rest_init+0x70/0x70
[0.646650] ---[ end trace ed6fe7a7042b42d8 ]---
[0.702400] [drm:intel_disable_transcoder] *ERROR* failed to disable
transcoder 0
--
Meelis Roos (mroos at ut.ee) http://www.cs.ut.ee/~mroos/
0.646645] [] ? ret_from_fork+0x7c/0xb0
[0.646646] [] ? rest_init+0x70/0x70
[0.646650] ---[ end trace ed6fe7a7042b42d8 ]---
[0.702400] [drm:intel_disable_transcoder] *ERROR* failed to disable
transcoder 0
--
Meelis Roos (mr...@ut.ee) http://www.cs.ut.
I tried 3.7-rc5 on an ironlale PC and got the warning in subject. The
computer last ran 3.6.0 without any warnings. Second reboot showed the
same warning plus a couple of EDID warnings (also below).
[0.00] Linux version 3.7.0-rc5 (mroos at prometheus) (gcc version 4.7.2
(Debian 4.7.2-4
This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in
Ultra 10 (clean, without my "Video RAM" hack that I talked in other
sparclinux posts). When I saw that Sun XVR-100 was detected fine by the
kernel, I compiled radeon drm driver with modesetting enabled and tried
it:
[drm] rad
This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in
Ultra 10 (clean, without my "Video RAM" hack that I talked in other
sparclinux posts). When I saw that Sun XVR-100 was detected fine by the
kernel, I compiled radeon drm driver with modesetting enabled and tried
it:
[drm] rad
y newer gcc version on that machine, and it has been compiling its own
kernels for stress-testing purposes.
So it's probably not related to gcc 4.6->4.7 changes.
--
Meelis Roos (mroos at linux.ee)
y newer gcc version on that machine, and it has been compiling its own
kernels for stress-testing purposes.
So it's probably not related to gcc 4.6->4.7 changes.
--
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
enabled from dmesg but I think I
did not notice screen going fbcon during boot... maybe it only used the
modesetting when X started.
So there are 2 different problems (maybe related), the new one above and
the old one of not seeing some window borders when modesetting and
acceleration are in use.
enabled from dmesg but I think I
did not notice screen going fbcon during boot... maybe it only used the
modesetting when X started.
So there are 2 different problems (maybe related), the new one above and
the old one of not seeing some window borders when modesetting and
acceleration are i
ver 1.3
[ 45.032461] Bluetooth: BNEP filters: protocol multicast
[ 45.945918] NET: Registered protocol family 10
[ 46.384565] Bridge firewalling registered
[ 55.289903] sshd (1379): /proc/1379/oom_adj is deprecated, please use
/proc/1379/oom_score_adj instead.
--
Meelis Roos (mroos at linux.ee)
ver 1.3
[ 45.032461] Bluetooth: BNEP filters: protocol multicast
[ 45.945918] NET: Registered protocol family 10
[ 46.384565] Bridge firewalling registered
[ 55.289903] sshd (1379): /proc/1379/oom_adj is deprecated, please use
/proc/1379/oom_score_adj instead.
--
Meelis Roos (mr...@linux.ee)
_
042] sshd (1391): /proc/1391/oom_adj is deprecated, please use
/proc/1391/oom_score_adj instead.
--
Meelis Roos (mroos at linux.ee)
042] sshd (1391): /proc/1391/oom_adj is deprecated, please use
/proc/1391/oom_score_adj instead.
--
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > 3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release
> > > hangs in random places while using X.
>
> Do you have VT-d enabled in the BIOS?
Disabled VT-d in BIOS and 3.2-rc3 has been running stable since then. SO
it seems to be the same problem.
-
> > > 3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release
> > > hangs in random places while using X.
>
> Do you have VT-d enabled in the BIOS?
Disabled VT-d in BIOS and 3.2-rc3 has been running stable since then. SO
it seems to be the same probl
able.
Well, there is reason for VT-x but actually none for VT-d because I am
not giving out any PCI devices to virtual machines. Will also test
witout it.
--
Meelis Roos (mroos at linux.ee)
633] e1000e :00:19.0: eth0: 10/100 speed: disabling TSO
[ 10.586628] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 17.331458] lp0: using parport0 (interrupt-driven).
[ 39.431271] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro,commit=0
[ 293.184449] tun: Universal TUN/TAP device driver, 1.6
[ 293.184452] tun: (C) 1999-2004 Max Krasnyansky
--
Meelis Roos (mroos at linux.ee)
able.
Well, there is reason for VT-x but actually none for VT-d because I am
not giving out any PCI devices to virtual machines. Will also test
witout it.
--
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://l
0:19.0: eth0: 10/100 speed: disabling TSO
[ 10.586628] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 17.331458] lp0: using parport0 (interrupt-driven).
[ 39.431271] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro,commit=0
[ 293.184449] tun: Universal TUN/TAP device driver, 1.6
[ 293
> 3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release
> hangs in random places while using X.
Just tested 3.2.0-rc2-00369-gbbbc479 after finishing bisecting, and it
also freezes.
.config below:
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.2.0-rc2 Kernel Conf
] intel-iommu:
Workaround IOTLB hang on Ironlake GPUgit bisect bad
6fbcfb3e467adb414e235eeefaeaf51ad12f2461
# good: [3e7abe2556b583e87dabda3e0e6178a67b20d06f] intel-iommu: Fix AB-BA
lockdep report
git bisect good 3e7abe2556b583e87dabda3e0e6178a67b20d06f
--
Meelis Roos (mroos at linux.ee)
461] intel-iommu:
Workaround IOTLB hang on Ironlake GPUgit bisect bad
6fbcfb3e467adb414e235eeefaeaf51ad12f2461
# good: [3e7abe2556b583e87dabda3e0e6178a67b20d06f] intel-iommu: Fix AB-BA
lockdep report
git bisect good 3e7abe2556b583e87dabda3e0e6178a67
e down uninitialized memory manager type 1
[5.943243] [TTM] Finalizing pool allocator.
[5.943523] [TTM] Zone kernel: Used memory at exit: 0 kiB.
[5.943693] [drm] radeon: ttm finalized
[5.944380] radeon :02:00.0: PCI INT A disabled
[5.944564] radeon: probe of :02:00.0
e.
It works, thank you! Now the console is switching 256x96 charactest and
I can see the console. fbset tells
mode "2048x1536"
geometry 2048 1536 2048 1536 8
timings 0 0 0 0 0 0 0
accel true
rgba 8/0,8/0,8/0,0/0
endmode
--
Meelis Roos (mroos at linux.ee)
e down uninitialized memory manager type 1
[5.943243] [TTM] Finalizing pool allocator.
[5.943523] [TTM] Zone kernel: Used memory at exit: 0 kiB.
[5.943693] [drm] radeon: ttm finalized
[5.944380] radeon :02:00.0: PCI INT A disabled
[5.944564] radeon: probe of :02:00
e.
It works, thank you! Now the console is switching 256x96 charactest and
I can see the console. fbset tells
mode "2048x1536"
geometry 2048 1536 2048 1536 8
timings 0 0 0 0 0 0 0
accel true
rgba 8/0,8/0,8/0,0/0
endmode
40x480"
EndSubSection
SubSection "Display"
Depth 15
Modes "1280x960" "1024x768" "832x624" "800x600"
"720x400" "640x480"
EndSubSection
SubSection "Display"
Depth 16
Modes "1280x960" "1024x768" "832x624" "800x600"
"720x400" "640x480"
EndSubSection
SubSection "Display"
Depth 24
Modes "1280x960" "1024x768" "832x624" "800x600"
"720x400" "640x480"
EndSubSection
EndSection
--
Meelis Roos (mroos at linux.ee)
10, EmulateWheelTimeout: 200
[41.258] (**) Option "config_info"
"udev:/sys/devices/platform/i8042/serio1/input/input1/event1"
[41.258] (II) XINPUT: Adding extended input device "ImExPS/2 Logitech
Explorer Mouse" (type: MOUSE)
[41.258] (II) ImExPS/2 Log
044] radeon :02:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level,
low) -> IRQ 11
[ 10.172664] [drm] initializing kernel modesetting (RV100 0x1002:0x5159).
[ 10.172897] [drm] register mmio base: 0xFEAF
[ 10.173098] [drm] register mmio size: 65536
[ 10.273609] [drm] GPU not posted. posting now...
--
Meelis Roos (mroos at linux.ee)
40x480"
EndSubSection
SubSection "Display"
Depth 15
Modes "1280x960" "1024x768" "832x624" "800x600"
"720x400" "640x480"
EndSubSection
SubSection &qu
"config_info"
"udev:/sys/devices/platform/i8042/serio1/input/input1/event1"
[41.258] (II) XINPUT: Adding extended input device "ImExPS/2 Logitech
Explorer Mouse" (type: MOUSE)
[41.258] (II) ImExPS/2 Logitech Explorer Mouse: initialized for relative
axes.
[
00:02:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level,
low) -> IRQ 11
[ 10.172664] [drm] initializing kernel modesetting (RV100 0x1002:0x5159).
[ 10.172897] [drm] register mmio base: 0xFEAF
[ 10.173098] [drm] register mmio size: 65536
[ 10.273609] [drm] GPU not posted. posting n
Commit 6ef3d4278034982c13df87c4a51e0445f762d316 introduces seq_file
usage in intel_overlay.c but does not include the header and now
compilation fails on i386. Fix it by including the necessary header.
Signed-off-by: Meelis Roos
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu
Commit 6ef3d4278034982c13df87c4a51e0445f762d316 introduces seq_file
usage in intel_overlay.c but does not include the header and now
compilation fails on i386. Fix it by including the necessary header.
Signed-off-by: Meelis Roos
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu
98 matches
Mail list logo
