Monday, July 27, 2015

Intel Rapid Storage Technology may be incompatible with SSDs

After installing a PNY CS1111 SSD, I started getting occasional hangs in Windows 7. Sometimes shutdown or standby would take way too long, and sometimes a hang would happen during normal use. Often, the hard drive LED would stay on all the time, but the computer would work normally, with no signs of actual constant disk activity. Also, trimcheck 0.7 reported that TRIM isn't working.

I just upgraded Intel Rapid Storage Technology from to The hard drive LED is behaving properly now, and trimcheck shows that TRIM works. I haven't gotten any hangs, though it hasn't been long enough to be sure.

There are newer versions of  Intel Rapid Storage Technology available, but I don't know of any newer versions which work with the ICH9R on this GA-P35-DS3R motherboard.

Sunday, June 28, 2015

Getting rid of the Tools pane in Acrobat Reader DC

Acrobat Reader is the best PDF viewer. It has the best performance on documents with huge amounts of stuff on a page, such as maps. It also has the fastest searching on documents with huge amounts of text.

Adobe stuffs it with all sorts of crap I do not want in an attempt to sell their online services, but the program starts up reasonably fast despite being bloated. There's just one important annoyance that the preferences can't fix: the Tools pane. It wastes the right side of the screen for a bunch of functions which I never use. It can be hidden, but there's no option to hide it permanently, so it has to be hidden again every time I open a document.

The Tools pane can be disabled by moving or deleting the Viewer.aapp plugin which creates it. For me, it is located at C:\Program Files\Adobe\Acrobat Reader DC\Reader\AcroApp\ENU\Viewer.aapp. In 64-bit windows it would be in C:\Program Files (x86)\, and the ENU part could be different if you have a different language installed. I created a new folder within ENU and put the file there, so I can move it back if I ever actually need it or if updates break because it's not there. It may be necessary to repeat this procedure after every Reader update.

Wednesday, June 10, 2015

AA cell diameter differs

I got some AA to D adapters so I can use AA rechargeables with the RCA RC3000A digital boombox.

The cell I tried was a new Duracell DX1500 pre-charged rechargeable NiMH, rated 2400 mAh. It was a very tight fit, and hard to remove. These adapters lock in the cell when you push it in all the way. You can start removal by pushing on the positive contact, which is like a button. After that, all you can do is pull on the negative side, which sticks out a bit. It's hard to apply a lot of pulling force by hand to a cell that sticks out very little. When I finally got the cell out, I saw the adapter had damaged it.

My first thought is that the inexpensive no-name adapters sucked. Then I tried three other kinds of cells. They all fit nicely. There was a bit of friction with some, but it wasn't a problem. Also, there was no damage. Even the older 2000 mAh Duracell DX1500 (same model as the problem cells) fit properly. Here are the cells. Only the cell at the right has a problem fitting in the adapters.

Does this PNY CS1111 SSD use a SandForce controller?

I recently finally upgraded to an SSD. I'm not too impressed. Some things are much faster, but those are generally rare operations such as rebooting and installing software or updates. Operating system caching and preloading was taking care of common operations. Practically speaking, going from a 160 GB Seagate 7200.7 to a 1 TB WD Black and later upgrading from 2 GB to 6 GB RAM were both more useful.

I chose a PNY CS1111 series 120 GB drive. It doesn't have the fastest read speeds, but it's faster than 3 Gbit/s SATA or 1x PCI Express 1.x, so the GA-P35-DS3R motherboard is the bottleneck.

According to PNY's 2015 SSD Product Comparison PDF, the CS1111 series uses a Silicon Motion SM2246EN controller. However, the SMART attributes don't make sense as SM2246EN attributes, and make sense as SandForce attributes. For example 241 and 242 are definitely measuring gigabytes. So, is PNY's information wrong? Are there multiple versions of this drive with different controllers? PNY's support didn't answer. I don't feel like opening up the drive to see if there's a SandForce controller inside, because that would void warranty. Here are the SMART attributes, as reported by smartmontools.

  1 Raw_Read_Error_Rate     0x0000   100   100   000    Old_age   Offline      -
  5 Reallocated_Sector_Ct   0x0000   100   100   000    Old_age   Offline      -
  9 Power_On_Hours          0x0000   100   100   000    Old_age   Offline      -
 12 Power_Cycle_Count       0x0000   100   100   000    Old_age   Offline      -
171 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -
172 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -
174 Unknown_Attribute       0x0000   000   000   000    Old_age   Offline      -
177 Wear_Leveling_Count     0x0000   000   000   000    Old_age   Offline      -
181 Program_Fail_Cnt_Total  0x0000   100   100   000    Old_age   Offline      -
182 Erase_Fail_Count_Total  0x0000   100   100   000    Old_age   Offline      -
187 Reported_Uncorrect      0x0000   100   100   000    Old_age   Offline      -
194 Temperature_Celsius     0x0000   033   100   000    Old_age   Offline      -
195 Hardware_ECC_Recovered  0x0000   100   100   000    Old_age   Offline      -
196 Reallocated_Event_Count 0x0000   098   098   003    Old_age   Offline      -
201 Unknown_SSD_Attribute   0x0000   100   100   000    Old_age   Offline      -
204 Soft_ECC_Correction     0x0000   100   100   000    Old_age   Offline      -
230 Unknown_SSD_Attribute   0x0000   100   100   000    Old_age   Offline      -
231 Temperature_Celsius     0x0000   100   100   010    Old_age   Offline      -
233 Media_Wearout_Indicator 0x0000   000   000   000    Old_age   Offline      -
234 Unknown_Attribute       0x0000   000   000   000    Old_age   Offline      -
241 Total_LBAs_Written      0x0000   000   000   000    Old_age   Offline      -
242 Total_LBAs_Read         0x0000   000   000   000    Old_age   Offline      -

If the Malicious Software Removal Tool won't go away, next month's updates might fix it

In May I stopped installation of Windows 7 updates because one simple update seemed to be taking a long time with no activity. After that, the May 2015 Malicious Software Removal Tool would not go away. It would install successfully every time, writing to C:\Windows\debug\mrt.log and setting HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RemovalTools\MRT\Version to the proper GUID. Nevertheless it would reappear after the next check for updates.

There were various ideas online, and I tried everything except deleting C:\Windows\SoftwareDistribution. Nothing helped. Eventually I just created a DWORD at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\MRT\DontOfferThroughWUAU, setting it to 1 to disable offering of the tool via Windows Update. You cannot simply hide the update, because then last month's tool is offered instead, and so on.

I just removed that setting, wondering if the June updates might fix it. They did. I don't know what happened. Maybe the June Malicious Software Removal Tool set something that Windows Update finally recognized. All I know is I spent way too much time on this little problem.

BTW There is some useful information in KB891716.

Monday, May 11, 2015

Performance of the Em-DOSBox CPU interpreter

When I first got DOSBox to run in a web browser, performance was terrible. The problem was the CPU interpreter. A single function fetches, decodes and executes most x86 instructions. Most of the function consists of a big switch statement with many cases. It is big because there are many x86 instructions.

The first problem was Emscripten converting the switch statement into a long chain of else if comparisons. Actually, a switch statement was used, but in most cases it merely set a variable which was later tested via comparisons. Instruction decoding, which needs to be done for every instruction, changed from O(1) into O(n).

Emscripten could generate a much better switch statement with a patch. This made DOSBox run fast in Firefox, but it was much too slow to use in Chrome. When I profiled it, I saw a warning triangle by the CPU interpreter function, telling me it's not optimized because the switch statement is too big. There was already v8 bug filed about this issue.

I solved this problem by transforming the cases of the big switch statement into functions using This reduces function size and allows a function pointer to be used instead of a switch statement. The process is somewhat convoluted because the switch statement is normally built using the preprocessor. First, preprocessor output files need to be produced. In order to get Automake to create them using proper dependencies, it needs to create a library which is otherwise unnecessary. Then the Python script parses the preprocessor files. It stores functions into a function store, removing duplicates and fixing name collisions. Finally, it creates header files which are used when building the final version of the CPU interpreters. Three CPU interpreters are processed this way: the simple, normal and prefetch cores.

Since then, the Emscripten bug has been fixed, I assume by the switch to Fastcomp. When Chrome started using TurboFan for asm.js, it could finally get good performance with an un-transformed CPU interpreter. This led me to check whether is still necessary.

Safari 8.0.6 and Internet Explorer 11 still get terrible performance without the transformation. Use of --llvm-opts '["-lowerswitch"]' doesn't seem to help. Looking at the JavaScript, I can confirm that it changes the big switch into a binary search, so this probably means the problem is due to the size or complexity of the function, and not just due to switch statements. I also experimented with the Emscripten outlining limit, with or without -lowerswitch. I assume that transforming switch cases into functions is a more efficient split than what's done by Emscripten outlining.

Friday, May 01, 2015

Gigabyte GA-P35-DS3R enables wake on any unicast packet by default

Recently I found that if I totally cut power to my computer (including standby power), booted to Linux and went into suspend, it would wake unexpectedly very soon. Booting into Windows would prevent this problem from happening until power is totally cut again. I suppose this problem existed before, but I never noticed it because I rarely fully cut power and I was using Linux less.

At first I thought this was a Linux bug, but actually, it the result of a crazy default setting for wake on LAN. By default, wake on unicast packet and magic packet are both enabled. If there was some network activity which caused ordinary unicast packets to arrive while the computer was sleeping, it woke up. That's why I found that with a minimal X setup using twm, the wakeups only happened if I was running a web browser.

This setting can be seen by running sudo ethtool eth0. Its output included:
        Supports Wake-on: pumbg
        Wake-on: ug

From the ethtool man page:
              u Wake on unicast messages
              g Wake on MagicPacket™

The solution was adding ethtool -s eth0 wol d to /etc/rc.local to disable wake on LAN. Then sudo ethtool eth0 would report Wake-on: d, which means "Disable (wake on nothing).". It's possible to also use g instead of d, which should only enable wake on magic packet.

The GA-P35-DS3R rev 1.0 motherboard F13 BIOS does not seem to have any options for changing wake on LAN settings, so this seems to be the only way to do it. I had already disabled wake on LAN in Windows via the Advanced settings in Device Manager. That setting persisted until standby power was cut.

It sure seemed like a Linux bug at first, so here's the Ubuntu bug I reported. Now I just wish Linux would tell me the wake reason. If something told me these wakeups were a result of wake on LAN, I would have wasted a lot less time on this.

Thursday, April 30, 2015

Sleep and wake notifications with systemd

After I upgraded to Ubuntu 15.04 Vivid Vervet, the Audacious plugin I used to control a display device I built had a problem. Functionality related to sleep and wake didn't work anymore. That's because UPower doesn't handle sleep and wake anymore. Notification events instead come from systemd-logind. In particular, it is the "PrepareForSleep" signal on the "org.freedesktop.login1.Manager" interface. When its argument is true, the system is preparing to go to sleep, and when it's false, the system is waking up. Here's the new code.

I still need to find a way to determine the last wake time. Formerly I was using the /var/log/pm-suspend.log modification time, but that is also now unavailable because systemd is handling it instead. If the plugin observes a wakeup, it gets the correct time from that, but when started it needs another method.

This illustrates a major difference between Windows and Linux. The Windows version of the plugin can still use the WM_POWERBROADCAST message, with parameters dating from Windows 2000. Linux is a moving target, and things will break unless you keep updating them. This probably also extends to Linux application APIs.