ATA locks up on the EeePC

[axeld]

When trying to boot using the new ATA stack (but from USB), the system locks up. I've investigated the issue a bit, but didn't get far before my only USB stick (128 MB!) died (obviously doesn't like being completely rewritten that often).

Anyway, when I added some debug output in on-screen-debug-output-mode, I noticed the system could sometimes boot. In fact, adding a spin(10000) at various locations in ATAChannel::Reset() (within the for loop) solved the issue. I'll buy a new stick on Monday, and see if I can find out more.

In the mean time, maybe someone knowing the specs has an idea :-)

In any case, the system seems to work fine when booting with IDE DMA off, but maybe that was just luck.

[axeld]

I bought a new stick, and I cannot reproduce my earlier results anymore with this one; the system always locks up now, no matter if I put snooze() in there, or turn off IDE DMA. Therefore bumping the bug's relevance.

[V!NCENT]

I have the same problem on the Eee PC 900.

It booted without anything disabled in the BIOS prior to the 13th of August hrev32334 version. The last know working version was the 12th of August hrev32290 version.

The system hang at startup, and therefore was not installed, at the fourth icon. The last two onscreen debug output lines from the 13th of October version hrev33585-x86gcc2hybrid before the complete system hang were: ata 0: _DevicePresent: device selection failed for device 0 ata 0: _DevicePresent: device 1. presence 0

No errors were displayed prior to the last two lines.

After that line is displayed the read/write activity LED on the USB stick stopped flashing indicating that nothing happens afterwards.

It doesn't matter if some/all onboard devices are de disabled in the BIOS. It doesn't matter what boot paramiters are checked at the Haiku safeboot screen by pressing the spacebar prior to startup.

The BIOS option OS Installation [start] was used.

The latest (as of 14 October 2009) Win32 Disk Imager tool was used under Windows to write RAW images to a brandless 1GB USB stick.

[V!NCENT]

PS: The latest non-working version that was tested was: the 13th of October hrev33575-x86gcc2hybrid version.

[axeld]

(In #4564) Duplicate of #3933.

[ahwayakchih]

It (hrev35511 and hrev35274) seems to work fine on EeePC 901, booted from USB flash drive. Also works when booting from hard drive connected through USB :). I did not try to boot it without USB tough.

[ambroff]

@ahwayakchih: I'm not surprised that it works on your 901, that machine has a different chipset (ICH7-M vs the ICH6-M in the 900).

I was experiencing this problem too. I set out to build HEAD of svn to track down the problem and found that it booted reliably with hrev36961, which was a pleasant surprise. I did a binary search and found that hrev36951 somehow miraculously fixes the problem. I don't understand why yet, I plan to investigate after work tonight.

[ptaylor1982]

I tried Rev:36969 on my eeepc 900 ssd, booting from usb, and it sticks on the same place, on the disk icon. i get the following error at the end of syslog.

ata 0:_devicepresent: device detection failed for device 0

[ambroff]

@ptaylor1982 did you try one of the revisions I referenced? I haven't had the chance to look deeper into this or try a more recent revision, but builds prior to hrev36951 fail for me with that same error:

ata 0:_devicepresent: device detection failed for device 0

Maybe it has something to do with my build configuration. I've been running a debug gcc4 build.

[ptaylor1982]

@ambross i have tried the most recent nightly i have(hrev36974). and get the same error, i will post either my syslog, if i can find a spare fat32 formatted usbflash, or pictures if i dont have an appropriate flash. as that will hopefully give more detail.

[Coldfirex]

Able to retest under a recent build and capture a syslog if it still fails?

[ptaylor1982]

Replying to Coldfirex:

Able to retest under a recent build and capture a syslog if it still fails?

I am not able to at the moment, i dont have a spare usb fat32 to put syslog onto if it does fail.

[ptaylor1982]

I tried 41078 on my eeepc 900,booting from sdhc, and progress. I managed to get haiku to boot. However you have to disable ide dma. but it boots now with that safemode option.

So whatever was previously blocking boot, whatever safemode options, has been worked out.

[axeld]

It certainly still doesn't work here with alpha 3, no matter what IDE options I choose.

[phoudoin]

Seems that somebody succeed to boot on his eeePC 900, after having upgade his BIOS:

​http://www.haiku-os.org/community/forum/asus_eeepc_900_haiku_dont_start

Could it be simply that previous BIOS was broken regarding IDE setup?

[Soft]

I had the same problem with my eeePC 900. Updating the BIOS to version 1006 fixed the problem and now Haiku boots fine. My old BIOS version was 802. As a side note eeePCs internal BIOS update tool (EZ　Flash) somehow failed to read the ROM file no matter what I did. Solution was to use FreeDos and Afudos BIOS update tool V2.36 (older versions failed to work) from Asus.

[mmlr]

I've identified the 0906 BIOS update as the one resolving this. ASUS says in their log: "Updated the literal string of SATA SSD displayed in BIOS setup.", which I couldn't verify, i.e. the strings looked the same to me at first glance, though both disks are actually listed as ATA so this may not even apply. It definitely changed something in the ATA init sequence which makes it not lock up anymore. I've downgraded to 0802 again and I'm now investigating a bit more. In either case, the up- and downgrades worked for me when using the ​Ubuntu instructions (placing the file renamed to 900.ROM on a 16MB FAT16 formated partition).

[ptaylor1982]

i can confirm, the above v-1006 bios upgrade for eeepc 900, allows r1a3 to boot properly.

[nielx]

Can this ticket be closed? It seems to be a bios problem.