kk Blog —— 通用基础

Linux系统启动过程分析

2016-01-21 16:13:00

http://blog.chinaunix.net/uid-23069658-id-3142047.html

BIOS自检

稍有计算机基础的人都应该听过BIOS(Basic Input / Output System)，又称基本输入输出系统，可以视为是一个永久地记录在ROM中的一个软件，是操作系统输入输出管理系统的一部分。早期的BIOS芯片确实是"只读"的，里面的内容是用一种烧录器写入的，一旦写入就不能更改，除非更换芯片。现在的主机板都使用一种叫Flash EPROM的芯片来存储系统BIOS，里面的内容可通过使用主板厂商提供的擦写程序擦除后重新写入，这样就给用户升级BIOS提供了极大的方便。

BIOS的功能由两部分组成，分别是POST码和Runtime服务。POST阶段完成后它将从存储器中被清除，而Runtime服务会被一直保留，用于目标操作系统的启动。BIOS两个阶段所做的详细工作如下：

步骤1：上电自检POST(Power-on self test)，主要负责检测系统外围关键设备（如：CPU、内存、显卡、I/O、键盘鼠标等）是否正常。例如，最常见的是内存松动的情况，BIOS自检阶段会报错，系统就无法启动起来；

步骤2：步骤1成功后，便会执行一段小程序用来枚举本地设备并对其初始化。这一步主要是根据我们在BIOS中设置的系统启动顺序来搜索用于启动系统的驱动器，如硬盘、光盘、U盘、软盘和网络等。我们以硬盘启动为例，BIOS此时去读取硬盘驱动器的第一个扇区(MBR，512字节)，然后执行里面的代码。实际上这里BIOS并不关心启动设备第一个扇区中是什么内容，它只是负责读取该扇区内容、并执行。

至此，BIOS的任务就完成了，此后将系统启动的控制权移交到MBR部分的代码。

PS: 在个人电脑中，Linux的启动是从0xFFFF0地址开始的。

系统引导

我们首先来了解一下MBR，它是Master Boot Record的缩写。硬盘的0柱面、0磁头、1扇区称为主引导扇区。它由三个部分组成，主引导程序(Bootloader)、硬盘分区表DPT（Disk Partition table）和硬盘有效标志（55AA），其结构图如下所示：

磁盘分区表包含以下三部分：

1）、Partition ID （5：延申 82：Swap 83：Linux 8e：LVM fd：RAID）

2）、Partition起始磁柱

3）、Partition的磁柱数量

通常情况下，诸如lilo、grub这些常见的引导程序都直接安装在MBR中。我们以grub为例来分析这个引导过程。

grub引导也分为两个阶段stage1阶段和stage2阶段(有些较新的grub又定义了stage1.5阶段)。

1)、stage1：stage1是直接被写入到MBR中去的，这样机器一启动检测完硬件后，就将控制权交给了GRUB的代码。也就是上图所看到的前446个字节空间中存放的是stage1的代码。BIOS将stage1载入内存中0x7c00处并跳转执行。stage1（/stage1/start.S）的任务非常单纯，仅仅是将硬盘0头0道2扇区读入内存。而0头0道2扇区内容是源代码中的/stage2/start.S，编译后512字节，它是stage2或者stage1_5的入口。而此时，stage1是没有识别文件系统的能力的。如果感觉脑子有些晕了，那么下面的过程就直接跳过，去看stage2吧！

【外传】定位硬盘的0头0道2扇区的过程：

BIOS将stage1载入内存0x7c00处并执行，然后调用BIOS INIT13中断，将硬盘0头0道2扇区内容载入内存0x7000处，然后调用copy_buffer将其转移到内存0x8000处。在定位0头0道2扇区时通常有两种寻址方式：LBA和CHS。如果你是刨根问底儿型的爱好者，那么此时去找谷哥打听打听这两种方式的来龙去脉吧。

2)、stage2：严格来说这里还应该再区分个stage1.5的，就一并把stage1.5放在这里一起介绍了，免得大家看得心里乱哄哄的。好的，我们继续说0头0到2扇区的/stage2/start.S文件，当它的内容被读入到内存之后，它的主要作用就是负责将stage2或stage1.5从硬盘读到内存中。如果是stage2，它将被载入到0x820处；如果是stage1.5，它将被载入到0x2200处。这里的stage2或者stage1_5不是/boot分区/boot/grub目录下的文件，因为这个时候grub还没有能力识别任何文件系统。

如果start.S加载stage1.5：stage1.5它存放在硬盘0头0道3扇区向后的位置，stage1_5作为stage1和stage2中间的桥梁，stage1_5有识别文件系统的能力，此后grub才有能力去访问/boot分区/boot/grub目录下的 stage2文件，将stage2载入内存并执行。

如果start.S加载stage2：同样，这个stage2也不是/boot分区/boot/grub目录下的stage2，这个时候start.S读取的是存放在/boot分区Boot Sector的stage2。这种情况下就有一个限制：因为start.S通过BIOS中断方式直接对硬盘寻址（而非通过访问具体的文件系统），其寻址范围有限，限制在8GB以内。因此这种情况需要将/boot分区分在硬盘8GB寻址空间之前。

假如是情形2，我们将/boot/grub目录下的内容清空，依然能成功启动grub；假如是情形1，将/boot/grub目录下stage2删除后，则系统启动过程中grub会启动失败。

启动内核

当stage2被载入内存执行时，它首先会去解析grub的配置文件/boot/grub/grub.conf，然后加载内核镜像到内存中，并将控制权转交给内核。而内核会立即初始化系统中各设备并做相关的配置工作，其中包括CPU、I/O、存储设备等。

关于Linux的设备驱动程序的加载，有一部分驱动程序直接被编译进内核镜像中，另一部分驱动程序则是以模块的形式放在initrd(ramdisk)中。

Linux内核需要适应多种不同的硬件架构，但是将所有的硬件驱动编入内核又是不实际的，而且内核也不可能每新出一种硬件结构，就将该硬件的设备驱动写入内核。实际上Linux的内核镜像仅是包含了基本的硬件驱动，在系统安装过程中会检测系统硬件信息，根据安装信息和系统硬件信息将一部分设备驱动写入 initrd 。这样在以后启动系统时，一部分设备驱动就放在initrd中来加载。这里有必要给大家再多介绍一下initrd这个东东：

initrd 的英文含义是 bootloader initialized RAM disk，就是由 boot loader 初始化的内存盘。在 linu2.6内核启动前，boot loader 会将存储介质中的 initrd 文件加载到内存，内核启动时会在访问真正的根文件系统前先访问该内存中的 initrd 文件系统。在 boot loader 配置了 initrd 的情况下，内核启动被分成了两个阶段，第一阶段先执行 initrd 文件系统中的init，完成加载驱动模块等任务，第二阶段才会执行真正的根文件系统中的 /sbin/init 进程。

另外一个概念：initramfs

initramfs 是在 kernel 2.5中引入的技术，实际上它的含义就是：在内核镜像中附加一个cpio包，这个cpio包中包含了一个小型的文件系统，当内核启动时，内核将这个 cpio包解开，并且将其中包含的文件系统释放到rootfs中，内核中的一部分初始化代码会放到这个文件系统中，作为用户层进程来执行。这样带来的明显的好处是精简了内核的初始化代码，而且使得内核的初始化过程更容易定制。疑惑的是：我的内核是2.6.32-71.el6.i686版本，但在我的/boot分区下面却存在的是/boot/initramfs-2.6.32-71.el6.i686.img类型的文件，没搞明白，还望高人解惑。我只知道在2.6内核中支持两种格式的initrd，一种是2.4内核的文件系统镜像image-initrd，一种是cpio格式。接下来我们就来探究一下initramfs-2.6.32-71.el6.i686.img里到底放了那些东西。

在tmp文件夹中解压initrd.img里的内容：

如果initrd.img文件的格式显示为“initrd.img:ISO 9660 CD-ROM filesystem data”，则可直接输入命令“mount -o loop initrd.img /mnt/test”进行挂载。

通过上的分析和我们的验证，我们确实得到了这样的结论：

grub的stage2将initrd加载到内存里，让后将其中的内容释放到内容中，内核便去执行initrd中的init脚本，这时内核将控制权交给了init文件处理。我们简单浏览一下init脚本的内容，发现它也主要是加载各种存储介质相关的设备驱动程序。当所需的驱动程序加载完后，会创建一个根设备，然后将根文件系统rootfs以只读的方式挂载。这一步结束后，释放未使用的内存，转换到真正的根文件系统上面去，同时运行/sbin/init程序，执行系统的1号进程。此后系统的控制权就全权交给/sbin/init进程了。

初始化系统

经过千辛万苦的跋涉，我们终于接近黎明的曙光了。接下来就是最后一步了：初始化系统。/sbin/init进程是系统其他所有进程的父进程，当它接管了系统的控制权先之后，它首先会去读取/etc/inittab文件来执行相应的脚本进行系统初始化，如设置键盘、字体，装载模块，设置网络等。主要包括以下工作：

1)、执行系统初始化脚本(/etc/rc.d/rc.sysinit)，对系统进行基本的配置，以读写方式挂载根文件系统及其它文件系统，到此系统算是基本运行起来了，后面需要进行运行级别的确定及相应服务的启动。rc.sysinit所做的事情(不同的Linux发行版，该文件可能有些差异)如下：

（1）获取网络环境与主机类型。首先会读取网络环境设置文件"/etc/sysconfig/network"，获取主机名称与默认网关等网络环境。

（2）测试与载入内存设备/proc及usb设备/sys。除了/proc外，系统会主动检测是否有usb设备，并主动加载usb驱动，尝试载入usb文件系统。

（3）决定是否启动SELinux。

（4）接口设备的检测与即插即用（pnp）参数的测试。

（5）用户自定义模块的加载。用户可以再"/etc/sysconfig/modules/*.modules"加入自定义的模块，此时会加载到系统中。

（6）加载核心的相关设置。按"/etc/sysctl.conf"这个文件的设置值配置功能。

（7）设置系统时间（clock）。

（8）设置终端的控制台的字形。

（9）设置raid及LVM等硬盘功能。

（10）以方式查看检验磁盘文件系统。

（11）进行磁盘配额quota的转换。

（12）重新以读取模式载入系统磁盘。

（13）启动quota功能。

（14）启动系统随机数设备（产生随机数功能）。

（15）清楚启动过程中的临时文件。

（16）将启动信息加载到"/var/log/dmesg"文件中。

当/etc/rc.d/rc.sysinit执行完后，系统就可以顺利工作了，只是还需要启动系统所需要的各种服务，这样主机才可以提供相关的网络和主机功能，因此便会执行下面的脚本。

2)、执行/etc/rc.d/rc脚本。该文件定义了服务启动的顺序是先K后S，而具体的每个运行级别的服务状态是放在/etc/rc.d/rc.d（=0~6）目录下，所有的文件均是指向/etc/init.d下相应文件的符号链接。rc.sysinit通过分析/etc/inittab文件来确定系统的启动级别，然后才去执行/etc/rc.d/rc*.d下的文件。

/etc/init.d-> /etc/rc.d/init.d

/etc/rc ->/etc/rc.d/rc

/etc/rc.d ->/etc/rc.d/rc.d

/etc/rc.local-> /etc/rc.d/rc.local

/etc/rc.sysinit-> /etc/rc.d/rc.sysinit

也就是说，/etc目录下的init.d、rc、rc*.d、rc.local和rc.sysinit均是指向/etc/rc.d目录下相应文件和文件夹的符号链接。我们以启动级别3为例来简要说明一下。

/etc/rc.d/rc3.d目录，该目录下的内容全部都是以 S 或 K 开头的链接文件，都链接到"/etc/rc.d/init.d"目录下的各种shell脚本。S表示的是启动时需要start的服务内容，K表示关机时需要关闭的服务内容。/etc/rc.d/rc.d中的系统服务会在系统后台启动，如果要对某个运行级别中的服务进行更具体的定制，通过chkconfig命令来操作，或者通过setup、ntsys、system-config-services来进行定制。如果我们需要自己增加启动的内容，可以在init.d目录中增加相关的shell脚本，然后在rc.d目录中建立链接文件指向该shell脚本。这些shell脚本的启动或结束顺序是由S或K字母后面的数字决定，数字越小的脚本越先执行。例如，/etc/rc.d/rc3.d /S01sysstat就比/etc/rc.d/rc3.d /S99local先执行。

3)、执行用户自定义引导程序/etc/rc.d/rc.local。其实当执行/etc/rc.d/rc3.d/S99local时，它就是在执行/etc/rc.d/rc.local。S99local是指向rc.local的符号链接。就是一般来说，自定义的程序不需要执行上面所说的繁琐的建立shell增加链接文件的步骤，只需要将命令放在rc.local里面就可以了，这个shell脚本就是保留给用户自定义启动内容的。

4)、完成了系统所有的启动任务后，linux会启动终端或X-Window来等待用户登录。tty1,tty2,tty3…这表示在运行等级1，2，3，4的时候，都会执行"/sbin/mingetty"，而且执行了6个，所以linux会有6个纯文本终端，mingetty就是启动终端的命令。

除了这6个之外还会执行"/etc/X11/prefdm-nodaemon"这个主要启动X-Window

至此，系统就启动完毕了。以上分析不到的地方还请各位大虾不吝指正。

关于Linux的其他分析内容下次再继续写。最后附上一张非常完整的系统启动流程图，适合各个水平阶段的读者。

http://blog.itpub.net/8111049/viewspace-680043

http://bbs.chinaunix.net/thread-2046548-1-1.html

http://blog.chinaunix.net/uid-26495963-id-3066282.html

linux 实时时钟（RTC）驱动

2016-01-12 15:53:00

Documentation/rtc.txt

http://blog.csdn.net/yaozhenguo2006/article/details/6820218

这个是linux内核文档关于rtc实时时钟部分的说明，此文档主要描述了rtc实时时钟的作用和编程接口，分别介绍了老的rtc接口和新的rtc类架构。并给出了一个测试rtc驱动的程序。

linux 实时时钟（RTC）驱动

翻译：窗外云天yaozhenguo2006@126.com 最后矫正时间：2011.9.25

当linux开发者提到“实时时钟”的时候，他们通常所指的就是墙钟时间，这个时间是电池供电的，所以在系统掉电的情况下还能正常工作。除非在MS-Windows启动的时候设置，否则这个时钟不会同步于本地时区和夏令时间。事实上，他被设置成格林威治时间。

最新的非pc体系的硬件趋向于记秒数，比如time(2)系统调用的输出，但是实时时钟用公历和24小时表示日期与时间，比如gmtime(3)的输出。

linux提供两类的rtc兼容性很高的用户空间系统调用接口，如下所示：
（1） /dev/rtc … 这个RTC适合pc体系的系统，而并不适合非x86体系的系统
（2） /dev/rtc0,/dev/rtc1 … 他们依赖一种架构，这种架构在所有的系统上被RTC芯片广泛的支持。

程序员必须知道，PC/AT的功能不总是有效，其他的系统可能会有另外的实现。这种情况下，如果在相同的系统结构上使用同样的RTC API，那么硬件会有不同的反应。例如，不是每一个RTC都提供IRQ，所以这些不能处理报警中断；标准的PC系统RTC只能处理未来24小时以内的闹钟，而其他系统的RTC可能处理未来一个世纪的任何时间。

老的PC/AT驱动：/dev/rtc

所有基于PC的系统（甚至Alpha体系的机器）都有一个集成的实时时钟。通常他们集成在计算机的芯片组内，但是也有一些系统是在主板上焊接着摩托罗拉MC146818（或者类似的芯片），他们给系统提供时间和日期，这个时间和日期在系统掉电后仍然会保存。

ACPT(高级配置与电源管理接口)对MC146818的功能进行了标准化，并且在一些方面进行了功能扩展（提供了更长的定时周期，睡眠唤醒功能）。然而这些扩展的功能不适合老的驱动程序。

这个RTC还可以产生频率从 2HZ 到 8192HZ 的信号，以2的乘方增长。这些信号通过中断信号线8报告给系统。这个RTC还可以用作定时限制为24小时的闹钟，当定时时间到时产生8号中断。这个闹钟可以设置成任意一个可编程值的子集，这意味着可以设置成任意小时的任意分钟任意秒，例如，可以将这个时钟设置成在每个clk产生中断，从而产生1hz的信号。

这些中断通过/dev/rtc报告给系统（主设备号10,次设备号135，只读字符设备），中断传回一个无符号整数类型的数据。最低的位包含中断的类型（更新，闹钟，或者期），其他的字节代表了最后一次读到现在中断发生的次数。状态信息由虚拟文件/proc/driver/rtc产生，前提条件是使能了/proc文件系统。驱动应该提供锁机制，保证在同一时刻只有一个进程访问/dev/rtc。

用户进程通过系统调用read(2)或者select(2)读取/dev/rtc来获取这些中断。当调用这两个系统调用的时候，进程会阻塞或者退出直到下一个中断到来。这个功能用在需要不频繁的获取数据而又不希望通过轮询当前时间而占用CPU时间的情况下。

在高频率中断或者高系统负载下，用户进程应该检查从上次读取到现在发生中断的次数以判断是否有未处理的中断。例如，一个典型的 486-33 对/dev/rtc以大于1024hz的频率进行循环读，偶尔会产生中断积累（从上次读取到现在发生大于一次的中断）。鉴于此你应该检查读取数据的高字节，特别是在频率高于普通定时器中断–100hz的情况下。

中断频率是可编程的或可以让他超过64hz，但是只有root权限的用户可以这样做。这样做可能有点保守，但是我们不希望有恶意的用户在一个较慢的386sx-16机器上产生很多中断，这样会严重影响系统的性能。我们可以通过向/proc/sys/dev/rtc/max-user-freq写入值来修改这个64hz的限制。但是注意你一定要这样做，减少中断处理程序的代码才会亡羊补牢，使对系统性能的影响降到最小。

如果内核时间是和外部时钟源同步的，那么内核将每隔11分钟就会将时间写回CMOS时钟。在这个过程中，内核会关闭rtc周期中断，如果你的程序在做一些关键的工作一定要注意到。如果你的内核不和外部时钟源同步，那么内核会一直处理rtc中断，处理方式根据你具体的应用。

闹钟和中断频率可以通过系统调用ioctl(2)来设置，ioctl的命令定义在./include/linux/rtc.h。与其长篇大论的介绍怎么样使用这个系统调用，还不如写一个实例程序来的方便，这个程序用来演示驱动的功能，对很多人来说用驱动程序提供的功能来进行应用编程他们会更感兴趣。在这个文档的最后有这段程序。

新接口 “RTC类” 驱动：/dev/rtcn

因为linux支持许多非ACPI非PC平台，其中一些平台有不只一个RTC，所以需要更多可移植性的设计，而不是仅仅在每个系统都实现类似MC146818的接口。在这种情况下，新的“RTC类”构架产生了。他提供不同的用户空间接口：（1） /dev/rtcn 和老的接口一样（2）/dev/class/rtc/rtcn sysfs 属性，一些属性是只读的（3） /dev/driver/rtc 第一个rtc会使用procfs接口。更多的信息会显示在这里而不是sysfs。

RTC类构架支持很多类型的RTC，从集成在嵌入式SOC处理器内的RTC到通过I2C，SPI和其他总线连接到CPU的芯片。这个架构甚至还支持PC系统的RTC，包括使用ACPI，PC的一些新特性。

新架构也打破了“每个系统只有一个RTC”的限制。例如，一个低功耗电池供电的RTC是一个分离的I2C接口的芯片，但是系统可能还集成了一个多功能的RTC。系统可能从分离的RTC读取系统时钟，但是对于其他任务用集成的RTC，因为这个RTC提供更多的功能。

SYSFS 接口

在/sys/class/rtc/rtcn下面的sysfs接口提供了操作rtc属性的方法，而不用通过Ioclt系统调用。所有的日期时间都是墙钟时间，而不是系统时间。

date:           RTC提供的日期
hctosys:        如果在内核配置选项中配置了CONFIG_RTC_HCTOSYS，RTC会在系统启动的时候提供系统时间，这种情况下这个位就是1,否则为0
max_user_freq:  非特权用户可以从RTC得到的最大中断频率
name:           RTC的名字，与sysfs目录相关
since_epoch:    从纪元开始所经历的秒数
time:           RTC提供的时间
wakealarm:      唤醒时间的时间事件。 这是一种单次的唤醒事件，所以如果还需要唤醒，在唤醒发生后必须复位。这个域的数据结构或者是从纪元开始经历的妙数，或者是相对的秒数

IOCTL 接口

/dev/rtc支持的Ioctl系统调用，RTC类构架也支持。然而，因为芯片和系统没有一个统一的标准，一些PC/AT功能可能没有提供。以相同方式工作的一些新特性，–包括ACPI提供的，–在RTC类构架中表现出的，在老的驱动上不会工作。

（1） RTC_RD_TIME,RTC_SET_TIME .. 每一个RTC都至少支持读时间这个命令，时间格式为公历和24小时制墙钟时间。最有用的特性是，这个时间可以更新。
（2） RTC_ATE_ON,RTC_ATE_OFF,RTC_ALM_SET,RTC_ALM_READ … 当RTC连接了一条IRQ线，他还能处理在未来24小时的报警中断。
（3） RTC_WKALM_SET，RTC_WKALM_RD 。。。 RTCs 使用一个功能更强大的api,他可以处理超过24小时的报警时间。这个API支持设置更长的报警时间，支持单次请求的IRQ中断。
（4） RTC_UIE_ON,RTC_UIE_OFF … 如果RTC提供IRQ，他可能也提供每秒更新的IRQ中断。如果需要，RTC结构可以模仿这个机制。

（5） RTC_PIE_ON,RTC_PIE_OFF,RTC_IRQP_SET,RTC_IRQP_READ … 如果一个IRQ是周期中断，那么这个IRQ还有可设置频率的特性（频率通常是2的n次方）

很多情况下，RTC报警时钟通常是一个系统唤醒事件，用于将Linux从低功耗睡眠模式唤醒到正常的工作模式。例如，系统会处于低功耗的模式下，直到时间到了去执行一些任务。注意这些ioctl的一些功能不必在你的驱动程序中实现。如果一个ioctl调用，你的驱动返回ENOIOCTLCMD，那么这个Ioctl就由通用RTC设备接口处理。下面是一些通用的例子：
（6） RTC_RD_TIME, RTC_SET_TIME: read_time/set_time 函数会被调用。
（7） RTC_ALM_SET, RTC_ALM_READ, RTC_WKALM_SET, RTC_WKALM_RD: set_alarm/read_alarm 函数将会被调用.
（8） RTC_IRQP_SET, RTC_IRQP_READ: irq_set_freq 函数将会调用，用来设置频率，RTC类构架会处理读请求，而频率保存在RTC设备结构中的irq_freq域。你的驱动需要在模块初始化的时候初始化irq_freq，你必须在irq_set_freq函数里检查设置的频率是否在硬件允许的范围。如果不是那么驱动应该返回-EINVAL。如果你不需要改变这个频率，那么不要定义irq_set_freq这个函数。
（7） RTC_PIE_ON, RTC_PIE_OFF: irq_set_state 函数会被调用。

如果所有的ioctl都失败了，用下面的rtc-test.c检查一下你的驱动吧！

/*
 *      Real Time Clock Driver Test/Example Program
 *
 *      Compile with:
 *             gcc -s -Wall -Wstrict-prototypes rtctest.c -o rtctest
 *
 *      Copyright (C) 1996, Paul Gortmaker.
 *
 *      Released under the GNU General Public License, version 2,
 *      included herein by reference.
 *
 */

#include <stdio.h>
#include <linux/rtc.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <errno.h>


/*
 * This expects the new RTC class driver framework, working with
 * clocks that will often not be clones of what the PC-AT had.
 * Use the command line to specify another RTC if you need one.
 */
static const char default_rtc[] = "/dev/rtc0";


int main(int argc, char **argv)
{
	int i, fd, retval, irqcount = 0;
	unsigned long tmp, data;
	struct rtc_time rtc_tm;
	const char *rtc = default_rtc;

	switch (argc) {
	case 2:
		rtc = argv[1];
		/* FALLTHROUGH */
	case 1:
		break;
	default:
		fprintf(stderr, "usage:  rtctest [rtcdev]\n");
		return 1;
	}

	fd = open(rtc, O_RDONLY);

	if (fd ==  -1) {
		perror(rtc);
		exit(errno);
	}

	fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n");

	/* Turn on update interrupts (one per second) */
	retval = ioctl(fd, RTC_UIE_ON, 0);
	if (retval == -1) {
		if (errno == ENOTTY) {
			fprintf(stderr,
				"\n...Update IRQs not supported.\n");
			goto test_READ;
		}
		perror("RTC_UIE_ON ioctl");
		exit(errno);
	}

	fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading %s:",
			rtc);
	fflush(stderr);
	for (i=1; i<6; i++) {
		/* This read will block */
		retval = read(fd, &data, sizeof(unsigned long));
		if (retval == -1) {
			perror("read");
			exit(errno);
		}
		fprintf(stderr, " %d",i);
		fflush(stderr);
		irqcount++;
	}

	fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:");
	fflush(stderr);
	for (i=1; i<6; i++) {
		struct timeval tv = {5, 0};     /* 5 second timeout on select */
		fd_set readfds;

		FD_ZERO(&readfds);
		FD_SET(fd, &readfds);
		/* The select will wait until an RTC interrupt happens. */
		retval = select(fd+1, &readfds, NULL, NULL, &tv);
		if (retval == -1) {
			    perror("select");
			    exit(errno);
		}
		/* This read won't block unlike the select-less case above. */
		retval = read(fd, &data, sizeof(unsigned long));
		if (retval == -1) {
			    perror("read");
			    exit(errno);
		}
		fprintf(stderr, " %d",i);
		fflush(stderr);
		irqcount++;
	}

	/* Turn off update interrupts */
	retval = ioctl(fd, RTC_UIE_OFF, 0);
	if (retval == -1) {
		perror("RTC_UIE_OFF ioctl");
		exit(errno);
	}

test_READ:
	/* Read the RTC time/date */
	retval = ioctl(fd, RTC_RD_TIME, &rtc_tm);
	if (retval == -1) {
		perror("RTC_RD_TIME ioctl");
		exit(errno);
	}

	fprintf(stderr, "\n\nCurrent RTC date/time is %d-%d-%d, %02d:%02d:%02d.\n",
		rtc_tm.tm_mday, rtc_tm.tm_mon + 1, rtc_tm.tm_year + 1900,
		rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);

	/* Set the alarm to 5 sec in the future, and check for rollover */
	rtc_tm.tm_sec += 5;
	if (rtc_tm.tm_sec >= 60) {
		rtc_tm.tm_sec %= 60;
		rtc_tm.tm_min++;
	}
	if (rtc_tm.tm_min == 60) {
		rtc_tm.tm_min = 0;
		rtc_tm.tm_hour++;
	}
	if (rtc_tm.tm_hour == 24)
		rtc_tm.tm_hour = 0;

	retval = ioctl(fd, RTC_ALM_SET, &rtc_tm);
	if (retval == -1) {
		if (errno == ENOTTY) {
			fprintf(stderr,
				"\n...Alarm IRQs not supported.\n");
			goto test_PIE;
		}
		perror("RTC_ALM_SET ioctl");
		exit(errno);
	}

	/* Read the current alarm settings */
	retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
	if (retval == -1) {
		perror("RTC_ALM_READ ioctl");
		exit(errno);
	}

	fprintf(stderr, "Alarm time now set to %02d:%02d:%02d.\n",
		rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);

	/* Enable alarm interrupts */
	retval = ioctl(fd, RTC_AIE_ON, 0);
	if (retval == -1) {
		perror("RTC_AIE_ON ioctl");
		exit(errno);
	}

	fprintf(stderr, "Waiting 5 seconds for alarm...");
	fflush(stderr);
	/* This blocks until the alarm ring causes an interrupt */
	retval = read(fd, &data, sizeof(unsigned long));
	if (retval == -1) {
		perror("read");
		exit(errno);
	}
	irqcount++;
	fprintf(stderr, " okay. Alarm rang.\n");

	/* Disable alarm interrupts */
	retval = ioctl(fd, RTC_AIE_OFF, 0);
	if (retval == -1) {
		perror("RTC_AIE_OFF ioctl");
		exit(errno);
	}

test_PIE:
	/* Read periodic IRQ rate */
	retval = ioctl(fd, RTC_IRQP_READ, &tmp);
	if (retval == -1) {
		/* not all RTCs support periodic IRQs */
		if (errno == ENOTTY) {
			fprintf(stderr, "\nNo periodic IRQ support\n");
			goto done;
		}
		perror("RTC_IRQP_READ ioctl");
		exit(errno);
	}
	fprintf(stderr, "\nPeriodic IRQ rate is %ldHz.\n", tmp);

	fprintf(stderr, "Counting 20 interrupts at:");
	fflush(stderr);

	/* The frequencies 128Hz, 256Hz, ... 8192Hz are only allowed for root. */
	for (tmp=2; tmp<=64; tmp*=2) {

		retval = ioctl(fd, RTC_IRQP_SET, tmp);
		if (retval == -1) {
			/* not all RTCs can change their periodic IRQ rate */
			if (errno == ENOTTY) {
				fprintf(stderr,
					"\n...Periodic IRQ rate is fixed\n");
				goto done;
			}
			perror("RTC_IRQP_SET ioctl");
			exit(errno);
		}

		fprintf(stderr, "\n%ldHz:\t", tmp);
		fflush(stderr);

		/* Enable periodic interrupts */
		retval = ioctl(fd, RTC_PIE_ON, 0);
		if (retval == -1) {
			perror("RTC_PIE_ON ioctl");
			exit(errno);
		}

		for (i=1; i<21; i++) {
			/* This blocks */
			retval = read(fd, &data, sizeof(unsigned long));
			if (retval == -1) {
				perror("read");
				exit(errno);
			}
			fprintf(stderr, " %d",i);
			fflush(stderr);
			irqcount++;
		}

		/* Disable periodic interrupts */
		retval = ioctl(fd, RTC_PIE_OFF, 0);
		if (retval == -1) {
			perror("RTC_PIE_OFF ioctl");
			exit(errno);
		}
	}

done:
	fprintf(stderr, "\n\n\t\t\t *** Test complete ***\n");

	close(fd);

	return 0;
}

kdump时间错误

2016-01-12 15:39:00

CentOS 5.x安装新内核之后时钟混乱问题

解决kdump的vmcore保存的目录的时间错误问题

diff --git a/mkdumprd b/mkdumprd
index d567085..7d946f4 100755
--- a/mkdumprd
+++ b/mkdumprd
@@ -2279,12 +2279,19 @@ mknod /dev/systty c 4 0
 mknod /dev/tty c 5 0
 mknod /dev/console c 5 1
 mknod /dev/ptmx c 5 2
-mknod /dev/rtc c 10 135
 mknod /dev/urandom c 1 9
 mknod /dev/efirtc c 10 136
 export network_up=0
 EOF
 
+kernelval=`echo $kernel | awk -F "[-|.]" '{print $1*65536+$2*256+$3}'`
+#echo "kernel=$kernel kernelval=$kernelval"
+if [ $kernelval -lt 132640 ]; then
+ emit "mknod /dev/rtc c 10 135"
+else
+ emit "mknod /dev/rtc c 254 0"
+fi
+
 # XXX really we need to openvt too, in case someting changes the
 # color palette and then changes vts on fbcon before gettys start.
 # (yay, fbcon bugs!)

← Older Blog Archives Newer →