[Atrix 4G Q&A, Help & Troubleshooting] mvniekerk:
The following is a common problem with the Atrix, so it seems:

http://xdaforums.com/showthread.php?p=26120173#post26120173

Symptoms:

Try to enable the WiFi or Bluetooth : Doesn't enable BT or WiFi, sometimes will reboot phone.

Or it will constantly reboot phone, depending if you can get to the Airplane mode switch quick enough.

Sometimes in middle of calls it will reboot.

Suggested remedies

1) Format cache

2) Fix permissions

3) Replace firmware libs on /system/etc/modules/wifi

4) Detach + reattach battery clock on CPU/Accelerometer/WiFi/BT motherboard

5) Run stock ROM

6) Vote for Ron Paul

I've done the following

1 + 2 + 3 + 4 + 5. 6 doesn't seem probable to fix this case.

TWICE I've got the WiFi to work again. After that, reboot hell untill I could disable WiFi / BT.

Disclaimer : the following is a cross post from the previous forum

Kernel dumps

[ 31.028143] sdhci_tegra_wlan_detect Detecting WLAN

[ 31.028164] mot_wifi_set_carddetect: Nobody to notify

[ 31.029391]

[ 31.029395] Dongle Host Driver, version 4.218.248.32

[ 31.029400] Compiled in /tank/jokersax/cm9/kernel/moto/olympus/wifi-module/wlan/osrc/open-src/src/dhd/linux/../.. on May 7 2012 at 11:40:09

[ 31.328158] mmc1: error -110 whilst initialising SDIO card

WARNING: at /tank/jokersax/cm9/kernel/moto/olympus/lib/kobject.c:595 kobject_put+0x50/0x60()

[ 214.627572] kobject: '<NULL>' (0003da74): is not initialized, yet kobject_put() is being called.

[ 214.627581] Modules linked in: dhd(+)

[ 214.627591] Backtrace:

[ 214.627612] [<c0040010>] (dump_backtrace+0x0/0x10c) from [<c05b68c8>] (dump_stack+0x18/0x1c)

[ 214.627622] r7:c031c6c4 r6:c071fb48 r5:00000253 r4:e83a1e98

[ 214.627647] [<c05b68b0>] (dump_stack+0x0/0x1c) from [<c00bc5b8>] (warn_slowpath_common+0x50/0x68)

[ 214.627663] [<c00bc568>] (warn_slowpath_common+0x0/0x68) from [<c00bc61c>] (warn_slowpath_fmt+0x30/0x38)

[ 214.627673] r7:bf081000 r6:00000000 r5:bf076570 r4:0003da74

[ 214.627692] [<c00bc5ec>] (warn_slowpath_fmt+0x0/0x38) from [<c031c6c4>] (kobject_put+0x50/0x60)

[ 214.627701] r3:00000000 r2:c071fb80

[ 214.627720] [<c031c674>] (kobject_put+0x0/0x60) from [<c03787f0>] (put_driver+0x14/0x18)

[ 214.627729] r4:e98390c0

[ 214.627742] [<c03787dc>] (put_driver+0x0/0x18) from [<c0378938>] (driver_register+0x144/0x164)

[ 214.627757] [<c03787f4>] (driver_register+0x0/0x164) from [<c037994c>] (platform_driver_register+0x4c/0x60)

[ 214.627767] r9:00000000 r8:00000000 r7:bf081000 r6:00000000 r5:e83a0000

[ 214.627782] r4:bf078890

[ 214.627826] [<c0379900>] (platform_driver_register+0x0/0x60) from [<bf049fa4>] (wifi_add_dev+0x24/0x40 [dhd])

[ 214.627870] [<bf049f80>] (wifi_add_dev+0x0/0x40 [dhd]) from [<bf0810bc>] (init_module+0xbc/0x238 [dhd])

[ 214.627902] [<bf081000>] (init_module+0x0/0x238 [dhd]) from [<c003b5c8>] (do_one_initcall+0x40/0x1bc)

[ 214.627912] r5:e83a0000 r4:c07e0c00

[ 214.627932] [<c003b588>] (do_one_initcall+0x0/0x1bc) from [<c00f3880>] (sys_init_module+0xcc/0x200)

[ 214.627941] r9:e83a0000 r8:c003c364 r7:00046bd8 r6:00000000 r5:bf076748

[ 214.627957] r4:5c126008

[ 214.627970] [<c00f37b4>] (sys_init_module+0x0/0x200) from <c003c1e0>] (ret_fast_syscall+0x0/0x2c)

[ 214.627979] r7:00000080 r6:5e0fdb34 r5:5c126008 r4:405ad0f0

[ 214.627995] ---[ end trace 2416c978061dd5a5 ]---

[ 214.628002] Error: Driver 'bcm4329_wlan' is already registered, aborting...

Now I had some experience with WiFi kernel driver development (iMx51 + CSR based WiFi/BT combo chip).

The startup sequence on kernel level will probably go like this:

1) Kernel startup

2) ARM CPU specifics startup

3) Platform specific device setup (setup clocks)

3) Platform driver dependency registration (like, on SDIO 1 there is a WiFI chip that needs driver X to work)

4) Sub-platform driver startup (SPI, SDIO, UART, I2C)

I think this is where we fail first - Error -110 means timeout. Each MMC / SDIO chip has a MMC specific startup sequence, then depending what was given on number 3, it jumps over to SDIO (SDIO is a superset of MMC).

When our BT/WiFi chip is put into SDIO mode, the SDIO commands fail with a time out.

Possible reasons for it failing:

1) Incorrect voltages

2) Skewed clock

3) Busted chip.

4) We talk to it too fast

5) Kernel is messed up

Now, seeing that (through weird loops, check my previous post) I could get the unit running two more times, I do not think it is 3.

Why it could be 1:

Voltage rails needs to start up at the correct sequence for some chips. Like some chips will specify an operating range of between 1.8V and 3.3V. That means if it finds 5V on it, it will shut itself off. Sometimes some chips needs an initial 3V, then after 10 seconds it can be put into 1.8V (in-chip startup). Sometimes, it needs 10seconds to stabilize before you can talk to it (in our case via SDIO).

Why it isn't 1:

I've tried a lot of other kernels. It is all based off the ATT code, and they do the voltage rail setup correctly. I've even reverted back to stock code - no dice.

Why it could be 2

By removing the small cell battery, the drain on the battery was lifted. It could then store up enough current to put itself into the correct clock rate when it was put back.

Why it isn't 2

? Don't know. More needs to be known of the function of this battery. Obviously it is driving some RTC (real time clock). RTC's normally work at 32MHz, (32768, easilly divideable by 2, 4, 8 etc).

Does the Broadcom chip need this RTC? Isn't its clock lines driven by the Tegra2?

Why it could be 4

If the RTC is compromised (number 2) then init will suffer. If the Tegra's clock is not derived from the battery and the Broadcom's is, then there will be a disparity between the 2 units chatting together, as SDIO communication is clock based and not latch based (like SPI). If I'm chatting to you at 32MHz and you are 5% off, then we will not be communicating (if you are an SDIO master and I'm an SDIO slave).

Why it isn't

No idea.

Why it could be 5

Bunch of kernel errors stating un-inited modules pointing to null.

Why it isn't 5

Stock kernels also have the same problem

So, sorry folks, this issue points to a hardware problem.

Our biggest answer will be at the following:

1) What does that battery do?

2) Why is the SDIO subsystem having timeouts?

That's all for now.