昨天晚饭后，打开本子继续工作，却发现无法连上无线路由器。最初以为路由器忘记打开了，可拿起路由器看了下，不是那么回事儿，路由器工作一切正常。我这才看到发现本子的无线网卡的指示灯不亮了，以前在这台x60本子上还从未出现此类情况，于是开始查找故障原因。

故障查找过程是痛苦的，一次次燃起希望，又一次次被冷水破灭：

* 最初怀疑是我误点击了Fn + F5而把无线网卡关了，于是我又无数次的点击Fn + F5，居然一点反应都没有；
* 我的T400上有无线网卡的硬件开关，我将x60翻转了几周，也没找到无线开关位置；
* Ubuntu上Network Manager面板中，无线网络显示已停用，且菜单项为灰色，无法选择，无法启用；
* N次重启机器，无果；
* 切换到Win7下，Win7设备管理器显示无线网卡设备正常，驱动正常；反复停用、启用无线，都无法使指示灯亮起；
* 重启机器，F1进入BIOS，查看网络设备也是Enabled，遂将BIOS恢复成默认出厂设置；
* 再尝试进入Win7，蓝屏，提示修复，修复若干次依旧无法进入Win7，无线指示灯依旧处于熄灭状态;
* 继续回到Ubuntu下折腾，卸载Network Manager，更换网络管理软件，用T400下载WCID，并用U盘COPY到x60里安装(家里没有备网线)，WCID也没比自带的Network Manager好哪里去，依旧无法找到无线网卡；
* 恢复Network Manager；
* 用系统->系统管理->系统日志查看器查看系统日志，看到如下错误日志：
    dhclient: receive_packet failed on wlan0: Network is down
    wpa_supplicant[824]: Failed to initiate AP scan.
    NetworkManager:   WiFi now disabled by radio killswitch
    NetworkManager:   (wlan0): device state change: 8 -> 2 (reason 0)
    NetworkManager:   (wlan0): deactivating device (reason: 0).
    NetworkManager:   (wlan0): canceled DHCP transaction, dhcp client pid 2816
* 根据网上资料，按如下操作：
  – sudo -i
  – echo 1 > /sys/class/rfkill/rfkill0/state
  – 重启机器
  问题依旧。

* 安装rfkill，rfkill list看到：
  0: phy0: Wireless LAN
 Soft blocked: yes
 Hard blocked: yes
  执行rfkill unblock all，得到：
  0: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: yes
  依旧无法打开无线网卡

* 被折腾近四个小时后上床睡觉！
* 上班后联系设备维修部门；
* 带着本子到维修部门查找故障原因，说明情况后，维修人员操作我的本子；
* 重启机器，进入BIOS，将Config -> Serial ATA -> SATA Controller的MODE OPTION改为COMPATIBILITY，保存退出；
* 选择Win7，居然不再蓝屏，正常进入Win7；
* 在Win7加载进度条还在闪烁的时候，这位维修人员托起本子看了看，指着本子某个部位对我说：这是不是无线开关？
* 他拨动无线开关，无线信号指示灯亮起；
* 我无语！

不得不承认：我的眼神儿太差了！

今天上午处理了一个线上产品的故障。分析来分析去，最后定位问题还是出在字节序转换的环节上。

其实测试组早在产品上线前就曾报告了这个问题，但是对应的开发人员并未对该问题进行深入地分析，而是有些草率地将该问题归结为客户端模拟器的实现不符合标准。因为这位同事比较资深，所以当时我也没有给予足够关注。

产品今天凌晨上线，9点左右业务量开始增大，这个问题立即就被我们在现场的运维人员发现，还好我们的系统是集群式的，运维同事及时的将线上有问题的版本停掉，用其他服务器支撑起了全部业务，躲过一劫。

我们还是回到这个问题上来。经验告诉我们：严重的问题往往都是由极其简单的错误导致的。这次也不例外！问题的直接原因就是：多调用了一次htonl。的确就是这么简单，但如果继续深入下去，我们还能得到一些收获。

当产品运行在x86服务器上，这个问题就会暴露出来，但是在Sun Sparc服务器上，该产品运行良好。我们分析后的结论是：这是由于在两种体系结构上htonl的实现不同而导致的。

我们先来做个试验，看下面的代码和执行结果：

/* testhtonl.c */
#include "stdio.h"
#include "arpa/inet.h"

int main() {
    unsigned int a = 0×12345678;
    unsigned int b = htonl(a);

    printf("0x%x\n", b);
    printf("0x%x\n", htonl(b));
   
    return 0;
}

将上面代码分别在x86和Sparc上编译运行。在x86上(ubuntu 10.04 Gcc 4.4.3 x86)运行的结果如下：
0×78563412
0×12345678

而在Sparc上(Solaris 10 for Sparc, Gcc 3.4.6)运行的结果如下：
0×12345678
0×12345678

由此我们可以看出，htonl这个接口并不总等价于字节序转换。在Sparc这种Big-endian体系结构的平台上，htonl相当于直接将参数值返回；而在x86这样的little-endian体系结构平台上，htonl则是等价于一个reverse_byte_order接口，每次调用都会把输入参数的byte order倒转后的结果返回。

还回到我们的那个问题中：多调了一次htonl在Sparc平台上没有什么影响；但是在x86平台上，我们得到了相反字节序的结果，导致故障的出现。

这不是我们第一次遇到字节序问题了，不过却是第一次在线上产品中遇到，上一次是在开发过程中遇到的。这次发生的问题并不仅仅是技术上的问题，更多的是在工作的严谨性和工作态度上出现问题了。对我来说，这是一个很值得吸取的教训。