sdhci module hangs Everex StepNote 2053T

It's likely that this bug also affects the following laptops:
* Averatec 2460
 * Everex Stepnote SA2050
 * Everex Stepnote SA2050T
 * Everex StepNote SA2052T
 * Everex StepNote SA2053T
 * Philips Freevents x52
 * Philips Freevents x53
 * Philips Freevents x54
 * Philips Freevents x55
 * Philips Freevents x56
 * Twinhead H12Y

(apparently these are all OEM models of the same laptop, as per a comment on Bug #90271)

I can confirm that this definitely affects Philips Freevents x52 and x59 laptops and will happily test any updates on them.

Mrs K

There has been some work on the SDHCI module since Gutsy. Hardy Alpha 4 will be released shortly. Please download and boot the Live CD. Note that built-in MMC readers will likely never work because of their proprietary nature, but the SD and Compact flash readers ought to work fine.

I have already tested this problem on the 2.6.24 kernel.org kernel. Do you think Hardy Alpha 4 is worth testing on -- are there changes beyond what were in the kernel.org source for 2.6.24 (released last week)?

I did try to test this on Hardy Alpha 3, by the way, but it didn't boot past the 8139too MMIO problem (Bug #90271) on this laptop, so I actually have not verified that sdhci will or will not load in Alpha 3. But unless the 8139too problem is fixed in Alpha 4, there is no way I'll be able to test it in Alpha 4 either.

However, I have independently of Ubuntu released kernels, created my own kernel.org kernel with the PIO option for the 8139too module. And through 2.6.24, loading the sdhci module does still hang the system.

Alpha 4 was frozen before 2.6.24 was released, so its not as current.

Hi Jennifer,

I notice you mention you've tested with the upstream 2.6.24 mainline kernel and that this issue still exists. I'd actually encourage you to also open an upstream bug report at bugzilla.kernel.org. I've noticed many times that once a bug is escalated upstream there is a quick resolution through the help and support fo the mainline kernel community. We can also monitor the upstream report from this launchpad report. For help with filing the bug upstream please refer to the "Reporting Bugs Upstream' section of: https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks!

We reported this, and the 8139too problem, to the kernel folks, via the kernel mailing list back when I first got the laptop. There has not been even a reply to that submission. It was months ago, back when 2.6.20 was still current.

We were under the impression that most of the kernel people don't really use their bugzilla, and instead that most of them just use the kernel mailing list archive to "track" bugs, which is why it went to the list and not to bugzilla.

Anyway, if you want to put it in Bugzilla there, be my guest, but I don't think I have much pull with the kernel people. You might have more.

Hi Jennifer,

I forwarded this upstream: http://bugzilla.kernel.org/show_bug.cgi?id=9905 . I tried to add your email to the CC list but I don't think it's registered with the kernel bugzilla so it wouldn't allow me to add you. Care to maybe register with bugzilla.kernel.org and add yourself to the upstream bug report? That way you will receive direct communication from the upstream developers. Thanks.

I confirm that the Phillips freevents X56 is affected as well

why is this bug marked as 'incomplete'? I don't see any information missing from it?

Setting status to Triaged and assiging to the kernel team. However, I believe Jennifer is actively working with upstream via the upstream bug report that was opened to test and get this resolved. Thanks.

I have a Philips X59 (yet another UK-only rebranded Dixons laptop) with the same problem. I ought to mention that the alternate install CD (available from http://releases.ubuntu.com/releases/8.04/ ) uses debian-installer, and it should take the boot option sdhci.blacklist=yes , as suggested by Jennifer on bug #90271 (the option is understood by debian-installer, not by the kernel).

I installed 7.04 using the alternate install CD using a messy approach (see http://ubuntuforums.org/showpost.php?p=1844744&postcount=18 ). Then I compiled a custom kernel and kept it frozen through the 7.10 upgrade. For 8.04 I'm going to do a clean install and simply blacklist the module. I'll post the results, in case it helps anyone.

I've just installed the system using the alternate-install CD as I said before. Although this doesn't _solve_ the problem (no live CD, and no card reader), if you want to _bypass_ it:

- Install from the alternate CD. The sdhci module will not interfere with the process.
- When done, boot again from the CD and use the recovery system to start up a terminal rooted on whichever partition holds your installation (or wherever you've decided to put your /etc). Type echo "blacklist sdhci" >> /etc/modprobe.d/blacklist , then exit and reboot into your new system.

This was a lot more complicated when the 8139 problem overlapped with this one, since debian-installer attempts to set up the network, so one had to prevent it from hanging by awkward means. I'm glad we got rid of that one!

Regarding the lack of a blacklist-module-on-boot capability in Ubuntu, I've noticed this idea on the Ubuntu brainstorm site, http://brainstorm.ubuntu.com/item/86 , which seems not to be too popular at present. I've made my case for it, perhaps some of the people affected by this bug may want to add a comment as well?

Following the debugging attempts on kernel bugzilla, this doesn't seem to be solvable in near future. To summarize the the results so far: The hardware seems to cause lockups even if the only action is to read from hardware registers. Also this doesn't seem to be connected to certain locations but probably to some timing or access pattern.
I will remove the milestone since I do not see a solution in time for the release.

Someone just changed this bug's status to "Fix Released". Could you point me to the fix so I could test it? So far, there hasn't been a solution that has worked on http://bugzilla.kernel.org/show_bug.cgi?id=9905 , and that is the only place it is being worked on that I'm aware of.

There is no fix actually. This is just an automatic process. Someone changed the kernel bugzilla to fix realesed, which gets reflected here.

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

> Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains.

I've installed 2.6.27-2-generic on Hardy. The issue remains; in addition to sdhci.ko, I had to blacklist the new sdhci-pci.ko module as well ("blacklist sdhci_pci") for the kernel to boot up. Other than that, 2.6.27-2 seems to run normally on my machine, although there may be an issue with the iwl3945 wireless driver.

Arne Fritzenreiter has posted a little patch to drivers/pci/quirks.c (see http://bugzilla.kernel.org/show_bug.cgi?id=10231 ) which seems to fix the issue on my laptop.

is it possible to have this patch added to the ubuntu intrepid kernel?

ive got one of the affected laptopts. i can confirm it works...

It looks like there is a bios bug at this notebook that assign a used mmio area to some pci devices.
SD Cardreader, MS Cardreader (not used in 2.6.24), Nic and Firewire (linux seems not use the second mmio area)

If a driver try to access this area's the notebook crash.

I had added a patch that force linux to move the devices outside of this area. (only If subvender/id match to H12Y)

Summarizing the present situation:

- There's a BIOS-induced conflict between PNP and PCI on these laptops.
- Arne's patch fixes this specifically for the laptop's hardware -- the patch should be safe to apply since it will not affect any machines other than these laptops.
- The BIOS inconsistency can be seen in the ACPI table, therefore there's scope for the kernel being able to fix this type of problem all by itself.
- Upstream, Jesse Barnes is trying to come up with a general solution for this type of conflicts. Some progress has been made, but it's not quite there yet.
- In the meantime, he's suggested that we apply Arne's patch to the Ubuntu kernel.
- This patch makes the one associated with LP bug #90271 ("Compile RealTek 8139 using PIO method") obsolete -- it should be removed.

I have a stepnote 2053t im trying to run ubuntu 8.04 also .. it hangs up on

[159.619612] input: PC speaker as /devices/platform/pcspkr/input/input8

when i run verbose mode..i installed using wubu...

did anyone every find a solution to this??? i have been trying to keep up with what you guys are saying but im such a nub... i really want to run ubuntu on the everex.... LMK!!!!

i dont know about installing ubuntu with the wubi installer. but you could try the method i explained in this thread (fresh install on a partition with the alternate installer).

http://ubuntuforums.org/showthread.php?t=704260

good luck

is there a version of linux that runs smoothly on the everex stepnote i mean a full GUI interface etc.... I mean i would love to try this but i just want to get it up and running i mean im learning a lot trying to install ubuntu ... ill give your method for the sake of knowledge but seems like a big hassle i was ready and pumped to learn linux...

if i used your method do i have to lose win xp in the process?

I am also having a problem resizing the ntfs partiton... i appreciate the response to this thread its the best ive seen so far!! there is a girl/boy named dansee on the everex forum who suggessted i try a few things she seems pretty knowledgeable on the subject here is the thread

http://www.everexforum.com/forum/index.php?a=topic&t=8862

thanks im trying to get ubuntu up n running im doing a little bit everday by reading these threads yours may be the most helpful but im still a novice to even playing with linux i just learned about no splash like a few days ago

 cont....
i also made this thread on launchpad
http://ubuntuforums.org/showthread.php?t=950335

If you follow the instructions and get the latest Ubuntu installed, everything works except the SDHCI card reader (currently -- even that may shortly be fixed). So you will have a full X-Windows GUI, all kinds of software, etc.

Here are instructions on how to install, using the "Alternate" install CD that you can download from Ubuntu:
   https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/90271/comments/42

I have my Everex laptop set up with only Ubuntu on it, so I am not sure about setting up a dual boot Windows/Ubuntu system or resizing NTFS partitions. Good luck with that!

if you are comfortable resizing a partition, it is possible to install ubuntu on a everex that has windows already on it. I am currently posting from my Ubuntu partition. Now using Wubi isn't possible unless you were to create your own iso that Wubi used. Using the alternate CD isn't too hard, and it does allow you the option of repartitioning your hard drive during the installation process, but unless you actually know what you are doing, I don't suggest you do this. http://www.fitzenreiter.de/averatec/index-e.htm has a torrent of the live cd that has been patched. So that may work with wubi, or will allow you to have a graphical interface while installing ubuntu.

I'm currently using Intrepid Ibex, and it's running great....to get it running I had to blacklist two modules in the kernel using the following commands: "sdhci.blacklist=yes sdhci_pci.blacklist=yes" but other than that. it's been smooth sailing.

Is there any Ubuntu kernel team member who can confirm whether Arne Fitzenreiter's patch will shipped with Ubuntu Intrepid on the 30th or not? That would make this bug's subscribers very happy...

dont want to fill this bugreport with whinning, but i second what pablomme said..

since we dont know if intrepid ibex will include this patch, ive managed to write a howto to blacklist sdhci and sdhci-pci in a livecd.
it is located here, please let me know what you think.

any suggestions are welcome..

and of course, the link is here: http://ubuntuforums.org/showthread.php?t=957357

Can the fix be targeted for an Intrepid SRU?

i think this fix will never be included in intrepid. i get the feeling developers dont pay much attention to launchpad entries anymore.

ive been tracking some bugs and there has not been a single response in none of them. maybe the launchpad system wasnt that good an idea after all..

PS. im taking the abuse of this post to ask all everex stepnote sa2053t, whats their status on their intrepid ibex update...because im in pain. there are some bugs i cant help but notice...and notice they go unnoticed in lanchpad.

PPS. the excessive use of the word notice has been noticed, and was intentional.

I came to the same conclusion. I have released a patched kernel package and and intrepid desktop cd with patched kernel.

But if you use this please check my page frequently because this kernel doesn't get autoupdates.
This is good because the updates may block the system again but it is bad for security fixes.

http://www.fitzenreiter.de/averatec/index.htm

On my Averatec all hardware works now. (Intel abg wlan) But i have heard that are also some problems with ralink wlan cards.

precisely, the ralink rt73 module which is supported by th NM 0.7 isnt as stable as it should, and wireless signal jumps up and down. overal performance, extremely poor.
the legacy rt73 module works like a charm, but NM must be out of the equation.

have you managed to get a sony memory stick working? it isnt being detected by the kernel here (insert mstick, and dmesg doesnt drop any info on it). sdcards work ok.

can i mail you concerning how to configure the kernel build correctly? i happen to end up with a 600MB kernel install :(

I do have problems with my Intel 3945 wlan card, see bug #285128. It depends on the network you connect to, bear that in mind!

I've also experienced bugs #292194 (fixed in intrepid-proposed) and #276311 (fixed by disabling the magnifier plugin in compiz), and I'll have to see if there exists any report regarding issues with external monitors and the gnome application that handles them.

In my opinion the problem is that Intrepid tries to be on the bleeding edge, and in doing so it has triggered a large number of regressions. Kernel 2.6.27 and Xorg 7.4 are behind most of these. Once these are sorted out Intrepid will be great, I'm sure, but I don't recommend upgrading for another couple of weeks unless you want to help with fixing the bugs. This also explains why this thread is not getting more attention from maintainers.

@eldragon: have you followed the wiki guide for compiling a custom kernel? It's at https://help.ubuntu.com/community/Kernel/Compile

well, i followed this guide: http://www.howtoforge.com/kernel_compilation_ubuntu

only enabled aspm from menuconfig.

@eldragon

That's old... I think you'd be better off following the instructions on the page I linked, which uses the Ubuntu kernel instead of the upstream one. Under bug #287172 I posted the exact command list, if you are interested.

I just wanted to thank Arne Fitzenreiter for the hard work invested here, gonna give it a try to the kernel patch tonight.

Sorry for the slightly off-topic question: has any of you experienced a bug (most likely a regression between 2.6.24 and 2.6.27) by which the laptop's fan works at a constant speed regardless of the temperature? eldragon and I are having that one, and is not exclusive to Ubuntu as far as we know. The problem may happen after several hours of uptime, and it involves /proc/acpi/thermal_zone becoming empty -- the temperature sensor applet, if you have it on, disappears from gnome-panel as a consequence.

If anyone knows of a Launchpad bug tracking this let me know, else I'll open one.

to be more specific on the problem, it happened constantly under ubuntu 8.10, i switched to arch and the problem only happened once. the sensor applet doesnt disappears, it just doesnt show text, if you set it to icon+value, you will see the icon gauge at minimum and no temperature text. this is due to not finding the ACPI sensor in /proc/acpi/thermal_zone.

im subscribed here, but i dont know if its the right bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/226397

arne's patch has been included in arch linux's kernel patchset. ive successfully booted with the stock 2.6.27.7-1 kernel which got updated today.

I've just installed with an alternate disc, blacklisting sdhci and sdhci_pci, then installed arne's patched kernel, removed the blacklisting and the memory card reader works! :D Too bad (good?) there is already a new kernel available from repositories, which tries to overwrite it. Is there anything that can be done to get this patch in Ubuntu's kernel soon?

what could be done, was done already, i dont think it will ever make it to the ubuntu kernel.

what best you could do is learn how to compile the ubuntu kernel so that you can apply the patch when a new release is out.

Looking at Arne's patch it does not look to be a general solution but a machine specific bodge. This would have undesirable effects on other machines which have the same hardware components but not the broken combination as in this machine. That makes it hard to see this patch making the mainstream kernel. What would appear to need to happen to make that possible is to find whatever is using the MMIO space and get that recognised. Not an easy task.

andy, what would be the next reasonable step to have this 'device' id'ed?

The best possibility is to identify the problem from the ACPI table provided by the BIOS, which is wrong (it is what suggests the overlap). I posted my DSDT at the kernel bugzilla, if you want to have a look.

Andy you have right. The patch is no general solution and very hardwarespecific.

But it should not affect other machines with the same hardware because patch check also the subvendor and subdevice id's that only found at Twinhead h12y notebooks. And if there is a twinhead H12Y with fixed bios it only move some mmio resources what should not give a problem because
 there are enough space...

I have added this subvendor check because the first patch moved all Realtec 8139 (I have only seen this with lspci at my test but the card has still worked)

Im not able to find a better solution. I had needed around a year to find the reason why this hardware crashing but im not able to fix this more generic.

I had missread this patch, seeing the device specific ids where there
were vendor ones. So this is probabally not so bad. Have you tried
to push this upstream? That would be the logical next step and makes
any request to include this in Intrepid easier to justify. If you are
sending it up stream please cc: me.

> Have you tried to push this upstream? That would be the logical next step and makes any request to include this in Intrepid easier to justify.

Yep, and the kernel PCI maintainer upstream suggested pushing the patch into the Ubuntu kernel instead, while he works on a more general solution for computers with silly MMIO configurations in the BIOS. No progress there for a month or two, though.

I should add, regarding justifiability, that the Ubuntu kernel is already maintaining a patch for a related bug (bug #90271). That patch forces all 8139too devices into PIO mode instead of MMIO mode, the latter being the default in the upstream kernel. Arne's patch makes that other patch obsolete, and is entirely focused on the machines affected by this bug (and 90271, which was a different consequence of the same problem).

I think this is a positive effect, in that people using the 8139too module will get MMIO --as intended upstream-- and no other side effects should be seen on computers other than the laptops associated with this bug. The patch could be justified solely on these grounds.

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.

After using Arne Fitzenreiter's patch, the SD Card reader works fine, however the MMC reader doesn't. I suppose there's no support for the mmc reader for this laptop on sdhci.

Unfortunately it seems this bug is still an issue.

It looks as if this patch might be a candidate for the ubuntu kernel.
Can you confirm this issue exists with the most recent Jaunty Jackalope 9.04 release - http://www.ubuntu.com/news/ubuntu-9.04-desktop . Please let us know your results. Thanks.

Yes, this is still an issue on Jaunty.

As commented in the kernel bugzilla, the patch allows use of the SD card reader, but problems remain if a PCMCIA card is used. It is not clear to me whether the PCMCIA problem is there without the patch or not. At worst, the patch turns a "can't boot" problem into a "can't insert extra hardware" problem, which in my point of view is an improvement, but it's clearly far from optimal.

I would personally welcome the patched kernel going into the repositories. Other people may disagree.

To clarify the patch made no problems on the h12y, But if you install the patched kernel on a machine with pcmcia slot and insert a 8139 based lan card your get a kernel opps that point to the quirk code. I don't understand why because the code should do nothing if it doesn't detect a h12y subvendor id.

I doesn't use the patch anymore. I have added reserve=0xFFB00000,0x100000 to my kernel commandline and can use the normal kernel.

Detailed howto install is on my website.
http://www.fitzenreiter.de/averatec/index-e.htm

I think the best way is a patch that reserve this memory if a H12Y system was detected but i have no idea how this can realized.

@Arne: I can't get that to work. The screen captures on your website are from a virtual machine (qemu?), so they need not be correct because hardware is not accessed directly. And indeed, you write "0xFFB00000,0x100000" in one place and "0xFFB00000-0x100000" in another. Could you paste the exact kernel line that you use on the actual menu.lst on the laptop? I'm very interested in this option...

pablomme wrote:
> @Arne: I can't get that to work. The screen captures on your website are
> from a virtual machine (qemu?), so they need not be correct because
> hardware is not accessed directly.
You have right. The pictures are made with qemu, and off coure it
ignores the line but i have installed it with this way on my laptop.

> And indeed, you write
> "0xFFB00000,0x100000" in one place and "0xFFB00000-0x100000" in another.
>
Damn. the correct parameter is reserve=0xFFB00000,0x100000
I will fix the pictures. I hope i have the virtual machine not deleted
yet. ;)
> Could you paste the exact kernel line that you use on the actual
> menu.lst on the laptop? I'm very interested in this option...
>
>

--
Arne Fitzenreiter
----------------------------------------------
mailto:<email address hidden>
http://www.fitzenreiter.de
ICQ: 285-193-731
----------------------------------------------
Tel: +49 3631 689517 (Fr-So)
 sip:<email address hidden>
 +49 179/8603400 (Mo-Do 17-22 Uhr)
----------------------------------------------

Ok, I couldn't get the "reserve=0xffb00000,0x100000" option to work on my Jaunty installation, but after a bit of testing it appears that the problem is that I'm running the x86_64 version - the option works fine on the i386 liveCD. Does anyone know why it doesn't work and/or how it could be made to?

I made the move to 64-bit precisely with Jaunty, and I'm going to stick to it with or without card reader, but wouldn't it be wonderful if everything worked at once with a little kernel parameter?

if im not mistaken (which i might), addressing under 64bit is of 40bit instead of 32bit, maybe you need to add another 00 to the address. try eith reserve=0x00ffb00000,0x00100000 instead...

i might be really wrong though ;)

Nope, that won't work either... I would be surprised if one had to pad memory addresses with zeros for them to work, but I've seen stranger things :-)

The addresses in the DSDT are the same as before (of course), so it's either that the 64-bit kernel shifts the mmio regions elsewhere (somehow, for some reason), or that its support for the 'reserve=' command-line parameter is broken... Anyone knows? If anyone gets the unmodified 64-bit liveCD running, drop me a line!

The "reserve=" boot parameter is indeed broken in 64-bit kernels: see bug #370003. Thanks Arne for the tips!

Given that this workaround works well (save unrelated 64-bit kernel issues), would any Ubuntu kernel maintainer know how patch the kernel to request a reserved memory range on detection of the HY12 hardware?

In case anyone is wondering, with GRUB2 (karmic) default kernel boot parameters go in /etc/default/grub, specifically in 'GRUB_CMDLINE_LINUX_DEFAULT'. Editing this file should be followed by a 'sudo update-grub'.

Still an issue for me :(

In comment #59 Arn Fitzenreiter proposed a workaround using the reserve command line parameter. Does this workaround work for everyone affected by this bug or do we need to revisit applying the patch to the kernel sources.

People affected by this bug are probably wondering why the kernel team doesn't just apply the patch and fix it. The reason is that the kernel team is reluctant (not opposed) to apply any patch to a stable kernel that is not from upstream. Applying patches that don't come from upstream add greatly to the support of the kernel as other upstream patches may touch the same area as the non-upstream patch and may prevent them from applying cleanly.

yes, the reserve command still works.

the kernel team is probably reluctant to apply the patch because:

a) its an ugly hack

b) a workaround exists

also, i seem to be the only one left using these notebooks,

finally. the sdhci device in this notebook is a Piece of crap which also breaks suspend / hibernate

so the prefered solution still is to blacklist the module entirely (makes the reserve line redundant).

if you wish a solution for ubuntu, just detect the hardware and blacklist the module on the fly

I am still using mine! (Philips Freevents X56)

I am using Ubuntu 10.04LTS with the Arnes "reserve" command.

I tried the latest version of Ubuntu with the "reserve" command and
although it worked I had no sound so reverted back to 10.04LTS.

@eldragon

Thanks for the additional information.

I'm using my Philips Freevents X55, too. The "reserve" flag fixes all the issues I had (though, SDHC card reader does not work but the driver does not cause any problems). Suspend to ram (S3) sometimes randomly hangs the system but that happened with the officially supported Windows install, too, so it could be a hardware issue. With ubuntu the S3 sleep seems to be more stable than it ever was with Windows.

Black listing the sdhci driver is not the correct fix because if one e.g. plugs in a suitable USB device that wants to load its driver (or perhaps that was DMA transfer window?) to reserved memory area, the system will hang because the reserved memory area is touched. I think Arne has more information about this if some kernel developer needs extra info.

The status of this issue for the kernel (if I've understood correctly) is that the kernel parses reserved memory areas from BIOS supplied data different from Windows and this hardware requires using the same method as Windows or the reserved areas are not computed correctly. In a sense, this is very similar to ACPI status where the current style is to try to emulate the Windows implementation, not to follow the official ACPI specification.

Mikko, blacklisting the sdhci module will make suspend/hibernate lockups go away. i find it more important than being able to read sd cards (which does not work anyways)

maybe uninstalling the device in windows will help too. i dont have it installed to test.

The patch is not only ugly it crash when a Realtek 8139 PCMCIA Cards is inserted. (in other notebooks)

This notebook hase many problems with linux. The newest is a strange backligt problem since i have updated to Ubuntu 11.10.
The sd device is also only a sd and no sdhc card reader so it cannot read the most cards...

This appears to have been fixed upstream.