[Bug 36255] New: [r128] Kernel panic after killing X since 2.6.37
https://bugs.freedesktop.org/show_bug.cgi?id=36255 Summary: [r128] Kernel panic after killing X since 2.6.37 Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/other AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: connor.behan at gmail.com Created an attachment (id=45651) --> (https://bugs.freedesktop.org/attachment.cgi?id=45651) Dmesg output I have seen this bug in kernels 2.6.38, 2.6.37 and NOT 2.6.36. Every time I quit the Xserver using the Xfce session manager, the message printed on the console it returns to is: EIP: [] r128_driver_irq_handler +0x15/0x50 [r128] SS:ESP 0068:df007fac CR2: e08c8044 --- [ end trace 632129fdd65eae19 ] --- Kernel panic - not syncing: Fatal exception in interrupt Pid: 0, comm: swapper tainted: G D 2.6.38-ARCH #1 Call trace: *some calls including r128_driver_irq_handler and other IRQ functions* And I have to reboot with Alt+SysRq+REISUB. This only happens when I quit X using the functions in the Xfce session manager. The return to the console will be fine if I use Ctrl+Alt+Backspace, "sudo killall X", or Ctrl+Alt+F1 followed by Ctrl+C. I admit that this is vague information but I simply cannot get an answer our of the Xfce developers as to what function is being used.
2.6.39-rc1 nouveau regression (bisected)
On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" > to everyone, but then chose to CC Maciej instead: Would you be so kind and > add this to your regression list? Thanks! > > Since commit 38f1cff > > From: Dave Airlie > Date: Wed, 16 Mar 2011 11:34:41 +1000 > Subject: [PATCH] Merge commit '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' > into dr > > This commit changed an internal radeon structure, that meant a new driver > in -next had to be fixed up, merge in the commit and fix up the driver. > > Also fixes a trivial nouveau merge. > > Conflicts: > drivers/gpu/drm/nouveau/nouveau_mem.c > > booting my atom/NM10/ION2 system crashes hard during boot, right after > blanking the screen, and before the initramfs gets loaded. I just > re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work > just fine, but the merge commit ( 38f1cff ) fails, same as tip ( 85f2e68 ). Can you activate netconsole and check whether kernel spits anything interesting? You might try to load nouveau module after boot - maybe something will be saved to /var/log or you could even ssh into the box and check dmesg... Marcin
[PATCH] i2c-algo-bit: make sure to call pre/post_xfer for bit_test
Apparently some distros set i2c-algo-bit.bit_test to 1 by
default. In some cases this causes i2c_bit_add_bus
to fail and prevents the i2c bus from being added. In the
radeon case, we fail to add the ddc i2c buses which prevents
the driver from being able to detect attached monitors.
The i2c bus works fine even if bit_test fails. This is likely
due to gpio switching that is required and handled in the
pre/post_xfer hooks, so call the pre/post_xfer hooks in the
bit test as well.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=36221
Cc: Jean Delvare
Signed-off-by: Alex Deucher
---
drivers/i2c/algos/i2c-algo-bit.c | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/algos/i2c-algo-bit.c b/drivers/i2c/algos/i2c-algo-bit.c
index 38319a6..e2740e6 100644
--- a/drivers/i2c/algos/i2c-algo-bit.c
+++ b/drivers/i2c/algos/i2c-algo-bit.c
@@ -232,9 +232,16 @@ static int i2c_inb(struct i2c_adapter *i2c_adap)
* Sanity check for the adapter hardware - check the reaction of
* the bus lines only if it seems to be idle.
*/
-static int test_bus(struct i2c_algo_bit_data *adap, char *name)
+static int test_bus(struct i2c_adapter *i2c_adap, char *name)
{
- int scl, sda;
+ struct i2c_algo_bit_data *adap = i2c_adap->algo_data;
+ int scl, sda, ret;
+
+ if (adap->pre_xfer) {
+ ret = adap->pre_xfer(i2c_adap);
+ if (ret < 0)
+ return -ENODEV;
+ }
if (adap->getscl == NULL)
pr_info("%s: Testing SDA only, SCL is not readable\n", name);
@@ -297,11 +304,19 @@ static int test_bus(struct i2c_algo_bit_data *adap, char
*name)
"while pulling SCL high!\n", name);
goto bailout;
}
+
+ if (adap->post_xfer)
+ adap->post_xfer(i2c_adap);
+
pr_info("%s: Test OK\n", name);
return 0;
bailout:
sdahi(adap);
sclhi(adap);
+
+ if (adap->post_xfer)
+ adap->post_xfer(i2c_adap);
+
return -ENODEV;
}
@@ -607,7 +622,7 @@ static int __i2c_bit_add_bus(struct i2c_adapter *adap,
int ret;
if (bit_test) {
- ret = test_bus(bit_adap, adap->name);
+ ret = test_bus(adap, adap->name);
if (ret < 0)
return -ENODEV;
}
--
1.7.1.1
[Bug 32982] Kernel locks up a few minutes after boot
https://bugzilla.kernel.org/show_bug.cgi?id=32982 --- Comment #8 from Bart Van Assche 2011-04-14 19:24:34 --- The result of the bisect process - not sure it's useful: # git bisect skip There are only 'skip'ped commits left to test. The first bad commit could be any of: 62e0ff1ef2d8ea0814487f73a7de431396a1e914 1fcf0069f4715f6f811466db68a547a348b4d5a9 94e948e6e43cd34e0e2ca496d5e90e4ff0d884f9 53f358a81e10e798f44af896ffacaedd7ac0269b e9c5db0b8dce1bcdc99ad26e718230810d6b5cff b73a21fc66fee35b41db755abebfacba48b2fc76 We cannot bisect more! git bisect start # skip: [1fcf0069f4715f6f811466db68a547a348b4d5a9] Merge branch 'common/fbdev' of master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6 git bisect skip 1fcf0069f4715f6f811466db68a547a348b4d5a9 # skip: [e9c5db0b8dce1bcdc99ad26e718230810d6b5cff] efifb: support AMD Radeon HD 6490 git bisect skip e9c5db0b8dce1bcdc99ad26e718230810d6b5cff # skip: [21cd72e7cb424f1686855602ec0fdc6e5830f249] savagefb: Set up I2C based on chip family instead of card id git bisect skip 21cd72e7cb424f1686855602ec0fdc6e5830f249 # skip: [47c87d930f3db4fc3a30505075e07f5597e2e953] fb: Reduce priority of resource conflict message git bisect skip 47c87d930f3db4fc3a30505075e07f5597e2e953 # good: [899631c7916b231ba6509c90dbc33221e9194029] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input git bisect good 899631c7916b231ba6509c90dbc33221e9194029 # bad: [b73a21fc66fee35b41db755abebfacba48b2fc76] video: s3c-fb: fix checkpatch errors and warning git bisect bad b73a21fc66fee35b41db755abebfacba48b2fc76 # skip: [6c5103890057b1bb781b26b7aae38d33e4c517d8] Merge branch 'for-2.6.39/core' of git://git.kernel.dk/linux-2.6-block git bisect skip 6c5103890057b1bb781b26b7aae38d33e4c517d8 # good: [247f99386100d1d1c369ba98120d2edebf5426fc] fbdev: sh_mobile_lcdcfb: fix module lock acquisition git bisect good 247f99386100d1d1c369ba98120d2edebf5426fc # skip: [53f358a81e10e798f44af896ffacaedd7ac0269b] Merge branch 'viafb-next' of git://github.com/schandinat/linux-2.6 git bisect skip 53f358a81e10e798f44af896ffacaedd7ac0269b # good: [3f086fe93f734ba76f2e130777687f81e0cbb318] viafb: initialize margins correct git bisect good 3f086fe93f734ba76f2e130777687f81e0cbb318 # skip: [62e0ff1ef2d8ea0814487f73a7de431396a1e914] fbcon: Remove unused 'display *p' variable from fb_flashcursor() git bisect skip 62e0ff1ef2d8ea0814487f73a7de431396a1e914 # skip: [94e948e6e43cd34e0e2ca496d5e90e4ff0d884f9] s3fb: fix Virge/GX2 git bisect skip 94e948e6e43cd34e0e2ca496d5e90e4ff0d884f9 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Linux 2.6.39-rc3
On Thu, Apr 14, 2011 at 6:56 PM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 06:58:46PM -0700, H. Peter Anvin wrote:
>> On 04/13/2011 12:14 PM, Yinghai Lu wrote:
>> >
>> > so looks bios program wrong address to the radon card?
>> >
>>
>> Okay, staring at this, it definitely seems toxic to overlay the GART
>> over memory areas reserved by the BIOS. ?If I were to guess, I would say
>> that the problem here seems to be that the kernel thinks it is
>> overlaying 64 MiB of memory, but the actual GART is in fact 512 MiB in
>> size -- 131072 CPU pages -- which now overlaps the BIOS reserved areas.
>>
>> Alex D., could you comment on the "num cpu pages" bit?
>
> Okay, I tried the debug-patch from Yinghai (posted to the bugzilla):
>
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -325,6 +325,8 @@ void radeon_gtt_location(struct radeon_device *rdev,
> struct radeon_mc *mc)
> ? ? ? ? ? ? ? ? ? ? ? ?mc->gtt_size = size_bf;
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?mc->gtt_start = (mc->vram_start & ~mc->gtt_base_align) -
> mc->gtt_size;
> + ? ? ? ? ? ? ? if (mc->gtt_start == 0xa000)
> + ? ? ? ? ? ? ? ? ? ? ? mc->gtt_start = 0x8000;
> ? ? ? ?} else {
> ? ? ? ? ? ? ? ?if (mc->gtt_size > size_af) {
> ? ? ? ? ? ? ? ? ? ? ? ?dev_warn(rdev->dev, "limiting GTT\n");
>
> And this makes a difference, with this change on-top of -rc3 the box boots
> fine. So there seems to be some dependency between the GART base and the GTT
> base even when they are in different address spaces.
>
> Alex, can you comment on this?
Wierd either a hw bug or some access to the GTT is leaking out before,
things are setup properly,
I think the RS780/880 docs are on the website, but generally the
address spaces are completely separate so anything getting through is
very unusual.
Dave.
[PATCH] drm/radeon/kms: adjust evergreen display watermark setup
This patch fixes two issues:
- A disabled crtc does not use any lb, so return 0 for
lb size. This makes the display priority calculation
more exact.
- Only use 1/2 and whole lb partitions. Using smaller
partitions can cause underflow to one of the displays
if you have multiple large displays on the same lb.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=34534
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 89 ++--
1 files changed, 44 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 5f057b8..11d1578 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -371,7 +371,7 @@ static u32 evergreen_line_buffer_adjust(struct
radeon_device *rdev,
struct drm_display_mode *mode,
struct drm_display_mode *other_mode)
{
- u32 tmp = 0;
+ u32 tmp;
/*
* Line Buffer Setup
* There are 3 line buffers, each one shared by 2 display controllers.
@@ -381,64 +381,63 @@ static u32 evergreen_line_buffer_adjust(struct
radeon_device *rdev,
* first display controller
* 0 - first half of lb (3840 * 2)
* 1 - first 3/4 of lb (5760 * 2)
-* 2 - whole lb (7680 * 2)
+* 2 - whole lb (7680 * 2), other crtc must be disabled
* 3 - first 1/4 of lb (1920 * 2)
* second display controller
* 4 - second half of lb (3840 * 2)
* 5 - second 3/4 of lb (5760 * 2)
-* 6 - whole lb (7680 * 2)
+* 6 - whole lb (7680 * 2), other crtc must be disabled
* 7 - last 1/4 of lb (1920 * 2)
*/
- if (mode && other_mode) {
- if (mode->hdisplay > other_mode->hdisplay) {
- if (mode->hdisplay > 2560)
- tmp = 1; /* 3/4 */
- else
- tmp = 0; /* 1/2 */
- } else if (other_mode->hdisplay > mode->hdisplay) {
- if (other_mode->hdisplay > 2560)
- tmp = 3; /* 1/4 */
- else
- tmp = 0; /* 1/2 */
- } else
+ /* this can get tricky if we have two large displays on a paired group
+* of crtcs. Ideally for multiple large displays we'd assign them to
+* non-linked crtcs for maximum line buffer allocation.
+*/
+ if (radeon_crtc->base.enabled && mode) {
+ if (other_mode)
tmp = 0; /* 1/2 */
- } else if (mode)
- tmp = 2; /* whole */
- else if (other_mode)
- tmp = 3; /* 1/4 */
+ else
+ tmp = 2; /* whole */
+ } else
+ tmp = 0;
/* second controller of the pair uses second half of the lb */
if (radeon_crtc->crtc_id % 2)
tmp += 4;
WREG32(DC_LB_MEMORY_SPLIT + radeon_crtc->crtc_offset, tmp);
- switch (tmp) {
- case 0:
- case 4:
- default:
- if (ASIC_IS_DCE5(rdev))
- return 4096 * 2;
- else
- return 3840 * 2;
- case 1:
- case 5:
- if (ASIC_IS_DCE5(rdev))
- return 6144 * 2;
- else
- return 5760 * 2;
- case 2:
- case 6:
- if (ASIC_IS_DCE5(rdev))
- return 8192 * 2;
- else
- return 7680 * 2;
- case 3:
- case 7:
- if (ASIC_IS_DCE5(rdev))
- return 2048 * 2;
- else
- return 1920 * 2;
+ if (radeon_crtc->base.enabled && mode) {
+ switch (tmp) {
+ case 0:
+ case 4:
+ default:
+ if (ASIC_IS_DCE5(rdev))
+ return 4096 * 2;
+ else
+ return 3840 * 2;
+ case 1:
+ case 5:
+ if (ASIC_IS_DCE5(rdev))
+ return 6144 * 2;
+ else
+ return 5760 * 2;
+ case 2:
+ case 6:
+ if (ASIC_IS_DCE5(rdev))
+ return 8192 * 2;
+ else
+ return 7680 * 2;
+ case 3:
+ case 7:
+ if (ASIC_IS_DCE5(rdev))
+ return 2048 * 2;
+ else
+ return 1920 * 2;
+ }
}
+
+ /* controller not enabled, so no lb used */
+ return 0;
}
static u32
2.6.39-rc1 nouveau regression (bisected)
Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" to everyone, but then chose to CC Maciej instead: Would you be so kind and add this to your regression list? Thanks! Since commit 38f1cff From: Dave Airlie Date: Wed, 16 Mar 2011 11:34:41 +1000 Subject: [PATCH] Merge commit '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr This commit changed an internal radeon structure, that meant a new driver in -next had to be fixed up, merge in the commit and fix up the driver. Also fixes a trivial nouveau merge. Conflicts: drivers/gpu/drm/nouveau/nouveau_mem.c booting my atom/NM10/ION2 system crashes hard during boot, right after blanking the screen, and before the initramfs gets loaded. I just re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work just fine, but the merge commit ( 38f1cff ) fails, same as tip ( 85f2e68 ). My previous reports (Apr 03, Apr 07) seem to have gotten lost (or ignored, or both). Best, Dominik
Linux 2.6.39-rc3
On Thu, Apr 14, 2011 at 5:09 PM, Joerg Roedel wrote: > On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote: >> On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel wrote: >> > And this makes a difference, with this change on-top of -rc3 the box boots >> > fine. So there seems to be some dependency between the GART base and the >> > GTT >> > base even when they are in different address spaces. >> > >> > Alex, can you comment on this? >> >> As Dave said, they are completely different addresses spaces. ?You >> could put the GPU aperture at 0 if you wanted (in fact we do on some >> chips). ?Perhaps there's some strange interaction with the nb gart >> since the nb gart on that chipset was designed to be used for graphics >> and the rs780/880 can be configured to use an agp aperture. >> Unfortunately, I'm not that familiar with the nb gart. > > Actually, the nb gart is part of the cpu. It is part of the cpu north > bridge and can translate io and cpu accesses. In fact, it is a remapper > of physical memory addresses. I know what it's for. In the IGP graphics chip is also part of the north bridge, but it may not be related at all. > > The problem seems to be related to specific gpu chips. On another > notebook with an hd3000 card gtt and the nb gart aperture are both on > 0xa000 too but the box works fine. I havn't tested with an hd5000 > yet. The failing notebook has an hd4200 mobility. What exact model is the hd3000? Is it IGP GPU or a discrete GPU? It it's an IGP, it's identical to the hd4200 programming-wise. > > Btw. what happens if the gpu accesses an unmapped address in the gtt > range? It's redirected to a dummy page. Alex
[PATCH] drm/radeon/kms: add connectors even if i2c fails
Sometimes the i2c test in i2c_bit_add_bus fails
if this happens we fail to register the i2c adapter and
eventually fail to add the connector. If i2c fails,
add the connector to the user can at least force
it on.
Note that some distros set i2c-algo-bit.bit_test to 1 by
default which sometimes fails preventing the ddc i2c adapter
from being added. The i2c adapter works even if the bit test
fails, probably due to pre/post_xfer not getting called in
the test_bit function. I have another patch to follow
up on that.
See:
https://bugs.freedesktop.org/show_bug.cgi?id=36221
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_connectors.c | 29 +++
drivers/gpu/drm/radeon/radeon_i2c.c|6 +
2 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 2ef6d51..5f45fa1 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1199,7 +1199,7 @@ radeon_add_atom_connector(struct drm_device *dev,
if (router->ddc_valid || router->cd_valid) {
radeon_connector->router_bus = radeon_i2c_lookup(rdev,
>i2c_info);
if (!radeon_connector->router_bus)
- goto failed;
+ DRM_ERROR("Failed to assign router i2c bus! Check dmesg
for i2c errors.\n");
}
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
@@ -1208,7 +1208,7 @@ radeon_add_atom_connector(struct drm_device *dev,
if (i2c_bus->valid) {
radeon_connector->ddc_bus = radeon_i2c_lookup(rdev,
i2c_bus);
if (!radeon_connector->ddc_bus)
- goto failed;
+ DRM_ERROR("VGA: Failed to assign ddc bus! Check
dmesg for i2c errors.\n");
}
radeon_connector->dac_load_detect = true;
drm_connector_attach_property(_connector->base,
@@ -1226,7 +1226,7 @@ radeon_add_atom_connector(struct drm_device *dev,
if (i2c_bus->valid) {
radeon_connector->ddc_bus = radeon_i2c_lookup(rdev,
i2c_bus);
if (!radeon_connector->ddc_bus)
- goto failed;
+ DRM_ERROR("DVIA: Failed to assign ddc bus!
Check dmesg for i2c errors.\n");
}
radeon_connector->dac_load_detect = true;
drm_connector_attach_property(_connector->base,
@@ -1249,7 +1249,7 @@ radeon_add_atom_connector(struct drm_device *dev,
if (i2c_bus->valid) {
radeon_connector->ddc_bus = radeon_i2c_lookup(rdev,
i2c_bus);
if (!radeon_connector->ddc_bus)
- goto failed;
+ DRM_ERROR("DVI: Failed to assign ddc bus! Check
dmesg for i2c errors.\n");
}
subpixel_order = SubPixelHorizontalRGB;
drm_connector_attach_property(_connector->base,
@@ -1290,7 +1290,7 @@ radeon_add_atom_connector(struct drm_device *dev,
if (i2c_bus->valid) {
radeon_connector->ddc_bus = radeon_i2c_lookup(rdev,
i2c_bus);
if (!radeon_connector->ddc_bus)
- goto failed;
+ DRM_ERROR("HDMI: Failed to assign ddc bus!
Check dmesg for i2c errors.\n");
}
drm_connector_attach_property(_connector->base,
rdev->mode_info.coherent_mode_property,
@@ -1329,10 +1329,10 @@ radeon_add_atom_connector(struct drm_device *dev,
else
radeon_dig_connector->dp_i2c_bus =
radeon_i2c_create_dp(dev, i2c_bus, "DP-auxch");
if (!radeon_dig_connector->dp_i2c_bus)
- goto failed;
+ DRM_ERROR("DP: Failed to assign dp ddc bus!
Check dmesg for i2c errors.\n");
radeon_connector->ddc_bus = radeon_i2c_lookup(rdev,
i2c_bus);
if (!radeon_connector->ddc_bus)
- goto failed;
+ DRM_ERROR("DP: Failed to assign ddc bus! Check
dmesg for i2c errors.\n");
}
subpixel_order = SubPixelHorizontalRGB;
drm_connector_attach_property(_connector->base,
@@ -1381,7 +1381,7 @@ radeon_add_atom_connector(struct drm_device *dev,
if (i2c_bus->valid) {
radeon_connector->ddc_bus = radeon_i2c_lookup(rdev,
i2c_bus);
if (!radeon_connector->ddc_bus)
- goto failed;
+ DRM_ERROR("LVDS: Failed to assign ddc bus!
Check dmesg for i2c
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #40 from revealed 2011-04-14 16:58:21 PDT --- wow ok. Then i will keep the patch and cleanup the source. Many thanks for all your help. I will go to bed now. It is close to two o clock in the morning in my place. Thank you very much once more :D -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #39 from Alex Deucher 2011-04-14 16:53:01 PDT --- (In reply to comment #38) > (In reply to comment #37) > > Whats next for me? > > > > Can i run make clean all on /usr/src/linux-2x? And wait for an Update`? > > I've sent the patch to the linux i2c list to be hopefully applied upstream. > It's up to the distros to pick up the patch in the meantime. Or they can set i2c-algo-bit.bit_test=0 in the interim. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #38 from Alex Deucher 2011-04-14 16:52:11 PDT --- (In reply to comment #37) > Whats next for me? > > Can i run make clean all on /usr/src/linux-2x? And wait for an Update`? I've sent the patch to the linux i2c list to be hopefully applied upstream. It's up to the distros to pick up the patch in the meantime. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #37 from revealed 2011-04-14 16:48:54 PDT --- Whats next for me? Can i run make clean all on /usr/src/linux-2x? And wait for an Update`? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #36 from Alex Deucher 2011-04-14 16:44:28 PDT --- (In reply to comment #35) > Seems to work fine! Great! thanks for testing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #35 from revealed 2011-04-14 16:38:08 PDT --- Seems to work fine! disk at wild-thing:~> grep command /var/log/boot.msg <5>[0.00] Kernel command line: root=/dev/sdc6 resume=/dev/sdc5 splash=silent disk at wild-thing:~> dmesg | grep i2c [8.316773] ivtv0: Reopen i2c bus for IR-blaster support [8.522473] cx25840 5-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0) [8.656997] tuner 5-0061: chip found @ 0xc2 (ivtv i2c driver #0) [8.889160] wm8775 5-001b: chip found @ 0x36 (ivtv i2c driver #0) [ 29.856130] input: i2c IR (Hauppauge WinTV PVR-150 as /devices/virtual/rc/rc0/input6 [ 29.856207] rc0: i2c IR (Hauppauge WinTV PVR-150 as /devices/virtual/rc/rc0 [ 29.856210] ir-kbd-i2c: i2c IR (Hauppauge WinTV PVR-150 detected at i2c-5/5-0071/ir0 [ivtv i2c driver #0] disk at wild-thing:~> dmesg | grep drm [2.461044] [drm] Initialized drm 1.1.0 20060810 [2.513747] [drm] radeon defaulting to kernel modesetting. [2.513801] [drm] radeon kernel modesetting enabled. [2.515575] [drm] initializing kernel modesetting (R580 0x1002:0x7240). [2.515685] [drm] register mmio base: 0xFF7F [2.515733] [drm] register mmio size: 65536 [2.517031] [drm] Generation 2 PCI interface, using max accessible memory [2.517335] [drm] radeon: irq initialized. [2.517455] [drm] Detected VRAM RAM=512M, BAR=256M [2.517502] [drm] RAM width 256bits DDR [2.517739] [drm] radeon: 512M of VRAM memory ready [2.517786] [drm] radeon: 512M of GTT memory ready. [2.517845] [drm] GART: num cpu pages 131072, num gpu pages 131072 [2.519502] [drm] radeon: 4 quad pipes, 1 z pipes initialized. [2.520495] [drm] PCIE GART of 512M enabled (table at 0x0004). [2.520643] [drm] Loading R500 Microcode [2.522154] [drm] radeon: ring at 0x20001000 [2.55] [drm] ring test succeeded in 3 usecs [2.522411] [drm] radeon: ib pool ready. [2.522519] [drm] ib test succeeded in 0 usecs [2.523408] [drm] Radeon Display Connectors [2.523456] [drm] Connector 0: [2.523502] [drm] DVI-I [2.523568] [drm] HPD2 [2.523621] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [2.523709] [drm] Encoders: [2.523762] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [2.523809] [drm] DFP3: INTERNAL_LVTM1 [2.523874] [drm] Connector 1: [2.523926] [drm] S-video [2.523972] [drm] Encoders: [2.524050] [drm] TV1: INTERNAL_KLDSCP_DAC2 [2.524104] [drm] Connector 2: [2.524150] [drm] DVI-I [2.524214] [drm] HPD1 [2.524267] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [2.524354] [drm] Encoders: [2.524407] [drm] CRT2: INTERNAL_KLDSCP_DAC2 [2.524454] [drm] DFP1: INTERNAL_KLDSCP_TMDS1 [2.636077] [drm] Possible lm64 thermal controller at 0x18 [2.636172] [drm] radeon: power management initialized [2.762666] [drm] fb mappable at 0xC00C [2.762722] [drm] vram apper at 0xC000 [2.762775] [drm] size 9216000 [2.762827] [drm] fb depth is 24 [2.762879] [drm]pitch is 7680 [2.775905] fb0: radeondrmfb frame buffer device [2.775926] drm: registered panic notifier [2.775949] [drm] Initialized radeon 2.7.0 20080528 for :01:00.0 on minor 0 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #34 from revealed 2011-04-14 16:33:22 PDT --- Will reboot and test now! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #33 from revealed 2011-04-14 16:11:04 PDT --- Yes i will... make is still processing at net/xy ... i guess this will take some time. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #32 from Alex Deucher 2011-04-14 16:09:29 PDT --- (In reply to comment #31) > So if i ignore this now, i can continue with: > > make modules > make modules_install > make install > and select the new kernel in grub. > > And it should work? yes. make sure you remove i2c-algo-bit.bit_test=0 from your grub config when testing it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #31 from revealed 2011-04-14 16:06:56 PDT --- So if i ignore this now, i can continue with: make modules make modules_install make install and select the new kernel in grub. And it should work? greetings, R -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34534] resolution 3840x1024 stopped to work on HD5850 after switch to 2.6.37 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=34534 --- Comment #19 from Alex Deucher 2011-04-14 16:06:19 PDT --- (In reply to comment #18) > (In reply to comment #17) > > Does this patch help? > > Yes, this patch works. 0x770c is set to the right value now. > 0x7718 and 0x771c are different than before too but that is probably intended. Yes. > Here they are: > 0x0c000x00030002 (196610) > 0x0c040x2e985963 (781736291) > 0x77180x00100024 (1048612) > 0x771c0x00100024 (1048612) > 0x770c0x00020004 (131076) > > Thanks for fixing this. No problem. Sorry it took so long. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #30 from Alex Deucher 2011-04-14 16:05:09 PDT --- (In reply to comment #28) > With this patch i get: > > drivers/i2c/algos/i2c-algo-bit.c: In Funktion ?i2c_bit_prepare_bus?: > drivers/i2c/algos/i2c-algo-bit.c:620:28: Warnung: Variable ?bit_adap? wird > nicht verwendet > > --- Make continues??? you can ignore it or remove this line in i2c_bit_prepare_bus(): struct i2c_algo_bit_data *bit_adap = adap->algo_data; It's just saying the variable is unused. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32982] Kernel locks up a few minutes after boot
https://bugzilla.kernel.org/show_bug.cgi?id=32982 --- Comment #7 from Bart Van Assche 2011-04-14 15:57:40 --- Still occurs with 85f2e689a5c8fb6ed8fdbee00109e7f6e5fefcb6 (2.6.29-rc3+). Note: I'm still trying to find the offending commit via bisecting. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 36236] Problems with lights in Trine game from www.humblebundle.com
https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #4 from Turo Lamminen 2011-04-14 15:47:42 PDT --- Something useful for you guys: 1. Back up the original executables and shaders (in data/shader/cg/) 2. Grab this: http://alternativegames.net/temp/trineUnofficialBeta.tar.bz2 This build is UNOFFICIAL and UNSUPPORTED. Don't get it unless you know you need it. 3. There's some better logging on shader errors. Post new logs, including log from the game ~/.frozenbyte/trine/logs/log.txt -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34534] resolution 3840x1024 stopped to work on HD5850 after switch to 2.6.37 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=34534 --- Comment #18 from Peter Hercek 2011-04-14 15:44:43 PDT --- (In reply to comment #17) > Does this patch help? Yes, this patch works. 0x770c is set to the right value now. 0x7718 and 0x771c are different than before too but that is probably intended. Here they are: 0x0c000x00030002 (196610) 0x0c040x2e985963 (781736291) 0x77180x00100024 (1048612) 0x771c0x00100024 (1048612) 0x770c0x00020004 (131076) Thanks for fixing this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #29 from revealed 2011-04-14 15:39:05 PDT --- I am always patching a fresh copy of i2c-algo-bit.c from SuSE rpm; ?? Is this correct? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #28 from revealed 2011-04-14 15:37:54 PDT --- With this patch i get: drivers/i2c/algos/i2c-algo-bit.c: In Funktion ?i2c_bit_prepare_bus?: drivers/i2c/algos/i2c-algo-bit.c:620:28: Warnung: Variable ?bit_adap? wird nicht verwendet --- Make continues??? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 Alex Deucher changed: What|Removed |Added Attachment #45636|text/x-csrc |text/plain mime type|| Attachment #45636|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #27 from Alex Deucher 2011-04-14 15:31:11 PDT --- Created an attachment (id=45637) View: https://bugs.freedesktop.org/attachment.cgi?id=45637 Review: https://bugs.freedesktop.org/review?bug=36221=45637 2.6.37 patch looks like the file changed slightly in newer kernels. Try this patch. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #26 from revealed 2011-04-14 15:27:06 PDT --- Created an attachment (id=45636) --> (https://bugs.freedesktop.org/attachment.cgi?id=45636) i2c-algo-bit.c from SuSE rpm; ?? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #25 from revealed 2011-04-14 15:21:32 PDT --- But if i run make with this file, i get: CC [M] drivers/i2c/algos/i2c-algo-bit.o drivers/i2c/algos/i2c-algo-bit.c: In Funktion ?i2c_bit_prepare_bus?: drivers/i2c/algos/i2c-algo-bit.c:623:3: Warnung: ?bergabe des Arguments 1 von ?test_bus? von inkompatiblem Zeigertyp drivers/i2c/algos/i2c-algo-bit.c:235:12: Anmerkung: expected ?struct i2c_adapter *? but argument is of type ?struct i2c_algo_bit_data *? CC [M] drivers/i2c/algos/i2c-algo-pca.o LD drivers/i2c/busses/built-in.o And it continues. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221
--- Comment #24 from revealed 2011-04-14 15:20:03
PDT ---
Starting new with the downloaded patch and the original file from SUSE rpm i
get the following output in the rej. file when issuing the:
Patch command: (forget my last both postings, please).
--- drivers/i2c/algos/i2c-algo-bit.c
+++ drivers/i2c/algos/i2c-algo-bit.c
@@ -622,7 +637,7 @@
int ret;
if (bit_test) {
- ret = test_bus(bit_adap, adap->name);
+ ret = test_bus(adap, adap->name);
if (ret < 0)
return -ENODEV;
}
drivers/i2c/algos/i2c-algo-bit.c.rej lines 1-11/11 (END)
I guess there is something wrong with the patch?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #23 from revealed 2011-04-14 15:16:35 PDT --- patch -p1 -i 0001-i2c-algo-bit-make-sure-to-call-pre-post_xfer-for-bit.patch patching file drivers/i2c/algos/i2c-algo-bit.c Hunk #1 FAILED at 232. Hunk #2 FAILED at 297. Hunk #3 FAILED at 607. 3 out of 3 hunks FAILED -- saving rejects to file drivers/i2c/algos/i2c-algo-bit.c.rej -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #22 from revealed 2011-04-14 15:05:08 PDT --- drivers/i2c/algos/i2c-algo-bit.c: In Funktion ?test_bus?: drivers/i2c/algos/i2c-algo-bit.c:237:28: Fehler: ?adap? als andere Symbolart redeklariert drivers/i2c/algos/i2c-algo-bit.c:235:47: Anmerkung: Vorherige Definition von ?adap? war hier drivers/i2c/algos/i2c-algo-bit.c:237:35: Fehler: ?i2c_adap? undeclared (first use in this function) drivers/i2c/algos/i2c-algo-bit.c:237:35: Anmerkung: each undeclared identifier is reported only once for each function it appears in drivers/i2c/algos/i2c-algo-bit.c: In Funktion ?i2c_bit_prepare_bus?: drivers/i2c/algos/i2c-algo-bit.c:623:3: Warnung: ?bergabe des Arguments 1 von ?test_bus? von inkompatiblem Zeigertyp drivers/i2c/algos/i2c-algo-bit.c:235:12: Anmerkung: expected ?struct i2c_algo_bit_data *? but argument is of type ?struct i2c_adapter *? drivers/i2c/algos/i2c-algo-bit.c:620:28: Warnung: Variable ?bit_adap? wird nicht verwendet make[3]: *** [drivers/i2c/algos/i2c-algo-bit.o] Error 1 make[2]: *** [drivers/i2c/algos] Error 2 make[1]: *** [drivers/i2c] Error 2 make: *** [drivers] Fehler 2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #21 from revealed 2011-04-14 14:44:09 PDT --- I did: make oldconfig now i am running make? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #20 from revealed 2011-04-14 14:41:15 PDT --- done! Will proceed with steps from comment 17. Greetings, -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221
--- Comment #19 from Alex Deucher 2011-04-14 14:39:07 PDT
---
(In reply to comment #18)
> Ok i will do but i have one question:
>
> The last line to add from the diff looks different in my version:
>
> My Version says:
>
> if (bit_test) {
> int ret = test_bus(bit_adap, adap->name);
> if (ret < 0)
> return -ENODEV;
> }
>
>
> Do i have to remove the 'int' too?
>
in your case keep it. Change it to:
int ret = test_bus(adap, adap->name);
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221
--- Comment #18 from revealed 2011-04-14 14:34:47
PDT ---
Ok i will do but i have one question:
The last line to add from the diff looks different in my version:
My Version says:
if (bit_test) {
int ret = test_bus(bit_adap, adap->name);
if (ret < 0)
return -ENODEV;
}
Do i have to remove the 'int' too?
Many thanks!
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #17 from Alex Deucher 2011-04-14 14:28:40 PDT --- (In reply to comment #16) > I would! > > Do i have to edit the file in: > /usr/src/linux-2.6.37.1-1.2/drivers/i2c/algos/i2c-algo-bit.c yes, just download the patch into /usr/src/linux-2.6.37.1-1.2/ and run: patch -p1 -i 0001-i2c-algo-bit-make-sure-to-call-pre-post_xfer-for-bit.patch > > And make the i2c-algo-bit somehow? I cant remember properly if i can recompile > a single module? I dont need to translate the whole kernel? > from /usr/src/linux-2.6.37.1-1.2/ run: make make modules make modules_install make install and select the new kernel in grub. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #16 from revealed 2011-04-14 14:22:20 PDT --- I would! Do i have to edit the file in: /usr/src/linux-2.6.37.1-1.2/drivers/i2c/algos/i2c-algo-bit.c And make the i2c-algo-bit somehow? I cant remember properly if i can recompile a single module? I dont need to translate the whole kernel? Can give me a hint? Greetings, R -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32402] Oops associated with radeon_unpin_work_func
https://bugzilla.kernel.org/show_bug.cgi?id=32402 Adriano changed: What|Removed |Added CC||adriano.vilela at yahoo.com --- Comment #10 from Adriano 2011-04-14 14:11:32 --- I'm having this problem too with kernel 2.6.38 series. As soon as my screen saver kicks in, my entire desktop gets corrupted. If I wait long enough for my screen to stand by or suspend (just the screen, not the computer), then the computer completely freezes. I'm not sure if I can add attachments to bugs reported by others; if so, I would be happy to attach a picture with the error messages. Please, let me know how I can help with this issue. Thank you, Adriano -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 Alex Deucher changed: What|Removed |Added Attachment #45619|0 |1 is obsolete|| --- Comment #15 from Alex Deucher 2011-04-14 14:03:58 PDT --- Created an attachment (id=45633) View: https://bugs.freedesktop.org/attachment.cgi?id=45633 Review: https://bugs.freedesktop.org/review?bug=36221=45633 better fix Is there any way you could test this patch? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36236] Problems with lights in Trine game from www.humblebundle.com
https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #3 from dcelasun at gmail.com 2011-04-14 13:28:46 PDT --- The quote the game developer's post over at Phoronix: The lights are missing. Which means that deferred phase is not working. Which means that most likely G-buffers are not filled correctly because multiple render targets do not work. This should probably be filed as a bug against the driver. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #14 from revealed 2011-04-14 13:13:47 PDT --- Ok. I am so happy at the moment having working desktop effects and such :D -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Linux 2.6.39-rc3
Hello, On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote: > On Wednesday, April 13, 2011, Linus Torvalds > wrote: > > On Wednesday, April 13, 2011, H. Peter Anvin wrote: > >> > >> Yes. ?However, even if we *do* revert (and the time is running short on > >> not reverting) I would like to understand this particular one, simply > >> because I think it may very well be a problem that is manifesting itself > >> in other ways on other systems. > > sorry, fingerfart. Anyway, I agree 100%. > > we definitely want to also understand the reason for things not > working, even if we do revert.. There were (and still are) places where memblock callers implemented ad-hoc top-down allocation by stepping down start limit until allocation succeeds. Several of them have been removed since top-down became the default behavior, so simply reverting the commit is likely to cause subtle issues. Maybe the best approach is introducing @topdown parameter and use it selectively for pure memory allocations. Thanks. -- tejun
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #13 from Alex Deucher 2011-04-14 12:37:33 PDT --- (In reply to comment #12) > Oh yes :) > > Sorry! I have to also omit that i have an open bugreport at novell bugzilla > since februar. I was getting few response. Thats the reason i opened this > bugreport here. > > I set that one in novel bugzilla to resolved. > > https://bugzilla.novell.com/show_bug.cgi?id=669937 > > I know this is a very unkind multiposting from me. I want to apologize for > this. No worries :) > I guess the report in novell bugzilla is unnecessary now? Leave it open for now. They might have some ideas why i2c-algo-bit.bit_test=1 is set by default. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Linux 2.6.39-rc3
On Wed, 2011-04-13 at 18:58 -0700, H. Peter Anvin wrote: > On 04/13/2011 12:14 PM, Yinghai Lu wrote: > > > > so those two patches uncover some problems. > > > > [0.00] Checking aperture... > > [0.00] No AGP bridge found > > [0.00] Node 0: aperture @ a000 size 32 MB > > [0.00] Aperture pointing to e820 RAM. Ignoring. > > [0.00] Your BIOS doesn't leave a aperture memory hole > > [0.00] Please enable the IOMMU option in the BIOS setup > > [0.00] This costs you 64 MB of RAM > > [0.00] memblock_x86_reserve_range: [0xa000-0xa3ff] > > aperture64 > > [0.00] Mapping aperture over 65536 KB of RAM @ a000 > > > > so kernel try to reallocate apperture. because BIOS allocated is pointed to > > RAM or size is too small. > > > > but your radeon does use [0xa000, 0xbfff) > > > > [4.281993] radeon :01:05.0: VRAM: 320M 0xC000 - > > 0xD3FF (320M used) > > [4.290672] radeon :01:05.0: GTT: 512M 0xA000 - > > 0xBFFF > > [4.298550] [drm] Detected VRAM RAM=320M, BAR=256M > > [4.309857] [drm] RAM width 32bits DDR > > [4.313748] [TTM] Zone kernel: Available graphics memory: 1896524 kiB. > > [4.320379] [TTM] Initializing pool allocator. > > [4.324948] [drm] radeon: 320M of VRAM memory ready > > [4.329832] [drm] radeon: 512M of GTT memory ready. > > > > and the one seems working: > > > > [0.00] Checking aperture... > > [0.00] No AGP bridge found > > [0.00] Node 0: aperture @ a000 size 32 MB > > [0.00] Aperture pointing to e820 RAM. Ignoring. > > [0.00] Your BIOS doesn't leave a aperture memory hole > > [0.00] Please enable the IOMMU option in the BIOS setup > > [0.00] This costs you 64 MB of RAM > > [0.00] memblock_x86_reserve_range: [0x8000-0x83ff] > > aperture64 > > [0.00] Mapping aperture over 65536 KB of RAM @ 8000 > > [0.00] memblock_x86_reserve_range: [0xacb6bdc0-0xacb6bddf] > > BOOTMEM > > > > will use different position... > > > > [4.250159] radeon :01:05.0: VRAM: 320M 0xC000 - > > 0xD3FF (320M used) > > [4.258830] radeon :01:05.0: GTT: 512M 0xA000 - > > 0xBFFF > > [4.266742] [drm] Detected VRAM RAM=320M, BAR=256M > > [4.271549] [drm] RAM width 32bits DDR > > [4.275435] [TTM] Zone kernel: Available graphics memory: 1896526 kiB. > > [4.282066] [TTM] Initializing pool allocator. > > [4.282085] usb 7-2: new full speed USB device number 2 using ohci_hcd > > [4.293076] [drm] radeon: 320M of VRAM memory ready > > [4.298277] [drm] radeon: 512M of GTT memory ready. > > [4.303218] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > > [4.309854] [drm] Driver supports precise vblank timestamp query. > > [4.315970] [drm] radeon: irq initialized. > > [4.320094] [drm] GART: num cpu pages 131072, num gpu pages 131072 > > > > So question is why radeon is using the address [0xa000 - 0xc00], > > and in E820 it is RAM > > > > [0.00] BIOS-e820: 0010 - acb8d000 (usable) > > [0.00] BIOS-e820: acb8d000 - acb8f000 (reserved) > > [0.00] BIOS-e820: acb8f000 - afce9000 (usable) > > [0.00] BIOS-e820: afce9000 - afd21000 (reserved) > > [0.00] BIOS-e820: afd21000 - afd4f000 (usable) > > [0.00] BIOS-e820: afd4f000 - afdcf000 (reserved) > > [0.00] BIOS-e820: afdcf000 - afecf000 (ACPI NVS) > > [0.00] BIOS-e820: afecf000 - afeff000 (ACPI data) > > [0.00] BIOS-e820: afeff000 - aff0 (usable) > > > > so looks bios program wrong address to the radon card? > > > > Okay, staring at this, it definitely seems toxic to overlay the GART > over memory areas reserved by the BIOS. If I were to guess, I would say > that the problem here seems to be that the kernel thinks it is > overlaying 64 MiB of memory, but the actual GART is in fact 512 MiB in > size -- 131072 CPU pages -- which now overlaps the BIOS reserved areas. > > Alex D., could you comment on the "num cpu pages" bit? These are not CPU addresses. I think we've stated that already. Not the droids. the num cpu pages is how many CPU pages would be needed to fill the GPU GTT, for those crazy cases where CPU pagesize != GPU pagesize. Dave.
Linux 2.6.39-rc3
On Thu, Apr 14, 2011 at 01:03:37PM +0900, Tejun Heo wrote: > Hello, > > On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote: > > On Wednesday, April 13, 2011, Linus Torvalds > > wrote: > > > On Wednesday, April 13, 2011, H. Peter Anvin wrote: > > >> > > >> Yes. ?However, even if we *do* revert (and the time is running short on > > >> not reverting) I would like to understand this particular one, simply > > >> because I think it may very well be a problem that is manifesting itself > > >> in other ways on other systems. > > > > sorry, fingerfart. Anyway, I agree 100%. > > > > we definitely want to also understand the reason for things not > > working, even if we do revert.. > > There were (and still are) places where memblock callers implemented > ad-hoc top-down allocation by stepping down start limit until > allocation succeeds. Several of them have been removed since top-down > became the default behavior, so simply reverting the commit is likely > to cause subtle issues. Maybe the best approach is introducing > @topdown parameter and use it selectively for pure memory allocations. Wouldn't it be better to provide a seperate memblock allocation function which operates top-down and use this one in the places that need it? This way it wouldn't break code that relies on bottom-up. Joerg
[PATCH] drm/radeon/kms: fix bad shift in atom iio table parser
Noticed by Patrick Lowry. Signed-off-by: Alex Deucher Cc: stable at kernel.org --- drivers/gpu/drm/radeon/atom.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c index d71d375..7bd7456 100644 --- a/drivers/gpu/drm/radeon/atom.c +++ b/drivers/gpu/drm/radeon/atom.c @@ -135,7 +135,7 @@ static uint32_t atom_iio_execute(struct atom_context *ctx, int base, case ATOM_IIO_MOVE_INDEX: temp &= ~((0x >> (32 - CU8(base + 1))) << - CU8(base + 2)); + CU8(base + 3)); temp |= ((index >> CU8(base + 2)) & (0x >> (32 - CU8(base + 1 << CU8(base + @@ -145,7 +145,7 @@ static uint32_t atom_iio_execute(struct atom_context *ctx, int base, case ATOM_IIO_MOVE_DATA: temp &= ~((0x >> (32 - CU8(base + 1))) << - CU8(base + 2)); + CU8(base + 3)); temp |= ((data >> CU8(base + 2)) & (0x >> (32 - CU8(base + 1 << CU8(base + @@ -155,7 +155,7 @@ static uint32_t atom_iio_execute(struct atom_context *ctx, int base, case ATOM_IIO_MOVE_ATTR: temp &= ~((0x >> (32 - CU8(base + 1))) << - CU8(base + 2)); + CU8(base + 3)); temp |= ((ctx-> io_attr >> CU8(base + 2)) & (0x >> (32 - -- 1.7.1.1
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #12 from revealed 2011-04-14 11:14:14 PDT --- Oh yes :) Sorry! I have to also omit that i have an open bugreport at novell bugzilla since februar. I was getting few response. Thats the reason i opened this bugreport here. I set that one in novel bugzilla to resolved. https://bugzilla.novell.com/show_bug.cgi?id=669937 I know this is a very unkind multiposting from me. I want to apologize for this. I guess the report in novell bugzilla is unnecessary now? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Linux 2.6.39-rc3
* Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 06:58:46PM -0700, H. Peter Anvin wrote:
> > On 04/13/2011 12:14 PM, Yinghai Lu wrote:
> > >
> > > so looks bios program wrong address to the radon card?
> > >
> >
> > Okay, staring at this, it definitely seems toxic to overlay the GART
> > over memory areas reserved by the BIOS. If I were to guess, I would say
> > that the problem here seems to be that the kernel thinks it is
> > overlaying 64 MiB of memory, but the actual GART is in fact 512 MiB in
> > size -- 131072 CPU pages -- which now overlaps the BIOS reserved areas.
> >
> > Alex D., could you comment on the "num cpu pages" bit?
>
> Okay, I tried the debug-patch from Yinghai (posted to the bugzilla):
>
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -325,6 +325,8 @@ void radeon_gtt_location(struct radeon_device *rdev,
> struct radeon_mc *mc)
> mc->gtt_size = size_bf;
> }
> mc->gtt_start = (mc->vram_start & ~mc->gtt_base_align) -
> mc->gtt_size;
> + if (mc->gtt_start == 0xa000)
> + mc->gtt_start = 0x8000;
> } else {
> if (mc->gtt_size > size_af) {
> dev_warn(rdev->dev, "limiting GTT\n");
>
> And this makes a difference, with this change on-top of -rc3 the box boots
> fine. So there seems to be some dependency between the GART base and the GTT
> base even when they are in different address spaces.
>
> Alex, can you comment on this?
I'd strongly suggest we revert back to the old and proven allocation order, as
long as it results in valid layouts. Even if we figure out this particular
GART/GTT assumption there might be a dozen others in other types of hardware.
Thanks,
Ingo
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 Alex Deucher changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #11 from Alex Deucher 2011-04-14 11:10:36 PDT --- Leave this open until we get some feedback from Suse or the i2c people. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #10 from Alex Deucher 2011-04-14 11:06:31 PDT --- Created an attachment (id=45619) View: https://bugs.freedesktop.org/attachment.cgi?id=45619 Review: https://bugs.freedesktop.org/review?bug=36221=45619 possible fix This patch should fix the issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 Alex Deucher changed: What|Removed |Added Resolution|WORKSFORME |FIXED --- Comment #9 from Alex Deucher 2011-04-14 11:05:36 PDT --- (In reply to comment #8) > Sorry for doubleposting: > > I added the option to menu.lst; As workaround. Thank you for the hint! > > Also i tried commenting out the option in 50-tv.conf; And i removed the newly > added bootparameter for a test. > > The issue came back in this constellation. So the value seems to be set as > default. odd. maybe your distro changed the default in their kernel source. > > Possible requirement for my TV-Card? No. It's a debugging option for i2c. You could potentially run into the same issue with another driver that uses i2c bit algo. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 revealed changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Linux 2.6.39-rc3
On Wed, Apr 13, 2011 at 03:31:09PM -0700, H. Peter Anvin wrote: > On 04/13/2011 03:22 PM, Joerg Roedel wrote: > > On Wed, Apr 13, 2011 at 03:01:10PM -0700, H. Peter Anvin wrote: > >> On 04/13/2011 02:50 PM, Joerg Roedel wrote: > >>> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote: > -addr = memblock_find_in_range(0, 1ULL<<32, aper_size, > 512ULL<<20); > +addr = memblock_find_in_range(0, 1ULL<<32, aper_size, > 512ULL<<21); > >>> > >>> Btw, while looking at this code I wondered why the 512M goal is enforced > >>> by the alignment. Start could be set to 512M instead and the alignment > >>> can be aper_size as it should. Any reason for such a big alignment? > >>> > >>> Joerg > >>> > >>> P.S.: The box is still in the office, I will try this debug-patch > >>> tomorrow. > >> > >> The only reason that I can think of is that the aperture itself can be > >> huge, and perhaps 512 MiB is the biggest such known. > > > > Well, that would work as well by just using aper_size as alignment, the > > aperture needs to be aligned on its size anyway. This code only runs > > when Linux allocates the aperture itself and if I am mistaken is uses > > always 64MB when doing this. > > Yes, I would agree with that. The sane thing would be to set the base > to whatever address needs to be guarded against (WHICH SHOULD BE > MOTIVATED), and use aper_size as alignment, *unless* we are only using > the initial portion of a much larger hardware structure that needs > natural alignment (which isn't clear to me, I do know we sometimes use > only a fraction of the GART, but that doesn't mean we need to > naturally-align the entire thing, nor that 512 MiB is sufficient to do so.) Whats allocated here is the address-space for the aperture. The code actually allocates the memory but all it needs is the physical address range. This range is later programmed into hardware as the GART aperture (the area the GART remaps). The Linux code can split the aperture if necessary for DMA-API usage and AGP usage. In that case both users get a half of the aperture and manage them itself. Joerg
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #8 from revealed 2011-04-14 10:58:39 PDT --- Sorry for doubleposting: I added the option to menu.lst; As workaround. Thank you for the hint! Also i tried commenting out the option in 50-tv.conf; And i removed the newly added bootparameter for a test. The issue came back in this constellation. So the value seems to be set as default. Possible requirement for my TV-Card? I can live with adding this as bootparameter to menu.lst Many Thanks! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 33867] [bisected] Graphics corruption related to pageflip ioctl support in 2.6.38-rc*
https://bugs.freedesktop.org/show_bug.cgi?id=33867 --- Comment #15 from Alex Deucher 2011-04-14 10:56:48 PDT --- possibly a dupe of bug 35452 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Linux 2.6.39-rc3
On Wed, Apr 13, 2011 at 06:58:46PM -0700, H. Peter Anvin wrote:
> On 04/13/2011 12:14 PM, Yinghai Lu wrote:
> >
> > so looks bios program wrong address to the radon card?
> >
>
> Okay, staring at this, it definitely seems toxic to overlay the GART
> over memory areas reserved by the BIOS. If I were to guess, I would say
> that the problem here seems to be that the kernel thinks it is
> overlaying 64 MiB of memory, but the actual GART is in fact 512 MiB in
> size -- 131072 CPU pages -- which now overlaps the BIOS reserved areas.
>
> Alex D., could you comment on the "num cpu pages" bit?
Okay, I tried the debug-patch from Yinghai (posted to the bugzilla):
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -325,6 +325,8 @@ void radeon_gtt_location(struct radeon_device *rdev, struct
radeon_mc *mc)
mc->gtt_size = size_bf;
}
mc->gtt_start = (mc->vram_start & ~mc->gtt_base_align) -
mc->gtt_size;
+ if (mc->gtt_start == 0xa000)
+ mc->gtt_start = 0x8000;
} else {
if (mc->gtt_size > size_af) {
dev_warn(rdev->dev, "limiting GTT\n");
And this makes a difference, with this change on-top of -rc3 the box boots
fine. So there seems to be some dependency between the GART base and the GTT
base even when they are in different address spaces.
Alex, can you comment on this?
Regards,
Joerg
[Bug 34137] Kernel null pointer dereference with 2.6.38_rc4, pageflip, Radeon 6310, KDE
https://bugs.freedesktop.org/show_bug.cgi?id=34137 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #7 from revealed 2011-04-14 10:48:28 PDT --- Ha! So the problem seems to have existed due to my TV-Card: cd /etc/modprobe.d/ disk at wild-thing:/etc/modprobe.d> grep i2c * 50-blacklist.conf:blacklist i2c-matroxfb 50-tv.conf:options i2c-algo-bit bit_test=1 Man!! :D I thank you so much! I dont know why this is enabled in 50-tv.conf; I have a Hauppauge PVR 150. I dont know if this has to be enabled for it. But it is... Greetings, R -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] drm: emit change events when mode config changes
We've already seen that apps want to monitor the display config, and
some (like upowerd) poll for changes since we don't provide a
notification for general mode config changes, just hotplug events. So
add a new drm event, with CHANGE=1 set in the event, to allow for it.
Signed-off-by: Jesse Barnes
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4c95b5f..174ee64 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1589,6 +1589,8 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.fb = fb;
ret = crtc->funcs->set_config();
+ drm_sysfs_change_event(dev);
+
out:
kfree(connector_set);
mutex_unlock(>mode_config.mutex);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9507204..df946d4 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -822,6 +822,8 @@ int drm_fb_helper_set_par(struct fb_info *info)
return ret;
}
}
+
+ drm_sysfs_change_event(dev);
mutex_unlock(>mode_config.mutex);
if (fb_helper->delayed_hotplug) {
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 2eee8e0..fd3af31 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -467,9 +467,9 @@ EXPORT_SYMBOL(drm_sysfs_connector_remove);
* drm_sysfs_hotplug_event - generate a DRM uevent
* @dev: DRM device
*
- * Send a uevent for the DRM device specified by @dev. Currently we only
- * set HOTPLUG=1 in the uevent environment, but this could be expanded to
- * deal with other types of events.
+ * Send a uevent for the DRM device specified by @dev. Set HOTPLUG=1 in the
+ * event to indicate a display config change occurred, probably due to a
+ * display being added or removed.
*/
void drm_sysfs_hotplug_event(struct drm_device *dev)
{
@@ -483,6 +483,24 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
EXPORT_SYMBOL(drm_sysfs_hotplug_event);
/**
+ * drm_sysfs_change_event - generate a DRM uevent indicating a display config
change
+ * @dev: DRM device
+ *
+ * Send a uevent for the DRM device specified by @dev. Set CHANGE=1 to
+ * indicate that a userspace initiated display configuration change occurred.
+ */
+void drm_sysfs_change_event(struct drm_device *dev)
+{
+ char *event_string = "CHANGE=1";
+ char *envp[] = { event_string, NULL };
+
+ DRM_DEBUG("generating hotplug event\n");
+
+ kobject_uevent_env(>primary->kdev.kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(drm_sysfs_change_event);
+
+/**
* drm_sysfs_device_add - adds a class device to sysfs for a character driver
* @dev: DRM device to be added
* @head: DRM head in question
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index ad5770f..3aff8fc 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1506,6 +1506,7 @@ extern struct class *drm_sysfs_create(struct module
*owner, char *name);
extern void drm_sysfs_destroy(void);
extern int drm_sysfs_device_add(struct drm_minor *minor);
extern void drm_sysfs_hotplug_event(struct drm_device *dev);
+extern void drm_sysfs_change_event(struct drm_device *dev);
extern void drm_sysfs_device_remove(struct drm_minor *minor);
extern char *drm_get_connector_status_name(enum drm_connector_status status);
extern int drm_sysfs_connector_add(struct drm_connector *connector);
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #6 from Alex Deucher 2011-04-14 10:30:21 PDT --- (In reply to comment #5) > Yes :D > > Computer boots up fine with this switch! Love that! :D > > Is that fixable? The default value for i2c-algo-bit.bit_test is 0. For some reason Suse sets it to 1. You can manually adjust it by editing the i2c_algo_bit entry in the files in /etc/modprobe.d/ -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Linux 2.6.39-rc3
On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 06:58:46PM -0700, H. Peter Anvin wrote:
>> On 04/13/2011 12:14 PM, Yinghai Lu wrote:
>> >
>> > so looks bios program wrong address to the radon card?
>> >
>>
>> Okay, staring at this, it definitely seems toxic to overlay the GART
>> over memory areas reserved by the BIOS. ?If I were to guess, I would say
>> that the problem here seems to be that the kernel thinks it is
>> overlaying 64 MiB of memory, but the actual GART is in fact 512 MiB in
>> size -- 131072 CPU pages -- which now overlaps the BIOS reserved areas.
>>
>> Alex D., could you comment on the "num cpu pages" bit?
>
> Okay, I tried the debug-patch from Yinghai (posted to the bugzilla):
>
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -325,6 +325,8 @@ void radeon_gtt_location(struct radeon_device *rdev,
> struct radeon_mc *mc)
> ? ? ? ? ? ? ? ? ? ? ? ?mc->gtt_size = size_bf;
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?mc->gtt_start = (mc->vram_start & ~mc->gtt_base_align) -
> mc->gtt_size;
> + ? ? ? ? ? ? ? if (mc->gtt_start == 0xa000)
> + ? ? ? ? ? ? ? ? ? ? ? mc->gtt_start = 0x8000;
> ? ? ? ?} else {
> ? ? ? ? ? ? ? ?if (mc->gtt_size > size_af) {
> ? ? ? ? ? ? ? ? ? ? ? ?dev_warn(rdev->dev, "limiting GTT\n");
>
> And this makes a difference, with this change on-top of -rc3 the box boots
> fine. So there seems to be some dependency between the GART base and the GTT
> base even when they are in different address spaces.
>
> Alex, can you comment on this?
As Dave said, they are completely different addresses spaces. You
could put the GPU aperture at 0 if you wanted (in fact we do on some
chips). Perhaps there's some strange interaction with the nb gart
since the nb gart on that chipset was designed to be used for graphics
and the rs780/880 can be configured to use an agp aperture.
Unfortunately, I'm not that familiar with the nb gart.
Alex
>
> Regards,
>
> ? ? ? ?Joerg
>
>
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #5 from revealed 2011-04-14 09:58:55 PDT --- Yes :D Computer boots up fine with this switch! Love that! :D Is that fixable? Many thanks! Greetings, R -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #4 from Alex Deucher 2011-04-14 09:44:35 PDT --- Does booting with: i2c-algo-bit.bit_test=0 on the kernel command line in grub fix the issue? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] Big Endian support for RV730 (Mesa r600)
Le 13/04/2011 14:10, Benjamin Herrenschmidt a ?crit : > On Wed, 2011-04-13 at 22:05 +1000, Benjamin Herrenschmidt wrote: >> On Tue, 2011-04-12 at 10:01 +0200, C?dric Cano wrote: >>> Hi >>> >>> Here you are a patch that adds big endian support for rv730 in r600 >>> classic mesa driver. The BE modifications are almost the same as the DRM >>> / DDX driver modifications >>> (http://lists.freedesktop.org/archives/dri-devel/2011-February/008151.html). >>> >>> I used the mesa-demos to test the driver status on big endian platform. >>> Nearly all demos renders the same as on Intel architecture. >>> Nevertheless, there are still some issues in glReadPixels (r600_blit) >>> with some formats. I can't figure out exactly what and when data must be >>> swapped (set_tex_resoures, set_render_target...). Review of the patch >>> would be greatly appreciated. >>> >>> It seems that r600g will be the default for Mesa 7.11 so I'll try to >>> enable big endian support for Gallium now. >> Cool stuff ! >> >> I'll try to test that one of these days on various ppc's > BTW. I see you used some FSL embedded board. Do you have your PCIe MMIO > space above 32-bit ? Last I looked, there was a bunch of fixing needing > to be done, among others in the TTM, to make that work. > > I had some preliminary patches but they bitrot... mostly the issue is to > make sure than a phys_addr_t is used instead of an unsigned long > whenever it tries to store the physical address of an object. > > Ben. > > > Hi Ben, I don't use Freescale eval boards but our custom PowerPC design. We didn't enable the 36-bit addressing mode yet. C?dric
[Bug 34534] resolution 3840x1024 stopped to work on HD5850 after switch to 2.6.37 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=34534 --- Comment #17 from Alex Deucher 2011-04-14 09:30:02 PDT --- Created an attachment (id=45616) View: https://bugs.freedesktop.org/attachment.cgi?id=45616 Review: https://bugs.freedesktop.org/review?bug=34534=45616 possible fix Does this patch help? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36221] KMS with X1950 XT i2c error --> no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #3 from revealed 2011-04-14 09:23:32 PDT --- Created an attachment (id=45615) --> (https://bugs.freedesktop.org/attachment.cgi?id=45615) lspci -vnn -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Linux 2.6.39-rc3
On Wed, 13 Apr 2011 19:33:40 -0700 Linus Torvalds wrote: > On Wednesday, April 13, 2011, Linus Torvalds > wrote: > > On Wednesday, April 13, 2011, H. Peter Anvin wrote: > >> > >> Yes. ?However, even if we *do* revert (and the time is running short on > >> not reverting) I would like to understand this particular one, simply > >> because I think it may very well be a problem that is manifesting itself > >> in other ways on other systems. > > sorry, fingerfart. Anyway, I agree 100%. > > we definitely want to also understand the reason for things not > working, even if we do revert.. Definitely because if it fails when the "magic" involves the GART base it starts to sound like something may be hitting the wrong address space or not flushing properly.
[Bug 36236] Problems with lights in Trine game from www.humblebundle.com
https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #2 from Sven Arvidsson 2011-04-14 09:02:12 PDT --- Created an attachment (id=45613) --> (https://bugs.freedesktop.org/attachment.cgi?id=45613) Correct rendering of Windows version Same problem with softpipe, so the bug should probably be reassigned to Mesa core. I tried swrast too, but it will not run the game. Just for reference, I have attached a screenshot of how it's supposed to look. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34155] [drm:radeon_crtc_page_flip] *ERROR* failed to reserve new rbo buffer before flip
https://bugs.freedesktop.org/show_bug.cgi?id=34155 --- Comment #2 from Alexandre Demers 2011-04-14 08:45:50 PDT --- When testing with latest drm and kernel, I can't find the error anymore. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36236] Problems with lights in Trine game from www.humblebundle.com
https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #1 from Krzysztof A. Sobiecki 2011-04-14 08:39:06 PDT --- Created an attachment (id=45612) --> (https://bugs.freedesktop.org/attachment.cgi?id=45612) Screenshot of the problem using llvmpipe LIBGL_ALWAYS_SOFTWARE=yes ./trine-bin64 glxinfo: name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_INTEL_swap_event client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_framebuffer_sRGB, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event GLX version: 1.4 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_multithread_makecurrent, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_INTEL_swap_event OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on llvmpipe OpenGL version string: 2.1 Mesa 7.11-devel (git-78e90bf) OpenGL shading language version string: 1.20 OpenGL extensions: GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object, GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture, GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters, GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_separate_specular_color, GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_ARB_framebuffer_sRGB, GL_ARB_multitexture, GL_EXT_framebuffer_sRGB, GL_IBM_multimode_draw_arrays, GL_IBM_texture_mirrored_repeat, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_blend_func_separate, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_secondary_color, GL_EXT_texture_env_add, GL_EXT_texture_lod_bias, GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texgen_reflection, GL_NV_texture_env_combine4, GL_S3_s3tc, GL_SUN_multi_draw_arrays, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_EXT_framebuffer_object, GL_EXT_texture_compression_s3tc, GL_EXT_texture_env_dot3, GL_MESA_window_pos, GL_NV_packed_depth_stencil, GL_NV_texture_rectangle, GL_ARB_depth_texture, GL_ARB_occlusion_query, GL_ARB_shadow, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_window_pos, GL_EXT_stencil_two_side, GL_EXT_texture_cube_map, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_shader_objects, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_primitive_restart, GL_ARB_fragment_program_shadow, GL_ARB_half_float_pixel, GL_ARB_occlusion_query2, GL_ARB_point_sprite, GL_ARB_shading_language_100, GL_ARB_sync, GL_ARB_texture_non_power_of_two, GL_ARB_vertex_buffer_object, GL_ATI_blend_equation_separate, GL_EXT_blend_equation_separate, GL_OES_read_format, GL_ARB_pixel_buffer_object, GL_ARB_texture_rectangle, GL_EXT_pixel_buffer_object, GL_EXT_texture_compression_dxt1, GL_EXT_texture_mirror_clamp, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_ARB_framebuffer_object, GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample, GL_EXT_packed_depth_stencil, GL_ARB_vertex_array_object, GL_ATI_separate_stencil, GL_ATI_texture_mirror_once, GL_EXT_draw_buffers2, GL_EXT_draw_instanced, GL_EXT_gpu_program_parameters, GL_EXT_texture_env_combine, GL_EXT_texture_sRGB_decode, GL_OES_EGL_image, GL_ARB_copy_buffer, GL_ARB_draw_instanced,
[Bug 36037] RV250Lf: airlied/drm-fixes branch crashes in new backlight code
https://bugs.freedesktop.org/show_bug.cgi?id=36037 --- Comment #9 from Matthew Garrett 2011-04-14 08:29:30 PDT --- That's bizarre. I can't see any obvious way this could happen. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36037] RV250Lf: airlied/drm-fixes branch crashes in new backlight code
https://bugs.freedesktop.org/show_bug.cgi?id=36037 --- Comment #8 from Michel D?nzer 2011-04-14 07:59:21 PDT --- So bl_get_data() returns NULL in radeon_legacy_backlight_get_brightness(). I'm stumped as to how that could happen... Any ideas, Matthew? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36236] New: Problems with lights in Trine game from www.humblebundle.com
https://bugs.freedesktop.org/show_bug.cgi?id=36236 Summary: Problems with lights in Trine game from www.humblebundle.com Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: sobkas at gmail.com Created an attachment (id=45611) --> (https://bugs.freedesktop.org/attachment.cgi?id=45611) Screenshot of the problem According to turol( http://phoronix.com/forums/showthread.php?46124-Here-s-The-Third-Humble-Indie-Bundle=197456#post197456 ) there is problem with lights. glxinfo: name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_INTEL_swap_event client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_framebuffer_sRGB, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event GLX version: 1.4 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on ATI RV530 OpenGL version string: 2.1 Mesa 7.11-devel (git-78e90bf) OpenGL shading language version string: 1.20 OpenGL extensions: GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object, GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture, GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters, GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_separate_specular_color, GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_ARB_multitexture, GL_IBM_multimode_draw_arrays, GL_IBM_texture_mirrored_repeat, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_blend_func_separate, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_secondary_color, GL_EXT_texture_env_add, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texgen_reflection, GL_NV_texture_env_combine4, GL_S3_s3tc, GL_SUN_multi_draw_arrays, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_EXT_framebuffer_object, GL_EXT_texture_compression_s3tc, GL_EXT_texture_env_dot3, GL_MESA_window_pos, GL_NV_packed_depth_stencil, GL_NV_texture_rectangle, GL_ARB_depth_texture, GL_ARB_occlusion_query, GL_ARB_shadow, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_window_pos, GL_EXT_stencil_two_side, GL_EXT_texture_cube_map, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_shader_objects, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_ARB_fragment_program_shadow, GL_ARB_half_float_pixel, GL_ARB_occlusion_query2, GL_ARB_point_sprite, GL_ARB_shading_language_100, GL_ARB_sync, GL_ARB_texture_non_power_of_two, GL_ARB_vertex_buffer_object, GL_ATI_blend_equation_separate, GL_EXT_blend_equation_separate, GL_OES_read_format,
[Bug 36227] Radeon HD4250 crash with modeset=1
https://bugs.freedesktop.org/show_bug.cgi?id=36227 --- Comment #1 from Jerome Glisse 2011-04-14 07:44:13 PDT --- Please boot in runlevel 3 (add 3 to your kernel boot line) to avoid starting X, unloading the radeon non kms module might let the hw in fuzzy state. Once booted in run level 3 load radeon with the modeset=1 and attach the new kernel log here -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Linux 2.6.39-rc3
On 04/14/2011 02:11 AM, Ingo Molnar wrote: > > I'd strongly suggest we revert back to the old and proven allocation order, > as > long as it results in valid layouts. Even if we figure out this particular > GART/GTT assumption there might be a dozen others in other types of hardware. > Yes, but we might also be hiding a real bug which bites other hardware. We have found real and very serious bugs in the kernel this way before -- things where drivers scribble over random memory and allocation order exposed the failure in a predictable way, as opposed to random crashes. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
[PATCH] drm/radeon/kms: fix suspend on rv530 asics
On Thu, Apr 14, 2011 at 12:52 AM, Alex Deucher wrote:
> On Wed, Apr 13, 2011 at 10:46 AM, Jerome Glisse wrote:
>> On Tue, Apr 12, 2011 at 1:33 PM, Alex Deucher
>> wrote:
>>> Apparently only rv515 asics need the workaround
>>> added in f24d86f1a49505cdea56728b853a5d0a3f8e3d11
>>> (drm/radeon/kms: fix resume regression for some r5xx laptops).
>>>
>>> Fixes:
>>> https://bugs.freedesktop.org/show_bug.cgi?id=34709
>>>
>>> Signed-off-by: Alex Deucher
>>> Cc: stable at kernel.org
>>> ---
>>> ?drivers/gpu/drm/radeon/atom.c | ? ?6 +-
>>> ?1 files changed, 5 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
>>> index 258fa5e..d71d375 100644
>>> --- a/drivers/gpu/drm/radeon/atom.c
>>> +++ b/drivers/gpu/drm/radeon/atom.c
>>> @@ -32,6 +32,7 @@
>>> ?#include "atom.h"
>>> ?#include "atom-names.h"
>>> ?#include "atom-bits.h"
>>> +#include "radeon.h"
>>>
>>> ?#define ATOM_COND_ABOVE ? ? ? ? ? ? ? ?0
>>> ?#define ATOM_COND_ABOVEOREQUAL 1
>>> @@ -101,7 +102,9 @@ static void debug_print_spaces(int n)
>>> ?static uint32_t atom_iio_execute(struct atom_context *ctx, int base,
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? uint32_t index, uint32_t data)
>>> ?{
>>> + ? ? ? struct radeon_device *rdev = ctx->card->dev->dev_private;
>>> ? ? ? ?uint32_t temp = 0xCDCDCDCD;
>>> +
>>> ? ? ? ?while (1)
>>> ? ? ? ? ? ? ? ?switch (CU8(base)) {
>>> ? ? ? ? ? ? ? ?case ATOM_IIO_NOP:
>>> @@ -112,7 +115,8 @@ static uint32_t atom_iio_execute(struct atom_context
>>> *ctx, int base,
>>> ? ? ? ? ? ? ? ? ? ? ? ?base += 3;
>>> ? ? ? ? ? ? ? ? ? ? ? ?break;
>>> ? ? ? ? ? ? ? ?case ATOM_IIO_WRITE:
>>> - ? ? ? ? ? ? ? ? ? ? ? (void)ctx->card->ioreg_read(ctx->card, CU16(base +
>>> 1));
>>> + ? ? ? ? ? ? ? ? ? ? ? if (rdev->family == CHIP_RV515)
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (void)ctx->card->ioreg_read(ctx->card,
>>> CU16(base + 1));
>>> ? ? ? ? ? ? ? ? ? ? ? ?ctx->card->ioreg_write(ctx->card, CU16(base + 1),
>>> temp);
>>> ? ? ? ? ? ? ? ? ? ? ? ?base += 3;
>>> ? ? ? ? ? ? ? ? ? ? ? ?break;
>>> --
>>> 1.7.1.1
>>>
>>
>>
>> So this patch enable io write only for one family ? This looks utterly
>> strange.
>
> No, it just does a read before write for rv515. ?I don't know why it
> needs it, but it seems to.
>
Yeah I really wish I knew why either,
Thinkpad T60 with X1300, no resume without this, it failed in the
memory initialisation table. this was the only thing I could find to
fix it.
My x1300 desktop card works fine without this.
Dave.
[Bug 36227] New: Radeon HD4250 crash with modeset=1
https://bugs.freedesktop.org/show_bug.cgi?id=36227 Summary: Radeon HD4250 crash with modeset=1 Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: goldenfish at linuxsoft.cz Created an attachment (id=45600) --> (https://bugs.freedesktop.org/attachment.cgi?id=45600) kernel.log Radeon driver crash with module parameter modeset=1. HW environment: M4A88TD-V EVO/USB3 motherboard, AMD Phenom x6 CPU, 8GB RAM, 32 bit Linux OS. 2.6.39-rc3+ kernel. Integrated graphic card: goldenfish at goldenfish:~$ lspci -s "01:05.0" 01:05.0 VGA compatible controller: ATI Technologies Inc RS880 [Radeon HD 4250] Steps to reproduce: 0) boot with parameter radeon.modeset=0 .With parameter radeon.modeset=1 computer crash. 1) stop X-server 2) unload module radeon 3) load radeon module: modprobe radeon modeset=1 I got this Oops: Apr 13 21:40:30 goldenfish kernel: [ cut here ] Apr 13 21:40:30 goldenfish kernel: kernel BUG at drivers/gpu/drm/drm_irq.c:923! Apr 13 21:40:30 goldenfish kernel: invalid opcode: [#2] SMP Apr 13 21:40:30 goldenfish kernel: last sysfs file: /sys/devices/pci:00/:00:01.0/:01:05.0/graphics/fb0/uevent Apr 13 21:40:30 goldenfish kernel: Modules linked in: radeon(+) tcp_diag inet_diag binfmt_misc battery ipv6 powernow_k8 mperf cpufreq_ondemand cpufreq_stats freq_table cpufreq_userspace cpufreq_conservative cpufreq_powersave loop usbhid hid snd_hda_codec_hdmi snd_hda_codec_realtek snd_ice1724 snd_ice17xx_ak4xxx snd_ac97_codec snd_hda_intel ac97_bus snd_hda_codec snd_ak4xxx_adda snd_seq_dummy snd_hwdep snd_ak4114 snd_pt2258 snd_i2c snd_seq_oss snd_ak4113 snd_pcm_oss snd_seq_midi snd_mixer_oss snd_rawmidi snd_pcm snd_seq_midi_event snd_seq ohci_hcd snd_timer snd_seq_device snd xhci_hcd rtc_cmos rtc_core firewire_ohci(+) ehci_hcd soundcore usbcore firewire_core ttm rtc_lib drm_kms_helper r8169 snd_page_alloc drm processor asus_atk0110 evdev crc_itu_t button [last unloaded: radeon] Apr 13 21:40:30 goldenfish kernel: Apr 13 21:40:30 goldenfish kernel: Pid: 4657, comm: work_for_cpu Tainted: G D 2.6.39-rc3+ #171 System manufacturer System Product Name/M4A88TD-V EVO/USB3 Apr 13 21:40:30 goldenfish kernel: EIP: 0060:[] EFLAGS: 00010246 CPU: 0 Apr 13 21:40:30 goldenfish kernel: EIP is at drm_vblank_put+0x16/0x4f [drm] Apr 13 21:40:30 goldenfish kernel: EAX: EBX: f23cfc00 ECX: f23cfc00 EDX: f1e08c40 Apr 13 21:40:30 goldenfish kernel: ESI: EDI: f23cfd70 EBP: f1f29a40 ESP: f1f29a38 Apr 13 21:40:30 goldenfish kernel: DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Apr 13 21:40:30 goldenfish kernel: Process work_for_cpu (pid: 4657, ti=f1f28000 task=f16264f0 task.ti=f1f28000) Apr 13 21:40:30 goldenfish kernel: Stack: Apr 13 21:40:30 goldenfish kernel: f23cfc00 f1f29a54 f8370b3c f1cbd000 f166a000 f23cfc00 f1f29a68 Apr 13 21:40:30 goldenfish kernel: f866907c f1cbd000 f23cfea0 f23418d0 f1f29a74 f86690e2 f86e039c f1f29c48 Apr 13 21:40:30 goldenfish kernel: f854952c f86de5e4 f23cfea4 f1675480 0100 Apr 13 21:40:30 goldenfish kernel: Call Trace: Apr 13 21:40:30 goldenfish kernel: [] drm_vblank_post_modeset+0x4b/0x5d [drm] Apr 13 21:40:30 goldenfish kernel: [] atombios_crtc_dpms+0x6b/0xc4 [radeon] Apr 13 21:40:30 goldenfish kernel: [] atombios_crtc_commit+0xd/0x19 [radeon] Apr 13 21:40:30 goldenfish kernel: [] drm_crtc_helper_set_mode+0x2d4/0x3ac [drm_kms_helper] Apr 13 21:40:30 goldenfish kernel: [] drm_crtc_helper_set_config+0x5b4/0x79a [drm_kms_helper] Apr 13 21:40:30 goldenfish kernel: [] drm_fb_helper_set_par+0x5c/0x97 [drm_kms_helper] Apr 13 21:40:30 goldenfish kernel: [] fbcon_init+0x2c1/0x3aa Apr 13 21:40:30 goldenfish kernel: [] visual_init+0xd2/0x127 Apr 13 21:40:30 goldenfish kernel: [] bind_con_driver+0x217/0x305 Apr 13 21:40:30 goldenfish kernel: [] take_over_console+0x28/0x33 Apr 13 21:40:30 goldenfish kernel: [] fbcon_takeover+0x53/0x8d Apr 13 21:40:30 goldenfish kernel: [] fbcon_event_notify+0x1ea/0x4f1 Apr 13 21:40:30 goldenfish kernel: [] ? sysfs_add_one+0x12/0x80 Apr 13 21:40:30 goldenfish kernel: [] notifier_call_chain+0x26/0x48 Apr 13 21:40:30 goldenfish kernel: [] __blocking_notifier_call_chain+0x34/0x48 Apr 13 21:40:30 goldenfish kernel: [] blocking_notifier_call_chain+0xc/0xe Apr 13 21:40:30 goldenfish kernel: [] fb_notifier_call_chain+0x11/0x13 Apr 13 21:40:30 goldenfish kernel: [] register_framebuffer+0x202/0x214 Apr 13 21:40:30 goldenfish kernel: [] drm_fb_helper_single_fb_probe+0x1b7/0x241 [drm_kms_helper] Apr 13 21:40:30 goldenfish kernel: [] drm_fb_helper_initial_config+0x3f8/0x405 [drm_kms_helper] Apr 13 21:40:30 goldenfish kernel: [] ? sysfs_add_one+0x12/0x80 Apr 13 21:40:30 goldenfish kernel: [] ?
Linux 2.6.39-rc3
On Wed, Apr 13, 2011 at 03:01:10PM -0700, H. Peter Anvin wrote: > On 04/13/2011 02:50 PM, Joerg Roedel wrote: > > On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote: > >> - addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20); > >> + addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21); > > > > Btw, while looking at this code I wondered why the 512M goal is enforced > > by the alignment. Start could be set to 512M instead and the alignment > > can be aper_size as it should. Any reason for such a big alignment? > > > > Joerg > > > > P.S.: The box is still in the office, I will try this debug-patch > > tomorrow. > > The only reason that I can think of is that the aperture itself can be > huge, and perhaps 512 MiB is the biggest such known. Well, that would work as well by just using aper_size as alignment, the aperture needs to be aligned on its size anyway. This code only runs when Linux allocates the aperture itself and if I am mistaken is uses always 64MB when doing this. Joerg
Linux 2.6.39-rc3
On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote: > - addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20); > + addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21); Btw, while looking at this code I wondered why the 512M goal is enforced by the alignment. Start could be set to 512M instead and the alignment can be aper_size as it should. Any reason for such a big alignment? Joerg P.S.: The box is still in the office, I will try this debug-patch tomorrow.
Linux 2.6.39-rc3
On 04/13/2011 07:07 PM, Dave Airlie wrote: >> >> Okay, staring at this, it definitely seems toxic to overlay the GART >> over memory areas reserved by the BIOS. If I were to guess, I would say >> that the problem here seems to be that the kernel thinks it is >> overlaying 64 MiB of memory, but the actual GART is in fact 512 MiB in >> size -- 131072 CPU pages -- which now overlaps the BIOS reserved areas. >> >> Alex D., could you comment on the "num cpu pages" bit? > > These are not CPU addresses. I think we've stated that already. Not the > droids. > > the num cpu pages is how many CPU pages would be needed to fill the GPU > GTT, for those crazy cases where CPU pagesize != GPU pagesize. > OK, well, something is still weird. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Re: Linux 2.6.39-rc3
On 04/13/2011 07:07 PM, Dave Airlie wrote: Okay, staring at this, it definitely seems toxic to overlay the GART over memory areas reserved by the BIOS. If I were to guess, I would say that the problem here seems to be that the kernel thinks it is overlaying 64 MiB of memory, but the actual GART is in fact 512 MiB in size -- 131072 CPU pages -- which now overlaps the BIOS reserved areas. Alex D., could you comment on the num cpu pages bit? These are not CPU addresses. I think we've stated that already. Not the droids. the num cpu pages is how many CPU pages would be needed to fill the GPU GTT, for those crazy cases where CPU pagesize != GPU pagesize. OK, well, something is still weird. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Big Endian support for RV730 (Mesa r600)
Le 13/04/2011 14:10, Benjamin Herrenschmidt a écrit : On Wed, 2011-04-13 at 22:05 +1000, Benjamin Herrenschmidt wrote: On Tue, 2011-04-12 at 10:01 +0200, Cédric Cano wrote: Hi Here you are a patch that adds big endian support for rv730 in r600 classic mesa driver. The BE modifications are almost the same as the DRM / DDX driver modifications (http://lists.freedesktop.org/archives/dri-devel/2011-February/008151.html). I used the mesa-demos to test the driver status on big endian platform. Nearly all demos renders the same as on Intel architecture. Nevertheless, there are still some issues in glReadPixels (r600_blit) with some formats. I can't figure out exactly what and when data must be swapped (set_tex_resoures, set_render_target...). Review of the patch would be greatly appreciated. It seems that r600g will be the default for Mesa 7.11 so I'll try to enable big endian support for Gallium now. Cool stuff ! I'll try to test that one of these days on various ppc's BTW. I see you used some FSL embedded board. Do you have your PCIe MMIO space above 32-bit ? Last I looked, there was a bunch of fixing needing to be done, among others in the TTM, to make that work. I had some preliminary patches but they bitrot... mostly the issue is to make sure than a phys_addr_t is used instead of an unsigned long whenever it tries to store the physical address of an object. Ben. Hi Ben, I don't use Freescale eval boards but our custom PowerPC design. We didn't enable the 36-bit addressing mode yet. Cédric ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.39-rc3
On Wed, 13 Apr 2011 19:33:40 -0700 Linus Torvalds torva...@linux-foundation.org wrote: On Wednesday, April 13, 2011, Linus Torvalds torva...@linux-foundation.org wrote: On Wednesday, April 13, 2011, H. Peter Anvin h...@zytor.com wrote: Yes. However, even if we *do* revert (and the time is running short on not reverting) I would like to understand this particular one, simply because I think it may very well be a problem that is manifesting itself in other ways on other systems. sorry, fingerfart. Anyway, I agree 100%. we definitely want to also understand the reason for things not working, even if we do revert.. Definitely because if it fails when the magic involves the GART base it starts to sound like something may be hitting the wrong address space or not flushing properly. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.39-rc3
On Wed, Apr 13, 2011 at 06:58:46PM -0700, H. Peter Anvin wrote:
On 04/13/2011 12:14 PM, Yinghai Lu wrote:
so looks bios program wrong address to the radon card?
Okay, staring at this, it definitely seems toxic to overlay the GART
over memory areas reserved by the BIOS. If I were to guess, I would say
that the problem here seems to be that the kernel thinks it is
overlaying 64 MiB of memory, but the actual GART is in fact 512 MiB in
size -- 131072 CPU pages -- which now overlaps the BIOS reserved areas.
Alex D., could you comment on the num cpu pages bit?
Okay, I tried the debug-patch from Yinghai (posted to the bugzilla):
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -325,6 +325,8 @@ void radeon_gtt_location(struct radeon_device *rdev, struct
radeon_mc *mc)
mc-gtt_size = size_bf;
}
mc-gtt_start = (mc-vram_start ~mc-gtt_base_align) -
mc-gtt_size;
+ if (mc-gtt_start == 0xa000)
+ mc-gtt_start = 0x8000;
} else {
if (mc-gtt_size size_af) {
dev_warn(rdev-dev, limiting GTT\n);
And this makes a difference, with this change on-top of -rc3 the box boots
fine. So there seems to be some dependency between the GART base and the GTT
base even when they are in different address spaces.
Alex, can you comment on this?
Regards,
Joerg
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.39-rc3
On Thu, Apr 14, 2011 at 6:56 PM, Joerg Roedel j...@8bytes.org wrote:
On Wed, Apr 13, 2011 at 06:58:46PM -0700, H. Peter Anvin wrote:
On 04/13/2011 12:14 PM, Yinghai Lu wrote:
so looks bios program wrong address to the radon card?
Okay, staring at this, it definitely seems toxic to overlay the GART
over memory areas reserved by the BIOS. If I were to guess, I would say
that the problem here seems to be that the kernel thinks it is
overlaying 64 MiB of memory, but the actual GART is in fact 512 MiB in
size -- 131072 CPU pages -- which now overlaps the BIOS reserved areas.
Alex D., could you comment on the num cpu pages bit?
Okay, I tried the debug-patch from Yinghai (posted to the bugzilla):
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -325,6 +325,8 @@ void radeon_gtt_location(struct radeon_device *rdev,
struct radeon_mc *mc)
mc-gtt_size = size_bf;
}
mc-gtt_start = (mc-vram_start ~mc-gtt_base_align) -
mc-gtt_size;
+ if (mc-gtt_start == 0xa000)
+ mc-gtt_start = 0x8000;
} else {
if (mc-gtt_size size_af) {
dev_warn(rdev-dev, limiting GTT\n);
And this makes a difference, with this change on-top of -rc3 the box boots
fine. So there seems to be some dependency between the GART base and the GTT
base even when they are in different address spaces.
Alex, can you comment on this?
Wierd either a hw bug or some access to the GTT is leaking out before,
things are setup properly,
I think the RS780/880 docs are on the website, but generally the
address spaces are completely separate so anything getting through is
very unusual.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.39-rc3
On Thu, Apr 14, 2011 at 01:03:37PM +0900, Tejun Heo wrote: Hello, On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote: On Wednesday, April 13, 2011, Linus Torvalds torva...@linux-foundation.org wrote: On Wednesday, April 13, 2011, H. Peter Anvin h...@zytor.com wrote: Yes. However, even if we *do* revert (and the time is running short on not reverting) I would like to understand this particular one, simply because I think it may very well be a problem that is manifesting itself in other ways on other systems. sorry, fingerfart. Anyway, I agree 100%. we definitely want to also understand the reason for things not working, even if we do revert.. There were (and still are) places where memblock callers implemented ad-hoc top-down allocation by stepping down start limit until allocation succeeds. Several of them have been removed since top-down became the default behavior, so simply reverting the commit is likely to cause subtle issues. Maybe the best approach is introducing @topdown parameter and use it selectively for pure memory allocations. Wouldn't it be better to provide a seperate memblock allocation function which operates top-down and use this one in the places that need it? This way it wouldn't break code that relies on bottom-up. Joerg ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.39-rc3
On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel j...@8bytes.org wrote:
On Wed, Apr 13, 2011 at 06:58:46PM -0700, H. Peter Anvin wrote:
On 04/13/2011 12:14 PM, Yinghai Lu wrote:
so looks bios program wrong address to the radon card?
Okay, staring at this, it definitely seems toxic to overlay the GART
over memory areas reserved by the BIOS. If I were to guess, I would say
that the problem here seems to be that the kernel thinks it is
overlaying 64 MiB of memory, but the actual GART is in fact 512 MiB in
size -- 131072 CPU pages -- which now overlaps the BIOS reserved areas.
Alex D., could you comment on the num cpu pages bit?
Okay, I tried the debug-patch from Yinghai (posted to the bugzilla):
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -325,6 +325,8 @@ void radeon_gtt_location(struct radeon_device *rdev,
struct radeon_mc *mc)
mc-gtt_size = size_bf;
}
mc-gtt_start = (mc-vram_start ~mc-gtt_base_align) -
mc-gtt_size;
+ if (mc-gtt_start == 0xa000)
+ mc-gtt_start = 0x8000;
} else {
if (mc-gtt_size size_af) {
dev_warn(rdev-dev, limiting GTT\n);
And this makes a difference, with this change on-top of -rc3 the box boots
fine. So there seems to be some dependency between the GART base and the GTT
base even when they are in different address spaces.
Alex, can you comment on this?
As Dave said, they are completely different addresses spaces. You
could put the GPU aperture at 0 if you wanted (in fact we do on some
chips). Perhaps there's some strange interaction with the nb gart
since the nb gart on that chipset was designed to be used for graphics
and the rs780/880 can be configured to use an agp aperture.
Unfortunately, I'm not that familiar with the nb gart.
Alex
Regards,
Joerg
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.39-rc3
On 04/14/2011 02:11 AM, Ingo Molnar wrote: I'd strongly suggest we revert back to the old and proven allocation order, as long as it results in valid layouts. Even if we figure out this particular GART/GTT assumption there might be a dozen others in other types of hardware. Yes, but we might also be hiding a real bug which bites other hardware. We have found real and very serious bugs in the kernel this way before -- things where drivers scribble over random memory and allocation order exposed the failure in a predictable way, as opposed to random crashes. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36227] Radeon HD4250 crash with modeset=1
https://bugs.freedesktop.org/show_bug.cgi?id=36227 --- Comment #1 from Jerome Glisse gli...@freedesktop.org 2011-04-14 07:44:13 PDT --- Please boot in runlevel 3 (add 3 to your kernel boot line) to avoid starting X, unloading the radeon non kms module might let the hw in fuzzy state. Once booted in run level 3 load radeon with the modeset=1 and attach the new kernel log here -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36236] New: Problems with lights in Trine game from www.humblebundle.com
https://bugs.freedesktop.org/show_bug.cgi?id=36236 Summary: Problems with lights in Trine game from www.humblebundle.com Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: sob...@gmail.com Created an attachment (id=45611) -- (https://bugs.freedesktop.org/attachment.cgi?id=45611) Screenshot of the problem According to turol( http://phoronix.com/forums/showthread.php?46124-Here-s-The-Third-Humble-Indie-Bundlep=197456#post197456 ) there is problem with lights. glxinfo: name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_INTEL_swap_event client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_framebuffer_sRGB, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event GLX version: 1.4 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on ATI RV530 OpenGL version string: 2.1 Mesa 7.11-devel (git-78e90bf) OpenGL shading language version string: 1.20 OpenGL extensions: GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object, GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture, GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters, GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_separate_specular_color, GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_ARB_multitexture, GL_IBM_multimode_draw_arrays, GL_IBM_texture_mirrored_repeat, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_blend_func_separate, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_secondary_color, GL_EXT_texture_env_add, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texgen_reflection, GL_NV_texture_env_combine4, GL_S3_s3tc, GL_SUN_multi_draw_arrays, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_EXT_framebuffer_object, GL_EXT_texture_compression_s3tc, GL_EXT_texture_env_dot3, GL_MESA_window_pos, GL_NV_packed_depth_stencil, GL_NV_texture_rectangle, GL_ARB_depth_texture, GL_ARB_occlusion_query, GL_ARB_shadow, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_window_pos, GL_EXT_stencil_two_side, GL_EXT_texture_cube_map, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_shader_objects, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_ARB_fragment_program_shadow, GL_ARB_half_float_pixel, GL_ARB_occlusion_query2, GL_ARB_point_sprite, GL_ARB_shading_language_100, GL_ARB_sync, GL_ARB_texture_non_power_of_two, GL_ARB_vertex_buffer_object, GL_ATI_blend_equation_separate, GL_EXT_blend_equation_separate, GL_OES_read_format, GL_ARB_color_buffer_float,
[Bug 36037] RV250Lf: airlied/drm-fixes branch crashes in new backlight code
https://bugs.freedesktop.org/show_bug.cgi?id=36037 --- Comment #8 from Michel Dänzer mic...@daenzer.net 2011-04-14 07:59:21 PDT --- So bl_get_data() returns NULL in radeon_legacy_backlight_get_brightness(). I'm stumped as to how that could happen... Any ideas, Matthew? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix bad shift in atom iio table parser
Noticed by Patrick Lowry. Signed-off-by: Alex Deucher alexdeuc...@gmail.com Cc: sta...@kernel.org --- drivers/gpu/drm/radeon/atom.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c index d71d375..7bd7456 100644 --- a/drivers/gpu/drm/radeon/atom.c +++ b/drivers/gpu/drm/radeon/atom.c @@ -135,7 +135,7 @@ static uint32_t atom_iio_execute(struct atom_context *ctx, int base, case ATOM_IIO_MOVE_INDEX: temp = ~((0x (32 - CU8(base + 1))) - CU8(base + 2)); + CU8(base + 3)); temp |= ((index CU8(base + 2)) (0x (32 - CU8(base + 1 CU8(base + @@ -145,7 +145,7 @@ static uint32_t atom_iio_execute(struct atom_context *ctx, int base, case ATOM_IIO_MOVE_DATA: temp = ~((0x (32 - CU8(base + 1))) - CU8(base + 2)); + CU8(base + 3)); temp |= ((data CU8(base + 2)) (0x (32 - CU8(base + 1 CU8(base + @@ -155,7 +155,7 @@ static uint32_t atom_iio_execute(struct atom_context *ctx, int base, case ATOM_IIO_MOVE_ATTR: temp = ~((0x (32 - CU8(base + 1))) - CU8(base + 2)); + CU8(base + 3)); temp |= ((ctx- io_attr CU8(base + 2)) (0x (32 - -- 1.7.1.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36037] RV250Lf: airlied/drm-fixes branch crashes in new backlight code
https://bugs.freedesktop.org/show_bug.cgi?id=36037 --- Comment #9 from Matthew Garrett mj...@srcf.ucam.org 2011-04-14 08:29:30 PDT --- That's bizarre. I can't see any obvious way this could happen. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36236] Problems with lights in Trine game from www.humblebundle.com
https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #1 from Krzysztof A. Sobiecki sob...@gmail.com 2011-04-14 08:39:06 PDT --- Created an attachment (id=45612) -- (https://bugs.freedesktop.org/attachment.cgi?id=45612) Screenshot of the problem using llvmpipe LIBGL_ALWAYS_SOFTWARE=yes ./trine-bin64 glxinfo: name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_INTEL_swap_event client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_framebuffer_sRGB, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event GLX version: 1.4 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_multithread_makecurrent, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_INTEL_swap_event OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on llvmpipe OpenGL version string: 2.1 Mesa 7.11-devel (git-78e90bf) OpenGL shading language version string: 1.20 OpenGL extensions: GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object, GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture, GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters, GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_separate_specular_color, GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_ARB_framebuffer_sRGB, GL_ARB_multitexture, GL_EXT_framebuffer_sRGB, GL_IBM_multimode_draw_arrays, GL_IBM_texture_mirrored_repeat, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_blend_func_separate, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_secondary_color, GL_EXT_texture_env_add, GL_EXT_texture_lod_bias, GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texgen_reflection, GL_NV_texture_env_combine4, GL_S3_s3tc, GL_SUN_multi_draw_arrays, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_EXT_framebuffer_object, GL_EXT_texture_compression_s3tc, GL_EXT_texture_env_dot3, GL_MESA_window_pos, GL_NV_packed_depth_stencil, GL_NV_texture_rectangle, GL_ARB_depth_texture, GL_ARB_occlusion_query, GL_ARB_shadow, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_window_pos, GL_EXT_stencil_two_side, GL_EXT_texture_cube_map, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_shader_objects, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_primitive_restart, GL_ARB_fragment_program_shadow, GL_ARB_half_float_pixel, GL_ARB_occlusion_query2, GL_ARB_point_sprite, GL_ARB_shading_language_100, GL_ARB_sync, GL_ARB_texture_non_power_of_two, GL_ARB_vertex_buffer_object, GL_ATI_blend_equation_separate, GL_EXT_blend_equation_separate, GL_OES_read_format, GL_ARB_pixel_buffer_object, GL_ARB_texture_rectangle, GL_EXT_pixel_buffer_object, GL_EXT_texture_compression_dxt1, GL_EXT_texture_mirror_clamp, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_ARB_framebuffer_object, GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample, GL_EXT_packed_depth_stencil, GL_ARB_vertex_array_object, GL_ATI_separate_stencil, GL_ATI_texture_mirror_once, GL_EXT_draw_buffers2, GL_EXT_draw_instanced, GL_EXT_gpu_program_parameters, GL_EXT_texture_env_combine, GL_EXT_texture_sRGB_decode, GL_OES_EGL_image, GL_ARB_copy_buffer,
[Bug 34155] [drm:radeon_crtc_page_flip] *ERROR* failed to reserve new rbo buffer before flip
https://bugs.freedesktop.org/show_bug.cgi?id=34155 --- Comment #2 from Alexandre Demers alexandre.f.dem...@gmail.com 2011-04-14 08:45:50 PDT --- When testing with latest drm and kernel, I can't find the error anymore. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32982] Kernel locks up a few minutes after boot
https://bugzilla.kernel.org/show_bug.cgi?id=32982 --- Comment #7 from Bart Van Assche bart.vanass...@gmail.com 2011-04-14 15:57:40 --- Still occurs with 85f2e689a5c8fb6ed8fdbee00109e7f6e5fefcb6 (2.6.29-rc3+). Note: I'm still trying to find the offending commit via bisecting. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36236] Problems with lights in Trine game from www.humblebundle.com
https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #2 from Sven Arvidsson s...@whiz.se 2011-04-14 09:02:12 PDT --- Created an attachment (id=45613) -- (https://bugs.freedesktop.org/attachment.cgi?id=45613) Correct rendering of Windows version Same problem with softpipe, so the bug should probably be reassigned to Mesa core. I tried swrast too, but it will not run the game. Just for reference, I have attached a screenshot of how it's supposed to look. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36221] KMS with X1950 XT i2c error -- no ddc
https://bugs.freedesktop.org/show_bug.cgi?id=36221 --- Comment #3 from revealed revea...@freakmail.de 2011-04-14 09:23:32 PDT --- Created an attachment (id=45615) -- (https://bugs.freedesktop.org/attachment.cgi?id=45615) lspci -vnn -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
