SR71 Blackbird kernel

[Banger]

Originally Posted by ses2017

Further, I would refute the 'Weak Pre' designation. Far too many variables to lay blame on the device. (Patch conflicts, conflicting programs/software, so on)

I tried twice, once on a fully patched and what not, the next on a freshly doctored/cleaned device. Both times failed.

[dballew]

Don't know if this is a result of the SR71 or not. Currently testing -81 release. Have had same rebooting issues as most others have experienced. Two things I have noticed, besides the rebooting...
-SR71 -81, if max speed set to less that 1205, say 1005, seems to be pretty stable, of course at a slightly less speed.
-81 a bit more stable that -80 BUT Still a lot of reboots with -81
-Every reboot resets number of launcher pages back to three...using add/delete cards, had 6 pages, now three. Takes all the other pages and puts them into one of the 3 pages. Nothing lost.
-temp does not seem to be an issue, stays in the 30's.

This kernel does seem to be a good bit quicker on loading apps, etc. Noticable for me. Was running F105-74 prior to this. No major issues with that one for me.

[ses2017]

With all due respect, from a manufacturing perspective, wouldn't it be more likely to assume a software variable than a hardware variable? Software being revised constantly, versus hardware in runs of tens of thousands or more?

While I am not steeped in the actual development, logic is logic, and a hardware run is a hardware run.

I refer to those who have a Sprint '1st gen' pre, who are running the patches/kernels that everyone kept telling them "the cpu is not up to the same spec at the pre+", etc. Now its a hardware run/weak Pre issue? I can't buy it.

Sorry. All respect intended.

[kill_Dano]

Originally Posted by ses2017

With all due respect, from a manufacturing perspective, wouldn't it be more likely to assume a software variable than a hardware variable? Software being revised constantly, versus hardware in runs of tens of thousands or more?

While I am not steeped in the actual development, logic is logic, and a hardware run is a hardware run.

I refer to those who have a Sprint '1st gen' pre, who are running the patches/kernels that everyone kept telling them "the cpu is not up to the same spec at the pre+", etc. Now its a hardware run/weak Pre issue? I can't buy it.

Sorry. All respect intended.

CPUs have variable tolerances. That's one reason why we are able to overclock them so much. The manufacturers leave head room to overcompensate for the fact that there are so many variable tolenrences. Some pre's may be able to pull off 1.2ghz. Most seem like they can't. All Pre can def handle 500mhz. Some Pres could not do 1ghz. CPUs are variable. If you don't understand that than I dare call you an overclocking noob. Any who has spent any time overclocking desktop PCs would understand this better.

[unixpsycho]

Originally Posted by ses2017

With all due respect, from a manufacturing perspective, wouldn't it be more likely to assume a software variable than a hardware variable? Software being revised constantly, versus hardware in runs of tens of thousands or more?

While I am not steeped in the actual development, logic is logic, and a hardware run is a hardware run.

I refer to those who have a Sprint '1st gen' pre, who are running the patches/kernels that everyone kept telling them "the cpu is not up to the same spec at the pre+", etc. Now its a hardware run/weak Pre issue? I can't buy it.

Sorry. All respect intended.

And I respectfully disagree.

This is like overclocking a PC to a degree. While one person with the same CPU can overclock just fine but you have a different motherboard rev and it doesnt work well.

This same scenario played out with the Droid/Milestone... almost exactly. Some complained it crashed, some said it works fine. Then the authors of the patch hooked into SetCPU to control voltages on the fly, for some it STILL didnt work.

If you see how a chip is made you will know each piece of that wafer isnt going to be exactly like the die right next to it. They are tested for certain tolerances to pass.

Running at 1.2gig on this SoC is pushing the boundaries as the CPU in spec can tolerate 1.5v up to 1.8 before you are just melting your phone literally. we are at 1.635v right now.

[wellwellwell11]

Originally Posted by kill_Dano

CPUs have variable tolerances. That's one reason why we are able to overclock them so much. The manufacturers leave head room to overcompensate for the fact that there are so many variable tolenrences. Some pre's may be able to pull off 1.2ghz. Most seem like they can't. All Pre can def handle 500mhz. Some Pres could not do 1ghz. CPUs are variable. If you don't understand that than I dare call you an overclocking noob. Any who has spent any time overclocking desktop PCs would understand this better.

correct, and thats what the developers have been telling people. I myself have been running the 1.2ghz kernal and just recently been having issues, though a tweak here and there may fix the issue, my CPU ultimatly may not be able to handle it, hence I may have a weak pre. As well as the Pre and Pre plus have the same instruments in each, the only difference is double ram, and storage on the plus, so those with the plus version will have similar results.

[ses2017]

So what you have said without saying it is that in any run of a device, the device immediately next to it on the line can be inferior/superior to it. Since they all have to meet a specific build criteria, I don't see how that is possible.

And further, only someone who doesn't see it the same way as another user would resort to casting aspersions at another poster, ie, "overclocking noob". If you can't state your position or case any better than resorting to name-calling, perhaps you are the "societal noob". So convince me, or agree to disagree.

Oh, and grow up. This is not Junior High, but a forum for MINDS to come together and share ideas. So get one, then share.

[kill_Dano]

Hey unixpsycho, I want to go back to F105 with out doctoring. I can put the phone into bootie mode. I donwloaded the image file you linked to. I don't know what to do now please advise.

[kill_Dano]

Originally Posted by ses2017

So what you have said without saying it is that in any run of a device, the device immediately next to it on the line can be inferior/superior to it. Since they all have to meet a specific build criteria, I don't see how that is possible.

at one point tech becomes very biological-like. Ever go to the super market and look at fruit? Do you see people squeezing the fruit and checking which one is the one they like the most? Why would they do that? They all came from the same delivery day and possibly even the same tree. Some are alittle riper. Some a little bigger and more green. They are all prob around the same tolerance of ripe and green. there are no rotten ones or ones that have not matured yet.

There are all in the same vicinity of being a good tomato. Some are great and some not as much. Same thing with CPUs

Now if you want to get into the minutia of the CPU manufacturing process and what exact materials are the most influential to the tolerances and why this happens from a manufacturing process then let me assure you it is not a simple answer and this is prob not the best place to find info on that. The internet is a big place bud. Go poke around it.

[unixpsycho]

Originally Posted by kill_Dano

Hey unixpsycho, I want to go back to F105 with out doctoring. I can put the phone into bootie mode. I donwloaded the image file you linked to. I don't know what to do now please advise.

Novacom on Windows - WebOS Internals

But for the last command run "novacom boot mem:// < uImage"

Replace "uImage" with the location and name of where you downloaded it to.

[wellwellwell11]

Originally Posted by kill_Dano

Hey unixpsycho, I want to go back to F105 with out doctoring. I can put the phone into bootie mode. I donwloaded the image file you linked to. I don't know what to do now please advise.

i just removed the file through preware, rebooted then applied the old f105. If your having issues with the rebooting loop, I got through it by first pulling the battery out plugging in the charger (so your phone clocks at 500mhz instead of 125mhz) put the battery back in let it reboot then once rebooted go right to govanh and set the min and max to 500/800 the first option, from there you should be fine to operate your phone and remove the kernal. This way worked for me without doctoring or pulling the image manually.

[rposa]

Wow, this thing is super fast. Just like .. well .. an SR-71 Blackbird.

Question: With screenstate -- if I use the power button to turn off the LCD, is that ok now, or do I need to let the screen naturally "expire"?

on .81, Set to 250/1200 -- must have a stronger one

[unixpsycho]

Originally Posted by rposa

Wow, this thing is super fast. Just like .. well .. an SR-71 Blackbird.

Question: With screenstate -- if I use the power button to turn off the LCD, is that ok now, or do I need to let the screen naturally "expire"?

on .81, Set to 250/1200 -- must have a stronger one

250 was removed in .80 due to soooo many girlie-Pre's with no pecs.

So setting 250 really means 500.

I dont know you would ever let it "expire"? its ok to turn off the screen. Unless you refer to the original screenstate in its infancy?

[wellwellwell11]

hey unixpsycho as i posted earlier (before your last update) i was running the kernal fine for 7 hours until it went into the reboot loop. I then did what I explained above about pluggin in the phone, once booted with the SR71 kernal installed i went to Govanh and set the freqency at 500/800 which of course ran fine. My question is do you think people with any issue should up the min to 500mhz, due to the freezen issues we had back when the first uber kernal was released, and was set that low causes pres to freeze, and reboot. Though I think this is the only problem I see, since when running the pre for the 7 hours the 1.2ghz, if not compatiable would have rebooted initally on me like it has so many others.

[psm9]

Originally Posted by ses2017

Viewed the recovery page. No info I can make out unless you have a degree in C++. However, PSM9's suggestion seems to be working.

HOW DO YOU KNOW THESE THINGS???

I've been here since 3 months before launch day

[pip smith]

Wow well finally bit the bullet after I got through my other testing.
I think from my inintial testing that I have a Chuck Norris Pre, he is working beautiful I can't believe how responsive it is. Govnah loads fine. Have yet to test a 3d game. I also want to test installing a patch to check the luna goes fine.

[Banger]

unixpsycho should i give it a try with the new one since my pre has giant boobs? Failed during the last 2 versions.

[unixpsycho]

Originally Posted by wellwellwell11

hey unixpsycho as i posted earlier (before your last update) i was running the kernal fine for 7 hours until it went into the reboot loop. I then did what I explained above about pluggin in the phone, once booted with the SR71 kernal installed i went to Govanh and set the freqency at 500/800 which of course ran fine. My question is do you think people with any issue should up the min to 500mhz, due to the freezen issues we had back when the first uber kernal was released, and was set that low causes pres to freeze, and reboot. Though I think this is the only problem I see, since when running the pre for the 7 hours the 1.2ghz, if not compatiable would have rebooted initally on me like it has so many others.

Since -80 the min is always 500.

Now i see the problem being the "weak" Pre's cant run 1.2gig reliably.

[kill_Dano]

novacom boot mem:/ < C:\Users\dANo\uImage-2.6.24-palm-joplin-3430

gives me "bad error response from ther side: 'err -1 bad command string'

[unixpsycho]

Originally Posted by Banger

unixpsycho should i give it a try with the new one since my pre has giant boobs? Failed during the last 2 versions.

*I* wouldnt. If your Pre has giant b00bs (Giggity) then the new version might not help. Unless you want to grab the kernel image from the package and try a mem boot so you dont have to doctor after failure.