# Gentoo on MSI S260 Notebook

## Martini

Hello

This should become a thread to share informations about Gentoo on a MSI S260 Centrino notebook.

I have different problems with the integrated cardreader and acpi configuration specially suspend to ram.

I use gentoo-sources 2.6.13-r3. After 1 hour or so wakeup via the power button ends in a black screen and 

the power/harddisk-led are shines. After 15min wakup from suspend to ram works fine.

I use at the moment only "echo mem > /sys/power/state" like commands for testing powermanagement things.

I'm a noob to "gentoo-on-notebooks". This is my first one.   :Smile: 

Interesting things are also undervolting smilarly in this thread:

https://forums.gentoo.org/viewtopic-t-341298-postdays-0-postorder-asc-start-0.html

If anyone have also this notebook, feel free to post your experiences.

My current kernel config can you find are  here

.. and sorry for my .... english   :Embarassed: 

Thank you

Martin

----------

## bdz

Hi!

My .config for 2.6.13 kernel is there

And here is my grub.conf section to load this kernel:

```
title=Gentoo 2.6.13-r3-r4 Undervolt Test

root=(hd0,0)

kernel= /kernel-2.6.13-gentoo-r3-bdz-r4 root=/dev/hda3 acpi_sleep=s3_bios resume=/dev/hda2 BOOT_SCHEME=wireless cpufreq.debug=7 video=vesafb:ywrap,mtrr,1280x800-16@60
```

About suspend to ram:

I do not have experimented a lot with suspend to ram. Only during a few seconds. And I have a problem with acpid that shutdown the laptop when I wake it up with the power button.

I don't know how to block acpid from doing this without loosing the possibility to shutdown the laptop with the power button when I want to.

Also I had to use the "acpi_sleep=s3_bios" boot parameter to have the display restored when waking up from suspend to ram.

About susend to disk:

I tried software suspend without patching the kernel with sofwware suspend 2 or modifying any script/config. And it looks like it is perfectly working.

About patching the fan: 

I have not tried it. Thank you for the link but I can't read German  :Sad:  I will try Google to translate but last time I tried this on another page I was a bit disapointed.

Is it a bios patch or a kernel patch?

I can't even read the fan speed in /proc/acpi/fan/ This folder is empty  :Sad:  (thermal zone and battery are ok though)

I also tried lmsensors but it has not detected any sensor  :Evil or Very Mad: 

About card reader:

I have not tried it at all. I don't have any card to put in it anyway.

But I have read that SD Card readers are not yet supported under Linux. (This need to be confirmed)

I've read that one guy has made the PCMCIA card reader working but he failed with the SD Card reader.

About the problem compiling the sysfs patch to undervolt the CPU:

I don't know what is the problem. I will look at it and post in the other thread.

This is kind of weird. We use the exact same kernel version. And it compiles fine on my laptop. Did you do a "make clean" before compiling? 

Except my problems with suspend to ram, the fan speed reading and lmsensors every thing else I tried is perfectly working. Even dual head display and DRI with xorg   :Very Happy: 

I'm very happy of this laptop. It is a lot more Linux friendly than my previous one (an acer)

And I'm also sorry for my frenglish  :Wink: 

Edit:

I tried to google-translate the link you gave to me about the fan patch. I tried both English and French translation and I can understand only one sentence out of ten  :Sad: 

And google translates only the first half of the page   :Evil or Very Mad: 

All I have understood is that it is about a patch from MSI and a problem with the USB that get shot in the head when using the patch   :Shocked: Last edited by bdz on Fri Oct 21, 2005 11:08 pm; edited 1 time in total

----------

## Martini

Hello

Thanks for the infos and your kernel config.

About the fan-patch:

It's not a kernel patch or a bios-update. It is a patched firmware for

the embedded fan-controller.

The newest version is this one:

http://www.msi-forum.de/attachment.php?attachmentid=2816

You need to unzip it and burn to a dos-bootable cd, boot from cd, run the

bat-file, wait, reboot. 

If the fan still blows after the reboot, you need to activate it on the fly.

For this you must stress the cpu to becoms a temperature over 60C.

Now your notebook is quiet. The fan switch on at 60C and switch off at 57C.

But be aware, the right side of the chassis are more warmly than before.

Thats normal without fan.  :Smile: 

Suspending:

With or without the bios parameter "acpi_sleep=s3_bios" the effects are the same

in suspend to ram. I will testing further.

Suspend to disk works here also without problems.

PCMCIA / card-reader

I have kernel parameter "pci=assign-busses" in my grub.conf.

The pcmcia works with yentaa-socket (kernel) and pcmcia-cs in default runlevel.

The cardreader is a part of the pcmcia controller. I think the support for this

is missing at this time. It's a Ricoh controller.

```

0000:01:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)

0000:01:04.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)

```

About your kernel-patch and my problems i have posted in the other thread.

Thanks.

Oh, and still about the fan-patch:

The problem is that the usb-controller must switched off when running the fan-patch.

In the batch-file (1012ec52.bat) is called a USBOFF.EXE to switch off the controller before flashing. Thats ok.

Thank you

Martin

----------

## bdz

Thank you very much for the explanations about the fan patch. I don't think I will install it. I prefer to keep the laptop as cool as possible.

And by the way, when undervolting the CPU the temperature never reach 50 °C, even at 1.6 GHz and 100% CPU usage. So the fan never runs at full speed and I find that the noise is acceptable. (But this is a matter of personal preferences. The fan does make some noise. I just don't care)

However I would be intersted to know the timing of a full fan switch on switch off cycle with this patch applied and the CPU at lowest sped. Or maybe the fan never switch on when the CPU is at 800 MHz? In this case what is the temperature that the CPU reach?

What would be very interesting is to have the source code of this firmware so that we can customize it as we like. But I don't think that MSI will agree to release it   :Wink: 

Or they will say "OK here is the source code. But if you modify the firmware it will void the waranty of your laptop!"   :Confused: 

For for the PCMCIA, I confirm I have the same lspci output. But as I do not have any PCMCIA device to plug into it I cannot try.

I have tried again the suspend to ram, after stopping acpid.

First time the resume was OK, after a few seconds sleeping.

Second time, one minute or so later and also a few seconds in suspend mode, the screen was completely messed up at resume. And even Ctrl-Alt-Del was not working. I had to do a hard shutdown  :Sad: 

I think I didn't do it the same way than the previous time I tried suspend to ram. Today I used "cat mem > /sys/power/state". But last time I used KLaptop GUI. And I'm not sure of what actually does this application when you click on the menu.

And now that damned KLaptop has been refusing to enable the acpi menus since last week.  :Evil or Very Mad: 

I'm kind of a windoz intoxicated, that's why I use kde. But the more I use Linux the more I become command line addicted. So I'm not sure I will even try to fix it  :Laughing: 

But I think I will have a look at the source code of klaptop_acpi_helper to know what exactly hides behind the GUI. 

Another difference compared to last time is that I was using a 2.6.12 kernel.

I will make more suspend to ram tests during the week end. With both 2.6.13 and my "old" 2.6.12 kernelLast edited by bdz on Sat Oct 22, 2005 3:45 am; edited 1 time in total

----------

## bdz

Martin,

Here is another script I use. This one is to set the new voltages more easily and experiment differents settings

It also provides a protection that is not done in the kernel patch.

That is to force a lower limit to the voltages based on a configuration. (The patch only have an upper limit protection)

I do not post it to the undervolting thread because it is too specific to the number

of voltage values that we have with the Pentium M 730 and the S260 ACPI default table

It would need some enhancements to be usable on any laptop and CPU model.

And maybe it is also too close to my very personal way of playing with voltages. It sets all the volatges at the same distance of a baseline. The distance being expressed in increments of 16 mV

Use it if you find it usefull, take it as a basis to build your own script, or simply put it to the trash  :Wink: 

But before trying it read carefully all the begining of the file until it is written that you can stop reading

Here are some sample outputs of this script:

(Read the file to understand what the non obvious parts exactly mean  :Wink:  )

```
quasar b12 # ./bin/undervolt 0 0 0

V1 = 956 mV = def - 400 mV = min + 32 mV

V2 = 860 mV = def - 384 mV = min + 32 mV

V3 = 764 mV = def - 352 mV = min + 16 mV

V4 = 700 mV = def - 288 mV = min + 0 mV

Current settings:   1356,1356,1356,1356,1356,1356,1356,1244,1116,988

Requested settings: 956,956,956,956,956,956,956,860,764,700

New settings:       956,956,956,956,956,956,956,860,764,700

quasar b12 # ./bin/undervolt -1 -1 -1

V1 = 940 mV = def - 416 mV = min + 16 mV

V2 = 844 mV = def - 400 mV = min + 16 mV

V3 = 748 mV = def - 368 mV = min + 0 mV

V4 = 700 mV = def - 288 mV = min + 0 mV

Current settings:   956,956,956,956,956,956,956,860,764,700

Requested settings: 940,940,940,940,940,940,940,844,748,700

New settings:       940,940,940,940,940,940,940,844,748,700

quasar b12 # ./bin/undervolt 100 100 100

V1 = 1356 mV = def - 0 mV = min + 432 mV

V2 = 1244 mV = def - 0 mV = min + 416 mV

V3 = 1116 mV = def - 0 mV = min + 368 mV

V4 = 988 mV = def - 0 mV = min + 288 mV

Current settings:   940,940,940,940,940,940,940,844,748,700

Requested settings: 1356,1356,1356,1356,1356,1356,1356,1244,1116,988

New settings:       1356,1356,1356,1356,1356,1356,1356,1244,1116,988

```

----------

## Martini

Good morning, bdz

I'v posted in the undervolting thread about the fan things.

I will reflash the controller with the original firmware.

The book now is too hot. The warming up is too high when it runs

for 3-4 hours. Your are right, i also do not like this. With undervolting

we becomes better temperature results as completely without fan.

With the new firmware the fan never runs at 800/1000/1300 Mhz.

Only at fullspeed and 100% cpu-usage the fan blows over 60C in

level 1. I think the controller has 3 levels.

The patch comes from MSI Taiwan. Also i dont think they are giving

the source for free.

60C are too high IMHO. 45/50C would be better.

Respect, your scripts an the kernel patch are great. The weekend is

reserved for trying out your great work. Results i will post it in this or

the undervolting thread.

On the book and my workstation runs also kde (splitted ebuilds). Klaptop

i have tryed for a while and then i have removed it. Its not bad, but i found

the way with acpi-user-scripts better. It must only function.   :Confused:   :Smile: 

Another question: I have seen you have framebuffer on your laptop enabled.

When i do this with vesafb-tng the framebuffer works great. But when 

runs into X (kde) and i switch to a framebuffer console (via the ctrl-alt-f keys),

the console are totally scrampled and unreadable. Have you the same effects?

I use a masked xfree version.

Thanks bdz

Martin

----------

## bdz

Good "morning"!

I completely agree with all that you wrote about the fan. 

But I have one question. How do you remove the firmware patch?

I don't plan to use this firmware but I ask it because I have posted your explanation about this patch to a french forum where there are some guys interested in it.

Is it like a bios flashing and the utility makes a backup of the old firmware?

And thank you for your compliment  :Smile:  You give me too much honor.

About the vesafb. I had the same problem before. 

I'm also using a masked verion of xfree: xorg-x11-6.8.99.15-r2 with a patch to have the DRI working.

There is now a newer version (xorg-x11-6.8.99.15-r4) but I have not tried it. It is near the end of my todo lst  :Wink: 

To solve the framebuffer problem I tried to switch back from vesafb-tng to the old vesafb driver. But it did not worked. The only thing that was working was to use the default 640x480 resolution. which is very ugly   :Razz: 

Now it works fine with vesafb-tng and a 1280x800 resolution. But I'm not sure of what I did:

I upgraded the kernel from 2.6.12 to 2.6.13 (but as you are also using 2.6.13 I guess that was not the solution)

I also changed the resolution I used. In my kernel config I now have this:

 *Quote:*   

> CONFIG_FB_VESA_DEFAULT_MODE="1280x800@60"

 

And in my grub.conf I have this boot param:

```
video=vesafb:ywrap,mtrr,1280x800-16@60
```

I think that it's this last one that solved the problem. (Before I used 24 bits colors, not 16)

Actualy the screen is still scrambled when I switch from X to the console. But only duing 2/3 seconds. After this small delay the screen restores correctly.

Have a good testing week-end   :Smile: 

----------

## Martini

Hello

Making a backup of the original firmware during or before the flashing is not available.

The only way ist simply reflash with the original firmware.

Here is the link:

http://www.msi-forum.de/attachment.php?attachmentid=2791

I have still not be done, but in the next 2 hours i will make a reflash with old firmware.

About vesafb:

Thanks for the infos. I have tryed with the same kernel parameters like yours, but the

result is the same. Also with 2.6.12 gentoo kernel for a while. I disabled the framebuffer

in the kernel again after some test. But this is not so importantly. 

I will now reflash the firmware. Results are following immediately...   :Smile: 

Thanx bdz

Martin

edit:

for your info: bdz, i have reflashed the original fw.... works without problem.   :Very Happy: 

----------

## bdz

Hello!

I did not had a lot of time to make suspend to ram tests this week-end.

About the console screen that is  messed up when switching from xorg: I was wrong. What made a difference was to setup xorg for dual-head display. When I use the single screen layout the problem is still there. I think that this is a bug with the i915 support of the i810 driver that is still experimental.

bdz

----------

## bdz

Hello!

 *Martini wrote:*   

> 
> 
> About vesafb:
> 
> Thanks for the infos. I have tryed with the same kernel parameters like yours, but the
> ...

 

Maybe I found the solution to this problem!

I'm not sure of all what I've done but here it is:

1/ I unmasqued and emerged the ~x86 version of gentoo-sources to check if the undervolting patch was working with it.

2/ I applied the patch to the kernel source

3/ I made a small modification on kernel config to add smbfs support

4/ I recompiled and installed this new kernel

I don't think that these steps changed anything. But here is what I did after that:

5/ As I was tired to re-emerege ipw2200 and ieee80211 "by hand" each time I was compiling a new kernel version I emerged sys-kernel/module-rebuild

6/ I executed "module-rebuild populate" to initialise the module database

7/ I executed "module-rebuild -X rebuild" to re-emerge all the package that ned to be recompiled for a new kernel version

8/ I rebooted and then switching from xorg to console mode was working in dual and single head mode. (I still have the screen that is scrambled during a few seconds when exiting xorg. But after this delay it comes back to normal)

I think that the important thing is that module-rebuild has recompiled "media-libs/svgalib".

Note: I still have vesafb-tng in my kernel.

Edit:

Well, once again I said victory too quickly. Actually it is still not working in some cases. I have just rebooted with the external screen disconnected. Started xorg. Exited xorg. And bang! console screen fucked up   :Sad: 

I still don't know what causes the switch from xorg to console mode working in some case and not working in other cases. But it looks like it is related the the external screen being connected when I boot or to starting xorg in dual-head mode first.

This is starting to piss me off   :Evil or Very Mad: 

----------

## bdz

This time I really think I found the solution to the problem of the console display that is messed up when switching back from xorg.

Actually someone else gave me the solution in another thread. 

The trick is:

Use vesafb instead of vesafb-tng

AND use the boot parameter "vga=0x361" in grub.conf

AND do not use the VBERestore option in xorg.conf.

For the vga boot parameter any value from 0x361 to 0x36b is working. They all give 1280x800 resolution with 8, 16 or 32 bit color depth. 0x360 is 8 bits. 

0x361 is 16 bits. 

0x362 is 32 bits

0x363 is 8 bits. 

0x364 is 16 bits.

etc ...

And as a nice side effect it seems that it has also improved the wake up from suspend to ram.

bdz

----------

## Martini

Hello bdz

Thank you very much for your tests and sorry for my long respond time. I'm on stress.   :Crying or Very sad: 

I will try this as soon as possible and post results.

Thanks

Martini

----------

