[karmic] long boot time on eee 900

Could be duff hardware... I now get this:-

GRUB loading.
Welcome to GRUB!

Entering rescue mode...
error: biosdisk read error
grub rescue> help
Unknown command 'help'
Try 'help' for usage
grub rescue>

and...

[ 5.204305] ata2.01: configured for UDMA/66
[ 5.204316] ata2: EH complete
[ 5.205803] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 5.205809] ata2.00: BMDMA stat 0x65
[ 5.205823] ata2.00: cmd c8/00:20:3f:00:00/00:00:00:00:00/e0 tag 0 dma 16384 in
[ 5.205826] res 51/44:20:3f:00:00/00:00:00:00:00/e0 Emask 0x9 (media error)
[ 5.205833] ata2.00: status: { DRDY ERR }
[ 5.205838] ata2.00: error: { UNC ABRT }

Hi popey,

Does seem like this might be a hw related issue. Although, it might be good to also give the latest mainline kernel build a test, currently 2.6.30-rc8 - https://wiki.ubuntu.com/KernelMainlineBuilds . Let us know if your results are the same or different. Thanks.

Seems laptop has gone pop (well, internal SSD has) so you can mark this one as invalid if you wish.

This may be a coincidence but my eee900 with Karmic has had the same problem.... lots of HSM violations in the error logs...

Karmic upgrade killed my laptop too. At first, I thought the HSM violations were related to something botched with the disk encryption that was set up in Jaunty. (I create sda1 for /, and sdb1 as an encrypted partition. I created a logical volume group on top of that and the had swap, /var, and /home created in the volume group) but this seems to be the root issue:

The problem got progressively worse with each reboot, so I'm assuming that there's a whole lot of disk corruption by now (DISCLAIMER: The below "output" was manually typed/copied, I didn't have a way to cut and copy to a file)...

ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata2.01: ST-ATA: DRQ=0 without device error, dev_stat 0x0
ata2.01: cmd 20/00:08:c7:49:7a/00:00:00:00:00/f0 tag 0 pio 4096 in
         res 00/00:00:00:00:00:/00:00:00:00:00:/00 Emask 0x202 (HSM violation)

those messages repeated on the screen for a while and eventually I got:

end_request: I/O error, dev sdb, sector 8014279

Fortunately, everything pre-upgrade was synced to my desktop, but I'm going to try a fresh install of Karmic and see what happens.

in case it wasn't clear, this was seen on my eee 900.

here's dmesg as running on the karmic desktop install:

Hi,

Just a sort message to say that I have exactly the same issue on my own EeePC 900,
I tried re-install from scratch several time, and each time I get the same error message described by Alan
I tested the desktop release and UNR release but both does not work. (both final release, not alpha or beta)

Chris

Same deal on my Eee 900/Karmic, using the 'generic-pae'-kernel (since that was what the installer picked).

I removed the 16 gig flash card, since I only had problems on that, in order to be able to boot the eee (root on the 4G, /home on the 16) and use it until I got around to maybe try and recover the removable drive.

When I did that, I started getting same problems on the 4G drive, and now the Eee is for all practical purposes useless (bar a reinstall), getting the same Grub-error as someone mentioned above.

As such, I blame the ata driver in the kernel for these problems.

This is the second straight release in which the (orn rather a) ata-driver is causing data loss (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/346691). I don't know if we're to blame the Linux kernel or Ubuntu, but this is NOT worthy of supposedly release quality software, and as such really ought to be "Critical" rather than "Medium", since it destroys data.

Adam

My EEE is bricked right now because of this problem. Dead. I got Jaunty re-installed but everything f*cked up again when I updated to Karmic. Now Jaunty can't work with either SSD because of I/O errors. This is an extremely CRITICAL problem. Any Linux novice would be pretty convinced their hardware was broken.

I'm about to boot in with a Gparted live USB and see if I can't get Jaunty working again.

How did a bug this big make it past even Alpha?

Reporting back: I think it's really bricked. I can't re-install 9.04. Nothing but the live USB itself shows up in fdisk -l with either a Crunchbang or Gparted live USB. I've even flashed the BIOS with the latest update, took out the battery, hit the little reset button on the bottom. This really doesn't look like a software problem anymore. I don't think I'm exaggerating when I say KARMIC KILLED MY LAPTOP.

Hi,

Sorry to hear about that Trey, for information I re-installed 9.04 on my own eee, (full re-install from USB-key, re-creating partition table for both disks with the installer) and it works fine again.

Chris

I got exactly the same problems as reported here with a Eee 900. Starting with long boot times (due to ata errors), and after some use time I got a completely dead installation after using hibernate (grub unable to load).

I hope the computer is not bricked, as I didn't have time to try a new reinstall, but I agree this bug shall become critical and all eee 900 owners warned to avoid Ubuntu 9.10 installations until this is clarified.

This is not a case of solid state disk drives suddenly giving up the ghost. Grub leaves them in a really messed up state. Any attempts to partition or format afterwords gives a hardware error.

Using a low level format utility can fix these drives, but of course you lose everything and you need to start from scratch wit hte drive

Hi,

To confirm that I have been fighting this problem on my eeepc 900 as well, though it only started to become an issue after ~1 week since i upgraded to karmic version of xbuntu from janty version of xbuntu.

Its looking like a pretty serious problem from the above comments, so it would appear the only safe action I can take is to move to another distro, which I really don't want to do but I also do not want to screw up my eeepc either.

Some ideas/comments from devs as to the status would be helpful here.

Regards,
Jon

Hmm. I thought when I originally filed the bug that it was a software error, but then dismissed it as a hardware problem. The comments on this bug report are leading me to think it might be fixable?

Can someone please comment if they have _revived_ a "broken" system. My eee 900 has been sat in a drawer since I filed this bug because /dev/sda was unusable. Can the fault be undone?

On this forum post you can find some similar reports of this bug and fault undone using low level format:

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

good luck

Alan, and others see my thread on the Eeepc forums to see how I fixed mine.

http://forum.eeeuser.com/viewtopic.php?id=78939

qwertinsky, that windows based tool is no different than zeroing the disk using "dd" on Ubuntu. Zeroing the disk doesn't "fix" or change anything other than wipe the contents out. There seems to be some misunderstanding about what a "low level" format is, and does.

The issue seems to be a kernel one introduced between the version shipped with Jaunty and that shipped with Karmic. You said yourself you wiped the disk and went back to 9.04, and thus you wont see the same problem because the problem on manifests itself on Karmic (9.10).

@Alan Pope

From your original comment:

[ 5.205809] ata2.00: BMDMA stat 0x65
[ 5.205823] ata2.00: cmd c8/00:20:3f:00:00/00:00:00:00:00/e0 tag 0 dma 16384 in
[ 5.205826] res 51/44:20:3f:00:00/00:00:00:00:00/e0 Emask 0x9 (media error)
[ 5.205833] ata2.00: status: { DRDY ERR }
[ 5.205838] ata2.00: error: { UNC ABRT }

I am fairly sure that this is a hardware failure. Not a duplicate of https://bugs.launchpad.net/bugs/445852 which is a HSM violation.

That said, your original dmesg file shows that you also have the real https://bugs.launchpad.net/bugs/445852 occurring on boot-up!!

@Andrew

That's the error I got ~5 months ago.. now..

[ 138.845938] ata2: lost interrupt (Status 0x58)
[ 138.848006] ata2: drained 32768 bytes to clear DRQ.
[ 138.919289] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 138.919297] ata2.00: BMDMA stat 0x64
[ 138.919314] ata2.00: cmd c8/00:00:00:00:00/00:00:00:00:00/e0 tag 0 dma 131072 in
[ 138.919318] res 58/00:00:00:00:00/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
[ 138.919325] ata2.00: status: { DRDY DRQ }
[ 138.919360] ata2: soft resetting link

I have a Eee 900 and had my ssd replaced on warranty was running on XP hdd was completley dead, upgraded today to UNR Karmic and now sda is unusable inout/output error at 15% on install, i thought it was a hardware issue and installed on sdb its working but long boot times and random errors

I confirmed the situation, I installed UNR 9.10 into my younger cousin's wife's Eeepc900 yesterday,and the same trouble happened, I have install UNR 9.10 into many different Eeepc.(1000 700..etc) Just the Eeepc900 meet the trouble. @_@

Alan Pope ㋛, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder, but the one at the top) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc4

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]