64-bit Intrepid automatic permanent reboot loop related to having exactly 4GB of memory

Is this a regression? Did Hardy work with it?

Gutsy & Hardy x86_64 have the same problem. Also, I tried Fedora.
Fedora Core 9 x86_64 live CDhas the same problem. Fedora Core 10
x86_64 (the DVD) boots and installs without complaining, but when I
try running off the hard drive, it goes into the infinite reboot loop.

So, it's not a regression.

If you can tell me how to trace or single step the boot (e.g., with
boot parameters), I would be happy to collect and send the
information.

Regards
-- Bhaskar

On Sat, Sep 20, 2008 at 10:27 PM, Mackenzie Morgan <email address hidden> wrote:
> Is this a regression? Did Hardy work with it?
>
> ** Changed in: linux (Ubuntu)
> Sourcepackagename: None => linux
> Status: New => Incomplete
>
> --
> 64-bit Intrepid automatic permanent reboot loop
> https://bugs.launchpad.net/bugs/272530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

When it asks if you want to start Ubuntu, hit F6 and backspace out the
quiet and splash parts, then watch for a failure or the last thing to
happen.

I did that even before reporting the problem. There is a blur of text
whizzing by way too fast for me to read, then the screen goes blank,
and a few seconds later, I see the BIOS messages as it reboots.

-- Bhaskar

On Sun, Sep 21, 2008 at 12:44 AM, Mackenzie Morgan <email address hidden> wrote:
> When it asks if you want to start Ubuntu, hit F6 and backspace out the
> quiet and splash parts, then watch for a failure or the last thing to
> happen.
>
> --
> 64-bit Intrepid automatic permanent reboot loop
> https://bugs.launchpad.net/bugs/272530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Same here on Samsung SE11-Aura Notebook
with P8400/4GB/nVidia 9600.

Ubuntu 8.10 is coming tomorrow, and will NOT even boot on a lot of notebooks.
Come on, guys, this is a SHOW STOPPER!

This bug will effect very many current systems.
It is time for 64bit Linux on 64bit CPUs with 4GB memory.
I can't believe, that this bug is marked to expire.

To give you more info:
Last thing i can see, when the messages are running over the screen is:
[..timestamp..] Checking if image is initramfs
I am not sure, but may be, there is a next message containig 'keyboard'.
It is way too fast.

hope it helps
  Ralf

To be fair to the Ubuntu folks, it is not just an Ubuntu issue. This
also happens with FC 10, and I have seen reports on the Internet of it
happening with SLES. At this point, my suspicion is that it has
something to do with the dynamic CPU frequency / power management
kernel modules not recognizing a brand new CPU or chip set.

-- Bhaskar

On Wed, Oct 29, 2008 at 8:46 AM, Ralf Naujokat <email address hidden> wrote:
> Same here on Samsung SE11-Aura Notebook
> with P8400/4GB/nVidia 9600.
>
> Ubuntu 8.10 is coming tomorrow, and will NOT even boot on a lot of notebooks.
> Come on, guys, this is a SHOW STOPPER!
>
> This bug will effect very many current systems.
> It is time for 64bit Linux on 64bit CPUs with 4GB memory.
> I can't believe, that this bug is marked to expire.
>
> To give you more info:
> Last thing i can see, when the messages are running over the screen is:
> [..timestamp..] Checking if image is initramfs
> I am not sure, but may be, there is a next message containig 'keyboard'.
> It is way too fast.
>
> hope it helps
> Ralf
>
> --
> 64-bit Intrepid automatic permanent reboot loop
> https://bugs.launchpad.net/bugs/272530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

On Wed, 2008-10-29 at 12:46 +0000, Ralf Naujokat wrote:
> Ubuntu 8.10 is coming tomorrow, and will NOT even boot on a lot of notebooks.
> Come on, guys, this is a SHOW STOPPER!

Very few really. Have you noticed, this bug has no duplicates? Testing
so far shows it as just you two. And it is guaranteed not to be fixed
for release because release is tomorrow. Today is for creating the cd
images. Quite a lot of progress on figuring out the cause along with
developing a patch, creating a test disk image, and getting that tested
by a large number of users to watch for regressions, would need to
happen sometime in the next oh....2 hours?

I'm setting this back to new. Don't know what else to ask. The lshw is there, but it's not enough because it could be any of that hardware, and unless some other people run into this bug, we'll never figure out which one you all have to cause it.

And I'll set it as High importance since it "has a severe impact on a small number of users," but whatever hardware incompatibility it is will still have to wait for Jaunty. There aren't updated CDs released, except for LTS.

Hi all.

I managed to setup a serial console and log the output.
See attachment.

I don't think it is 'yust us two'. Having the same bug on two very different
machines will perhaps cover a lot of other machines, too.
No idea, why no other people complain about this, but i think, they will.

I never expected this bug to be fixed in two hours, but i was wondering,
why no one seems to cares since 2008-09-21...

BTW: I really like Ubuntu and have it on about 10 machines since v 6.06,
and i know, all of you are doing a great job.

greetings
  Ralf

Added my hardware info as attachment.
If someone needs more, please ask for it.

To have some kind of workaround:
I installed the 32bit version with the server kernel.
As far as i can see, all of the hardware is supported out of the box,
some issues with Fn-Keys for brightness control (does not work),
but with the server kernel you can access all of the 4GB memory.

greetings
  Ralf

You can access all 4GB because the server kernel uses PAE. PAE is also
the reason the server kernel usually kernel panics on hardware more than
a couple years old.

Ralf:
Different models don't make them "very different," just like same model
doesn't necessarily mean a single piece of hardware is the same
(ugh...when manufacturers do that, it's a pain). I'm going to look
through the lshw outputs you both provided and see if there's anything
that matches.

Just to check, did you install with the Intrepid CD or upgrade? I intended to keep Hardy a while longer, so I don't want to install it, but if this is present on the CD, I can try with my Core 2 Duo.

Hm, you both have 4GB of memory, right? Any chance 64bit boots when you remove some memory? If it's only triggered with exactly 4GB, that'd be interesting...

I can't experiment with RAM because my son now has the laptop in
college, and I won't get my hands on it till the end of the month.

Also, in response to your earlier question, I have tried:

 - the live CD
 - booting from USB
 - copying in an AMD64 Intrepid from another laptop

All exhibit the same behavior. 32-bits works perfectly.

Regards
-- Bhaskar

On Wed, Oct 29, 2008 at 12:19 PM, Mackenzie Morgan <email address hidden> wrote:
> Hm, you both have 4GB of memory, right? Any chance 64bit boots when you
> remove some memory? If it's only triggered with exactly 4GB, that'd be
> interesting...
>
> --
> 64-bit Intrepid automatic permanent reboot loop
> https://bugs.launchpad.net/bugs/272530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Hi all.

After Mackenzie Morgan's guess i removed one of the memory modules.
So my Laptop has only 2GB of Ram instead of 4GB now.
And bingo:I can boot the 64bit-Live-System from the Desktop CD and
seems to work perfectly. (As far as i can see right now.)

greetings
  Ralf

Just a comment:

My Desktop PC has 4GB of Ram, and does boot with Intrepid-64.
So it's not just having 4GB of Ram.

greetings
  Ralf

Yeah, I figure there have to be other 4GB users, so it's got to be a
combination of 4GB and something else. That's why I put "related to".

I have another x86_64 laptop with 4GB RAM that runs 64-bit Intrepid perfectly.

The problem has something to do with that particular CPU and chipset.
And it has something to do with power / CPU frequency. If you put
acpi=off in the boot line, it doesn't automatically reboot, but it
does hang. On Fedora Core 10, I was able to install it from the
installer (live CD does hard reboot), but the installed image would
reboot unless I disabled the automatic startup of the CPU frequency
service. But then, if I tried shutting down Linux, it would again
reboot hard. Maybe the power / frequency management in 64-bits
doesn't recognize the CPU / chipset type or something like that.

-- Bhaskar

On Wed, Oct 29, 2008 at 2:20 PM, Ralf Naujokat <email address hidden> wrote:
> Just a comment:
>
> My Desktop PC has 4GB of Ram, and does boot with Intrepid-64.
> So it's not just having 4GB of Ram.
>
> greetings
> Ralf
>
> --
> 64-bit Intrepid automatic permanent reboot loop related to having exactly 4GB of memory
> https://bugs.launchpad.net/bugs/272530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

A wild and crazy idea - I wonder if maybe there is a BIOS bug. Ralf,
are you able to try a boot with 4GB RAM and with a mem= on the boot
line in /boot/grub/menu.lst? And if it still gives the problem with
4GB, try 1MB less than 4GB or something like that.

Regards
-- Bhaskar

On Wed, Oct 29, 2008 at 2:30 PM, Mackenzie Morgan <email address hidden> wrote:
> Yeah, I figure there have to be other 4GB users, so it's got to be a
> combination of 4GB and something else. That's why I put "related to".
>
> --
> 64-bit Intrepid automatic permanent reboot loop related to having exactly 4GB of memory
> https://bugs.launchpad.net/bugs/272530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

bhaskars idea may be wild and crazy, but he was right:

I added mem=4096m as boot parameter and
the 64bit-Live-System from the Desktop CD
(still the beta, i will try the release later)
booted and everything is fine.

'free' tells me something about 3GB, is this because of the ram disk
in the live-system?

i add a dmesg output as attachment.

greetings
  Ralf

Hi,

i did a complete new install of my Notebook with the actual Ubuntu 8.10 64bit Desktop release CD.
I added mem=4096M to the boot parameter and everything went fine.
After first reboot, i had to modify /boot/grub/menu.lst with the same boot parameter, because
the installer did not add this in this file.

bhaskar, did you do anything (removing memory, adding parameter) to verify this 'bug fix'?

Ralf --

I do not have the laptop any more. It was purchased for my son, who
is now away at college. When he comes home for the Thanksgiving
holiday at the end of November, I will be able to try specifying the
mem=4096m on the command line and/or removing RAM.

Regards
-- Bhaskar

On Wed, Nov 5, 2008 at 3:23 AM, Ralf Naujokat <email address hidden> wrote:
> Hi,
>
> i did a complete new install of my Notebook with the actual Ubuntu 8.10 64bit Desktop release CD.
> I added mem=4096M to the boot parameter and everything went fine.
> After first reboot, i had to modify /boot/grub/menu.lst with the same boot parameter, because
> the installer did not add this in this file.
>
> bhaskar, did you do anything (removing memory, adding parameter) to
> verify this 'bug fix'?
>
> --
> 64-bit Intrepid automatic permanent reboot loop related to having exactly 4GB of memory
> https://bugs.launchpad.net/bugs/272530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I just tested my son's laptop, and with mem=4096m on the boot line, it
boots perfectly!

Regards
-- Bhaskar

On Wed, Nov 5, 2008 at 7:01 AM, K.S. Bhaskar <email address hidden> wrote:
> Ralf --
>
> I do not have the laptop any more. It was purchased for my son, who
> is now away at college. When he comes home for the Thanksgiving
> holiday at the end of November, I will be able to try specifying the
> mem=4096m on the command line and/or removing RAM.
>
> Regards
> -- Bhaskar
>
> On Wed, Nov 5, 2008 at 3:23 AM, Ralf Naujokat <email address hidden> wrote:
>> Hi,
>>
>> i did a complete new install of my Notebook with the actual Ubuntu 8.10 64bit Desktop release CD.
>> I added mem=4096M to the boot parameter and everything went fine.
>> After first reboot, i had to modify /boot/grub/menu.lst with the same boot parameter, because
>> the installer did not add this in this file.
>>
>> bhaskar, did you do anything (removing memory, adding parameter) to
>> verify this 'bug fix'?
>>
>> --
>> 64-bit Intrepid automatic permanent reboot loop related to having exactly 4GB of memory
>> https://bugs.launchpad.net/bugs/272530
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>

I am trying to install 64-bit Intrepid on a Gigabyte MA78GM-S2H with an Athlon X2 and 2 GB of memory. After the install splash screen the system reboots. It does not report any messages.

On Tue, 2008-11-25 at 05:07 +0000, Joe Halpen wrote:
> I am trying to install 64-bit Intrepid on a Gigabyte MA78GM-S2H with an
> Athlon X2 and 2 GB of memory. After the install splash screen the
> system reboots. It does not report any messages.

2GB...well that's new. And does mem=2048m make a difference?

1. Do your laptops use shared video memory? If so, how much? (BIOS
should tell you)

2. If you install Intrepid then install all the updates, including the
kernel in -proposed, can it boot without the mem=4096m?

Hi all.

My laptop should have shared video memory (see below and attachment),
but there are no options in BIOS for changing any settings.

1.)

I started Vista (sorry for this) and looked at the nvidia driver system infos,
i found this:
-----8<--------
NVIDIA Systeminformationen-Bericht erstellt am: 11/25/2008 10:23:15

Name des Systems: NB03

[Anzeige]

Prozessor: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz (2261 MHz)

Betriebssystem: Microsoft Windows Vista (Service Pack 1)

DirectX-Version: 10.0

&GPU-Prozessor: GeForce 9600M GT

ForceWare-Version: 176.24

Gesamter verfügbarer Grafikspeicher: 1788 MB
 | -> total abvailable graphic memory
Dedizierter Videospeicher: 512 MB
 -> | dedicated video memory
System-Videospeicher: 0 MB
 | -> system video memory
Freigegebener Systemspeicher: 1276 MB
 | freed/released? system memory
Video-BIOS-Version: 62.94.4a.00.c6

IRQ: 16

Bus: PCI Express x1

-----8<--------

2.)

Starting the system with the lastest kernel
-----8<--------
admin@nb03:~$ uname -a
Linux nb03 2.6.27-10-generic #1 SMP Fri Nov 21 19:19:18 UTC 2008 x86_64 GNU/Linux
-----8<--------
and no mem=4096m option does not work,
same reboot as with the kernel from the install cd.

greetings
  Ralf

Sorry for that '| ->' things,
that was only meant to mark the translations.

Another comment:
As i found after some googling, the GeForce 9600M GT should have _NO_ shared video memory.
(confused)

greetings
  Ralf

No, I tried using mem=2048m and it did not make a difference. I also tried Intrepid-32 bit and Hardy-64 bit versions with the same results. Removing "quiet" from the boot parameters I see that "Mounting Root File System" never says "ok" before it reboots.

On Tue, 2008-11-25 at 13:49 +0000, Joe Halpen wrote:
> No, I tried using mem=2048m and it did not make a difference. I also
> tried Intrepid-32 bit and Hardy-64 bit versions with the same results.
> Removing "quiet" from the boot parameters I see that "Mounting Root File
> System" never says "ok" before it reboots.

File a separate bug. If 32bit is also doing it, you don't likely have
the same root cause.

Hi all.

Being happy about the booting with the mem=4096m parameter i did not notice, that the memory
is not fully regocnized now. Seems, that only 3GB of RAM is used:

-----8-----
admin@nb03:~$ free
             total used free shared buffers cached
Mem: 3084356 744276 2340080 0 18532 257028
-/+ buffers/cache: 468716 2615640
Swap: 7992328 0 7992328
-----8-----

@bhaskar:
Can you check this on your system?

@Others:
What infos are needed to continue with this?

greetings
  Ralf

It only sees 2GB on mine:

bhaskar@localhost:~$ free
             total used free shared buffers cached
Mem: 2568504 1199264 1369240 0 1124 573900
-/+ buffers/cache: 624240 1944264
Swap: 2097144 0 2097144

With a 32-bit or 64-bit kernel, it only sees 2GB.

-- Bhaskar

On Thu, Nov 27, 2008 at 5:38 PM, Ralf Naujokat <email address hidden> wrote:
> Hi all.
>
> Being happy about the booting with the mem=4096m parameter i did not notice, that the memory
> is not fully regocnized now. Seems, that only 3GB of RAM is used:
>
> -----8-----
> admin@nb03:~$ free
> total used free shared buffers cached
> Mem: 3084356 744276 2340080 0 18532 257028
> -/+ buffers/cache: 468716 2615640
> Swap: 7992328 0 7992328
> -----8-----
>
> @bhaskar:
> Can you check this on your system?
>
> @Others:
> What infos are needed to continue with this?
>
> greetings
> Ralf
>
> --
> 64-bit Intrepid automatic permanent reboot loop related to having exactly 4GB of memory
> https://bugs.launchpad.net/bugs/272530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

HI all.

looks like there is a similar problem in
https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/287031

greetings
  Ralf

Hi all,

Just to let you know: Same things happen with Fedora 10/64bit.
Crash/Reboot with standard boot, works with param mem=4096m, but only 3GB of RAM available.

Is this a dead end here? Can i report this error in an other place?

greetings
  Ralf

Setting this to Triaged since it seems to have all relevant info.

Just wanted to add that I have a Samsung R560 with a P8400 chipset and indeed 4 GB of memory. My last state with Ubuntu 8.10 AMD64 (released version) was as well: reboots unless I use acpi=off.

I tried mem=4096M after finding this bug. It boots, but only sees 3 GB instead of 4 GB which are installed. It does see all 4 GB when booting with acpi=off.

Some more ACPI info can probably be found here:

http://www.lesswatts.org/projects/acpi/

Hi all.

Shame on me, i never tried this acpi=off before.
Now i find exactly the same here on my notebook.
Boots with acpi=off, and sees all 4G.
I upload a dmesg output for this.

Hopefully, someone finds a solution for this.

greetings
  Ralf

Hi all,
I have Samsung R560 [NP-R560-ASS1EE], P8600 and geforce 9600M GT, Montevina platform and the same instant reboot problem.
Before I was using acpi=off, but it actually was terrible solution - system with this was very unstable, closing lid or plugging in/out power leads to the same instant restart. Also 'Fn' controls did the same. Ex. Volume or Brightness control. Also there was no power manager Applet, no Hibernate and so on... When booting with mem=4096m (BIG thank to you guys) system is usable and stable - only disadvantage with this memory, but in other hand I prefer stable and usable system with some less RAM than more RAM but totaly unstable and unusable system.
And I think also that, 3GB can be real RAM amount because of shared video ram. With acpi=off system shows 4GB, thats ok, but who knows if this whole amount is really accessible and stable.
I just Guessing that actual problem lies on memory amont detection, and specifying mem=4096m helps memory detector to detect atual RAM amount available.

Of course no power management worked without ACPI. ACPI *is* power
management. However, it seems to me that you've all hit an ACPI bug and
that mem=4096 is just a workaround for it.

Actually, let's try testing out some other ACPI boot options. On
https://wiki.ubuntu.com/DebuggingACPI there is a list of them. See if
booting with one of them works (don't use mem=4096 or acpi=off when
testing them).

 status incomplete

Hi,

i just tried the options listed on that page.

Only acpi=off and acpi=ht does boot but showing only 3G.
(What makes sense, because the cpu is a real dual core
and has no hyper threading.)
Every other options has the crash and the auto reboot.
Output of dmidecode attached. I can do some more test
today, but next 2 weekys i'm away from keyboard.

Hi,
To Mackenzie Morgan:
I do not agree with you because mem=4096M is not an ACPI option but with this option OS and also ACPI is working just fine.
Actually I've also tried many of that options from your link, also tried doing many things since I bought this Laptop, but the mem=4096M option is that only option which makes my laptop fully usable with x64 Linux.

Ralf says it works fine if you turn off ACPI and if you only turn off
ACPI's hyperthreading. That would mean it's a bug in ACPI's
hyperthreading. Does that not work for you too, Dasl?

Oh, and no, there's no shared video RAM involved on these systems.
They're using discrete graphics with onboard video memory from Nvidia
(yeah, I asked that too...see above).

Hi,
I'm was telling about this in very first post here.
Once again:
* acpi=off or acpi=ht no crash, can boot, but system is unstable - actions like (un)plugging power, closing lid or adjust volume leads to the same immediate crash and autoreboot.
* mem=4096M - everything is working just fine. No side effects are watched except that systems total memory is 2.9GB

About that onboard video memory - not sure - I suspect, graphics is using same RAM which is no problem on 32bit vista(notebook came with it) because it anyway can use 3MB max... I'll also try to look what are telling system information tools like SiSoft sandra, etc. about graphics and system RAM.

Vista only sees only 3GB of RAM because your Vista is 32bit. It can't
see all 4GB.

So that is what I told before :)

OK, I'm asking #ubuntu-bugs and being told it's most likely a kernel bug. I think there's enough info here for a developer to look into it. They might ask for more info when they do.

Oh, and please try with a Jaunty daily live cd, just to check it hasn't been fixed yet.

I have the same issue on a Samsung E152 -Aura T5750 Eron.

I filled in this bug before I found this thread: bug 310355

sorry for the duplicate thread :)

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

I tried the jaunty alpha2 live CD today, and the problem remains. Booting does not work without the mem=4096M flag (reboots in a loop), and using this flag only 3GB of memory are mapped by the kernel.

Hi all.

I updated the BIOS of my notebook
(Samsung R710, SE11-Aura, P8400)
today from ver. 05SV to ver. 10SV.

Now i can boot without the mem=4096m option
and all memory is usable. (free reports 4050516 bytes total)

May be some of you can find updates, too.

greetings
  Ralf

Everybody else:
Can you check for a BIOS update and see if that also fixes your problem?

The latest Bios for my notebook (Samsung Q310, bios version 10SU 30/01/2009) still doesn't work.

Good news for all owners of a Samsung R560 Aura. I upgraded my BIOS from version 08LA to version 09LA and the problem went away. The 64 bit LiveCD boots without any special options and all 4 GB are reported to be available.

Some inline update for all users of that laptop:

BIOS updating is only possible from Windows and I was only able to install Windows XP onto a harddisk I swapped after removing one memory module as the XP installer crashes on 4 GB. So the recommended BIOS upgrade procedure for this laptop is:

1. Download the BIOS update onto some removable media, for example an USB stick while you still have a network connection. (You won't once you installed XP!)
2. Get an empty 2,5" SATA harddisk and put it in.
3. Reduce memory to 2 GB.
4. Install Windows.
5. Update BIOS.
6. Put memory and HD with Linux back.
7. Enjoy!

it doesn't work too on my Samsung E152 Aura T5750 Eron. I wrote an email to samsung a few days ago asking if there will be a bios fix, but got no response until yet. Let them some time... I did also send them a link to this thread...

in addition:

If you are thinking of some USB boot media instead of getting a 2nd HD:

- booting from USB is only supported with BIOS version 08LA.
- the BIOS updater won't run from any Windows PE media for whatever reason

It would be nice if BIOS flashing could become part of the Linux kernel and / or the vendors would support Linux in their BIOS update tools or at least offer some bootable CD for BIOS updates.

Confirmed: Samsung R560 - Latest BIOS update(08LA -> 09LA) solves the problem.
But in other hand, having same problem on Lenovo 3000 N500(4233) - latest BIOS update(1.02->1.03) has no effect.

I'm having exactly the same problem in Gentoo amd64.

Actually I'm using mem=4000M, the laptop is not rebooting and 'free' reports:
tiago@alice ~ $ free -m
             total used free shared buffers cached
Mem: 3011 677 2333 0 9 162
-/+ buffers/cache: 505 2505
Swap: 0 0 0

I've found out people using Vista 64 bits has the same problem (a guy from the laptop vendor said me) and the way they "fix" it is making something similar to set mem=4000M on Linux.

Therefore, I think the problem is really only in our BIOS.

Hi,

it's a pity, I had to ask a second time to get an answer from samsung, and that is what they said:

Von unserer Seite aus werden nur 32-Bit Betriebssysteme ausgeliefert und nur
Treiber für 32-Bit Versionen
angeboten. Daher werden auch nur diese unterstützt. Uns ist kein Fehler in der
Speicheradressierung der
E152-Serie bekannt, weshalb auch nicht davon auszugehen ist, dass ein Bios
Update für dieses erscheinen
wird.

for those who don't understand german, they say they're only supporting 32 bit systems and that they don't believe that there is a bug in memory management for the E152 series. I don't believe that, because I read at some other place that even Vista 64-bit doesn't want to install on this laptop. I liked samsung before, but that will be the last samsung thing I bought....

If samsung doesn't want to correct the bug, is there maybe a possibility for a kernel-patch as a sort of workaround?

The machine in question is made by Cleo (a Taiwanese ODM - at least
mine is), and there is supposedly a BIOS upgrade that fixes the memory
problem. But I haven't picked up the courage to install try it
because it requires a non-Linux OS to install it, and one would have
to do some experimentation to see how to update it with Linux.

I am not sure a kernel patch would work, because the BIOS has to turn
on the memory to make it read-writable (or so I understand).

-- Bhaskar

On Fri, Mar 13, 2009 at 5:45 AM, BongoMan <email address hidden> wrote:
> Hi,
>
> it's a pity, I had to ask a second time to get an answer from samsung,
> and that is what they said:
>
> Von unserer Seite aus werden nur 32-Bit Betriebssysteme ausgeliefert und nur
> Treiber für 32-Bit Versionen
> angeboten. Daher werden auch nur diese unterstützt. Uns ist kein Fehler in der
> Speicheradressierung der
> E152-Serie bekannt, weshalb auch nicht davon auszugehen ist, dass ein Bios
> Update für dieses erscheinen
> wird.
>
> for those who don't understand german, they say they're only supporting
> 32 bit systems and that they don't believe that there is a bug in memory
> management for the E152 series.  I don't believe that, because I read at
> some other place that even Vista 64-bit doesn't want to install on this
> laptop. I liked samsung before, but that will be the last samsung thing
> I bought....
>
> If samsung doesn't want to correct the bug, is there maybe a possibility
> for a kernel-patch as a sort of workaround?
>
> --
> 64-bit Intrepid automatic permanent reboot loop related to having exactly 4GB of memory
> https://bugs.launchpad.net/bugs/272530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

bhaskar, I think you did a typo and meant "Clevo" ;) But I couldn't find any hint on the net for my samsung notebook beeing also made by Clevo...

I wouldn't risk to do a BIOS update using wine too, even if I think it should work...

After having an open-source OS, I now would love to have an open-source BIOS :) Damn, apparently we are completely dependant on the good will of those samsung guys!

Yes, I did mean Clevo. Sorry. I wish I had the courage (and
expertise) to try something like Coreboot (http://coreboot.org).

On Fri, Mar 13, 2009 at 10:53 AM, BongoMan <email address hidden> wrote:
> bhaskar, I think you did a typo and meant "Clevo" ;) But I couldn't find
> any hint on the net for my samsung notebook beeing also made by Clevo...
>
> I wouldn't risk to do a BIOS update using wine too, even if I think it
> should work...
>
> After having an open-source OS, I now would love to have an open-source
> BIOS :) Damn, apparently we are completely dependant on the good will of
> those samsung guys!
>
> --
> 64-bit Intrepid automatic permanent reboot loop related to having exactly 4GB of memory
> https://bugs.launchpad.net/bugs/272530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

There are some BIOS bugs that can be worked around in the kernel. For
example, there are a *ton* of workarounds in the HDA sound drivers to tell the
kernel what pins to initialize because BIOSes often report it wrong.

I'm not sure that this falls into that category, but in case it does, can you
attach the output of "acpidump"?

Information from my laptop attached.

Regards
-- Bhaskar

On Fri, Mar 13, 2009 at 12:37 PM, BongoMan <email address hidden> wrote:
>
> ** Attachment added: "lshw.txt"
>   http://launchpadlibrarian.net/23831456/lshw.txt
>
> --
> 64-bit Intrepid automatic permanent reboot loop related to having exactly 4GB of memory
> https://bugs.launchpad.net/bugs/272530
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Same issue for me wit an Samsung R560

opened a bug report ere:
https://bugs.launchpad.net/ubuntu/+bug/343585

Found this one an hour ago and am going to try your suggestions.

Hi all,

I have a Clevo laptop (sold as Xxodd) with an Intel P9500 and 4GB Ram.

Some history:
I purchased the laptop (last summer) and tried to install the current Ubuntu 64-bit and Fedora 64-bit.
The effect in both cases was endless rebooting and I couldn't get it to work.
I installed CentOS 5.2 64Bit and was able to get most of the system working. One of the remaining anoyning problems was that when I do 'shutdown' the system woould shutdown and reboot.

Now last week I upgraded the system to CentOS 5.3 64Bit (newer kernel) and I was faced with this problem again.
Because centOS has an Interactive startup I figured out that the system rebooted during the startup of the "kudzu" and "cpuspeed" services. So I disabled these and the system worked (always at fullspeed :( )

yesterday I read this bug report and descided to try the mentioned mem=4096m solution.
So I added the mem=4096m option (to my CentOS 5.3) and all my troubles have gone. The system now works like a charm and also when I do a shutdown the system actually powers off when I shutdown.

My assesments based on this and all the stories above: This is a kernel issue.

Hello!

Exact same problem on a Samsung r510 with 4gb (2x2gb dual kit)

ubuntu x64, opensuse x64 and fedora x64 will not work with 4gb. However if i pull a 2gb stick out they all work.

I have noticed a few of us have samsung laptops.

My laptop chipset, and processor , gfx

Intel GM45 + ICH9(m)
Intel T3200 processor
Intel x4500 gfx (integrated)

somehow something changed since the last kernel updates on jaunty. I now have kernel 2.6.28-12-generic (from jaunty-proposed) and it still reboots if I don't use the "mem=4096M" argument, but the reboot happens a little bit later than before. I could narrow it down to the command "/sbin/udevadm trigger" in /etc/init.d/udev. The reboot occurs while this command is executed, just after the output of the string "loading hardware drivers". I hope this helps a little...

I couldn't find this bug, so I reported another here: https://bugs.launchpad.net/linux/+bug/387955

For me mem=4096M option also workes and I also get only 2,9Gb of RAM available. Now I'll check for BIOS version, maybe BIOS update can fix the problem.

I've tested Ubuntu 8.04-9.10, Debian 5.0.

Systems, which workes perfectly: Windows 7 x86-64, FreeBSD 7.1 x86-64, OpenSolaris x86-64.

My laptop is Samsung X360 AA03. 4Gb of RAM

I updated the BIOS to 07LM version. THis fixes the problem with amd64 version of ubuntu. Now it installs correct without any options and all 4Gb of memory are available.

*Small tip. BIOS can be updates from 32-bit version of Windows only.*

On Mon, Jun 29, 2009 at 8:14 AM, Sokolov
Sergey<email address hidden> wrote:
> I updated the BIOS to 07LM version. THis fixes the problem with amd64
> version of ubuntu. Now it installs correct without any options and all
> 4Gb of memory are available.
>
> *Small tip. BIOS can be updates from 32-bit version of Windows only.*

[KSB] Anyone try FreeDOS to apply the BIOS update? Any way to update
the BIOS without Windows? Thanks.

-- Bhaskar

I tried update from DOS boot disk. It doesn't work. As I understand the program is 16-bit, but needs WinAPI.

I flashed BIOS from WIndows 7. Here you can find it: http://torrents.ru/forum/viewtopic.php?t=1925536

It's not a pirate version. It's available pre-RTM release. You can get code from Microsoft. But you won't need it just for flashing.

It's a special build that can be installed from USB.

Just to register:
My laptop with this problem is a Compal JFT00 (bios version 1.05A).

At the moment it started having other problems, maybe related to this one (e.g., rebooting also when compiling a lot of things and ACPI thermal_zone temperature is oscillating quickly and too much between 42, 55, 63, 69, 76 C) -- but please don't assume it yet.

I still believe it's not a problem on Kernel, because it also affects Windows 64 bits. For me, it's clear that's a hardware problem, probably with chipset (motherboard) or processor.

@Everyone Any news since October, 2008?

I can just repeat what I said in my last message, it seems important to me: If I modify /etc/init.d/udev around line 68 like this:

    echo BEFORE
    sleep 5

    # Fix permissions and missing symlinks/programs for devices made in
    # initramfs, and catch up on everything we missed
    log_begin_msg "Loading hardware drivers..."
    /sbin/udevadm trigger
    if /sbin/udevadm settle; then
        log_end_msg 0
    else
        log_end_msg $?
    fi

    echo AFTER
    sleep 5

I can still see "BEFORE" appearing on the screen, but it will reboot before "AFTER" appears. So the reboot occurs while execution of " /sbin/udevadm trigger". Does anybody else observe this?

my kernel is now 2.6.28-15-generic on kubunty jaunty 64 bit.

sorry I must correct myself, actually the reboot occurs during execution of the command
"/sbin/udevadm settle" just after the one I said before.

thus if I write:

    echo BEFORE
    sleep 5

    # Fix permissions and missing symlinks/programs for devices made in
    # initramfs, and catch up on everything we missed
    log_begin_msg "Loading hardware drivers..."
    /sbin/udevadm trigger

    echo IN_BETWEEN
    sleep 5

    if /sbin/udevadm settle; then
        log_end_msg 0
    else
        log_end_msg $?
    fi

    echo AFTER
    sleep 5

I will see BEFORE and IN_BETWEEN, but not AFTER

I have a new information:
This problem in my laptop is caused by a motherboard incompatibility with the processor. I believe a BIOS update could fix it, but a guy with the same laptop guaranteed me that other processor can fix it too.

My processor is a Intel Core 2 Duo T5750 (Merom) and some working models are T8100 and T9300 (Penryn).

same cpu here, thanx for the info.

I had the same problem and, in fact, I still have! But now I know the origin: the chipset. My laptop has a 945 Intel chipset which cannot remap the ram. So, even with a 64bits OS I can't use the whole memory, unfortunately.

Me got the same problem with a Samsung R510 Driton. It recognizes only 3Gb of my holy RAM but I do not have the boot problems. I guess I have a 32bits system installed. ...

I had the exact same problem of infinite reboot loop, and then I read this bug report. I think this is actually not a Ubuntu x64 or any Linux x64 distribution bug, but a bug in the computer. I am using Samsung R710, and this problem went away after I installed a new BIOS (version 11SV), released by Samsung on the 12th of January 2010.

So in my case this was a BIOS problem, and not Ubuntu or Linux problem.

My first suggestion is to check if there is a newer BIOS available, install it, and check all of the settings!

Yeah finally they fixed it at samsung :)))) Since Nov. 2009 there is
also a BIOS-Update for my notebook (samsung E152-Aura T5750 Eron) which
fixes the bug. Yes!

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.