I think the whole hardware / software related discussion is obsolete. The boundary isn't that clear cut. With new technologies software can't be set up to listen to a exactly defined subset of hardware. The relation is probably more "coherentistic" and not "foundationalistic". Its a many to many relation that needs to be coherent. Classical deductive logic can't be used anymore for these complex systems. So if the fix is hardware related or software related isn't important. Important is that the whole system functions coherently.
Do you have an issue with Galaxy Nexus volume changing automatically? (Updated 01.12)
- Thread starter kristovaher
- Start date
- Status
I think the whole hardware / software related discussion is obsolete. The boundary isn't that clear cut. With new technologies software can't be set up to listen to a exactly defined subset of hardware. The relation is probably more "coherentistic" and not "foundationalistic". Its a many to many relation that needs to be coherent. Classical deductive logic can't be used anymore for these complex systems. So if the fix is hardware related or software related isn't important. Important is that the whole system functions coherently.
Okay, let me step in again and say that the people who are saying "bull**** on software fix" either don't know what they're talking about or aren't thinking hard enough. From what I understand, this problem is entirely fixable at either the kernel level or the firmware level. I posted that I would attempt a fix today when I get my Galaxy Nexus, but it looks like Google already has it handled.
To me, this seems like hardware issue that can be compensated for completely in software.
I don't have my Galaxy Nexus yet, but from what I gather from logs posted earlier as well as this video: http://www.youtube.com/watch?v=Rp-N352hwZY, the issue is that 900MHz interference makes the volume down button oscillate between on and off so quickly that it overflows the buffer for the keypad device. This is the key here. Such a thing would NEVER happen in normal usage - there's no way a human could possibly press the button quickly enough.
From the video, we can see that when the bug happens, the volume pretty much immediately jumps from maximum to minimum. We all know that if you hold the volume down button in Android, it doesn't decrease nearly that quickly (it lowers one level immediately and then gradually lowers the volume for as long as the button is held). So a 900MHz signal does not hold down the button. It just presses it (and releases it) really, really quickly.
The 900MHz signal never seems to hold the button for longer than tiny fractions of a second. A human wanting to change the volume would always hold the button down for at least many times that rate. So now we know the difference between the 900MHz signal and a human pressing the button - the 900MHz signal never holds the button for any significant period of time.
So how do we fix it? See source file: https://www.codeaurora.org/gitweb/q...fc70774;hb=aosp-new/android-omap-tuna-3.0-mr0
Pressing the button or releasing the button causes a hardware interrupt which calls omap4_keypad_interrupt(). An example fix (there's probably a better/more low level way to do this - this would just be a quick fix): All we'd have to do is add the following logic to omap4_keypad_interrupt():
- If we get an interrupt for volume down pressed, do not register it yet.
- In 100 milliseconds, volume down is still pressed, register the key press. If not, ignore it.
- If we got another interrupt for volume down in the meantime (volume down pressed or volume down released), ignore it even if it's pressed.
This would, more likely than not, fix the issue, or mitigate it so much that the interference becomes negligible.
Yes, it's a workaround, but workarounds like this happen all the time. Hardware is limited by the laws of physics, but that doesn't mean software can't compensate for it. The procedure is very similar to "debouncing." See: http://en.wikipedia.org/wiki/Debounce#Contact_bounce. This wouldn't fix the issue in the bootloader - you would need to have the above logic implemented in the keypad driver there, or just fix it in firmware.
DO NOT return your phones yet. There is no reason not to believe Google. I'll still look into writing a proof of concept fix, but as it stands, I live in the US where I can't easily get a 900MHz GSM signal (and I don't have easy access to baby monitors/portable radios or 900MHz cordless telephones).
To me, this seems like hardware issue that can be compensated for completely in software.
I don't have my Galaxy Nexus yet, but from what I gather from logs posted earlier as well as this video: http://www.youtube.com/watch?v=Rp-N352hwZY, the issue is that 900MHz interference makes the volume down button oscillate between on and off so quickly that it overflows the buffer for the keypad device. This is the key here. Such a thing would NEVER happen in normal usage - there's no way a human could possibly press the button quickly enough.
From the video, we can see that when the bug happens, the volume pretty much immediately jumps from maximum to minimum. We all know that if you hold the volume down button in Android, it doesn't decrease nearly that quickly (it lowers one level immediately and then gradually lowers the volume for as long as the button is held). So a 900MHz signal does not hold down the button. It just presses it (and releases it) really, really quickly.
The 900MHz signal never seems to hold the button for longer than tiny fractions of a second. A human wanting to change the volume would always hold the button down for at least many times that rate. So now we know the difference between the 900MHz signal and a human pressing the button - the 900MHz signal never holds the button for any significant period of time.
So how do we fix it? See source file: https://www.codeaurora.org/gitweb/q...fc70774;hb=aosp-new/android-omap-tuna-3.0-mr0
Pressing the button or releasing the button causes a hardware interrupt which calls omap4_keypad_interrupt(). An example fix (there's probably a better/more low level way to do this - this would just be a quick fix): All we'd have to do is add the following logic to omap4_keypad_interrupt():
- If we get an interrupt for volume down pressed, do not register it yet.
- In 100 milliseconds, volume down is still pressed, register the key press. If not, ignore it.
- If we got another interrupt for volume down in the meantime (volume down pressed or volume down released), ignore it even if it's pressed.
This would, more likely than not, fix the issue, or mitigate it so much that the interference becomes negligible.
Yes, it's a workaround, but workarounds like this happen all the time. Hardware is limited by the laws of physics, but that doesn't mean software can't compensate for it. The procedure is very similar to "debouncing." See: http://en.wikipedia.org/wiki/Debounce#Contact_bounce. This wouldn't fix the issue in the bootloader - you would need to have the above logic implemented in the keypad driver there, or just fix it in firmware.
DO NOT return your phones yet. There is no reason not to believe Google. I'll still look into writing a proof of concept fix, but as it stands, I live in the US where I can't easily get a 900MHz GSM signal (and I don't have easy access to baby monitors/portable radios or 900MHz cordless telephones).
Last edited:
Unfortunately, there aren't really any good software fixes for this.
You can try and filter the button presses - you could then end up with situations where you hit the button quickly and it thinks it is just interference, or where the interference just happens to closely imitate a real button press and the volume goes down. Either way, the constant interrupts may prevent the phone from correctly sleeping and could cause poor battery life.
The alternative is to completely disable the input pins, resulting in dead volume buttons. No battery life issues, but you would need to use a widget or app to change the volume.
A hardware fix could be as simple as changing (or installing) a resistor or capacitor. Unfortunately, any hardware changes could take quite some time (and be a massive inconvenience).
So who would prefer possibly-temperamental volume buttons over non-functional volume buttons?
I ordered from Handtec...
I am afraid though to allow them to ship my phone since my provider in Belgium (Proximus) uses 900Mhz for 2G and also has 900Mhz (+1800Mhz) on 3G ...
I'm afraid I would be properly f*cked because of the 900mhz usage on 3G networks as well here
And I'm also a little skeptical about a software fix for this issue...
Unless it could be fixed firmware/radio wise...
I'm no Samsung Engineer, can't conclude how they (or Google) messed up and are going to solve it
Seeing Samsung & Google are 2 big companies (A company's primary goal is to make profit), they will just "patch" up things and hope everybody will remain silent about this "feature" afterwards.
I am afraid though to allow them to ship my phone since my provider in Belgium (Proximus) uses 900Mhz for 2G and also has 900Mhz (+1800Mhz) on 3G ...
I'm afraid I would be properly f*cked because of the 900mhz usage on 3G networks as well here
And I'm also a little skeptical about a software fix for this issue...
Unless it could be fixed firmware/radio wise...
I'm no Samsung Engineer, can't conclude how they (or Google) messed up and are going to solve it
Seeing Samsung & Google are 2 big companies (A company's primary goal is to make profit), they will just "patch" up things and hope everybody will remain silent about this "feature" afterwards.
Correct me if I am wrong, but once this fix has been applied, we will still be able to look at the logs to see if the "ghost" button presses are being registered by the device, but just being ignored unless the rocker is held down for +/- 100ms as a coolbho3000 said?
This sounds a lot like software debouncing.
The problem is that the button is not bouncing - a "bouncing" button eventually enters a steady state (usually within 20ms). The interference in this case is continuous - it can happen continuously for several seconds. 100ms is not long enough - it is entirely possible that the button will randomly happen to be "down" at this instant.
If you fix it on the lowest level possible in the kernel and do it efficiently, nothing should log to logcat, and there should be just the tiniest minimal performance impact. If you fix it on the firmware level, it would be completely transparent to the user.
I mention that. It's very similar to software debouncing.
But... We listen for the volume down released interrupt, too. The on/off oscillations seem to be happening at a much greater frequency than 10Hz.
If we get a volume down pressed interrupt and 100 milliseconds later the volume down button is still held, then register it BUT if we get a volume down released interrupt in the meantime, then we know it's from interference. Yes, it could be held at both instants and happen to randomly be down 100ms later - but if there was no volume down released interrupt between our two measurements, then we are sure the button was held down between them.
Last edited:
Yes, that's exactly what I was thinking over. Samsung engineers might have just accidentally misconfigured the port parameters, e.g. forgotten the pullups.
Every time we get a volume down pressed interrupt, we repeat this process. So if the user presses the volume down switch in the meantime, we ignore the original volume down pressed signal, and start calculating from the last volume down pressed signal (actuated by the user).
But, you say, wouldn't we continue to get interrupts from interference as the 900MHz signal continues while the user is holding the button? I don't think so.
When the volume down button is held by the user, the switch is constantly at an "on" position and interference cannot change that (rapidly inducting an "on" signal in a switch when it's already on results in the switch continuing to be on), so we get no further interrupts in the kernel other than the original pressed and released interrupts. If this interval is >= 100ms, then we register the keypress because we assume it's from the user (the signal doesn't seem to be capable of holding down the switch for that long). Otherwise, we do not.
Last edited:
There is no relationship between "It's a hardware flaw" and "It can be fixed with software". A software/firmware fixable issue does not imply the issue is not due to a hardware flaw, so I am sorry to say that the title of Android Police is misleading.
OK I know there is no definite answer from Google/Samsung about whether this is a hardware/software issue. But let's ASSUME that the volume bug is really caused by hardware, i.e. due to insufficient shielding. Can Google issue a fix? Definitely. As some member had said, Google can fix it by detecting and ignoring the unreasonably frequent "button pressing" triggers because an ordinary man can't press a button so many times in a second.
But is it a "fix" to the issue? It depends on how you look at it. For a normal user , it is definitely "fixed" if it no longer bothers the user by some mysterious volume change alerts. But in a design perspective you can say no because the cause (insufficient shielding) is still there and they are just hiding the problem. Key presses are still registered and passed to the CPU. The implication is that it lowers the performance (CPU cycles wasted to process those wrongly triggered key presses) and affects battery life (CPU cycle = battery).
Yes we still don't know (or Google/Samsung still didn't acknowledge) the cause. But I personally would say it a "software issue" if the fix from Google stops the sensor from generating any incorrect button pressing trigger. If Google just hides the problem, I would say it is still a hardware issue, but workaround by some software trick.
Personally I still hope that it is a pure software issue because I want to get the phone as early as possible. But is "hardware issue hidden via software workaround" unacceptable? Well it again depends on your view. Just think CPU. AFAIK every new generation of Intel CPU has a list of design flaw (or errata) that can impact performance and may need software workaround. Some of those errata are fixed at the hardware side with new stepping. Can you say that Intel should not retail those early stepping CPUs? I think not. Of course the Galaxy Nexus case is a bit different, but still I personally accept software workaround, provided that the impact on battery/performance is now drastic.
OK I know there is no definite answer from Google/Samsung about whether this is a hardware/software issue. But let's ASSUME that the volume bug is really caused by hardware, i.e. due to insufficient shielding. Can Google issue a fix? Definitely. As some member had said, Google can fix it by detecting and ignoring the unreasonably frequent "button pressing" triggers because an ordinary man can't press a button so many times in a second.
But is it a "fix" to the issue? It depends on how you look at it. For a normal user , it is definitely "fixed" if it no longer bothers the user by some mysterious volume change alerts. But in a design perspective you can say no because the cause (insufficient shielding) is still there and they are just hiding the problem. Key presses are still registered and passed to the CPU. The implication is that it lowers the performance (CPU cycles wasted to process those wrongly triggered key presses) and affects battery life (CPU cycle = battery).
Yes we still don't know (or Google/Samsung still didn't acknowledge) the cause. But I personally would say it a "software issue" if the fix from Google stops the sensor from generating any incorrect button pressing trigger. If Google just hides the problem, I would say it is still a hardware issue, but workaround by some software trick.
Personally I still hope that it is a pure software issue because I want to get the phone as early as possible. But is "hardware issue hidden via software workaround" unacceptable? Well it again depends on your view. Just think CPU. AFAIK every new generation of Intel CPU has a list of design flaw (or errata) that can impact performance and may need software workaround. Some of those errata are fixed at the hardware side with new stepping. Can you say that Intel should not retail those early stepping CPUs? I think not. Of course the Galaxy Nexus case is a bit different, but still I personally accept software workaround, provided that the impact on battery/performance is now drastic.
Last edited:
Unfortunately the testing may be modular.
Chipset manufacturers probably test the radio in isolation. If radio proves to be producing the correct emissions and functioning properly (on every band), then it passes.
Once the radio is installed in a device, it is (generally) no longer necessary to test it on every band.
If you very carefully time every event, it might be possible. It would be nice if someone could produce a log of all the interrupt events during an "episode" in order to assess the feasibility of this. This may require a custom driver to be loaded which replaces the default interrupt handler.
That would be wonderful if that turned out to be the issue. With a rooted device it may be fairly easy to adjust the pin configuration and see what happens.
Are you sure the drivers are not in binary format? Is there anybody with rooted Nexus to try this? Just curious if this theory works out.
I tend to think its just a silly lost pullup problem, since the engineering version didn't have this bug, and the latter was the one which has taken each and every test from crash to RF-proof and found OK. But the mass-production device is checked against defects in declared functionality only.
I do believe that the pre-released and mass production devices differ only in terms of SW, but not HW. So, the mass version could have a newer version driver with the misconfigured port. My 5 cents...
Last edited:
Yes, that would be easy. I would try it and even try to write a fix, but unfortunately, I don't have anything in my house that could possibly generate a 900MHz signal.
I think my "pseudo-debouncing" solution wouldn't even require careful timing. (Google's engineers are smarter than I am and have probably come up with an even better solution)
There is no way Samsung are going to recall devices to ship out fixed units, no time and expense, they will just either rely on the "software fix" or make changes to the current manufacturing process silently and a proper solution will filter out.
This phone is going to cost me 800+ over its contract term, i expect it to be at least usable for voice calls.
This phone is going to cost me 800+ over its contract term, i expect it to be at least usable for voice calls.
I agree on that.
But I'm talking about the opposite version. Interference is present, it keeps the interrupt for itself for 50ms, which means if the user presses the button in that 50ms, it won't recognize the press.
As we can see from the logs and the videos, the button gets the interrupts really frequently, so it can happen.
(Not trolling, just want to clearly understand your idea.)
But I'm talking about the opposite version. Interference is present, it keeps the interrupt for itself for 50ms, which means if the user presses the button in that 50ms, it won't recognize the press.
As we can see from the logs and the videos, the button gets the interrupts really frequently, so it can happen.
(Not trolling, just want to clearly understand your idea.)
Guys,
I'm looking forward to my GN,i hope they release it soon in Germany.
But this volume issue it seems will have a fix,this i great.It's no use to argue before the fix if it's sw or hw...we'll see after the fix is released if it still affects the phone in bootloader mode then your phone is just patched,not fixed.
If the phone isn't affected in bootloader then from my point of view it's 100% fixed and will probably not affect me or bother me.It will be like nothing ever happened(that's because right now i dont even have it).
I'm looking forward to my GN,i hope they release it soon in Germany.
But this volume issue it seems will have a fix,this i great.It's no use to argue before the fix if it's sw or hw...we'll see after the fix is released if it still affects the phone in bootloader mode then your phone is just patched,not fixed.
If the phone isn't affected in bootloader then from my point of view it's 100% fixed and will probably not affect me or bother me.It will be like nothing ever happened(that's because right now i dont even have it).
It does make one wonder - how many hardware problems in consumer electronics are "hidden" by last-minute patches?
For all those people who are saying that you can force the phone into 3G only mode - I have some news for you -
It doesn't stick.
Try it yourself.
1. Go to the phone application
2. Hit *#*#4636#*#*
3. Select Phone Information
4. Scroll down until you find Set preferred network type
5. Change it to WDCDMA only (or indeed anything other than GSM/CDMA Auto PRL)
6. Now reboot your phone
It doesn't stay persistent.
As to all the blog sites and tech news sites that are running with the notion that this isn't a hardware related issue, that is extremely disingenuous - All that Google have said is the following:
Google have said nothing to contradict reports and claims that this is a hardware defect, yet the tech sites/blogs are still putting 1 and 1 together and getting 15
It doesn't stick.
Try it yourself.
1. Go to the phone application
2. Hit *#*#4636#*#*
3. Select Phone Information
4. Scroll down until you find Set preferred network type
5. Change it to WDCDMA only (or indeed anything other than GSM/CDMA Auto PRL)
6. Now reboot your phone
It doesn't stay persistent.
As to all the blog sites and tech news sites that are running with the notion that this isn't a hardware related issue, that is extremely disingenuous - All that Google have said is the following:
Google have said nothing to contradict reports and claims that this is a hardware defect, yet the tech sites/blogs are still putting 1 and 1 together and getting 15
T
Thyrus
Guest
@oscillik
notwithstanding the overall issue, the CDMA only actually sticks on my GN even after 10 reboots.
Just make sure you "exit" the Phone information display prior to rebooting, that "forces" it.
notwithstanding the overall issue, the CDMA only actually sticks on my GN even after 10 reboots.
Just make sure you "exit" the Phone information display prior to rebooting, that "forces" it.
- Status
Similar threads
- Locked
Top Liked Posts
-
There are no posts matching your filters.
-
18NEW IN THIS THREAD?
PLEASE READ THE FOLLOWING BEFORE REPLYING
PLEASE NOTE THAT THE PROBLEM HAS BEEN FIXED WITH AN OVER-THE-AIR UPDATE BY GOOGLE. IF YOU SUFFER FROM THIS PROBLEM THEN YOU SHOULD WAIT FOR THE UPDATE TO ARRIVE ON YOUR DEVICE.
Full details:
What the problem is
- The device has an issue of volume acting strangely. Most often the volume mutes very quickly. Sometimes the volume starts 'jumping' between muted and loud very quickly.
- This volume issue happens often during phone calls, using internet or receiving SMS text messages.
- Some users are also reporting that when calling, they can hear 'radio interference' sounds.
- The device is often unresponsive while the problem happens. Power button not working for the brief time has been reported.
How it happens
- The problem happens while the device uses GSM 900 network, that is when the device is in 2G.
- Your phone is on 2G when it uses E (Edge) and G (GPRS) connections, both data and mobile. If data is used, a small letter near signal indicator points out what you are connected to.
- The problem happens while another device that is on GSM 900 is nearby and is transmitting in 2G network. This happens even if Nexus itself is not using any networks at the time (such as when radios are off and the device is in Airplane mode).
- The problem is more evident when user is in low-signal area and more 2G information is transmitted.
- The problem also happens in bootloader and is not the fault of Android 4.0 itself.
- Please remember that the problem does not happen for all 2G networks, some 2G networks (especially outside Europe) do not use GSM 900.
How many users are affected
- Every Samsung Galaxy Nexus handset seems to be affected by this problem. Majority of users however are not encountering the problem due to not using GSM 900 2G networks.
- 2G networks working on GSM 900 are majority of Europe, Africa, Australia, Middle East and large part of Asia.
- In UK, the GSM 900 is used by O2, Vodafone, giffgaff, Tesco Mobile.
What Samsung and Google are saying
- No official statements from Samsung other than asking people to send details of the problems on their customer support e-mail (uk.technical@samsung.com).
- Samsung did post a quote on their Samsung UK Facebook wall that says 'We are aware of the volume issue and have developed a fix. We will update devices as soon as possible.' This quote is said to be originating from Google according to Samsung, Clove, androidpolice.com and The Verge.
- Google employee has confirmed in an Android developer chatroom that Google is developing or has developed a software fix for the problem.
- Another Google employee, Dan Morrill, shared a post by Lee Johnson on his wall and said that he is very accurate in his estimation about how software can fix this hardware flaw.
- Google has replied to a customer support thread that there is a fix and it will be rolled out in the coming week. It is possible that the 'coming week' refers to week starting 5th of December.
What sellers are saying
- Handtec and Clove conducted additional testing on the devices and both found the volume bug to exist on their devices.
- Handtec stopped the shipments after the problem became widely known. Samsung Distribution also stopped shipments for sellers few days later, delaying shipments of the device for a week.
- Clove stated that according to what they heard from Google, that a software fix is being worked upon. Clove stated that according to their sources the problem is in software and not hardware. Clove has not gotten this information from Google or Samsung directly however and refers to their inside research about information found online and their own sources.
- While it was originally believed that the shipment delays are because of Samsung flashing the devices with updated software that will fix the bug, the new devices shipped on 29.11 also carry the bug according to Clove. It seems Samsung held the shipments to give Google additional testing time with the fix and held back possible refunds and replacement handsets would have gotten had the shipments not been held back.
Is it hardware or software problem?
- All the tests conducted by many users so far indicate that the problem is in hardware and that the device receives signals from 2G that it should not receive due to not being protected from radio interference. This is also shown while the device runs in bootloader.
- Many engineers here and in other forums and social networks say that a cheap hardware shielding would fix the problem easily, however Samsung and Google intend to fix the problem with possibly as valid means through software.
- If the software fix manages to patch the problem, then it really does not matter if the problem was in software or hardware, as long as the device works properly and there are no after-effects, since some users fear that the software fix of a hardware might cause additional battery drain or unresponsiveness problems. But this is merely an opinion, we will know more once the patch is out.
- The flaw is confirmed to be a hardware flaw by engineers, as well as a Google employee (referred to above). But both state that it is common for this type of hardware flaw to be patched with software and it is likely that many devices you already own have such patches in place without you knowing it.
What you can do
- Wait for the update to arrive on your Galaxy Nexus. Google is slowly rolling out a fix to all handsets right now. Make sure you have internet or data connection for the update and have your phone in a charger just in case while updating.
8
Let's get the qualification bit out of the way: I am pursuing a PhD in Electrical Engineering. While you're right that this problem has its roots in hardware, and one possible fix would be a change to RF shielding, I encourage you to explain why a fix in firmware is so terribly inferior.
First of all, the problem has been exhibited in the bootloader, so the patch cannot be applied in the kernel as you have suggested, since the kernel isn't even in play in bootloader mode. If you're claiming that the fix will *only* fix the bug within Android, and the bootloader will remain borked, that's a very bold and easily verifiable claim now that the fix has been released.
Secondly, claims abound that there's something wrong with a software fix, as if this sort of thing isn't common. As pointed out by Google engineer Dan Morrill (google 'Dan Morrill Nexus Volume), and, as I can confirm from my undergraduate degree, whenever you have a button, you need to debounce ( wikipedia 'debounce' ) the signal from the switch or else you will get spurious multiple presses whenever the button is pressed. So the idea of using logic circuitry/software to inhibit event generation soon after a button press is the absolutely dead-standard solution used by everyone, from hobbyists to global giants. Adapting that to testing if a button press is consistent and long, and not spurious noise is an absolutely trivial modification.
OK, so this means that the problem can probably be completely solved in software. That is, perfectly solved, you will never ever see a spurious button press due to radio interference. The only concern that remains is whether or not the CPU is 'overwhelmed with interrupts'; spending all of its time handling spurious interrupts only to find that the interrupts should be ignored to implement debouncing. Again, there is a far better solution: *disable* the volume button interrupt for a certain amount of time. That is, disable the volume button interrupt, and set a hardware timer going to fire x milliseconds later. When the hardware timer fires, re-enable the volume button interrupt, and see what's up. During the x ms, the processor is left in complete peace to do whatever processing is necessary.
When implemented on a slow (strictly compared to a Cortex A8) Atmel AVR microcontroller, this sort of strategy can transform a situation where the microcontroller is completely stalled, running at 100% CPU, just continually handling spurious button press interrupts, to < 1% CPU utilisation with no apparent overhead whatsoever.
Now, a hypothetical question: When *any* smartphone company, with the tight profit margins endemic to such a competitive marketplace, is presented with the option to a) implement proper RF shielding, which costs 2 cents per phone or b) do it in software for zero cents in such a way that it has an absolutely immeasurably negligble bearing on software performance or battery life, what would they choose? The only difference here is that Samsung made a bit of a mistake in not testing it in all markets, and are now putting out the software that they would have always put out if they were on a more relaxed timeline.
I cannot stress this enough: it is almost completely irrelevant how nasty the signal on the volume button line is, and how badly it makes the *current* software lag out. Software has control over the nature of the interrupts that it REQUESTS (the R in IRQ), so a complete, perfect fix for the lagging comes inherently with the fix of the spurious presses. And it's a fix shared not just by all smartphones in the market (admittedly, perhaps, only to implement debouncing), but just about any modern device that has a button on it.
Now I've already made my point at this stage, but I'm going to keep on going just to cover all the bases.
A smartphone is a bloody complicated thing; it's much closer to a PC than an Arduino board with an Atmel AVR on it. Imagine this problem happened on your PC: a 2G phone nearby caused your keyboard to type random characters. Everyone seems to be reacting under an apparent assumption here that this 'bandaid fix' is like a terrible hack in Windows that just uses some complicated heuristic to guess which key presses are fake and discard them. So what would you prefer? The keyboard is broken, so you would want to fix that instead, right? How would you do that? By updating the software on the keyboard. So why didn't Samsung do that... oh, wait. They probably did.
While the firmware inside a keyboard is probably not updateable over USB, there's in a micro hiding in there. Even in a tightly integrated device like a smartphone, the volume button probably isn't directly wired to a pin on the CPU. Just like the keyboard in a PC goes via the southbridge, then the northbridge, and then finally to the CPU. (Yes, I know the northbridge and southbridge have been merged in recent PCs, this is beside point.) Even though space is at a premium in a smartphone, I seriously doubt they would send each volume button and power button (and touch screen inputs) into their own pins on the smartphone CPU. It'll go into some other intermediary chip that handles all of the above, handles debouncing etc, and multiplexes all the data onto some kind of standard bus from the CPU that handles everything else like speakers, microphone, SD card, etc.
If this isn't the case, and the volume buttons are indeed directly wired to the CPU, i've already covered that case above. But otherwise, read on.
That random intermediary chip is probably vaguely related to a microcontroller itself, and guess what, that microcontroller runs software ('firmware'). Update that software, and the problem is completely and utterly fixed, at no cost to performance or anyone's pockets. An utterly perfect solution, that no-one has any valid reason to complain about.8
you should see an android with a spinning hexagon ball ("Buckminsterfullerene" anyone??) and a progress bar at the bottom of the screen
this stage took me about 2 minutes then the phone will restart and you will see "android is upgrading" and another progress bar optimising all your apps.
---------- Post added at 12:09 AM ---------- Previous post was at 12:01 AM ----------
Post-OTA CPU Usage Test (and Bootloader test)
http://www.youtube.com/watch?v=h3T4my6Eyf8
So from this not-so-scientific test this patch (ITL41F) does seem to address the volume bug without significant impact on CPU or system responsiveness.
Like someone mentioned earlier this patch was applied to the Android OS but not the lower level (such as firmware) so the volume bug can still be triggered in boot loader mode.
I've also tried pressing the volume button on GN while another phone was emitting 900MHz GSM signal, and there was no problem controlling the volume of my Galaxy Nexus. (GN responded to human input without erratic behaviour)7A CPU doesn't really process any hardware on its own. Things like key or button presses generate what are known as "interrupts". When the CPU is interrupted, it halts instruction execution and looks for an "interrupt handler" which is a piece of code (software) normally installed by the OS at boot. After the interrupt handler has executed, the CPU returns to executing where it left off before the interrupt. If there is no handler, or interrupts are disabled, nothing happens.
In the case of a PS/2 keyboard, the PS/2 controller on the motherboard talks to the keyboard using the PS/2 protocol which is completely separate from any of this. The controller on the motherboard generates an interrupt when a key is pressed. The CPU halts and executes the interrupt handler, which reads the key from the keyboard buffer (by executing a memory read software instruction, reading from the buffer's location in the address space) and passes it to the OS to handle later.
Buttons on a phone would generate an interrupt. Even the bootloader (which is a piece of software) would have to install an interrupt handler in order to know about them. This is all done through CPU instructions... ie. software.
However, oscillik is not wrong, as what he is really talking about is the interrupts at the hardware level, which is most definitely direct to the CPU. In summary: the 900 MHz interference is probably causing spurious interrupts to be generated. This is very common when RF shielding is inadequate.
