在本章节□会指出一些常见的 PCMCIA 子系统的失败模式。请您试著在 这些例子中找出您所遇到的问题之症状。本章只描述”一般的错误”问题, 因此并不针对特定的卡片或驱动程式。
想要除错在我们试著经由 PCMCIA 装置来安装 Linux 时遇到的 PCMCIA 驱 动程式问题几近乎不可能。甚至您能从症状中知道是哪方面的问题,想要修 改安装磁片又很难,尤其是无法在 Linux 系统下存取时。 要自订安装磁片 完全要仰赖 Linux 供应者的的选择了,这也不在本文件的□围内。 但一般 来说, 最佳的步骤是先使用其他的方法来安装好 Linux, 然後拿到最新的 PCMCIA 驱动程式後,再来除错那些仍存在的问题。
症状:
lsmod
并没秀出任何的 PCMCIA 模组。cardmgr
执行报告 ``no pcmcia driver in /proc/devices''
在系统日志中。核心模组中包括它的版本资讯会在模组被载入时与现在的核心相核对。检查
的方式视 CONFIG_MODVERSIONS
这项核心选项来看。 如果这项目是否
定的, 核心版本号码就会被编译到每一个模组内,而 insmod
会检查
这项是否与执行中的核心是相符合的。 如果 CONFIG_MODVERSIONS
是
yes,核心所提报的每个符号会被做成一份检查总览 (Checksum)。这些程式
码都会被与相对应的程式码相比对後编译成模组。这麽做旨在让模组们减少
版本依赖度, 因为检查总览只会在核心介面更动时才会跟著变动, 且对於
小小的核心更新升级几乎维持与原来相同。在实务上,检查总览已变成更加
的严格,因为有许多的核心介面都依赖是在编译时期时核心选项的设定。而
且,检查总览己变成一个判断相容度的极端悲观的工具了。
有些 PCMCIA 模组需要核心服务程式,但这些服务程式可能存在或不存在,
这完全要看核心的建构。 例如,SCSI 控制卡驱动程式就需要核心已被建构
支援了 SCSI 了。网路驱动程式就需要支援网路的核心。如果核心缺少了一
需要的功能,insmod
可能会报告出有未定义的符号而不去载入该模组
。
这样继续的结果是,核心模组紧密地与核心版本以及许多的核心建构选项的 设定相结合。一般来说,结核心 2.0.31 版的一组被编译好的模组并无法被 其他的核心 2.0.31 版本上使用。除非有特别地注意到将两个建构成相同的 设定。这个问题,就让那些供应已编译好的核心模组的工作变得有点奇怪了 。
您有几种选项:
Documentation/Changes
档案内针对模组公用程式及二进位公具
程式中列明的最小需求 (``minimal requirements'')。
症状:
在辨视 PCMCIA 控制器之後,插槽驱动程式会侦测空著的插断号码。这个动 作会为每个显然是空著的插断做程式化, 然後产生一个 `` 软的 '' 插断, 来看看是否这个插断可以被正确地被侦测到。有些时候,侦测到一些特殊的 插断时会影响到其他的系统设备。
这麽侦测的理由是,我们要辨视出真正空著可用的插断。 (例如,那些不是 被任何其他 Linux 设备驱动程式所预留著的, 也并非实体上已连接著 PCMCIA 控制器的,或是已连接著其他的设备但并没有驱动程式的。)
有二种继续的方法:
irq_list
参数设定来限制
只对某些插槽实施而已。例如 ``irq_list=5, 9, 10
'' 会限制只对这
三个插断做扫描探测而已。所有的 PCMCIA 设备会被限制只能使用这几个插
断而已 (假如它们略过了侦测动作 )。你可能需要□试几次失败并再接再厉
地才能找到哪些插断可以被安全地侦测使用的。另一个方法,我们可以使用在 PCMCIA 启动手稿中指定 PCIC_OPTS
的
设定,例如:
PCIC_OPTS="irq_list=5,9,10"
症状:
或是:
主模组程式在第一次插入卡片使做一定记忆体扫描。这个动作有潜在可能地
干涉到其他记忆体映射的设备。另外,pre-3.0.0 版本前的驱动程式套件还
会做比现今的驱动程式版本更进一步的扫描。记忆体窗是被定义在
/etc/pcmcia/config.opts
内。 预设的窗口很大,所以它可能会
帮助来限制扫描到较窄的□围。比较合理的□围可试看看包含进以下的位址
:0xd0000-0xdffff, 0xc0000-0xcffff, 0xc8000-0xcffff, 或
0xd8000-0xdffff。
如果你有 DOS 或 Windows 版的 PCMCIA 驱动程式, 你就可以 you may be
able to deduce what memory region those drivers use. 请记得 DOS 的
记忆体位址通常都使用 `` 段 '' 位址形式,也就是它会将尾巴的十六位元
数字省略掉(所以 0xd0000 的绝对位址就是 0xd000 )。 记得在改
/etc/pcmcia/config.opts
时要确认这项。
症状:
一般来说,卡槽驱动程式 (i82365
或 tcic
) 会自动地侦测并选
择一个适合的插断来传送卡片状态的更动。 某些 Intel 相容控制器的自动
插断侦测不能工作。 包含 Cirrus 晶片和装在 IBM ThinkPads 上的晶片。
如果在侦测时设备无法起动,它的插断也会是□置的。这种状态下,卡槽驱
动程式也许会挑到一个已被其他装置使用中的插断来使用。
在 i82365
和 tcic
的驱动程式□的 irq_list
选项可以
用来限制哪些插断可以被测试的。这个插断列表可被限制成只被 PCMCIA 卡
所使用或用来监控卡片状态的改变。 另外 cs_irq
选项可明白地设定
哪个插断要被用来监控卡片状态的改变的。
如果您无法找到可正常工作的插断号码,还有一个票选状态模式可用:不论
是 i82365
或 tcic
都接受 poll_interval=100
这选项,
用来票选卡片的每秒的改变状态。如果您的系统已短缺可被 PCMCIA 卡使用
的插断时这个选项也可以被使用。特别是在系统内有一种以上的 PCMCIA 控
制器时就必须注意这点了。
所有的这些选项必须在 PCIC_OPTS=
这行来设定, 看您的系统是设在
/etc/rc.d/rc.pcmcia
□或是 /etc/sysconfig/pcmcia
。
Symptoms:
通常这就表示已经和某个 Linux 不知道的系统设备相冲突了。PCMCIA 设备 是被动态建构的,所以,例如,插断是在被需要时被分配的,而不是特别被 指定到特别的卡片或是插槽的。现在有一个可用资源的清单,卡片会在他们 被建构时依序地被指派给资源的。在这种状况下,最後被建构的卡片会被指 派到一个并非是空□著的资源上了。
您可检查系统日志有哪些资源被非正在工作的卡片所占用著。在
/etc/pcmcia/config.opts
□把这些排除在外, 再重新启动
cardmgr
精灵来再载入资源资料库。
症状:
这表示卡片已被成功地辨视了。但是 cardmgr
因某些原因已无法完成
建构程序。最有可能的原因是在卡片设定手稿的某一步骤被困住了。当一个
网路卡被插入时并没有接上一个正活动中的网路上时,网路手稿被困住了,
这就是最好的例子。
要找出问题出在哪□,你可以手动执行一个设定手稿来看看它是被困在哪儿
的。这个手稿就放在 /etc/pcmcia
目录内。他们会使用二个参数
:设备名称及动件。 cardmgr
精会把记录建构的命令记录在系统日志
内。 例如, 在系统日志中显示出 `./network 命令开始了 eth0'' 是被
cardmgr
最後一个执行的命令,以下的命令会追踪这个手稿:
cd /etc/pcmcia
sh -x ./network start eth0