Inconsistent booting

[manekineko]

Has anyone else seen this behavior? Anyone able to explain what causes it?

When I boot up it seems like there are 3 different possibilities:
1. Works fine, everyone is pleased
2. Boots up, but is extremely slow. Slowness is usually (but not always) permanent until next reboot. Will sit right after boot on partially rendered lock screen and be extremely unresponsive. Initial connection to network takes forever. Generally when you finally do manage to unlock, widgets take forever to load, and there is usually a message up about how the system isn't responding. Clicking the App button to bring up the app list will take 2 seconds or more to respond sometimes. Interestingly, running Neocore yields a benchmark half of what I usually get, at 9.5fps.
3. Boot dies almost immediately after launching haret, on the line "allocated dma buffer at ffc0b000, dma_addr 25260000". Words stop scrolling, though the cursor is still flashing, and a reset is necessary.

It strikes me as really weird that the boot can result in different outcomes. I would have thought it's pretty much deterministic, being a computer and all.

I haven't always had the 3rd outcome in there, but the first two have been with me pretty much since I started using XDAndroid I think, and I've restarted from a clean data.img with a reformatted SD card many times.

Edit: Also, just to clarify, I'm running with no overclock.

[demonlordoftheround]

Wirelessly posted (Mozilla/5.0 (Linux; U; Android 2.2; en-us; MSM Build/MASTER) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1)

Well, I am not having the issues you describe. Have you been making alot of kernal updates?

[manekineko]

Originally Posted by demonlordoftheround

Wirelessly posted (Mozilla/5.0 (Linux; U; Android 2.2; en-us; MSM Build/MASTER) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1)

Well, I am not having the issues you describe. Have you been making alot of kernal updates?

I do generally keep up to date, but I haven't noticed any correlation there.

[bluedeer]

I have had these problems as well as others (spontaneous rebooting, especially if left idle for a period of time), though I haven't been able to narrow this down. I've even disabled the hardware 3d and reduced the overclocking by 100mhz and still no joy. I really want this project to be reliable and viable, but I wouldn't consider this 'stable' yet. Maybe there's hope with the nand flash, I suspect it has something to do with the way Haret accesses the sdcard and certain things in memory during boot time. Maybe Haret itself needs an update?

[natemcnutty]

Wirelessly posted (Opera/9.80 (Windows Mobile; Opera Mini/5.1.21594/22.414; U; en) Presto/2.5.25 Version/10.54)

Originally Posted by manekineko

Has anyone else seen this behavior? Anyone able to explain what causes it?

When I boot up it seems like there are 3 different possibilities:
1. Works fine, everyone is pleased
2. Boots up, but is extremely slow. Slowness is usually (but not always) permanent until next reboot. Will sit right after boot on partially rendered lock screen and be extremely unresponsive. Initial connection to network takes forever. Generally when you finally do manage to unlock, widgets take forever to load, and there is usually a message up about how the system isn't responding. Clicking the App button to bring up the app list will take 2 seconds or more to respond sometimes.
3. Boot dies almost immediately after launching haret, on the line "allocated dma buffer at ffc0b000, dma_addr 25260000". Words stop scrolling, though the cursor is still flashing, and a reset is necessary.

It strikes me as really weird that the boot can result in different outcomes. I would have thought it's pretty much deterministic, being a computer and all.

I haven't always had the 3rd outcome in there, but the first two have been with me pretty much since I started using XDAndroid I think, and I've restarted from a clean data.img with a reformatted SD card many times.

There are too many factors at play to expect the same results on similar devices. Also, even with buffered ECC memory, computers don't always perform the exact same.

A couple of things to note as far as performance goes, I highly recommend staying away from class 10 and class 6 cards for this project. Class 4 is where I would go for, and here's why.

Flash memory has to be optimized for specific functions. The higher class cards are rated for high throughput but generally suck at random read/write. The really low class cards are generally bottom of the bin chips, and the class 4 cards seem to be the most well balanced.

Second random performance factor is the unique setup that everyone is using. I use a recent version of haret that I compiled a couple of months ago while the one in reefer's packages is over a year old. Also, you never know what apps others have installed, and we just aren't comparing clean apples to clean apples if ya know what I mean

[arrrghhh]

+1 to what nate said, and I think I can speak to #3 specifically. This is most likely due to your SD card in general, have you tried a different card? Sometimes I wonder if this project is just slowly basting our cards until they eventually die a glazed and delicious death.

Sorry, I'm hungry.

Also in respect to #2 - seems to be related to this nasty system_server process absolutely hogging every processor cycle it can absorb. Devs are looking into the cause, but the reason seems relatively unknown at the moment.

[manekineko]

Originally Posted by arrrghhh

+1 to what nate said, and I think I can speak to #3 specifically. This is most likely due to your SD card in general, have you tried a different card? Sometimes I wonder if this project is just slowly basting our cards until they eventually die a glazed and delicious death.

Sorry, I'm hungry.

Also in respect to #2 - seems to be related to this nasty system_server process absolutely hogging every processor cycle it can absorb. Devs are looking into the cause, but the reason seems relatively unknown at the moment.

That's really interesting, thanks. It's funny, with respect to #2, I had just discovered the same last night.

I wonder if it is something data.img related with that one. I was rebooting a lot testing out the new kernels, and after a while, the number of times it would boot into #2 was almost 100%. I've since moved back to a known good data.img I had backed up and it booted up okay. I'm not completely sure though, could be a coincidence.

I do wonder if the project is damaging our SD cards. Every time I reboot, even using the shutdown command, one of those FOUND001.fck files is generated, and that's not a good sign. Sure we can delete them, but if nothing is messed up, those shouldn't being generated.

[steveholtam]

I get #1 and #2 quite a bit. After a rebuild, my phone is normally good for about a week before I start getting the above errors. Then it seems harder to get a good boot, like OP mentioned.

This is not a huge problem as there has been so much development lately that I am rebuilding my phone mostly before I see the above problems at this point.

It is something I'll research later if things slow down. Maybe I can figure out which file(s) are causing the hangs.

[InvincibleLiving]

I'm back to experiencing hanging boots when I try to load haret. The progress bar freezes just before the 2 vibrations and boot init screen.... only solution when it hangs is to soft reset.

Had this same issue about a month ago then it resolved itself just as randomly as it came.

[ndno]

One thing I noticed is that if I have been using WinMo for a while, I just "hard reset" (not restart), then power up and then launch haret.exe. Seems to always work (Android comes up and works smoothly) for me.