Recommending the MSI MegaBook PR200WX-058EU laptop to Linux users

I recently bought a new MSI laptop and I am really pleased with my choice so far.

Since with the previous laptop I managed to kill two of my desired features, long battery life and pretty portable, I decided is time to look really well and see what the market has to offer.

I settled on a MSI PR200WX-058EU which has the following:

• built on a Centrino platform
• Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz
  
• Intel Corporation PRO/Wireless 4965 AG or AGN
• Intel mobile chipset
• 3GB of memory (yes, I would have enjoyed 4, but it seems the 32 bit barrier still decides hardware configurations)
• 320GB HDD
• DVD+/-RW
• Mobile GM965/GL960 Integrated Graphics Controller
• 12" wide screen (1280x800)
• 1 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet
• 8 cell battery by default (long battery life)
  
• 1 USB 2.0 Camera - uses luvc driver
• bluetooth
• 1 card reader
• 3 USB port, 1 HDMI, 1 D-sub 15 connector, 1 PCI Express port, modem port
• fingerprint reader
• an advertised weight of 1.8kg (I weighted it at 2.1kg with the 8 cell battery)
  

In other words a small and mobile powerhouse for which I payed 3800 RON (approx. 1100€). I'd say not too bad at all.

Thanks to Gonéri Le Bouder and some searches on the internet I concluded that
the brand is not bad at all, and now that I have it I really am sure.

Of course, I installed Debian Lenny on it (I also sent an installation report), and, in spite of the initial problems, I managed to make the laptop work pretty nice, but I am especially excited about the webcam, which works with the linux-uvc driver.


There were some issues, but I managed to fix some them while I have been ignoring some other. The LaptopTestingTeam page for MSI PR200 on the ubuntu wiki was very helpful.
What have I been ignoring?

• it seems that from time to time the battery charge status isincorrect, or acpi report that the AC is plugged in
• headphones don't automatically turn off the speakers
• fingerprint reader is not used yet, but I intent to experiment at some point with it (authentication via the fingerprint would be cool)
  
• the keyboard seems a little bit too hard (but I hope it will loose up with time)
• modem isn't probably working, but I don't think I'll ever try
• there are some issues in gnome-power-manager which cause strange behaviour and grief wrt screen brighness
• sleep doesn't work,but hibernation does
  

What would you do if I'd tell you that the battery lasts 4 hours or even more while the wlan is on and working (browsing and stuff like installing new packages, configs) with the brightness set to minimum?


I am really excited about this and I can say that I think I have found my next generation laptop, so if you're thinking of a cheap mobile powerhouse on which Linux must run, this laptop might be for you.

I find the following to be selling points (for a Linux buyer or others):

• comes with FreeDOS, so no extra money for an OS you don't use
  
• wifi works
• webcam works with luvc
• no big problems during install (the most severe are already fixed)
• long battery life, even when using wifi (4+ hours in browsing+some package installation mode, according to my tests)
• light enough to carry around easily (2.1kg, 2.4kg with charger)
• nice design - some people asked me if I bought a MacBook
• 4 state kill switch for all possible combinations for wifi/bluetooth
• hibernate works with 2.6.24 or newer (sleep doesn't, but I will try a few things later)
  
• there's no mechanical latch for the lid, there is a magnet, so there's no plastic to be broken, the laptop is more robust
• the 8 cell battery is thicker than the regular one, allowing better ventilation
• it seems it doesn't get too hot to put on my lap (still, I am a little afraid of blocking its ventilation due to the fabric of my clothes, so I'll probably try to carry around a hard paperboard or something like that)
• the big resolution 1280x800 (for this screen size) seems to partly compensate for the reduced physical size of the screen (12")
• bright screen

So, thanks again to Gonéri, Debian Installer team, LVM2 maintainers, Ubuntu Laptop Testing team, linux uvc developers, Lilo developers and maintainers, all the nice people who made and still make Debian possible.

wpa2-psk with aes on a broadcom wlan0 (2.6.24)

Update: I managed to find out why the wpa_action stuff was needed. Please ignore the lines written like this; they are there just for reference.

One more update: it seems that the firmware needs to be in sync. I ended up using the wireless-2.6 kernel from the everything branch.

---

I just managed to get my wlan from my laptop to work with WPA2-PSK with AES with the free Broadcom driver (now named b43, formerly bcm43xx).

0b:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01)

0b:00.0 0280: 14e4:4311 (rev 01)

In order to do this I needed linux 2.6.24-1 from unstable and the b43 driver.

bounty:/home/eddy# lsmod | grep b43
b43                   119976  0
rfkill                 12816  3 rfkill_input,b43
mac80211              132236  1 b43
led_class              10120  1 b43
input_polldev           9872  1 b43
ssb                    39428  2 b43,b44
pcmcia                 45720  2 b43,ssb
pcmcia_core            46500  2 b43,pcmcia
firmware_class         15232  2 b43,pcmcia

The final trick was to convince wpasupplicat to reload the config with:

bounty:/home/eddy# wpa_action wlan0 reload
wpa_action: reloading wpa_supplicant configuration file via HUP signal

This is the wpasupplicant.conf file that I used:

bounty:/home/eddy# cat /etc/wpa_supplicant/wpasupplicant.conf | grep -v '^\s*#' | sed 's/psk=.*/psk=aaabbb___ENCRIPTED_SEE_wpa_password___cccddd/'
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
network={
ssid="toblerone"
scan_ssid=1
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
group=CCMP
psk=aaabbb___ENCRIPTED_SEE_wpa_password___cccddd
}

and this is the relevant interfaces area:

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-conf /etc/wpa_supplicant/wpasupplicant.conf
wpa-ap-scan 2

This is what it looks like when is working:

bounty:/home/eddy# iwconfig wlan0
wlan0     IEEE 802.11g  ESSID:"toblerone"
Mode:Managed  Frequency:2.412 GHz  Access Point: 00:1B:FC:45:33:70
Bit Rate=48 Mb/s   Tx-Power=27 dBm
Retry min limit:7   RTS thr:off   Fragment thr=2346 B
Encryption key:1337-0000-C121-d73D-0207-RE41-0000-3210 [2]
Link Quality=98/100  Signal level=-36 dBm  Noise level=-68 dBm
Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
Tx excessive retries:0  Invalid misc:0   Missed beacon:0

And here's the result of a scan (relevant section):

  Cell 02 - Address: 00:1B:FC:45:33:70
ESSID:"toblerone"
Mode:Master
Channel:1
Frequency:2.412 GHz (Channel 1)
Quality=93/100  Signal level=-42 dBm  Noise level=-68 dBm
Encryption key:on
IE: IEEE 802.11i/WPA2 Version 1
   Group Cipher : CCMP
   Pairwise Ciphers (1) : CCMP
   Authentication Suites (1) : PSK
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
         24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
         12 Mb/s; 48 Mb/s
Extra:tsf=0000000072ff542d

and here is proof it works:

bounty:/home/eddy# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.77.0    0.0.0.0         255.255.255.0   U     0      0        0 wlan0
0.0.0.0         192.168.77.254  0.0.0.0         UG    0      0        0 wlan0

bounty:/home/eddy# ping debian.org
PING debian.org (192.25.206.10) 56(84) bytes of data.
64 bytes from gluck.debian.org (192.25.206.10): icmp_seq=1 ttl=36 time=201 ms
64 bytes from gluck.debian.org (192.25.206.10): icmp_seq=2 ttl=36 time=199 ms
64 bytes from gluck.debian.org (192.25.206.10): icmp_seq=3 ttl=36 time=200 ms

--- debian.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 199.691/200.519/201.046/0.786 ms

Woooohooo! :-)

Thanks to all people involved in b43 development and all the ones made this possible (Debian developers).

Posted from bed, via wlan.

---

Update: You need the firmware blob, which can be extracted from a Windows driver with bcm43xx-fwcutter (now called b43-fwcutter); I already had it from my previous attempts to configure wlan with bcm43xx. I am not sure if I should use the new tool. You really need the firmware and driver to be in sync.

Update: it seems the b43 driver page (the entire linuxwireless.org site) went down sometime yesterday evening, since yesterday afternoon I was browsing through the site without any issues. (Note: I live in Europe, for reference)

back(b)loging until 2008

I haven't blogged since last year :-D so a "Happy New Year!" is required.

So what happened meanwhile? Quite a few things, both good and bad.

• 15th-16th of December: severe teeth pain, and since it was weekend, I couldn't see a dentist
• 17th of December: I got a dentist appointment and got rid of the pain; more sessions planned
• 18th of December
• around 17 o'clock: I start feeling back pains;
  
• around 19 o'clock: takes me 20 minutes to walk from the office to the subway station, 15 minutes more than it usually takes; I postpone the second dentist appointment because of the back pains;
• later that evening: I end up calling the emergency service because the back pain became unbearable; they arrived about 2 hours later; after some basic treatment I was able to sleep
• 19th of December:
  
• I had the rescheduled dentist appointment scheduled at 9 o'clock; the back pain became so bad that I couldn't sit on the dentist chair; I had to postpone again the appointment
  
• later that day: I had to call in sick, the back pain was back; I spent all day indoors and just tried to rest
  
• 20th of December:
  
• my father and my fiancee came and took me home;
• while on the road the people from emag called me to tell me the laptop is fixed - sadly, about two hours too late
  
• I went to the doctors' and got the papers for the sick leave; until the end of that week I was to feel better, but not great.
• Christmas' Eve and Christmas:
• although planned to be spent at my sister's, we had to stay home since I wasn't feeling well enough for a 50km drive
• nice gifts were exchanged; even the hardest ones to please were pleased
• my sister, my brother in law, my nephew and my niece came to Caracal; it was nice to see Andu (my nephew) literally jump in my arms out of sheer joy (in spite of the back pain, I was glad); Denisa was so cute telling "Tica, Tica"[1] to Santa, especially since, at her stage of verbal development, using verbs seems to be optional :-)
  
• New Year's Eve and 1st of January:
• spent (finally, as planned) in Craiova, with my sister, my brother in law and some of their friends
• was nice to see again my nephew and my niece
• on the 1st: drove back to Caracal on a really bad road due to the heavy snow fall during the morning of that day;
  
• 2nd of January:
• heavy snow falls; a layer of snow of approximately 50cm covers everything
• the area where a neighbour shoveled the snow the previous evening seems to be leveled with the rest

Maybe at a future point in time I'll post a picture or two with my nephews.

To all the people, thanks for the support and, once again, Happy New Year!

[1] a simple poem for kids

Lesson relearned: when Linux networking weirdess occurs...

My relearned lesson for the day: when Linux networking weirdness occurs in a NAT environment, remember to try MTU clamping.

Thanks to the comments by Justin and Sesse, I was fast-tracked to the core of the problems I have been experiencing since Thursday, MTU issues. What's worse (from my pov) is that I have encountered this issue before with the provider I had in Timișoara, but, since that ISP was using PPPoE and my current ISP in Bucharest doesn't, I never really made the connection. I even had a commented out iptables rule for MTU clamping in my firewall script.

The rule I am talking about looks like this:

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $EXT_IF -j TCPMSS --clamp-mss-to-pmtu

or like the one I have been using (seems more logical to me):

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu


Note that this is not a fix, but a workaround and the real problem is over-zealous admins or weird setups[1] which think that banning TCP fragmentation (or the entire ICMP traffic) is a way to secure networks.


Once again, thanks to everybody who read and/or commented about my issue.

[1] Sesse told me that in his case there was a transparent proxy involved when he exeprienced MTU weirdness.

gpg signatures sent

I finally managed to resend the signatures to the few people I decided to send them a while back after debconf7.

I actually resent all the signatures I thought I should sign (if I didn't socialize at all with you during debconf or before you shouldn't receive a signature from me).

So, please:

• sorry, if you get my signatures again; if so, ignore
• don't be mad if you didn't receive a signed key from me, I probably don't consider I know you enough to do that yet ;-)
  

Now I can cross one more item on my long todo list. Yay!

This message has emerged thanks to: caff, dato, python's smtplib and rfc822, vi, gpg, exim, linksys, dell, todo(the application from openhand) and blogger :-)

svn-buildpackage 0.6.22 released to experimental

Thanks to Damyan Ivanov for the upload, svn-buildpackage 0.6.22 is now in experimental. The upload was done to experimental due to the big number of changes affecting it and because I wanted to get a fairly significant amount of testing of the major fixes before propagating the code to unstable.

This release should fix 15 (yes, fifteen) bugs[0], most of which were important bugs or bugs affecting usability.

The major fixes are:

• mkdir -p like functionality in the repo for the tags and other possibly missing directories - this means that even repositories created with older broken versions should be fixed automatically[1]
  
• .svn/deb-layout is no longer a broken cache, but only a real local override for the layout information; .svn/deb-layout is created only on express request via --svn-savecfg; note that although .svn/deb-layout is no longer created automatically, old checkouts should be purged of this cruft (unless the override is wanted)
  
• build dependencies are not required on --svn-export
• automatic creation of the origDir when using origUrl
• some code clean up
  

Installing the package on an etch, lenny or sid system should be straight forward: just get the deb from experimental and install it (no backporting is necessary).


If you usually use svn-buildpackage, please install the experimental version and report any bugs and/or success stories. I am particularly interested in feedback related to the behaviour around .svn/deb-layout and the other methods of specifying layout information.

Please send success stories to me directly eddy.petrisor @ gmail.com. Bugs should be directed to the BTS, but I hope there will be mail just directly to me :-) .


[0] I wonder, does the thickness of the yellow area on these graphs ever decreases?
[1] as soon as the breakage would have been visible in the past

Invariant sections...

Thanks to Holger's post I saw this really educational comic strip.

To those who don't get the joke: the invariant sections could put you in that exact position. Please read the chapter about "Invaraint sections" from the "Draft Debian Position Statement about the GNU Free Documentation License(GFDL)"

more news from the nslu2 front

The main reason for the lack of activity during this week was that I had some problems with my router, a NSLU2 running the debian arm port. This was the machine I wanted the softfloat rrdtool I was talking about in these 2 posts.

It turns out that for some weird reason the USB controller of the slug resets when there is too much traffic going on. I got lots and lots of messages like:


$ grep reset -A 1 /var/log/syslog | grep -E '(reset|repeated)'
Aug 3 07:02:27 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
...
Aug 3 11:50:29 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:51:03 ritter last message repeated 4 times
Aug 3 11:53:15 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:53:46 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:55:48 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:56:07 ritter last message repeated 2 times
Aug 3 11:56:52 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:56:57 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2


That wouldn't have been a problem as long as the damn thing worked, but in some cases after the reset the root filesystem was lost and all the services running on the machine died (except the networking itself since all of that is part of the kernel and is loaded in memory).

It took me about three evenings to get to this conclusion (imagine being locked out of a machine which advertised running ssh, http, and dns services, being able to telnet and getting a respons, but the full protocol failed).

It all became more clear when, while being connected via ssh I got his result:

eddy@ritter ~ $ ls
-bash: ls: command not found

"WHAT?" was the first reaction, then I figured that life without ls is unbearable and came up with this bit:

alias ls='for I in * ; do echo $I ; done'

Quite cool to understand a little bit about the system. Still, cat was unavailable so having /proc and /sys available did not help that much. At some point I was thinking about a busybox shell, tried that, it didn't work since it wanted to remove some important bits like the initramfs tools.


I googled again and found a good starting point for a discussion of the same problem someone else was having. I ended up trying all the proposed solutions: rmmod-ing ehci-hcd, blacklisting the module, regenerating a initrd image with the blacklisted module... None of these worked (individually) and I ended up having an even more unstable system when ehci was not present (I was loosing the root FS after aprox. 1 min after logging in remotely immediately after start). Restoring the image with ehci was a pain (not to mention the time spent trying to figure a way to revert the change safely, since bricking the machine was not out of the question - imagine loosing the FS while flashing the ram drive image).

I finally managed to revert the ehci enabled image and tried the workaround proposed in this gentoo BR. I tried 128 and now I am at 64 and I am still getting those resets; Still something good came out of this, I followed Michael Prokop's Use root=UUID on NSLU2 article and I think I have now a stable root file system just thanks to him.

Now I am stuck:


grep -E '(max_sect|reset)' /var/log/syslog
Aug 3 07:02:27 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 08:27:38 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 08:38:43 ritter manual message: max_sectors was set to 128
Aug 3 08:55:25 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 09:31:47 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 09:54:11 ritter set_max_sectors: max_sectors was set to 128
Aug 3 10:09:32 ritter set_max_sectors: max_sectors was set to 128
Aug 3 10:15:27 ritter set_max_sectors: sda's max_sectors was set to 128
Aug 3 10:24:24 ritter set_max_sectors: sda's max_sectors was set to 128
Aug 3 10:38:12 ritter set_max_sectors: sda's max_sectors was set to 128
Aug 3 10:47:04 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 10:48:27 ritter set_max_sectors: sda's max_sectors was set to 64
Aug 3 11:04:36 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:06:16 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
....
Aug 3 15:05:58 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2

Should I try setting to 32?

In case you're wondering, I am doing the setting with this script:

#!/bin/sh

MAX_SECTORS=64
DISK=$(ls -l `grep 'uuid.* / ' /etc/fstab | awk '{print $1;}'` | sed 's#.*/\(.*\)$#\1#' | tr -d '[0-9]')

[ -z "$DISK" ] && logger -t 'set_max_sectors' "error: could not detect root disk" && exit

echo "$MAX_SECTORS" > /sys/block/$DISK/device/max_sectors
logger -t 'set_max_sectors' "${DISK}'s max_sectors was set to ${MAX_SECTORS}"

exit 0


Dear (not at all) lazy web, what can I do to fix/workaround this issue? Any help would be gratly appreciated (personal mail or comments).

Note: I am reluctant to try the fix proposed in the last comment that claims to fix the issue since compiling an arm kernel natively is a pain and I would like to have an official kernel from Debian Etch, as I do now.

required file `./config.rpath' not found

If you ever encounter this error:

eddy@twix:/tmp/wormux/wormux$ ./autogen.sh
[+] Clean files generated by autoconf, aclocal, automake and configure
[+] Run aclocal
[+] Run autoheader
[+] Run automake
configure.ac:25: required file `./config.rpath' not found

Try this simple fix:

eddy@twix:/tmp/wormux/wormux$ touch config.rpath
eddy@twix:/tmp/wormux/wormux$ ./autogen.sh
[+] Clean files generated by autoconf, aclocal, automake and configure
[+] Run aclocal
[+] Run autoheader
[+] Run automake
[+] Run autoconf

Now run ./configure


Now you can go on with your work. Credits go to Daniel P. Berrange: http://www.mail-archive.com/fedora-xen@redhat.com/msg01017.html


P.S.: Apparently this is an automake 1.10 issue and can be avoided by using automake 1.9

Thanks...

The answer to my previous question is "to be". That happened thanks to a bunch of people, in no particular order:

• Jens Sidel, for committing and suggesting early activation and advices about switching to PO format
• Christian Perrier, for being a really nice guy and for being the person that made me click and start contributing to Debian
• Kobayashi Noritada, for magic po4a related commands
  
• Frans Pop, for actually activating the thing and for advices
• Andrei Popescu, for the multiple patches sent and the late hours sacrificed on the Romanian localization altar
  
• Stan Ioan Eugen, for the work done on the translation done for 1.119, multiple comments and comments done at really late hours last night
• Dan Damian, for being the first person to translate the Release Notes in Romanian, at my suggestion
• Ruşeţ Zeno, for comments and suggestions
• Denis Barbier and Martin Quinson for creating po4a
• Nicolas François (aka nekral) for maintaining po4a
• Javier Fernández-Sanguino Peña, for making calls to translations and sacrificing the Spanish translation while working on the English text to bringing it in shape
  
• anyone that I forgot or don't know about and had a role in making this possible
• silent reviewers on the debian-l10n-romanian list - I wish you started speaking instead of unsubscribing

Updates:

• David Roundy, for creating darcs with its nice darcs send feature which allowed parallel work