Archive for the ‘PC Hardware/Consumer Electronics’ Category

Repairing a completely dead Asus ROG G75VW 17-inch Gaming Laptop

Saturday, December 1st, 2018

This one was fairly uncomplicated:

  • There was a bad 4936N MOSFET near the power jack.  In circuit there was very low resistance between gates, sources, and drains of both MOSFETs. It was not really possible to tell which of the two MOSFETs in that area was bad without removing both the 4936N and the nearby PH5030AL.  After removing both, the 4936N was confirmed bad as it read 15 ohms from gate to drain and 0 ohms from gate to source.
  • Additionally, the Winbond 25Q64FVSIG BIOS chip was visibly fried (cracked package).  You can get a programmed replacement for about USD $20 and I would recommend this unless you are experienced with programming BIOS chips.
  • Using hot air it is easy to remove all of these and install the replacements, but watch the very small capacitor next to the MOSFET and to the left of the JP4601 marking – if you blow it away it’s a headache to get back into place, if you can even find it!  (In this picture it’s next to the 4936N, but on my board the PH5030AL was in that location.)
  • Use a rework flux pen.

You should be good to go for reassembly in half an hour.  To test, just connect the power jack board, the power switch board with the ribbon cable, and a fan, connect power and depress the power switch momentarily and it should spring to life!  Note: If the CPU is not installed and/or the BIOS is inoperative, it is expected behavior that the fan speed will cycle up and down rhythmically.  Once the CPU can execute the correct BIOS code, it will then control the fan speed appropriately.

Reviving a bitrotted OEM Windows Vista installation on your Linux laptop

Sunday, June 24th, 2018

If you’re a normal sort of Linux user, when you buy a laptop you probably keep that Microsoft OS partition around, shrinking it to a minimal size and allowing it to coexist with Linux just in case you need it for firmware updates, special Windows-only tools for special situations, or sometimes just for an A/B comparison if you suspect something might be wrong with the Linux driver for a particular device.

So, after not booting that Windows Vista partition for a few years, and possibly having gone through a few disk upgrades and associated disk imaging in the meantime, you try to boot it up only to find:

  • It doesn’t boot via the automatically populated GRUB entry, hanging at a black screen
  • It doesn’t boot via Hiren’s Boot CD or another tool booting the Vista partition directly, with a winload.exe “missing or corrupt” BSOD
  • Third-party software upgrades don’t work
  • Windows Update doesn’t work
  • Anything you try to install manually doesn’t work

ARGH!!

Well, here’s how you should be able to fix that mess (steps tested on Windows Vista Home Premium OEM 32-bit SP1).

(more…)

Can LiteOn/Slimtype DS8A1H laptop DVD recorder burn dual layer DVDs?

Sunday, April 22nd, 2018

Many mid-2000s Compaq/HP laptops which shipped while DVD media was predominant included this unbranded “Slimtype DVD A DS8A1H” DVD recorder, which is actually a rebadged LiteOn drive.  It’s not that great a drive, but it does work to burn double/dual layer (DL) DVDs for use on a console DVD player.  Here is what you need to know to produce DVDs that work on a console player.

(more…)

Google Pixel Phones With Android Oreo Repeatedly Disconnect From Wi-Fi

Wednesday, February 28th, 2018

There is a long thread in the Google support forums which links to several other long threads regarding Google Pixel phones with Android Oreo 8.0 or 8.1 repeatedly disconnecting from WiFi access points that work for other users.  There are multiple causes, some of which were fixed in the January security patch, so here’s the TL;DR.  (As you can see, factory resetting should be a last resort rather than a first resort in this case.)

  • Delete Verizon “Security & Privacy” app, or at least turn off WiFi security, on branded phones.
  • Disable all Chromecast devices on the network to prevent a flood condition when the phone first comes online.  This problem was fixed in the January security patch.
  • Disable 5GHz on a dual-band wireless access point.
  • Set a static IP for the phone in the router DHCP configuration.
  • Use WPA to secure your wireless access point instead of the obsolete WEP standard.
  • Turn on Bluetooth.
  • Disable IPv6 in the router configuration.
  • Reboot in ‘safe mode’, then disable and re-enable WiFi and see if it stays connected.  If it does, reboot normally and then:
    • Force-stop the Google Home app, disable and re-enable WiFi.
    • Force-stop the Waze app, disable and re-enable WiFi. (This was the fix for my phone on Oreo 8.1, as improbable as it may be.)

 

Install Linux on an Android-Based Lenovo Yoga Book (YB1X90F)

Friday, April 28th, 2017

Having a Linux distribution installed on an Android netbook can be the best of both worlds. Leveraging the Linux kernel already running on any Android device, a Linux userspace will be native and fast and come with many tools power users will appreciate. Here are some ways to get the most out of the Linux on Android experience.

(more…)

APC AP9584 USB Conversion Kit and APC Serial Smart-UPS

Wednesday, April 26th, 2017

The AP9584 serial-to-USB conversion kit for older APC UPS models with a serial host interface is the manufacturer-endorsed solution for interfacing such older UPS units with a USB-based host computer. However, it is specified on the label for “use with APC Back-UPS and Back-UPS Pro only”. Will it work with a Smart-UPS unit?

Initially, it would seem so – all the variables are read properly. However, after a period of 30 days or so, and generally unnoticed to the operator, the “LB” (Low Battery”) status flag is flipped on, while nothing is actually wrong with the battery. This does not cause an immediate problem. However, the next time the UPS does a periodic self-test, the “OB” (“On Battery”) status flag will be temporarily set as is expected during a self-test cycle. However, from the perspective of UPS monitoring software, the combination of LB and OB means “The UPS is nearly dead, so shut down the system cleanly”. As a result, every system listening to the UPS monitoring software would immediately (and cleanly) shut down, and then dutifully wait for a UPS power-cycle that never came!

  • I thought at first this was an anomaly with the particular UPS (Smart-UPS 1500), so I switched to a Smart-UPS 1000. Same result.
  • I thought then that I had just gotten a defective cable, and bought another AP9584 to test. Same result.
  • I then replaced the AP9584 with a good old APC 940-0024C and a Kawamall USB to DB9 (male) serial converter. After months, the problem never happened again!

The Kawamall USB to serial converter has USB vendor:device 1a86:7523 corresponding to a QinHeng Electronics HL-340. Others have noted that Prolific converters also seem to work.

In any case, don’t bother trying to use the APC AP9584 on a Smart-UPS – there seems to be a bug that will cause your systems to be powered off unexpectedly. Just use a normal USB-to-serial converter with the APC 940-0024C or similar smart monitoring cable.

ACPI Warning: SystemIO range X conflicts with OpRegion Y error

Sunday, April 23rd, 2017

On a Linux system, you might be trying to use a utility like decode-dimms to read the SPD EEPROM of your system’s RAM DIMM modules.

But it does not work, and checking the kernel messages, you see:

[    1.457863] i801_smbus 0000:00:1f.3: enabling device (0001 -> 0003)
[    1.457945] ACPI Warning: SystemIO range 0x0000000000000400-0x000000000000041F conflicts with OpRegion 0x0000000000000400-0x000000000000040F (\SMRG) (20160831/utaddress-247)
[    1.458063] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver

In this case, the Intel 82801 SMBus driver is attempting to load, finding that the ACPI SMRG (System Management Region) has already claimed part or all of the SMBus I/O range, and failing due to strict ACPI resource enforcement. (In the general case, this will be true of whatever driver is attempting enablement immediately preceding the ACPI messages.)

To work around this and accept the risk of system instability, add the acpi_enforce_resources=lax parameter to your kernel command line and reboot.

Afterwards you will see two extra lines in the output:

[    1.457863] i801_smbus 0000:00:1f.3: enabling device (0001 -> 0003)
[    1.457945] ACPI Warning: SystemIO range 0x0000000000000400-0x000000000000041F conflicts with OpRegion 0x0000000000000400-0x000000000000040F (\SMRG) (20160831/utaddress-247)
[    1.458031] ACPI: This conflict may cause random problems and system instability
[    1.458063] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    1.458110] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt

The third line is new and appears advisory, but it is actually advising that the device is being enabled despite the risk of instability posed by two kernel drivers owning the same I/O region. The fifth line is from the driver that was attempting to load and its appearance means that it has proceeded to load.

While this parameter might bypass SMBus conflicts in particular, allowing a utility like decode-dimms to offer functionality not offered by the ACPI BIOS that first claimed that I/O region, it will also bypass this conflict for any device affected by ownership by the ACPI BIOS that would prevent a driver from loading.

How to use fio to stress test a hard drive

Sunday, April 23rd, 2017

So you’ve a got a disk in your hand that’s new, used, or questionably refurbished, and you want to give it a thorough thrashing to see how it holds up before trusting your data to it. How? SMART tests and badblocks are the usual tools, but you really want to simulate a workload instead of just doing a linear once-over.

Fortunately, the fio benchmarking tool has a randrw module that can do exactly this. Run this and it will scribble all over a disk and check the results. You should then have a good idea whether that disk is a winner or a dud for a real world workload.

Example, assuming we will stress-test the disk for 1 day (86400 seconds), we have 4 CPU threads, and the disk to be tested is /dev/sdg (WARNING: all data on this disk will be randomly trashed):

# fio --name=randrw --time_based --runtime=86400 --ioengine=libaio --iodepth=64 --rw=randrw --bs=4k --direct=1 --numjobs=4 --filename=/dev/sdg

Asus P5B-E: Limited to 3GB RAM, or fourth DIMM slot appears not working

Friday, April 21st, 2017

If you have an Asus P5B-E or other motherboard with AMI BIOS that was manufactured during the Windows Vista era, you might find, especially after replacing the battery or resetting BIOS settings, that the BIOS will only count 3GB (3008MB) of memory, and only 3GB is made available to the operating system. Swapping DIMMs has no effect, lending an appearance if utilizing a 4x1GB DIMM configuration, that the fourth DIMM slot is bad. However, launching memtest86 or a DMI decoder tool clearly shows via reading the SPD EEPROM that the fourth DIMM is in fact installed and accessible.

Fortunately, the fix is simple: enable the Memory Remap setting in the BIOS ‘North Bridge Chipset Configuration’ menu:

memory.remap

Why does this setting exist?  The chipset is capable of remapping RAM that conflicts with PCI MMIO regions to addresses above 4GB; this feature is useful when the operating system supports accessing that RAM, such as a 64-bit operating system or a 32-bit operating system with PAE support.  For more information, see here and here.

However, what is less comprehensible is why the default behavior is to unmap RAM between 3GB and 4GB entirely.  While it is true that disabling physical addresses that conflict with PCI MMIO regions is more costly than necessary due to poor granularity of the disabled regions, it would seem that allowing the remaining memory to at least be counted and allocated to the extent possible would be a reasonable default behavior.  Instead, the system pretends that RAM between 3GB and 4GB does not exist at all.  Is there a reason for this?  Inquiring minds want to know!

Edit: It appears that enabling this setting remaps the physical region from 2GB-4GB to be addressible starting at 4GB instead (only accessible by a 64-bit OS). With it disabled, the OS will be able to use up to 4GB of RAM that is not covered by PCI MMIO address space. In the case of this system, I had forgotten about the GPU RAM! So with Memory Remap turned off, more than 1GB of PCI address space was overlapping physical memory and rendering it unusable to the system. Mystery solved!

CPU upgrade note

The fastest CPUs available for the P5B-E are the Core 2 Extreme ‘Kentsfield XE’ series.  These are quad-core processors with a 130W TDP.  The QX6800 and QX6850 are very similar; the only difference is the FSB (1066MHz and 1333MHz respectively).  However, the Intel P965 platform limits the FSB to 1066MHz, which makes the QX6800 the fastest available processor for the P5B-E.  This processor can now be obtained on eBay for $50 or less.

Another reason the QX6800 is a good choice for the P5B-E is because the clock multiplier is unlocked.  The reason this is a beneficial feature in a non-overclocking scenario is a bit obscure.

The Intel P965 chipset does not allow a downward memory multiplier.  In effect, this means that the memory cannot run at a slower clock speed than the CPU FSB.

The fastest RAM the P5B-E supports is DDR2-800 (PC2-6400).  To use DDR2-800 RAM at 400MHz, the CPU FSB must thus be set at 400MHz (1600MHz).

However, to run a multiplier-locked 1066MHz CPU at a 1600MHz FSB would become more difficult with higher multipliers due to the leveraging effect.  If the QX6800 were multiplier-locked, its 11X multiplier would cause it to be clocked at 4.4GHz, which is at the very top end of what is possible on the Core 2 platform.  (There are other considerations for scaling the FSB upwards such as the how the manufacturer implemented northbridge strapping: see here and here.)

Fortunately, since the QX6800 is multiplier-unlocked, it can be run at at a close-to-stock 7x or 8x multiplier to yield a 2.8Ghz or 3.2GHz clock speed.  This will not require special cooling considerations for the CPU, but will allow DDR2-800 RAM to operate at its rated speed.  This would otherwise be impossible with a high-end, multiplier-locked Core 2 CPU!

P5B-E board revision and CPU FSB

There are at least two revisions of the P5B-E mainboard. Rev. 1.02G adds the ability to adjust the northbridge, southbridge, and ICH voltages:

p5b-e.1.02g

The northbridge voltage is the most important; it is difficult to attain a CPU FSB above 350MHz on the P5B-E without being able to increase the P965 NB Vcore from the default 1.25V, although the very similar P5B has possibly seen some better results.  Therefore, if you have a Rev. 1.01G P5B-E, don’t bother trying to increase the CPU FSB beyond 350MHz or so.

At a 350MHz CPU FSB, you have two choices for the RAM speed: 700MHz and 875MHz.  If DDR2-800 RAM is not stable at 875MHz, options are to loosen the timings or increase memory voltage.  For example, if the memory is rated for 4-4-4-12, try 5-5-5-15 instead.  Increasing the memory voltage may help stability, but the tradeoff is greater heat generation; RAM with small heat spreaders is often rated up to 2.1V, and RAM with large heat spreaders can likely tolerate more.  If neither of these options result in a stable system, or the system will not boot at all at 875MHz regardless of timings, then the final option is to decrease the RAM clock to 700MHz.

At a 350MHz FSB, the closest CPU multiplier to stock will be 9x, to run the QX6800 at 3.15Ghz.  Again, the unlocked multiplier helps here in keeping the CPU close to stock speed, and thereby reducing the number of experimental variables in customizing for maximum speed.

In my case, I was able to initially run the QX6800 (SLACP) at a 320MHz FSB and 10X multiplier (3.2GHz) with air cooling and BIOS automatically-determined voltages.  The DDR2-800 RAM was then able to operate at its native speed (at a 4:5 FSB:RAM clock ratio) and 4-4-4-12 timings.  Increasing the FSB even to 333MHz began necessitating tradeoffs: the RAM was then nonfunctional at CL4 and had to be bumped to 5-5-5-15 or reduced to a 1:1 FSB:RAM clock ratio to even successfully POST. As for the CPU, an 11X multiplier for the CPU (3.55GHz) proved unstable in memtest86+ under air cooling.

Unfortunately, the G.Skill F2-6400CL4S-1GBPK RAM that came with the system — despite being marked 4-4-4-12 — proved unstable at 4-4-4-12 during kernel compilation, but worked at the SPD default CL5. Increasing the DIMM voltage to 1.9V as indicated on the G.Skill website — but not the DIMM label itself — provided stability sufficient to complete a multicore Linux kernel build. (One point of interest revealed by using decode-dimms to dump the SPD EEPROM data is that the tRC and tRFC timings differ between DIMMs that, while being marked with identical G.Skill model numbers, are via visual differences obviously sourced from different manufacturing batches.) Also, a consistently bad address was found in repeated memtest86+ runs on one of the DIMMs; this was disappointing in terms of quality, but the GRUB_BADRAM configuration to exclude the small bad region saved the day at least.

The P5B-E has at least two minor annoyances in an overclocking configuration. The smaller of these is that depending on various settings, RAM speed is sometimes reported incorrectly by the BIOS: for example, RAM running at DDR2-800 speed will be incorrectly reported as PC2-5300. (Using memtest86+ or a DMI tool will report the correct configured speed.)

The larger annoyance is that to compensate for increasing the CPU FSB speed without running the CPU itself at an infeasibly high speed, it is only possible in the P5B-E BIOS (even the last version 1807) to set a lower fixed multiplier, rather than to set a maximum multiplier.  But by setting a fixed multiplier, SpeedStep dynamic clocking is disabled entirely by the BIOS.  Not being able to utilize dynamic clocking results in even hotter operation and more power consumption at idle for this already-hot 65nm process CPU.  A better option would have been to allow the user to set a maximum multiplier and for the BIOS to regenerate appropriate ACPI _PSS tables.

Alternatively, if it were possible to boot Linux at the minimum CPU speed (perhaps by defaulting to the powersave cpufreq governor), then the maximum speed could be limited through tunables for the ondemand cpufreq governor after boot. Unfortunately, the default governor is a compile-time option and is chosen as performance, at least on Debian kernels, so pursuing this option would necessitate maintaining a locally customized kernel.

initrd hacking

A compromise is available that could allow increasing the FSB clock while leaving SpeedStep enabled, which would normally produce an infeasible top CPU speed.  If your system is stable enough at the otherwise-infeasible top CPU speed to at least boot an initrd, the initrd script can immediately replace the cpufreq governor with the powersave governor, which will set the CPU to its minimum speed.  After the system is booted, a local init script such as /etc/rc.local can set the maximum stable CPU speed, before once again enabling the ondemand governor as in normal operation.

I made the following modifications to my system to change the governor as early as possible (it does not seem to be possible to change it any earlier, such as in early-boot where CPU microcode is loaded from the initrd):

Create /etc/initramfs-tools/scripts/init-premount/overclock (chmod +x):

#!/bin/sh
# Force all cores to lowest speed as soon as possible during boot
PREREQ=""
prereqs()
{
        echo "$PREREQ"
}

case $1 in
prereqs)
        prereqs
        exit 0
        ;;
esac

. /scripts/functions
# Begin real processing below this line
for cpu_policy in /sys/devices/system/cpu/cpufreq/policy*; do echo 'powersave' > ${cpu_policy}/scaling_governor; done

In /etc/initramfs-tools/modules:

# List of modules that you want to include in your initramfs.
#
# Syntax:  module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod
cpufreq_powersave

Create /etc/default/cpufrequtils:

GOVERNOR="powersave"

In /etc/rc.local (add this later after successfully booting at least once):

for cpu_policy in /sys/devices/system/cpu/cpufreq/policy*; do echo 3000 > ${cpu_policy}/scaling_max_freq; echo 'ondemand' > ${cpu_policy}/scaling_governor; done

And then finally, update the initrd:

# update-initramfs -k all -u

Unfortunately, the results were pathetic. Above 300MHz FSB, Linux would not even completely boot through the initrd, regardless of CPU or FSB voltage settings. Between 280MHz and 300MHz, the initrd would finish, effectively removing the CPU as an experimental variable. However, Linux would crash as the normal system init scripts were running, indicating a remaining problem with the FSB clock. Only once the FSB clock was lowered to 280MHz could I successfully compile a kernel. The QX6800 CPU itself had no problem operating at 3.2GHz there, but without the ability to increase the northbridge voltage, it was impossible to get system stability above 280MHz FSB. Unfortunately, lowering the FSB this low also meant the RAM clock would be lowered with it in a massive tradeoff, since the RAM could not operate at any higher FSB:RAM clock multiplier. The result was that a kernel compilation in the overclocked configuration was only 4% faster than that in the nominal configuration, making this all mostly a mental exercise.

Conclusion

In the end, I left the CPU at the default 266MHz FSB so that SpeedStep could be utilized; I used a 2:3 FSB:RAM clock ratio to run the RAM at DDR2-800 speed; and set the RAM timings to 4-4-4-12 and the DIMM voltage to 1.9V.  Trying to squeeze any more performance from the CPU and increasing the FSB speed both involved unacceptable tradeoffs.

Notes on upgrading system with Asus M3A rev 1.x motherboard

Thursday, April 20th, 2017

The Asus M3A 1.xx (not to be confused with the M3A-H) is a decent Socket AM2+ motherboard.  Despite being dated (having been released in 2007), it’s still part of a usable — if trailing-edge — desktop system today.  The main limitations are DDR2 RAM, SATA II, PCIe 2.0, HyperTransport 3.0, and those of the Phenom CPU platform itself.  Here is a small guide for upgrading this system to the maximum.

(more…)