[HD 3650] Startup failure "Idle timed out, resetting engine..."

[shelvingguy]

Binary package hint: xserver-xorg-video-ati

I have a Toshiba Satellite A355 with Intel Core 2 Duo Processor T6400 / 4GB SDRAM / ATI Mobility Radeon HD 3650.

I have not been able to boot into a GUI with any free, or non-free, drivers for my video card--except vesa.

A previous bug (336348) fixed an error with PLL dividers. But, we have another error now.

The Xorg.0.log is attached.

Thank you.

[lspci]
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Mobility Radeon HD 3650 [1002:9591]
 Subsystem: Toshiba America Info Systems Device [1179:ff01]

[Tormod Volden (tormodvolden)]

Please attach the output from "lspci -vvnn".

[shelvingguy (shelvingguy)]

It looked different when I ran it as root, so I attached both.

[Tormod Volden (tormodvolden)]

Seems like more people in http://ubuntuforums.org/showthread.php?t=1076047 are bitten by this one.

[Tormod Volden (tormodvolden)]

Can you please update your Jaunty installation (so that you get xserver-xorg-core 1.6 and libdrm2 2.4.5) and attach the new log?

[Tormod Volden (tormodvolden)]

(Please also update to the newest PPA packages of -ati/-radeon)

Can you please try to add
 Option "AccelMethod" "XAA"
to the Device section of your xorg.conf? I am not sure these cards should use EXA if DRI is not enabled.

[shelvingguy (shelvingguy)]

I updated Juanty. It looks like the xserver-xorg-core 1.6 and libdrm2 were installed with the update.

I also reinstalled xserver-xorg-video-ati_6.11.0.99+git20090311.945ccbbd-0ubuntu0tormod_amd64.deb and the corresponding radeon package.

I added Option "AccelMethod" "XAA" to xorg.conf.

Xorg.conf and Xorg.0.log are attached. Is the xorg.conf okay? All of the other distros and installations I have tried had much more detail. I hope that hasn't been part of the problem all along.

Thank you.

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

Created an attachment (id=23832)
Xorg.0.log HD 3650

Forwarded from Ubuntu bug https://bugs.launchpad.net/bugs/341681

Starting X just gives a black screen, and the log is filling up with:
(EE) RADEON(0): Idle timed out, resetting engine...

A forum post (from another guy) indicates that removing 2 GB (from 4 GB) of RAM from the laptop fixes a similar issue with -radeonhd, but this has not been confirmed by the reporter on -ati.

Another thing that looks contradicting in the log:
(EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
[dri] Disabling DRI.
...
(==) RADEON(0): Will attempt to use R6xx/R7xx EXA support if DRI is enabled.
(**) RADEON(0): Using EXA acceleration architecture

He also tried to force XAA in xorg.conf:
(**) RADEON(0): Option "AccelMethod" "XAA"
but it does not take effect. Is it supported?

The driver is built from git 945ccbbd4fa2b65ccdfb23716c178c95b036734d

[agd5f (agd5f)]

Does:
Option "DRI" "FALSE"
in the device section of the config fix the problem?

[agd5f (agd5f)]

Created an attachment (id=23833)
posible fix

Does this patch help?

[Timo Jyrinki (timo-jyrinki-hut)]

According to:

https://lists.ubuntu.com/archives/jaunty-changes/2009-March/007167.html

Kernel support is coming soon, now that the git snapshot of xf86-video-ati is in. But probably the driver shouldn't fail in the case that kernel lacks the needed drm bits. [right: a proposed patch was already offered while I'm writing this]

XAA won't be supported on r600/r700 AFAIK.

[agd5f (agd5f)]

(In reply to comment #3)
> Kernel support is coming soon, now that the git snapshot of xf86-video-ati is
> in. But probably the driver shouldn't fail in the case that kernel lacks the
> needed drm bits. [right: a proposed patch was already offered while I'm writing
> this]

This case actually has nothing to do with the DRI per se, it's that the engine isn't idle for whatever reason in this case. Since we aren't using the engine when the dri is disabled and don't really know what state it's in, we can ignore it.

[Tormod Volden (tormodvolden)]

There is a typo in your xorg.conf: There must be a space between "AccelMethod" and "XAA".

Yes, the xorg.conf is minimal. This is because the new server/drivers do more autoconfiguration, on the fly.

[shelvingguy (shelvingguy)]

I was part of the original bug submission that was pushed by Tormod. I think my log was that one he attached to this bug.

I am new to linux, but I have been struggling with this issue for over a month now. If I can help by trying out fixes, and sending information back, please let me know.

Thank you.

[shelvingguy (shelvingguy)]

I corrected the xorg.conf and I will attach the file, and the Xorg.0.log.

What do you think of the post on the forum about removing RAM? I don't want to have to remove 2GB of RAM, but does it shine any light on the issue?

Thanks.

[Tormod Volden (tormodvolden)]

Does removing RAM also solve the issue when using the -ati/-radeon driver?

[shelvingguy (shelvingguy)]

I have not tried it.

[Tormod Volden (tormodvolden)]

I've forwarded your bug upstream to http://bugs.freedesktop.org/show_bug.cgi?id=20645 - please subscribe to this bug in case upstream needs more information or wishes you to test something. Thanks ahead of time!

[Josh Beitelspacher (joshbeitelspacher)]

Created an attachment (id=23839)
Xorg.0.log with 2GB RAM (Ubuntu 8.10)

[Josh Beitelspacher (joshbeitelspacher)]

I just attached an Xorg.0.log from a successful startup with only 2 GB of RAM installed.

This system is identical to the system that produced the first log (Toshiba Satellite A355-S6935), I just removed a stick of RAM.

Comparing the two logs shows that video memory is detected incorrectly when 4 GB of RAM are installed. The machine has 512 MB of video memory, but when 4 GB of RAM are installed 4194303K of video RAM are detected.

[Tormod Volden (tormodvolden)]

I have uploaded a new PPA package with the proposed patch from the upstream report, please test 1:6.11.0.99+git20090313.104e13da-0ubuntu0tormod2 (when it's ready).

[Josh Beitelspacher (joshbeitelspacher)]

Removing 2GB of memory also works for the ati drivers. Attaching the Xorg.0.log from a successful run with only 2GB memory installed.

[Josh Beitelspacher (joshbeitelspacher)]

That previous attachment is from a fully updated Ubuntu 8.10 install.

[Josh Beitelspacher (joshbeitelspacher)]

Comparing the working and the non-working Xorg.0.logs shows that the video card memory is being detected incorrectly when 4GB of RAM are installed. When only 2GB of RAM are installed 524288K of video RAM are correctly detected. When 4GB of RAM are installed 4194303KB of video RAM are detected, but only 524288K are accessible.

Also with 2GB of RAM the PLL rd parameter is 12, but with 4GB of RAM the PPL rd parameter is 1023. Maybe the PLL divider bug wasn't really a bug after all...

[shelvingguy (shelvingguy)]

Created an attachment (id=23924)
Xorg.0.log after Jaunty update. Still not screen. Different error.

I upgraded Jaunty and the ATI Mobility Radeon HD 3650 is still not functioning.

The Xorg.0.log is attached.

Thank you.

[agd5f (agd5f)]

Created an attachment (id=23925)
workaround

(In reply to comment #8)
> Created an attachment (id=23924) [details]
> Xorg.0.log after Jaunty update. Still not screen. Different error.
>
> I upgraded Jaunty and the ATI Mobility Radeon HD 3650 is still not functioning.
>

Weird. the MC is busy, This is also probably related to why you were getting engine idle errors previously. Is this from a fresh boot or had you been running fglrx previously? This patch will work around this mc idle, but it may have problems when writing the new fb location. Let me know how it goes.

[shelvingguy (shelvingguy)]

That last Xorg.0.log was the .old. After trying to boot with "ati" in the xorg.conf, I have to boot in safe mode, drop to command line, and add "vesa" back to xorg.conf. Then I open the Xorg.0.log.old and attach it.

I haven't tried fglrx in a while.

You'll have to forgive me. I am not that experienced with linux. Can you describe to me how to apply the patch you attached.

Thank you.

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

Jeff, I'll make patched packages in my PPA.

[shelvingguy (shelvingguy)]

(In reply to comment #11)
> Jeff, I'll make patched packages in my PPA.
>

Great. Thanks.

I'll watch for them.

[shelvingguy (shelvingguy)]

Created an attachment (id=23933)
New PPA installed - Xorg.0.log - HD 3650

I installed the new driver from the PPA. The Xorg.0.log is attached. It booted to an unresponsive black screen.

Thanks.

[shelvingguy (shelvingguy)]

Created an attachment (id=23943)
HD 3650 - ati works after removing 2GB (out of 4GB) of RAM

The ati driver for the ATI Mobility Radeon HD 3650 works after removing 2GB of RAM. The Xorg.0.log is attached.

Someone else posted this the other day. Does this shine any light on the issue with this card?

Thank you.

[Tormod Volden (tormodvolden)]

Please try 1:6.12.0.99~git20090316.a6855c37-0ubuntu0tormod from my PPA once it is built.

[shelvingguy (shelvingguy)]

It's been quiet on this. Is there any new information on this bug?

I'm still carrying around half of my RAM.

Thank you.

[Bryce Harrington (bryce)]

Anyone had a chance to test so far?

[Mhopf-suse (mhopf-suse)]

Alex, I vaguely remembered that we had the same issue with radeonhd with an Asus Laptop, that only worked with only 2GB installed.

Now, found on our wiki http://www.x.org/wiki/radeonhd :

Newer ASUS laptops with more than 2GB of memory. There are several reports about getting RadeonHD (or any graphics driver) to work on Linux on ASUS laptops with M72, M82 and possibly other chipsets when more than 2GB of RAM is installed. This is very likely not a graphics driver issue. For now the only work around is to reduce the amount of RAM installed to 2GB or less.

AFAIK we still weren't able to find a reasonable solution for that.

Just for information

[agd5f (agd5f)]

Thanks Matthias. I wonder if it's an mtrr issue with the bios? Are there any options in your bios related to memory setup?

[shelvingguy (shelvingguy)]

I tested again with all 4GB of RAM. It still boots to an unresponsive black screen. The Xorg.0.log is attached.

Regarding the BIOS, I do not see any options for adjusting RAM. I tried all the menus I could access, but I did not see anything.

The BIOS I am running seems to have very few options. It is Phoenix SecureCore Setup Utility - BIOS version 1.7.

Thank you.

[shelvingguy (shelvingguy)]

Created an attachment (id=24676)
Testing ATI driver with 4GB of RAM.

[Christoph Piefke (anmeldung-dunklevollnuss)]

Same Bug here, I also have

(II) RADEON(0): Detected total video RAM=4194303K, accessible=524288K (PCI BAR=524288K)

in my Xorg.0.log.

Did anyone find a solution without removing 2GB Ram? I did a BIOS update for my Toshiba Satellite A350, but there is still no option in the BIOS to set the Ram for the videocard.

[agd5f (agd5f)]

The bios is setting up the mtrrs wrong. The fix is to enable the MTRR cleanup support (CONFIG_MTRR_SANITIZER) option in the kernel:
http://lists.opensuse.org/radeonhd/2009-05/msg00070.html

[agd5f (agd5f)]

this is a bios issue that needs to be fixed in the kernel.

[shelvingguy (shelvingguy)]

sweet...I just added the xorg-edgers ppa to my repositories. Would it be wise to keep it, or will the ati fixes come through the normal sources? R

[Bryce Harrington (bryce)]

On Wed, May 13, 2009 at 08:06:10PM -0000, shelvingguy wrote:
> sweet...I just added the xorg-edgers ppa to my repositories.

And did that fix the issue? What was the exact package and version you
installed from xorg-edgers that solved it?

> Would it be wise to keep it, or will the ati fixes come through the
> normal sources? R

Depends. Ubuntu does not roll out random updates of things to users,
since they can cause regressions; I'm sure you appreciate that you can
do updates and trust that your machine won't randomly break.

So, you'd need to help isolate the specific change that fixed the
problem. Then, a thorough review of that specific patch is done, and
thorough testing performed to ensure it causes no regressions. If you
have time to work through that process, I can give guidance. Otherwise,
yes stick with xorg-edgers. Sounds like we'll have the version with the
fix in Karmic so I understand if you'd prefer to just wait for that.

[Tormod Volden (tormodvolden)]

Generally there are no card driver (like -ati) packages in the xorg-edgers PPA (only for -intel because it is so... special). Test packages for -ati are in my own PPA. However I don't think there is anything that should have fixed this bug at this point. I asked specifically for testing of one version in comment 20 and although no one answered here I think Jeff tested it (with negative result) in the upstream report.

[Tormod Volden (tormodvolden)]

I just saw Alex's post of today in the upstream report. The 2.6.28-12-generic kernel in Jaunty actually has CONFIG_MTRR_SANITIZER=y so please try the boot options mentioned in that mailing list thread. (I think enable_mtrr_cleanup mtrr_spare_reg_nr=0 should do it but please read that thread carefully yourself).

[shelvingguy (shelvingguy)]

Bryce and Tormod. Thank you for your comments.

I removed the xorg-edgers from my repositories. There was no solution there. I just thought it might be something to monitor.

Also, I just tried the MTRR idea. I went into /boot/config-2.6.28-12-generic and changed the values to CONFIG_NTRR_SANITIZER_ENABLE_DEFAULT to 1 and CONFIG_MTRR_SANITZER_SPARE_REG_NR_DEFAULT to 0. Unfortunately, I still booted to the old unresponsive black screen.

My Xorg.0.log is attached. I don't see an error.

Thanks again.

[Tormod Volden (tormodvolden)]

> I removed the xorg-edgers from my repositories. There was no solution there. I just thought it might be something to monitor.

If it would have been fixed upstream in a relevant package, the fix would show up there rather quickly. But in this case it is a kernel issue.

> I went into /boot/config-2.6.28-12-generic and changed the values

No, that file just tells you how the kernel was compiled, and which default values were compiled into it. You can override these values with the kernel boot option I mentioned (see also https://help.ubuntu.com/community/BootOptions).

[shelvingguy (shelvingguy)]

I read the opensuse thread on mtrr. I then added "enable_mtrr_cleanup mtrr_spare_reg_nr=0" to my "/boot/grub/menu.lst". Still booted to unresponsive black.

Xorg.0.log attached.

Thanks.

[Tormod Volden (tormodvolden)]

Can you please attach /var/log/dmesg from booting with this option?

[shelvingguy (shelvingguy)]

dmesg attached.

[shelvingguy (shelvingguy)]

I upgraded to karmic and made added the mtrr boot option. It still boots to an unresponsive black screen. The Xorg.0.log is attached.

Thanks.

[Peter Haight (peterh-sapros)]

I've got the same problem. Tried all the solutions mentioned, but the only thing that works is taking out 2GB of the 4GB of main memory. I'm game for trying any patches or tests if anyone has any ideas.

[Igor Bunjevac (igor-bunjevac)]

Same here, i just took out 2GB of RAM and everything works fine now.
If anyone got any workaround or anythin else that will make it work with 4GB RAM, please let us know. :) cheers!

[Bryce Harrington (bryce)]

From the upstream report: "this is a bios issue that needs to be fixed in the kernel." so am reassigning to the kernel.

[Leann Ogasawara (leannogasawara)]

Addtionally from the upstream bug report:

"The bios is setting up the mtrrs wrong. The fix is to enable the MTRR cleanup support (CONFIG_MTRR_SANITIZER) option in the kernel: http://lists.opensuse.org/radeonhd/2009-05/msg00070.html"

And from the link:

"I enabled MTRR cleanup support (CONFIG_MTRR_SANITIZER), set MTRR cleanup
enable value (CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT) to 1 and set MTRR
cleanup spare reg num (CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT) to 0."

Examining the Karmic kernel config files, CONFIG_MTRR_SANITIZER is enabled, but the other options don't have the the values mentioned above:

ogasawara@emiko:~/ubuntu-karmic/debian/config$ grep -rn "CONFIG_MTRR_SANITIZER" *
config.common.ubuntu:2317:CONFIG_MTRR_SANITIZER=y
config.common.ubuntu:2318:CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
config.common.ubuntu:2319:CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1

A description of the config options can be found in ubuntu-karmic/arch/x86/Kconfig:

config MTRR_SANITIZER
        def_bool y
        prompt "MTRR cleanup support"
        depends on MTRR
        ---help---
          Convert MTRR layout from continuous to discrete, so X drivers can
          add writeback entries.

          Can be disabled with disable_mtrr_cleanup on the kernel command line.
          The largest mtrr entry size for a continuous block can be set with
          mtrr_chunk_size.

          If unsure, say Y.

config MTRR_SANITIZER_ENABLE_DEFAULT
        int "MTRR cleanup enable value (0-1)"
        range 0 1
        default "0"
        depends on MTRR_SANITIZER
        ---help---
          Enable mtrr cleanup default value

config MTRR_SANITIZER_SPARE_REG_NR_DEFAULT
        int "MTRR cleanup spare reg num (0-7)"
        range 0 7
        default "1"
        depends on MTRR_SANITIZER
        ---help---
          mtrr cleanup spare entries default, it can be changed via
          mtrr_spare_reg_nr=N on the kernel command line.

[Géza Búza (medve)]

I have got fglrx to work on Ubuntu/Jaunty with the latest driver from ati (ati-driver-installer-9-8-x86.x86_64.run).
Here is the installation guide I used: http://wiki.cchtml.com/index.php/Ubuntu_Jaunty_Installation_Guide#Installing_the_drivers_manually

It is not perfect, but at least it works. I experienced performance problems with compiz, described here: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/351186

[Igor Bunjevac (igor-bunjevac)]

I just now tried that new driver and guide, but still no luck.
My notebook freezes when starting X on ATi Mobility Radeon HD 3650 with 4GB RAM.
With 2GB works perfectly. :s

[nikodc (nikodc2)]

I have this same issue with my new Toshiba A355-SP7927R notebook with ATI Mobility Radeon HD 3650. I've read a lot about this problem but it's difficult to me to track what's going on with this. Where can I track the kernel modification status? Is there any other bug tracking site where this bug has been posted and where I could see what's going on?

Could you please tell me if there's any workaround in order to get a 1366x768 at least using "vesa" as driver?

Thank you!

[Tormod Volden (tormodvolden)]

If adding "enable_mtrr_cleanup mtrr_spare_reg_nr=0" to the boot options does not help, then the issue is more complicated than described upstream.

Can you anyway please try the Karmic kernel?

[nikodc (nikodc2)]

I did that with radeonhd driver and nothing happened. The same black screen appeared. Please, let me know in which context should I try this configuration... should I be using an specific driver (ati, radeon, radeonhd, fglrx)? should this work with a 4GB RAM configuration or should I remove 2GB from my notebook?

About the Karmic kernel, is there fix for the BIOS-Kernel communication issue applied to that kernel? Why should this new kernel work?

Thank you so much!

[Tormod Volden (tormodvolden)]

This should have worked with the default driver (-ati/-radeon) and with the 4 GB RAM. I don't know if the Karmic kernel has much changes in this regard, but it would be a very quick test for those of you who have the hardware.

[nikodc (nikodc2)]

I'm on Ubuntu 9.04 (Jaunty). I've recompiled the 2.6.28 kernel with the MTRR adjustments and then I've tried "ati", "radeon" and "radeonhd" drivers... all them with similar results: black screen or low graphics mode. I'll try with fglrx later.

[nikodc (nikodc2)]

BTW, i'm on Jaunty 32-bits

[Tormod Volden (tormodvolden)]

Recompiling the 2.6.28 should not be necessary if you use the boot options above. You can try the Karmic kernel on your Jaunty system, just download the deb from https://edge.launchpad.net/ubuntu/karmic/i386/linux-image-2.6.31-10-generic/2.6.31-10.32

[nikodc (nikodc2)]

I've tried to install 2.6.31-10.32 and something went wrong and I couldn't even boot with 2GB RAM. After the last kernel update for my 9.04 distro I've tried to put the other 2GB's back but unfortunately the old black screen appeared once again. I'm attaching my Xorg.0.log file.

Thank you!

[Tormod Volden (tormodvolden)]

Please don't use the link I posted above, there is a newer kernel in Karmic now. Find it here: https://launchpad.net/ubuntu/+source/linux

[gentoo_fan (bernihe-gmail)]

Hello there,

I have this problem on a Toshiba Satellite A350 with ATI Mobility Radeon HD 3650. I have just tried the ubuntu 9.10 . The problem still exists. My screen is black.

I have not tried to remove two of the four Gig RAM yet. I will try this as soon as I get hold of the notebook again.
If this helps I think the problem might be related to the fact that the driver is made for 32bit. As far as I know there are problems with addressing >= 4Gig RAM with 32bit. Furthermore I do not think the kernel can solve the problem. It looks like the bad ATI driver is not capable of residing within 4 Gig of RAM.

any news from your side?

Regards

[shelvingguy (shelvingguy)]

After literally months of trying, I was not able to resolve the issue. I
was able to run it in a virtual machine by reducing the RAM being utilized
by the Guest OS (Ubuntu), but the performance was sluggish and their were
still display issues on boot up. It was not a satisfactory solution for
me. I ended up removing linux altogether, and buying a new laptop (MSI
GT735 - ATI Mobility Radeon HD 3850 - AMD Turion X2 - 3GB RAM). I think the
new card is supported, but I'm too shell shocked to try it right now. I
spent *a lot of time and effort *trying to get linux running on that
machine, which is not in my wheelhouse in the first place. I'm waiting for
my free Windows 7 upgrade and I think my next machine will be Mac.

If I try linux again, I will make sure I research all of the hardware
compatibility beforehand. Although I appreciate the time and effort people
are putting into open source--from a layman's perspective--I found the
overall experience frustrating. Searching a multitude of loosely structured
forums; posting ill-informed questions; waiting for someone to respond; and
then getting all kinds of different and conflicting advice from people who
may or may not be qualified did not work out for me. If it was my
specialty, and had relevance to my job or career, maybe it would be worth
the time and effort. But, I'm in a different field altogether. Technology
is only of value to me in proportion to how much time it gives back to me,
not the other way around.

Sorry for the rant.

On Thu, Oct 29, 2009 at 5:31 PM, gentoo_fan <email address hidden> wrote:

> Hello there,
>
> I have this problem on a Toshiba Satellite A350 with ATI Mobility Radeon
> HD 3650. I have just tried the ubuntu 9.10 . The problem still exists.
> My screen is black.
>
> I have not tried to remove two of the four Gig RAM yet. I will try this as
> soon as I get hold of the notebook again.
> If this helps I think the problem might be related to the fact that the
> driver is made for 32bit. As far as I know there are problems with
> addressing >= 4Gig RAM with 32bit. Furthermore I do not think the kernel can
> solve the problem. It looks like the bad ATI driver is not capable of
> residing within 4 Gig of RAM.
>
> any news from your side?
>
> Regards
>
> --
> [HD 3650] Startup failure "Idle timed out, resetting engine..."
> https://bugs.launchpad.net/bugs/341681
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in X.org XServer - ATI gfx chipset driver: Invalid
> Status in “linux” package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: xserver-xorg-video-ati
>
> I have a Toshiba Satellite A355 with Intel Core 2 Duo Processor T6400 /
> 4GB SDRAM / ATI Mobility Radeon HD 3650.
>
> I have not been able to boot into a GUI with any free, or non-free, drivers
> for my video card--except vesa.
>
> A previous bug (336348) fixed an error with PLL dividers. But, we have
> another error now.
>
> The Xorg.0.log is attached.
>
> Thank you.
>
> [lspci]
> 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Mobility
> Radeon HD 3650 [1002:9591]
> Subsystem: Toshiba America Info Systems Device [1179:f...

[nikodc (nikodc2)]

I'll try 9.10 soon. I don't think this is an ATI issue because the same happens using other open source drivers. Is this problem present using Ubuntu 64-bit or is just something present only in 32-bit versions?

[nielm (niel)]

The problem affects me in both on 9.04 and 9.10RC, amd64 versions (Tosh A350 4Gb RAM and HD3650). Currently using the VESA drivers... which dont support standby...

[nikodc (nikodc2)]

OK. What about the resolution with VESA? I have a 1366x768 resolution LCD monitor but with VESA I was able just to get a 1024x768 resolution.

[gentoo_fan (bernihe-gmail)]

I got hold of the toshiba A350 again. I tried ubuntu 9.10 64bit. After I installed it I removed 2GB RAM. It works! Great, what a relief!
Since linux is so nice to me I can live with 2GB at the moment. I still think the reason for the 4GB RAM problem is the driver itself. It is not able to live within this amount of RAM. Maybe the driver is not able to cope with addresses out of 32 bit range. What do you think? I can imagine that people often develop drivers for 32 bit to keep it compatible to 32bit architectures.
by the way, I used the wubi.exe installer

[Christoph Piefke (anmeldung-dunklevollnuss)]

Hi everybody,
I tried ubuntu 9.10 32bit standart and pae kernel, both are not working. Still the same problems, with 2GB of RAM everything works fine, 4GB of RAM give me a shell, no X. I also tried the 'enable_mtrr_cleanup' and 'mem=2GB' boot options on both kernels without success. Any ideas?

[Peter Haight (peterh-sapros)]

On the off chance anyone is paying attention who knows anything about this stuff, here's some more data.

I'm uploading 6 files. Three each for my laptop with 2GB main memory installed and 4GB installed. One is cat /proc/mtrr, one is lspci -v, and the last is a copy of Xorg.log.

Also I found a program that prints mtrrs in Windows XP 32-bit (where the video works with 4GB installed) and I ran that on my laptop with 4GB installed:

Address Start Address End Memory Type
--------------------------------------------

Fixed Ranges
0x00000000 0x0009ffff WriteBack
0x000a0000 0x000bffff Uncacheable
0x000c0000 0x000fffff WriteProtected

[Peter Haight (peterh-sapros)]

One thing I forgot to mention is that these attempts to launch X are with the ATI proprietary driver. It exhibits nearly the same behavior as the radeon driver. The only difference is that if I use the ATI proprietary driver, it doesn't sit at a blank screen forever when I have 4GB in the machine, instead it exits with an error. Just like the radeon driver, though, if I take out 2GB, everything works fine. All those files were from the 64bit kernel. The results are the same with the 32bit kernel.

I kinda feel like this is some sort of MTRR problem, but I'm not really up on MTRRs and while I have tried fiddling with them a bunch in an effort to get it to work, I've had no luck.

[Tormod Volden (tormodvolden)]

I thought I would share this link http://madduck.net/blog/2009.11.18:ram-reclaimed-mystery-solved/ which explains a bit about MTRR.

[Lawrence LaSH (lawrencelsh)]

I have tried installing a driver through envyng, the ATI driver and the fglrx driver through "Hardware Drivers".
And then limited the RAM to 2GB.

Still this does not work for me.

I am new to using Ubuntu. Am I missing some steps in what should be done?

I am using Ubuntu 9.10 amd64 and had install and still currently running on the safe graphics (vesa) setting. My computer is the Toshiba A350 laptop with Intel Core 2 Duo Processor P8600 / 4GB SDRAM / ATI Mobility Radeon HD 7450 512 MB.

[Lawrence LaSH (lawrencelsh)]

Sorry mistyped. My processor is P7450 and the card is obviously ATI Mobility Radeon HD 3650

[sypky (tomasz-acm-group)]

On unstable git versions kernel 2.6.30 above git18 - (2.6.30-git19 - 2.6.30-git22) ATI driver (fglrx) and open driver (radeon/radeonhd) work fine. In my opinion this change is only implemented in kernel unstable version, so maybe they forget about add this changes to stable kernel tree or they plan do it in future). My kernel is compiled with mtrr options:

CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=0

Tomasz P.

[nikodc (nikodc2)]

Does stable 2.6.32 work? (i'm still on Jaunty)

[sypky (tomasz-acm-group)]

On 2.6.32 and 2.6.33-rc1-git4 still not work ;(

[nikodc (nikodc2)]

How can I install an "unstable git version of the kernel 2.6.30 above git18" ? Any tip? I don't even know where to get the code :)

[sypky (tomasz-acm-group)]

Today I found better resolution. Please append pci=use_crs to kernel boot options.

Tomasz Piasecki

[nikodc (nikodc2)]

Great! That totally worked! Thank you so much!

[nikodc (nikodc2)]

BTW, what that "pci=usr_crs" does?

[Peter Haight (peterh-sapros)]

This fixed it for me as well.

You rock, man.

[sypky (tomasz-acm-group)]

This option force on kernel to use other method of allocation PCI resources. IHMO only way to use this method (CRS) is append this option to kernel parameters. So I think this resolution is not best, becouse this is not nature of the problem.
The question is: why kernel with 4gb ram can't correctly allocate PCI resource using classical (not CRS) method, this is important because in future this option (use_crs) can be removed or changed.

In my free time I try search more and maybe I will find source of the problem.

Tomasz Piasecki

[nikodc (nikodc2)]

Thanks sypky for your answer. But which are the repercussions of using the CRS method instead of the normal approach? Is it better? Is it worse?

[Bjorn Helgaas (bjorn-helgaas)]

The normal method is to assume that all addresses to go the PCI bus unless they're claimed by RAM or other builtin devices first. That's certainly not true when we have more than one PCI host bridge, and apparently it's not true even on some single-bridge machines like this A355.

_CRS is the way BIOS tells the OS about the actual routing, and Windows uses it, so in most respects, I think it's definitely better. I'm working on making it the default for all new machines: http://lkml.org/lkml/2010/2/17/260

I think this will fix the problem reported here (and Peter Haight confirmed this with an older version of my patches: http://bugzilla.kernel.org/show_bug.cgi?id=14183), but I would like a better understanding of what's happening on these machines. If anybody can boot an upstream kernel (2.6.33-rc1 or later) and attach the dmesg log, that would be very helpful. That will show what _CRS is reporting, and hopefully we'll see Linux doing something wrong because it is still ignoring it.

[Peter Haight (peterh-sapros)]

Here's dmesg from 2.6.33-rc8 without the pci=use_crs option.

[Peter Haight (peterh-sapros)]

Here's dmesg from 2.6.33-rc8 with the pci=use_crs

[Bjorn Helgaas (bjorn-helgaas)]

Thanks, Peter!

Here's what happens without "pci=use_crs":

  ACPI: PCI Root Bridge [PCI0] (0000:00)
  pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xfebfffff] (ignored)
  pci 0000:00:01.0: PCI bridge to [bus 01-01]
  pci 0000:00:01.0: bridge window [mem 0xbfe00000-0xbfefffff] <= outside host bridge window
  pci 0000:00:01.0: bridge window [mem 0xc0000000-0xdfffffff 64bit pref]
  pci 0000:01:00.0: reg 18: [mem 0xbfef0000-0xbfefffff] <= video device, outside host bridge window
  pci 0000:01:00.1: reg 10: [mem 0xbfeec000-0xbfeeffff] <= hda-intel, outside host bridge window

So it looks like both devices on bus 01 have memory BARs programmed where accesses will never reach the devices, because they aren't forwarded by the host bridge. With "pci=use_crs", we reprogram them to be inside the host bridge window:

  pci 0000:00:01.0: no compatible bridge window for [mem 0xbfe00000-0xbfefffff] <= P2P window outside upstream (host bridge) window
  pci 0000:01:00.0: no compatible bridge window for [mem 0xbfef0000-0xbfefffff] <= device outside P2P window (which has now been closed)
  pci 0000:01:00.1: no compatible bridge window for [mem 0xbfeec000-0xbfeeffff]
  pci 0000:00:01.0: BAR 14: assigned [mem 0xf2600000-0xf29fffff] <= moved P2P bridge mem window, now inside host bridge window
  pci 0000:01:00.0: BAR 2: assigned [mem 0xf2620000-0xf262ffff] <= video BAR moved inside P2P window
  pci 0000:01:00.1: BAR 0: assigned [mem 0xf2630000-0xf2633fff] <= hda-intel BAR moved inside P2P window

The fact that these two bus 01 devices are unreachable looks like a BIOS bug to me. The BIOS normally programs at least the video device so it works, and Linux shouldn't have to touch it. I think it just happens that with "pci=use_crs", we have enough information to work around the BIOS problem. I expect this is just a point problem with this particular BIOS, and it probably doesn't affect a whole class of machines.

It would be interesting to know what Windows reports for the host bridge windows, the P2P bus windows, and the bus 01 device BARs (you can see this information in the Device Manager). I assume it must be doing basically the same thing Linux does with "pci=use_crs".

[Josh Beitelspacher (joshbeitelspacher)]

Ubuntu 10.10 installs and runs correctly on the Toshiba Satellite A355-S6935 laptop with the full 4GB of memory installed. The "pci=use_crs" option is no longer needed.

[Joseph Salisbury (jsalisbury)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.