kk Blog —— 通用基础

date [-d @int|str] [+%s|"+%F %T"]

Linux系统启动过程分析

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)驱动

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系统调用。所有的日期时间都是墙钟时间,而不是系统时间。

1
2
3
4
5
6
7
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检查一下你的驱动吧!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
/*
 *      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时间错误

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
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!)

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

1
2
$ ll /etc/rc.sysinit
/etc/rc.sysinit -> rc.d/rc.sysinit

el5在调用mkinitrd命令时,会将/dev/rtc生成好,放到initrd- x.x.x.img文件中。而el6的系统在 /etc/rc.sysinit的/sbin/start_udev 之前是有这两个文件,也没找到el6的系统是在哪里加的这两句。

el5可选的一个做法是:修改/etc/rc.sysinit,在/sbin/start_udev这行之前加入两行:

1
2
mv /dev/rtc /dev/rtc0
ln -sf rtc0 /dev/rtc

在/sbin/start_udev这行之后加入一行

1
[ -x /sbin/hwclock ] && /sbin/hwclock $CLOCKFLAGS

这样el5系统用18、32内核都没问题了。

el5试着将这两句改在/sbin/mkinitrd里修改,但不知道为什么改完后在执行到 /etc/rc.sysinit 时 /dev/rtc 这个软连接不见了。

或者直接将/dev/rtc改成254,0

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
diff --git a/mkinitrd b/mkinitrd
index 5ddb909..dcba61d 100755
--- a/mkinitrd
+++ b/mkinitrd
@@ -1708,7 +1708,14 @@ done
 mknod $MNTIMAGE/dev/tty c 5 0
 mknod $MNTIMAGE/dev/console c 5 1
 mknod $MNTIMAGE/dev/ptmx c 5 2
-mknod $MNTIMAGE/dev/rtc c 10 135
+
+kernelval=`echo $kernel | awk -F "[-|.]" '{print $1*65536+$2*256+$3}'`
+#echo "kernel=$kernel kernelval=$kernelval"
+if [ $kernelval -lt 132640 ]; then
+ mknod $MNTIMAGE/dev/rtc c 10 135
+else
+ mknod $MNTIMAGE/dev/rtc c 254 0
+fi
 
 if [ "$(uname -m)" == "ia64" ]; then
	 mknod $MNTIMAGE/dev/efirtc c 10 136
@@ -1911,8 +1918,16 @@ 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
 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
+
 if [ "$(uname -m)" == "ia64" ]; then
	 emit "mknod /dev/efirtc c 10 136"
 fi

然后重建img

1
/sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install 2.6.32-XXX

http://www.csdn123.com/html/mycsdn20140110/59/59dd8c5f069a09bf9dc1785e19eb329f.html

CentOS在安装完新内核之后,每次重启之后时钟总是会发生一些变化,使得系统时钟不准确。在多操作系统的情况下(例如windows和 linux双系统),还可能会出现时区的偏差,而且无论如何设置,在重启之后都会恢复原样。如何解决这个问题还得从操作系统的时钟原理开始。

1. 操作系统中的时钟

操作系统为实现其功能,必须知道当前外部世界的时间(年月日时分秒等)。为实现这一目的,计算机设计者在主板上设置了一个硬件时钟,由主板上的一块纽扣电池(Cell)供电,这个硬件时钟无论计算机电源是否接通都会不停的数秒,来计算当前时间。

操作系统在启动的时候,会调用一段程序来读取主板上的硬件时钟,并记录在操作系统的一个(或一组)变量中。自此之后,操作系统的时钟便脱离主板的硬件时钟,开始单独运行(操作系统时钟的运行是由时钟中断来驱动的,不同于主板上的时钟)。

无论做工多么精细,主板硬件时钟和由时钟中断维护的操作系统内的时钟多多少少会有一些误差。所以,操作系统在每次关闭的时候会调用另一段程序,将操作系统 内的时钟写到主板硬件时钟里(这样设计是不是说明时钟中断比主板硬件时钟更准确一些呢?)。类似的,当用户在操作系统内修改时钟之后,也不会立即写入主板 时钟,而是在关机的时候写入硬件时钟。

2. 旧汤和新药的冲突

主板上的硬件时钟在Linux操作系统中呈现为一个设备,设备名称为rtc(Real Time Clock)。

使用旧的系统(如CentOS的2.6.18内核)编译新内核时,在调用mkinitrd命令时,会将/dev/rtc生成好,放到initrd- x.x.x.img文件中;而新的内核是自己生成/dev/rtc文件的,当kernel生成/dev/rtc时,发现系统内已经有了这个设备,于是就会 创建/dev/rtc0设备。这时hwclock程序仍然会读取rtc设备,就会造成设备读写失败。运行hwclock --debug命令可以看到如下输出:

1
2
3
4
5
[root@localhost ~]# hwclock --debug
hwclock from util-linux-2.13-pre7
hwclock: Open of /dev/rtc failed, errno=19: No such device.
No usable clock interface found.
Cannot access the Hardware Clock via any known method.

但是有的能够直接读写I/O,这样虽然/dev/rtc是错的,但还能正常运行

1
2
3
4
5
[root@localhost ~]# hwclock --debug
hwclock from util-linux-2.13-pre7
hwclock: Open of /dev/rtc failed, errno=19: No such device.
Using direct I/O instructions to ISA clock.
.....

其实,对应这个问题,新版的hwclock已经做出了调整。新的hwclock会主动去寻找/dev/rtc0设备,来操作主板硬件时钟。于是,解决方法就出现了。

3. 新汤配新药

既然内核这剂药已经换成了新的,那我们就把外围应用程序hwclock也换成新的。

从这里可以下载比较新的(不用最新的是因为最新的源码在旧版的CentOS上编译会出现错误)程序源码:http://now-code.com/download/util-linux-ng-2.17.tar.bz2

如果需要更多版本的程序源码,请到这里下载:ftp://ftp.kernel.org/pub/linux/utils/%E3%80%82

下载完成之后,编译该程序:

1
2
3
4
tar xfv util-linux-ng-2.17.tar.bz2
cd util-linux-ng-2.17
./configure
make

编译完成之后,将生成的hwclock文件拷贝到指定位置即可:

1
cp hwclock/hwclock /sbin/

之后,操作系统和主板的硬件时钟就可以同步起来了。

linux系统时间和硬件时钟问题(date和hwclock)

http://rpf413.blog.163.com/blog/static/4556376020122831444674/

总结一下hwclock,这个容易晕:

1)/etc/sysconfig/clock 文件,只对 hwclock 命令有效,且只在系统启动和关闭的时候才有用(修改了其中的 UTC=true 到 UTC=false 的前后,执行 hwclock (--utc, 或 --localtime) 都没有变化,要重启系统后才生效);

2)/etc/rc.d/rc.sysinit 文件,run once at boot time,其中有从硬件时钟同步时间到系统时间的操作;

3)hwclock --localtime 的输出,才是硬件时钟真正的时间。如果输出结果带时区(比如CST),还要看/etc/sysconfig/clock里的UTC参数,如果 UTC=false,那时区有意义;如果 UTC=true,那时区没意义,实际上是UTC时间。

4)在 /etc/sysconfig/clock 中 UTC=false 时,date、hwclock、hwclcok --localtime 输出的时间应该都一致,且此时 hwclock --utc是没有意义的;

5)在 /etc/sysconfig/clock 中 UTC=ture 时,date、hwclock 的输出是一致的,hwclock --localtime 的输出则是UTC时间;

6)如果不想在输出中带时区,则 export LANG=C ,然后再运行 hwclock 就没有什么CST了,免得时区误导你;

7)hwclock --utc 很闹腾,还是别看了,你会晕的。。。

8)系统关闭时会同步系统时间到硬件时钟,系统启动时会从硬件时钟读取时间更新到系统,这2个步骤都要根据 /etc/sysconfig/clock 文件中UTC的参数来设置时区转换。

实际案例分析

修改了 /etc/sysconfig/clock 中UTC参数但系统未正常关闭的情况

修改 /etc/sysconfig/clock 文件后,如果系统内核突然崩溃,然后直接按电源重启,则系统没有进行 系统时间到硬件时钟的 同步;但是 系统启动时,又根据 /etc/sysconfig/clock 中UTC的参数,来同步硬件时钟到系统,这时就会出现时间问题:

0)假设系统的时区为CST(UTC+8);
1)假设原 /etc/sysconfig/clock 中 UTC=true,修改成 UTC=false;
2)如果此时系统未正常关机,系统时间未按参数 UTC=false 同步时间到硬件时钟(没有+8小时);
3)但系统被按电源重启后,系统读取到 UTC=false,认为硬件时钟为CST时间,直接用于系统时间;
4)那么此时,系统时间将少了8小时。


http://hi.baidu.com/lujunqianglw/blog/item/bc2d9144d24fc48fb3b7dc1d.html

一、首先要弄清几个概念:

1. “系统时间”与“硬件时间”

系统时间: 一般说来就是我们执行 date 命令看到的时间,linux系统下所有的时间调用(除了直接访问硬件时间的命令)都是使用的这个时间。

硬件时间: 主板上BIOS中的时间,由主板电池供电来维持运行,系统开机时要读取这个时间,并根据它来设定系统时间(注意:系统启动时根据硬件时间设定系统时间的过程可能存在时区换算,这要视具体的系统及相关设置而定)。

2. “UTC时间”与“本地时间”

UTC时间:Coordinated Universal 8 e2 i( H7 t0 ^/ ^Time 世界协调时间(又称世界标准时间、世界统一时间),在一般精度要求下,它与GMT(Greenwich Mean Time,格林威治标准时间)是一样的,其实也就是说 GMT≈UTC,但 UTC 是以原子钟校准的,更精确。

本地时间:由于处在不同的时区,本地时间一般与UTC是不同的,换算方法就是

本地时间 = UTC + 时区 或 UTC = 本地时间 - 时区

时区东为正,西为负,例如在中国,本地时间都使用北京时间,在linux上显示就是 CST(China Standard Time,中国标准时,注意美国的中部标准时Central Standard Time也缩写为CST,与这里的CST不是一回事!),时区为东八区,也就是 +8 区,所以 CST=UTC+(+8小时) 或 UTC=CST-(+8小时)。

二、时间命令

1. 系统时间 date

直接调用 date,得到的是本地时间。如果想得到UTC时间的话,使用 date -u。

1
2
3
4
[12-01 19:07> ~]$ date
2009年 12月 07日 星期一 14:22:20 CST
[12-01 19:07> ~]$ date -u
2009年 12月 07日 星期一 06:22:22 UTC
2. 硬件时间 /sbin/hwclock

直接调用 /sbin/hwclock 显示的时间就是 BIOS 中的时间吗?未必!这要看 /etc/sysconfig/clock 中是否启用了UTC,如果启用了UTC(UTC=true),显示的其实是经过时区换算的时间而不是BIOS中真正的时间,如果加上 –localtime 选项,则得到的总是 BIOS 中实际的时间.

1
2
3
4
5
6
[12-01 19:07> ~]# hwclock
2009年12月07日 星期一 14时28分43秒 -0.611463 seconds
[12-01 19:07> ~]# hwclock --utc
2009年12月07日 星期一 14时28分46秒 -0.594189 seconds
[12-01 19:07> ~]# hwclock --localtime
2009年12月07日 星期一 06时28分50秒 -0.063875 seconds
3. /etc/localtime

这个文件用来设置系统的时区,将 /usr/share/zoneinfo/ 中相应文件拷贝到/etc下并重命名为 localtime 即可修改时区设置,而且这种修改对 date 命令是及时生效的。不论是 date 还是 hwclock 都会用到这个文件,会根据这个文件的时区设置来进行UTC和本地之间之间的换算。

4. /etc/sysconfig/clock

这个文件只对 hwclock 有效,而且似乎是只在系统启动和关闭的时候才有用,比如修改了其中的 UTC=true 到 UTC=false 的前后,执行 hwclock (--utc, 或 --localtime) 都没有变化,要重启系统后才生效。注:如果设置 UTC=false 并重启系统后,执行一些命令结果如下:

1
2
3
4
5
date 2009年 12月 07日 星期一 19:26:29 CST
date -u 2009年 12月 07日 星期一 11:26:29 UTC
hwclock 2009年12月07日 星期一 19时26分30秒 -0.442668 seconds
hwclock --utc 2009年12月08日 星期二 03时26分31秒 -0.999091 seconds
hwclock --localtime 2009年12月07日 星期一 19时26分32秒 -0.999217 seconds

可见,如果不使用UTC,BIOS时间(红色部分)就是系统本地时间,而且注意这时执行 hwclock --utc 得到的结果没有任何意义,因为这里我们已经禁用了UTC,而且也明显不符合“本地时间=UTC+时区”的关系。

三、linux与windows双系统间的时间同步

系统启动和关闭时,硬件时间与系统时间之间的同步有两种方式(假设在中国,用CST代表本地时间):

方式A: 使用UTC(对linux就是 /etc/sysconfig/clock 中 UTC=true)

开机: BIOS——->UTC(将BIOS中的时间看成是UTC)——(时区变化)—–>CST
关机: CST ——-(时区变化)—–>UTC——-存储到——>BIOS

方式B: 不使用UTC(对linux就是 /etc/sysconfig/clock 中 UTC=false)

开机: BIOS———————>CST(将BIOS中的时间看成是CST)
关机: CST ———存储到——>BIOS


FIX:

方式A: 使用UTC(对linux就是 /etc/sysconfig/clock 中 UTC=true)

关机: CST ——-操作系统根据时区算出UTC时间——-存储到——>BIOS
开机: BIOS——->BIOS中的时间是UTC———–操作系统根据时区计算出localtime———-CST

方式B: 不使用UTC(对linux就是 /etc/sysconfig/clock 中 UTC=false)

关机: CST ——–操作系统中UTC=false,直接将localtime存储到——>BIOS
开机: BIOS——–BIOS中的时间是localtime—–操作系统中UTC=false,BIOS时间当成localtime——–>CST(将BIOS中的时间看成是CST)


通过设定 /etc/sysconfig/clock,linux可以支持这两种方式,然而windows只支持方式B(至少是默认支持B,而我不知道怎么能让它支 持A),那么在双系统情况下,如果linux设成A方式,那么在linux与windows系统切换时一定会造成时间混乱的,解决办法就是将linux中 的UTC禁用,也设成B方式就可以了。

注:可以通过 hwclock --hctosys 来利用硬件时间来设置系统时间(注意不是简单的复制BIOS中的时间为系统时间,要看是否使用UTC,如果使用的话则要做时区换算),通过 hwclock --systohc 来根据系统时间设置硬件时间(也要看是否启用UTC来决定是否做时区换算)。

总之,不论使用 --systohc 还是 --hctosys,同步后直接运行不带参数的 hwclock 得到的时间与直接运行 date 得到的时间应该一致,这个时间是否就是BIOS中的时间(hwclock --localtime)那就不一定了,如果启用了UTC就不是,没启用UTC就是。

而且还要注意:在系统中手动使用 hwclock hwclock --set --date='yyyy-mm-dd' 来设置BIOS时间只在系统运行时有效,因为当系统关闭时,还会按设定好的方式根据系统时间来重设BIOS时间的,于是手动的设置便被覆盖掉了。