Specific instructions Reference Documentation/fault-injection/fault-injection.txt documentation
I used fail_mmc_request when I was debugging MMC drivers, and I was able to control the generation of Data.error
Kernel configuration is Config_fail_mmc_request
Kernel Hacking --->
[*] fault-injection framework
[*] fault-injection capability for MMC IO
[* ] Debugfs entries for fault-injection capabilities
So the Fail_mmc_request directory will appear below the/SYS/KERNEL/DEBUG/MMC0 directory, into this directory
/sys/kernel/debug/mmc0/fail_mmc_request # ls
interval probability space task-filter times verbose
Parameter description:
Probability: The probability of an error, if the value is 100, indicates that 100% will occur
Times: Limit the number of occurrences of an error, and his value will be reduced by one after each error occurs. A value of-1 indicates an unlimited number of errors.
/sys/kernel/debug/mmc0/fail_mmc_request # echo 1 > Times/sys/kernel/debug/mmc0/fail_mmc_request # echo > Proba Bility/sys/kernel/debug/mmc0/fail_mmc_request # veridisk-f/dev/mmcblk0-e 1-m 1-v-D offset [0, 1), Len [1, 2], seq Pfault_injection:forcing a failure Attern 0x00 offset 0, Len 1, secpu:0 pid:247-comm:mmcqd/0 not tainted 3.10.27+ #114 Q pattern 0x01 stack:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000 0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000-00 000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000-00000
00000000 00000000 00000000 00000000 00000000 83ee3cb0 ... Call Trace:[<800152a4>] 0x800152a4 [<800152a4>] 0x800152a4 [<801d036c>] 0x801d036c [<8034766c ] 0x8034766c [<80040000>] 0x80040000 [<80348458>] 0x80348458 [<803558BC>] 0X803558BC [<801b03cc>] 0x801b03cc [<80356ebc>] 0x80356ebc [<80347b60>] 0x80347b60 [ <80045F0C>] 0x80045f0c [<803575b4>] 0x803575b4 [<80048898>] 0x80048898 [<80357fe8>] 0x80357fe8 [<80357f00>] 0x80357f00 [<80357f00>] 0x80357f00 [<8003cd10>] 0X8003CD10 [<80045b4c ] 0x80045b4c [<80045c10>] 0x80045c10 [<8003cc58>] 0x8003cc58 [<800129fc>] 0X800129FC mmcblk0: error-145 transferring data, Sector 0, nr 1, cmd response 0x900, card status 0x0 W 0.002mb/s, R 1.055mb/s Pass 1/1, W 0.002MB/S, R 1.055mb/s veridisk_write_loop:--------------------TEST result--------------------veridisk_write_loop : Pass 1/1, W 0.002mb/s, R 1.055mb/s veridisk_write_loop:failed Count:open 0, write 0, read 0, compare 0//re-execute as Ti
Mes has become 0, so there is no transmission error. /sys/kernel/debug/mmc0/fail_mmc_request # veridisk-f/dev/mmcblk0-e 1-m 1-v-D offset [0, 1), Len [1, 2], seq pattern 0x00 offset 0, len 1, seq PatteRN 0x01 W 0.030mb/s, R 0.656mb/s Pass 1/1, W 0.030mb/s, R 0.656mb/s veridisk_write_loop:--------------------TEST Result--------------------Veridisk_write_loop:pass 1/1, W 0.030mb/s, R 0.656mb/s veridisk_write_loop:failed Count : Open 0, write 0, read 0, compare 0/sys/kernel/debug/mmc0/fail_mmc_request #
#ifdef config_fail_mmc_request static void Mmc_should_fail_request (struct mmc_host,
struct mmc_request *mrq) {struct Mmc_command *cmd = mrq->cmd;
struct Mmc_data *data = mrq->data;
static const int data_errors[] = {-etimedout,-eilseq,-eio,};
if (!data) return;
if (Cmd->error | | data->error | |
!should_fail (&host->fail_mmc_request, Data->blksz * data->blocks)) return;
Data->error = data_errors[prandom_u32 ()% array_size (data_errors)];
data->bytes_xfered = (prandom_u32 ()% (data->bytes_xfered >> 9)) << 9; #else static inline void mmc_should_fail_request (struct mmc_host *host, struct mmc_request) {} #endif
When you call mmc_should_fail_request in the Mmc_request_done function, you assign a value according to a certain rule data->error, the error that may occur is Etimedout,eilseq,eio, This can simulate the data transmission probability error situation. And in the mmc/core/debugfs.c file, the Fail_mmc_request directory is created in the/SYS/KERNEL/DEBUG/MMC0 directory.