fault-injection-developer Mailing List for Fault Injection Test Harness (Page 3)
Status: Alpha
Brought to you by:
rustyl
Menu
▾
▴
fault-injection-developer — Developer discussions about creating a fault injection test harness.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(13) |
Sep
(2) |
Oct
(49) |
Nov
(69) |
Dec
(70) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(64) |
Feb
(41) |
Mar
(25) |
Apr
(18) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2016 |
Jan
(2) |
Feb
(5) |
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
|
From: Stanley W. <sta...@li...> - 2003-03-11 08:29:10
|
On Mon, 10 Mar 2003, Greg KH wrote: > On Fri, Mar 07, 2003 at 12:05:45PM +0800, Stanley Wang wrote: > > I've completed a mock e100 CPCI peripheral board based on FITH > > project(http://fault-injection.sourceforge.net/). It would intercept all > > pci config access and could be used to test CPCI hotswap driver without real > > hardware support. > > You say, "Could be used". Does that mean you have used it in such a > manner? And does that mean that other pci hotplug drivers could be > tested with a modification of this framework? Certainly. I could use it to trigger an insertion/extraction event at any time. You could also list this mock peripheral board by "lspci" after it was inserted. I just implement the HotSwap part of the mock peripheral board, and you could let it be any device you want. This simulator is based on FITH. FITH provides ability to intercept and inject faults into any PIO/MMIO access or IRQ handler. Hence we could emulate a real device easily by intercept serval PIO/MMIO/IRQ. Best Regards, Stan -- Opinions expressed are those of the author and do not represent Intel Corporation |
|
From: Greg KH <gr...@kr...> - 2003-03-11 08:08:35
|
On Fri, Mar 07, 2003 at 12:05:45PM +0800, Stanley Wang wrote: > I've completed a mock e100 CPCI peripheral board based on FITH > project(http://fault-injection.sourceforge.net/). It would intercept all > pci config access and could be used to test CPCI hotswap driver without real > hardware support. You say, "Could be used". Does that mean you have used it in such a manner? And does that mean that other pci hotplug drivers could be tested with a modification of this framework? Looks very interesting. thanks, greg k-h |
|
From: Louis Z. <lou...@li...> - 2003-03-11 00:52:21
|
Dear Sripriya, Our kernel patch is based on the top of Linus' tree. If you would like to develop driver with FITH, I suggest you download our development tree by BK directly. I think 2.5 kernel is also reasonably stable because of feature-frozen and much work on it. I don't see many changes in network driver model between 2.4 and 2.5 except trivial module mechanism. So it is easy to port driver bi-directly. According to backport FITH to 2.4, making KMMIO/KIRQ work in 2.4 is trivial, but DBP/DR are a little difficult because they need KPROBE. -- Yours truly, Louis Zhuang --------------- Fault Injection Test Harness Project BK tree: http://fault-injection.bkbits.net/linux-2.5 Home Page: http://sf.net/projects/fault-injection |
|
From: Sripriya N. <sri...@np...> - 2003-03-10 11:42:27
|
Hi,
I am currently involved in developing network driver for gigabit =
ethernet card under Linux. I would like to test the driver I develop =
with the "Fault injection test harness" that comes as a patch for Kernel =
2.5. Now my question is, what kernel version would be advisable to write =
the driver on? Is it too much of a porting work if I develop on the =
kernel 2.4 which is reasonably stable, to finally test with the =
hardening tool.or will it be a risk developing on kernel 2.5 development =
series? I would also like to know the amount of work involved in porting =
back the harness tool to kernel 2.4, if it is possible.
Kindly suggest the latest kernel version I can work on inorder to use =
the hardening tool.
Thanks
Sripriya
|
|
From: Stanley W. <sta...@li...> - 2003-03-07 04:11:48
|
I've completed a mock e100 CPCI peripheral board based on FITH project(http://fault-injection.sourceforge.net/). It would intercept all pci config access and could be used to test CPCI hotswap driver without real hardware support. You could get it @ http://osdn.dl.sourceforge.net/sourceforge/fault-injection/mock_e100.tgz And you could get the FITH's bk tree @ http://fau...@fa.../2.5-fi-extern Enjoys! Stan -- Opinions expressed are those of the author and do not represent Intel Corporation |
|
From: Gao, K. <kev...@in...> - 2003-03-05 01:51:19
|
Now FITH can inject fault while driver reads/writes the
special IO/MMIO. After analysis e100 specification, we make
many test case for e100. These test cases may help e100 run
some exception branch, which will hardly be runned.
Now the codecoverage test for e100 test cases is as follow:
(The percent of runned code is less is becuase the result
does not include all the code of driver uninitialization.
And most ioctl operations are not tested.)
The percent of codecoverage (Driver without FI):
e100_main.c 54.96%
e100_phy.c 44.11%
e100_config.c 45.28%
e100_eeprom.c 51.81%
The percent of codecoverage (Driver with FI):
e100_main.c 57.81%
e100_phy.c 46.62%
e100_config.c 45.28%
e100_eeprom.c 51.81%
The progress we made:
e100_main.c 2.85% 46 lines.
e100_phy.c 2.51% 10 lines.
The advantage of FITH for code coverage:
1. FITH can simulate hardware fault while driver reads or
writes the special IO, MMIO of the device. If the branch checks
hardware status or data in IO/MMIO, FITH always can intercept
it and changes it. (example as follow).
status = readw(port); //We can change here.
if (status & BIT2) {
...
}
else {
..
}
2. We can print information to kernel message by FITH, so that when
the the turn of the driver operation is complex, with the great
information
we get, we can also make test cases for it.
The disadvantage of FITH for code coverage:
Driver always use some private struct and data to record some
flags, so that based on it, driver will decide how to do. About the
branch
of these branches, inject fault is difficult, just because FITH
cannot
track the private data of driver. (example as follow)
if (private->flags & FL_OK) { //We cannot track private.
...
}
else {
...
}
|
|
From: Louis Z. <lou...@li...> - 2003-03-04 02:36:39
|
On Tue, 2003-03-04 at 10:25, Wang, Frank wrote: > Just curious, can this be used in conformance testing (something like > POSIX API conformance testing) to simulate "out of memory" return > value? Dear Frank, I think there is a better way to do user-space FI. We can set LD_PERLOAD to override system api by your api. - Louis |
|
From: Wang, F. <fra...@in...> - 2003-03-04 02:25:30
|
Just curious, can this be used in conformance testing (something like = POSIX API conformance testing) to simulate "out of memory" return value? -----Original Message----- From: Louis Zhuang [mailto:lou...@li...] Sent: 2003?3?4? 9:12 To: FITHML Subject: [Fault-injection-developer] [RFC] [PATCH] general symbol = replacement Dear all, Following is a tiny tool used to change a symbol name in your module. So you can replace, for example, 'kmalloc' with 'fmalloc'. And then you can write fmalloc implementation yourself in a module. In this way, you can intercept any software API in kernel only if it is not a macro. Any comments? --=20 Yours truly, Louis Zhuang --------------- Fault Injection Test Harness Project BK tree: http://fault-injection.bkbits.net/linux-2.5 Home Page: http://sf.net/projects/fault-injection # This is a BitKeeper generated patch for the following project: # Project Name: Fault Injection Test Harness tools # This patch format is intended for GNU patch command version 2.5 or = higher. # This patch includes the following deltas: # ChangeSet 1.22 -> 1.25 =20 # fith_utility/Makefile.am 1.1 -> 1.2 =20 # fith_utility/configure.in 1.1 -> 1.2 =20 # (new) -> 1.2 = fith_utility/replacesym/replacesym.c # (new) -> 1.1 = fith_utility/replacesym/Makefile.am # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/02/27 lo...@ha... 1.23 # Add replace symbol mechanism # -------------------------------------------- # 03/02/27 lo...@ha... 1.24 # add replacesym # -------------------------------------------- # 03/02/27 lo...@ha... 1.25 # Fix a bug -- Should seek in .strtab instead of .shstrtab # -------------------------------------------- # diff -Nru a/fith_utility/Makefile.am b/fith_utility/Makefile.am --- a/fith_utility/Makefile.am Tue Mar 4 09:06:35 2003 +++ b/fith_utility/Makefile.am Tue Mar 4 09:06:35 2003 @@ -1,4 +1,4 @@ AUTOMAKE_OPTIONS =3D foreign EXTRA_DIST =3D ./*=20 =20 -SUBDIRS =3D ficl=20 +SUBDIRS =3D ficl replacesym=20 diff -Nru a/fith_utility/configure.in b/fith_utility/configure.in --- a/fith_utility/configure.in Tue Mar 4 09:06:35 2003 +++ b/fith_utility/configure.in Tue Mar 4 09:06:35 2003 @@ -36,4 +36,5 @@ =20 AC_OUTPUT([ Makefile=20 - ficl/Makefile]) + ficl/Makefile + replacesym/Makefile]) diff -Nru a/fith_utility/replacesym/Makefile.am = b/fith_utility/replacesym/Makefile.am --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/fith_utility/replacesym/Makefile.am Tue Mar 4 09:06:35 2003 @@ -0,0 +1,8 @@ +AUTOMAKE_OPTIONS =3D foreign +sbin_PROGRAMS =3D replacesym + +include $(top_srcdir)/rules.mk + +replacesym_SOURCES =3D replacesym.c + +=09 diff -Nru a/fith_utility/replacesym/replacesym.c = b/fith_utility/replacesym/replacesym.c --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/fith_utility/replacesym/replacesym.c Tue Mar 4 09:06:35 2003 @@ -0,0 +1,98 @@ +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <fcntl.h> +#include <sys/mman.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <unistd.h> +#include <errno.h> +#include <asm/unistd.h> + +#include <elf.h> + +typedef Elf32_Ehdr Elf_Ehdr; +typedef Elf32_Shdr Elf_Shdr; + +static int replace_symbol(void *map, int len, const char *old, const = char *new) +{ + Elf_Ehdr *hdr; + Elf_Shdr *sechdrs; + char *strtab; + char *s; + int n; +=09 + hdr =3D map; + if (len < sizeof(*hdr)) { + fprintf(stderr, "File is too short\n"); + return -1; + } + + /* Sanity checks against insmoding binaries or wrong arch, + * weird elf version */ + if (memcmp(hdr->e_ident, ELFMAG, 4) !=3D 0 + || hdr->e_type !=3D ET_REL + || hdr->e_shentsize !=3D sizeof(*sechdrs)) { + fprintf(stderr, "File is weird\n"); + return -1; + } =09 + + sechdrs =3D map + hdr->e_shoff; + strtab =3D map + sechdrs[hdr->e_shnum-1].sh_offset; +=09 + n =3D sechdrs[hdr->e_shnum-1].sh_size; + s =3D strtab; + while (n) { + int len; + =09 + len =3D strnlen(s, n); + if (len >=3D n) { + fprintf(stderr, "Bad string table\n"); + break; + } + printf("Symbol name:'%s'\n", s); + =09 + if (!strcmp(s, old)) { + if (strlen(new) <=3D len) { + strncpy(s, new, len); + } else { + fprintf(stderr,=20 + "New symbol name is too long\n"); + } + } + =09 + s +=3D len+1; + n -=3D len+1; + }=09 + + return 0; +} + +int main(int argc, char *argv[]) +{ + int fd; + struct stat st; + void *map; +=09 + if (argc !=3D 4) { + printf("Usage: %s <module_file> <old_sym> <new_sym>\n", argv[0]); + exit(1); + } +=09 + fd =3D open(argv[1], O_RDWR, 0); + if (fd < 0) { + perror("Unable to open file"); + exit(1); + } + + fstat(fd, &st); + map =3D mmap(NULL, st.st_size, PROT_WRITE|PROT_READ, MAP_SHARED, fd, = 0); + if (MAP_FAILED =3D=3D map) { + perror("Unable to mmap file"); + exit(1); + } + + replace_symbol(map, st.st_size, argv[2], argv[3]); + return 0; +} ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The = debugger=20 for complex code. Debugging C/C++ programs can leave you feeling lost = and=20 disoriented. TotalView can help you find your way. Available on major = UNIX=20 and Linux platforms. Try it free. www.etnus.com _______________________________________________ Fault-injection-developer mailing list Fau...@li... https://lists.sourceforge.net/lists/listinfo/fault-injection-developer |
|
From: Louis Z. <lou...@li...> - 2003-03-04 01:13:38
|
Dear all, Following is a tiny tool used to change a symbol name in your module. So you can replace, for example, 'kmalloc' with 'fmalloc'. And then you can write fmalloc implementation yourself in a module. In this way, you can intercept any software API in kernel only if it is not a macro. Any comments? -- Yours truly, Louis Zhuang --------------- Fault Injection Test Harness Project BK tree: http://fault-injection.bkbits.net/linux-2.5 Home Page: http://sf.net/projects/fault-injection # This is a BitKeeper generated patch for the following project: # Project Name: Fault Injection Test Harness tools # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.22 -> 1.25 # fith_utility/Makefile.am 1.1 -> 1.2 # fith_utility/configure.in 1.1 -> 1.2 # (new) -> 1.2 fith_utility/replacesym/replacesym.c # (new) -> 1.1 fith_utility/replacesym/Makefile.am # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/02/27 lo...@ha... 1.23 # Add replace symbol mechanism # -------------------------------------------- # 03/02/27 lo...@ha... 1.24 # add replacesym # -------------------------------------------- # 03/02/27 lo...@ha... 1.25 # Fix a bug -- Should seek in .strtab instead of .shstrtab # -------------------------------------------- # diff -Nru a/fith_utility/Makefile.am b/fith_utility/Makefile.am --- a/fith_utility/Makefile.am Tue Mar 4 09:06:35 2003 +++ b/fith_utility/Makefile.am Tue Mar 4 09:06:35 2003 @@ -1,4 +1,4 @@ AUTOMAKE_OPTIONS = foreign EXTRA_DIST = ./* -SUBDIRS = ficl +SUBDIRS = ficl replacesym diff -Nru a/fith_utility/configure.in b/fith_utility/configure.in --- a/fith_utility/configure.in Tue Mar 4 09:06:35 2003 +++ b/fith_utility/configure.in Tue Mar 4 09:06:35 2003 @@ -36,4 +36,5 @@ AC_OUTPUT([ Makefile - ficl/Makefile]) + ficl/Makefile + replacesym/Makefile]) diff -Nru a/fith_utility/replacesym/Makefile.am b/fith_utility/replacesym/Makefile.am --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/fith_utility/replacesym/Makefile.am Tue Mar 4 09:06:35 2003 @@ -0,0 +1,8 @@ +AUTOMAKE_OPTIONS = foreign +sbin_PROGRAMS = replacesym + +include $(top_srcdir)/rules.mk + +replacesym_SOURCES = replacesym.c + + diff -Nru a/fith_utility/replacesym/replacesym.c b/fith_utility/replacesym/replacesym.c --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/fith_utility/replacesym/replacesym.c Tue Mar 4 09:06:35 2003 @@ -0,0 +1,98 @@ +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <fcntl.h> +#include <sys/mman.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <unistd.h> +#include <errno.h> +#include <asm/unistd.h> + +#include <elf.h> + +typedef Elf32_Ehdr Elf_Ehdr; +typedef Elf32_Shdr Elf_Shdr; + +static int replace_symbol(void *map, int len, const char *old, const char *new) +{ + Elf_Ehdr *hdr; + Elf_Shdr *sechdrs; + char *strtab; + char *s; + int n; + + hdr = map; + if (len < sizeof(*hdr)) { + fprintf(stderr, "File is too short\n"); + return -1; + } + + /* Sanity checks against insmoding binaries or wrong arch, + * weird elf version */ + if (memcmp(hdr->e_ident, ELFMAG, 4) != 0 + || hdr->e_type != ET_REL + || hdr->e_shentsize != sizeof(*sechdrs)) { + fprintf(stderr, "File is weird\n"); + return -1; + } + + sechdrs = map + hdr->e_shoff; + strtab = map + sechdrs[hdr->e_shnum-1].sh_offset; + + n = sechdrs[hdr->e_shnum-1].sh_size; + s = strtab; + while (n) { + int len; + + len = strnlen(s, n); + if (len >= n) { + fprintf(stderr, "Bad string table\n"); + break; + } + printf("Symbol name:'%s'\n", s); + + if (!strcmp(s, old)) { + if (strlen(new) <= len) { + strncpy(s, new, len); + } else { + fprintf(stderr, + "New symbol name is too long\n"); + } + } + + s += len+1; + n -= len+1; + } + + return 0; +} + +int main(int argc, char *argv[]) +{ + int fd; + struct stat st; + void *map; + + if (argc != 4) { + printf("Usage: %s <module_file> <old_sym> <new_sym>\n", argv[0]); + exit(1); + } + + fd = open(argv[1], O_RDWR, 0); + if (fd < 0) { + perror("Unable to open file"); + exit(1); + } + + fstat(fd, &st); + map = mmap(NULL, st.st_size, PROT_WRITE|PROT_READ, MAP_SHARED, fd, 0); + if (MAP_FAILED == map) { + perror("Unable to mmap file"); + exit(1); + } + + replace_symbol(map, st.st_size, argv[2], argv[3]); + return 0; +} |
|
From: Stanley W. <sta...@li...> - 2003-02-27 09:34:24
|
Hi, folks! I've integrated FI_DR and FI_DBP into the new FITH extern tree, hence the new tree includes all interceptors :) You could get it by : bk get http://fau...@fa.../2.5-fi-extern Cheers, Stan -- Opinions expressed are those of the author and do not represent Intel Corporation |
|
From: Louis Z. <lou...@li...> - 2003-02-25 07:33:45
|
Dear Vamsi,
I try to port your kprobes into 2.5.63. The only efforts is deleting
redundant code in restoring interrupt bit. If I make msitake, please
tell me.
yours truly,
- Louis
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.1025 -> 1.1026
# arch/i386/mm/fault.c 1.23 -> 1.24
# arch/i386/Kconfig 1.42 -> 1.43
# arch/i386/kernel/traps.c 1.46 -> 1.47
# arch/i386/kernel/Makefile 1.36 -> 1.37
# kernel/Makefile 1.27 -> 1.28
# arch/i386/kernel/entry.S 1.57 -> 1.58
# (new) -> 1.1 include/asm-i386/kprobes.h
# (new) -> 1.1 include/linux/kprobes.h
# (new) -> 1.1 arch/i386/kernel/kprobes.c
# (new) -> 1.1 kernel/kprobes.c
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/02/25 lo...@ha... 1.1026
# kprobes-2.5.63
# --------------------------------------------
#
diff -Nru a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig Tue Feb 25 15:23:04 2003
+++ b/arch/i386/Kconfig Tue Feb 25 15:23:04 2003
@@ -1434,6 +1434,15 @@
Say Y here if you are developing drivers or trying to debug and
identify kernel problems.
+config KPROBES
+ bool "Kprobes"
+ depends on DEBUG_KERNEL
+ help
+ Kprobes allows you to trap at almost any kernel address, using
+ register_kprobe(), and providing a callback function. This is useful
+ for kernel debugging, non-intrusive instrumentation and testing. If
+ in doubt, say "N".
+
config DEBUG_STACKOVERFLOW
bool "Check for stack overflows"
depends on DEBUG_KERNEL
diff -Nru a/arch/i386/kernel/Makefile b/arch/i386/kernel/Makefile
--- a/arch/i386/kernel/Makefile Tue Feb 25 15:23:04 2003
+++ b/arch/i386/kernel/Makefile Tue Feb 25 15:23:04 2003
@@ -26,6 +26,7 @@
obj-$(CONFIG_SOFTWARE_SUSPEND) += suspend.o suspend_asm.o
obj-$(CONFIG_X86_NUMAQ) += numaq.o
obj-$(CONFIG_EDD) += edd.o
+obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_MODULES) += module.o
obj-y += sysenter.o
diff -Nru a/arch/i386/kernel/entry.S b/arch/i386/kernel/entry.S
--- a/arch/i386/kernel/entry.S Tue Feb 25 15:23:04 2003
+++ b/arch/i386/kernel/entry.S Tue Feb 25 15:23:04 2003
@@ -461,9 +461,16 @@
jmp ret_from_exception
ENTRY(debug)
+ pushl $-1 # mark this as an int
+ SAVE_ALL
+ movl %esp,%edx
pushl $0
- pushl $do_debug
- jmp error_code
+ pushl %edx
+ call do_debug
+ addl $8,%esp
+ testl %eax,%eax
+ jnz restore_all
+ jmp ret_from_exception
ENTRY(nmi)
pushl %eax
@@ -476,9 +483,16 @@
RESTORE_ALL
ENTRY(int3)
+ pushl $-1 # mark this as an int
+ SAVE_ALL
+ movl %esp,%edx
pushl $0
- pushl $do_int3
- jmp error_code
+ pushl %edx
+ call do_int3
+ addl $8,%esp
+ testl %eax,%eax
+ jnz restore_all
+ jmp ret_from_exception
ENTRY(overflow)
pushl $0
diff -Nru a/arch/i386/kernel/kprobes.c b/arch/i386/kernel/kprobes.c
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/arch/i386/kernel/kprobes.c Tue Feb 25 15:23:04 2003
@@ -0,0 +1,160 @@
+/*
+ * Support for kernel probes.
+ * (C) 2002 Vamsi Krishna S <vam...@in...>.
+ */
+
+#include <linux/config.h>
+#include <linux/kprobes.h>
+#include <linux/ptrace.h>
+#include <linux/spinlock.h>
+#include <linux/preempt.h>
+
+/* kprobe_status settings */
+#define KPROBE_HIT_ACTIVE 0x00000001
+#define KPROBE_HIT_SS 0x00000002
+
+static struct kprobe *current_kprobe;
+static unsigned long kprobe_status, kprobe_old_eflags, kprobe_saved_eflags;
+
+/*
+ * returns non-zero if opcode modifies the interrupt flag.
+ */
+static inline int is_IF_modifier(u8 opcode)
+{
+ switch(opcode) {
+ case 0xfa: /* cli */
+ case 0xfb: /* sti */
+ case 0xcf: /* iret/iretd */
+ case 0x9d: /* popf/popfd */
+ return 1;
+ }
+ return 0;
+}
+
+static inline void disarm_kprobe(struct kprobe *p, struct pt_regs *regs)
+{
+ *p->addr = p->opcode;
+ regs->eip = (unsigned long)p->addr;
+}
+
+/*
+ * Interrupts are disabled on entry as trap3 is an interrupt gate and they
+ * remain disabled thorough out this function.
+ */
+int kprobe_handler(struct pt_regs *regs)
+{
+ struct kprobe *p;
+ int ret = 0;
+ u8 *addr = (u8 *)(regs->eip-1);
+
+ /* We're in an interrupt, but this is clear and BUG()-safe. */
+ preempt_disable();
+
+ /* Check we're not actually recursing */
+ if (kprobe_running()) {
+ /* We *are* holding lock here, so this is safe.
+ Disarm the probe we just hit, and ignore it. */
+ p = get_kprobe(addr);
+ if (p) {
+ disarm_kprobe(p, regs);
+ ret = 1;
+ }
+ /* If it's not ours, can't be delete race, (we hold lock). */
+ goto no_kprobe;
+ }
+
+ lock_kprobes();
+ p = get_kprobe(addr);
+ if (!p) {
+ unlock_kprobes();
+ /* Unregistered (on another cpu) after this hit? Ignore */
+ if (*addr != BREAKPOINT_INSTRUCTION)
+ ret = 1;
+ /* Not one of ours: let kernel handle it */
+ goto no_kprobe;
+ }
+
+ kprobe_status = KPROBE_HIT_ACTIVE;
+ current_kprobe = p;
+ kprobe_saved_eflags = kprobe_old_eflags
+ = (regs->eflags & (TF_MASK|IF_MASK));
+ if (is_IF_modifier(p->opcode))
+ kprobe_saved_eflags &= ~IF_MASK;
+
+ p->pre_handler(p, regs);
+
+ regs->eflags |= TF_MASK;
+ regs->eflags &= ~IF_MASK;
+
+ /* We hold lock, now we remove breakpoint and single step. */
+ disarm_kprobe(p, regs);
+ kprobe_status = KPROBE_HIT_SS;
+ return 1;
+
+no_kprobe:
+ preempt_enable_no_resched();
+ return ret;
+}
+
+static void rearm_kprobe(struct kprobe *p, struct pt_regs *regs)
+{
+ regs->eflags &= ~TF_MASK;
+ *p->addr = BREAKPOINT_INSTRUCTION;
+}
+
+/*
+ * Interrupts are disabled on entry as trap1 is an interrupt gate and they
+ * remain disabled thorough out this function. And we hold kprobe lock.
+ */
+int post_kprobe_handler(struct pt_regs *regs)
+{
+ if (!kprobe_running())
+ return 0;
+
+ if (current_kprobe->post_handler)
+ current_kprobe->post_handler(current_kprobe, regs, 0);
+
+ /*
+ * We singlestepped with interrupts disabled. So, the result on
+ * the stack would be incorrect for "pushfl" instruction.
+ * Note that regs->esp is actually the top of the stack when the
+ * trap occurs in kernel space.
+ */
+ if (current_kprobe->opcode == 0x9c) { /* pushfl */
+ regs->esp &= ~(TF_MASK | IF_MASK);
+ regs->esp |= kprobe_old_eflags;
+ }
+
+ rearm_kprobe(current_kprobe, regs);
+ regs->eflags |= kprobe_saved_eflags;
+
+ unlock_kprobes();
+ preempt_enable_no_resched();
+
+ /*
+ * if somebody else is singlestepping across a probe point, eflags
+ * will have TF set, in which case, continue the remaining processing
+ * of do_debug, as if this is not a probe hit.
+ */
+ if (regs->eflags & TF_MASK)
+ return 0;
+
+ return 1;
+}
+
+/* Interrupts disabled, kprobe_lock held. */
+int kprobe_fault_handler(struct pt_regs *regs, int trapnr)
+{
+ if (current_kprobe->fault_handler
+ && current_kprobe->fault_handler(current_kprobe, regs, trapnr))
+ return 1;
+
+ if (kprobe_status & KPROBE_HIT_SS) {
+ rearm_kprobe(current_kprobe, regs);
+ regs->eflags |= kprobe_old_eflags;
+
+ unlock_kprobes();
+ preempt_enable_no_resched();
+ }
+ return 0;
+}
diff -Nru a/arch/i386/kernel/traps.c b/arch/i386/kernel/traps.c
--- a/arch/i386/kernel/traps.c Tue Feb 25 15:23:04 2003
+++ b/arch/i386/kernel/traps.c Tue Feb 25 15:23:04 2003
@@ -344,7 +344,6 @@
}
DO_VM86_ERROR_INFO( 0, SIGFPE, "divide error", divide_error, FPE_INTDIV, regs->eip)
-DO_VM86_ERROR( 3, SIGTRAP, "int3", int3)
DO_VM86_ERROR( 4, SIGSEGV, "overflow", overflow)
DO_VM86_ERROR( 5, SIGSEGV, "bounds", bounds)
DO_ERROR_INFO( 6, SIGILL, "invalid operand", invalid_op, ILL_ILLOPN, regs->eip)
@@ -358,6 +357,9 @@
{
if (regs->eflags & VM_MASK)
goto gp_in_vm86;
+
+ if (kprobe_running() && kprobe_fault_handler(regs, 13))
+ return;
if (!(regs->xcs & 3))
goto gp_in_kernel;
@@ -482,6 +484,17 @@
nmi_callback = dummy_nmi_callback;
}
+asmlinkage int do_int3(struct pt_regs *regs, long error_code)
+{
+ if (kprobe_handler(regs))
+ return 1;
+ /* This is an interrupt gate, because kprobes wants interrupts
+ disabled. Normal trap handlers don't. */
+ restore_interrupts(regs);
+ do_trap(3, SIGTRAP, "int3", 1, regs, error_code, NULL);
+ return 0;
+}
+
/*
* Our handling of the processor debug registers is non-trivial.
* We do not clear them on entry and exit from the kernel. Therefore
@@ -504,7 +517,7 @@
* find every occurrence of the TF bit that could be saved away even
* by user code)
*/
-asmlinkage void do_debug(struct pt_regs * regs, long error_code)
+asmlinkage int do_debug(struct pt_regs * regs, long error_code)
{
unsigned int condition;
struct task_struct *tsk = current;
@@ -512,6 +525,9 @@
__asm__ __volatile__("movl %%db6,%0" : "=r" (condition));
+ if (post_kprobe_handler(regs))
+ return 1;
+
/* It's safe to allow irq's after DR6 has been saved */
if (regs->eflags & X86_EFLAGS_IF)
local_irq_enable();
@@ -566,17 +582,17 @@
__asm__("movl %0,%%db7"
: /* no output */
: "r" (0));
- return;
+ return 0;
debug_vm86:
handle_vm86_trap((struct kernel_vm86_regs *) regs, error_code, 1);
- return;
+ return 0;
clear_TF_reenable:
set_tsk_thread_flag(tsk, TIF_SINGLESTEP);
clear_TF:
regs->eflags &= ~TF_MASK;
- return;
+ return 0;
}
/*
@@ -740,6 +756,8 @@
struct task_struct *tsk = current;
clts(); /* Allow maths ops (or we recurse) */
+ if (kprobe_running() && kprobe_fault_handler(®s, 7))
+ return;
if (!tsk->used_math)
init_fpu(tsk);
restore_fpu(tsk);
@@ -840,7 +858,7 @@
set_trap_gate(0,÷_error);
set_intr_gate(1,&debug);
set_intr_gate(2,&nmi);
- set_system_gate(3,&int3); /* int3-5 can be called from all */
+ _set_gate(idt_table+3,14,3,&int3); /* int3-5 can be called from all */
set_system_gate(4,&overflow);
set_system_gate(5,&bounds);
set_trap_gate(6,&invalid_op);
diff -Nru a/arch/i386/mm/fault.c b/arch/i386/mm/fault.c
--- a/arch/i386/mm/fault.c Tue Feb 25 15:23:04 2003
+++ b/arch/i386/mm/fault.c Tue Feb 25 15:23:04 2003
@@ -20,6 +20,7 @@
#include <linux/tty.h>
#include <linux/vt_kern.h> /* For unblank_screen() */
#include <linux/module.h>
+#include <linux/kprobes.h>
#include <asm/system.h>
#include <asm/uaccess.h>
@@ -160,6 +161,9 @@
/* get the address */
__asm__("movl %%cr2,%0":"=r" (address));
+
+ if (kprobe_running() && kprobe_fault_handler(regs, 14))
+ return;
/* It's safe to allow irq's after cr2 has been saved */
if (regs->eflags & X86_EFLAGS_IF)
diff -Nru a/include/asm-i386/kprobes.h b/include/asm-i386/kprobes.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-i386/kprobes.h Tue Feb 25 15:23:04 2003
@@ -0,0 +1,34 @@
+#ifndef _ASM_KPROBES_H
+#define _ASM_KPROBES_H
+/*
+ * Dynamic Probes (kprobes) support
+ * Vamsi Krishna S <vam...@in...>, July, 2002
+ * Mailing list: dp...@ww...
+ */
+#include <linux/types.h>
+#include <linux/ptrace.h>
+
+struct pt_regs;
+
+typedef u8 kprobe_opcode_t;
+#define BREAKPOINT_INSTRUCTION 0xcc
+
+/* trap3/1 are intr gates for kprobes. So, restore the status of IF,
+ * if necessary, before executing the original int3/1 (trap) handler.
+ */
+static inline void restore_interrupts(struct pt_regs *regs)
+{
+ if (regs->eflags & IF_MASK)
+ __asm__ __volatile__ ("sti");
+}
+
+#ifdef CONFIG_KPROBES
+extern int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
+extern int post_kprobe_handler(struct pt_regs *regs);
+extern int kprobe_handler(struct pt_regs *regs);
+#else /* !CONFIG_KPROBES */
+static inline int kprobe_fault_handler(struct pt_regs *regs, int trapnr) { return 0; }
+static inline int post_kprobe_handler(struct pt_regs *regs) { return 0; }
+static inline int kprobe_handler(struct pt_regs *regs) { return 0; }
+#endif
+#endif /* _ASM_KPROBES_H */
diff -Nru a/include/linux/kprobes.h b/include/linux/kprobes.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/linux/kprobes.h Tue Feb 25 15:23:04 2003
@@ -0,0 +1,60 @@
+#ifndef _LINUX_KPROBES_H
+#define _LINUX_KPROBES_H
+#include <linux/config.h>
+#include <linux/list.h>
+#include <linux/notifier.h>
+#include <linux/smp.h>
+#include <asm/kprobes.h>
+
+struct kprobe;
+struct pt_regs;
+
+typedef void (*kprobe_pre_handler_t)(struct kprobe *, struct pt_regs *);
+typedef void (*kprobe_post_handler_t)(struct kprobe *, struct pt_regs *,
+ unsigned long flags);
+typedef int (*kprobe_fault_handler_t)(struct kprobe *, struct pt_regs *,
+ int trapnr);
+
+struct kprobe {
+ struct list_head list;
+
+ /* location of the probe point */
+ kprobe_opcode_t *addr;
+
+ /* Called before addr is executed. */
+ kprobe_pre_handler_t pre_handler;
+
+ /* Called after addr is executed, unless... */
+ kprobe_post_handler_t post_handler;
+
+ /* ... called if executing addr causes a fault (eg. page fault).
+ * Return 1 if it handled fault, otherwise kernel will see it. */
+ kprobe_fault_handler_t fault_handler;
+
+ /* Saved opcode (which has been replaced with breakpoint) */
+ kprobe_opcode_t opcode;
+};
+
+#ifdef CONFIG_KPROBES
+/* Locks kprobe: irq must be disabled */
+void lock_kprobes(void);
+void unlock_kprobes(void);
+
+/* kprobe running now on this CPU? */
+static inline int kprobe_running(void)
+{
+ extern unsigned int kprobe_cpu;
+ return kprobe_cpu == smp_processor_id();
+}
+
+/* Get the kprobe at this addr (if any). Must have called lock_kprobes */
+struct kprobe *get_kprobe(void *addr);
+
+int register_kprobe(struct kprobe *p);
+void unregister_kprobe(struct kprobe *p);
+#else
+static inline int kprobe_running(void) { return 0; }
+static inline int register_kprobe(struct kprobe *p) { return -ENOSYS; }
+static inline void unregister_kprobe(struct kprobe *p) { }
+#endif
+#endif /* _LINUX_KPROBES_H */
diff -Nru a/kernel/Makefile b/kernel/Makefile
--- a/kernel/Makefile Tue Feb 25 15:23:04 2003
+++ b/kernel/Makefile Tue Feb 25 15:23:04 2003
@@ -18,6 +18,7 @@
obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
obj-$(CONFIG_SOFTWARE_SUSPEND) += suspend.o
obj-$(CONFIG_COMPAT) += compat.o
+obj-$(CONFIG_KPROBES) += kprobes.o
ifneq ($(CONFIG_IA64),y)
# According to Alan Modra <al...@li...>, the -fno-omit-frame-pointer is
diff -Nru a/kernel/kprobes.c b/kernel/kprobes.c
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/kernel/kprobes.c Tue Feb 25 15:23:04 2003
@@ -0,0 +1,89 @@
+/* Support for kernel probes.
+ (C) 2002 Vamsi Krishna S <vam...@in...>.
+*/
+#include <linux/kprobes.h>
+#include <linux/spinlock.h>
+#include <linux/hash.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <asm/cacheflush.h>
+#include <asm/errno.h>
+
+#define KPROBE_HASH_BITS 6
+#define KPROBE_TABLE_SIZE (1 << KPROBE_HASH_BITS)
+
+static struct list_head kprobe_table[KPROBE_TABLE_SIZE];
+
+unsigned int kprobe_cpu = NR_CPUS;
+static spinlock_t kprobe_lock = SPIN_LOCK_UNLOCKED;
+
+/* Locks kprobe: irqs must be disabled */
+void lock_kprobes(void)
+{
+ spin_lock(&kprobe_lock);
+ kprobe_cpu = smp_processor_id();
+}
+
+void unlock_kprobes(void)
+{
+ kprobe_cpu = NR_CPUS;
+ spin_unlock(&kprobe_lock);
+}
+
+/* You have to be holding the kprobe_lock */
+struct kprobe *get_kprobe(void *addr)
+{
+ struct list_head *head, *tmp;
+
+ head = &kprobe_table[hash_ptr(addr, KPROBE_HASH_BITS)];
+ list_for_each(tmp, head) {
+ struct kprobe *p = list_entry(tmp, struct kprobe, list);
+ if (p->addr == addr)
+ return p;
+ }
+ return NULL;
+}
+
+int register_kprobe(struct kprobe *p)
+{
+ int ret = 0;
+
+ spin_lock_irq(&kprobe_lock);
+ if (get_kprobe(p->addr)) {
+ ret = -EEXIST;
+ goto out;
+ }
+ list_add(&p->list, &kprobe_table[hash_ptr(p->addr, KPROBE_HASH_BITS)]);
+
+ p->opcode = *p->addr;
+ *p->addr = BREAKPOINT_INSTRUCTION;
+ flush_icache_range(p->addr, p->addr + sizeof(kprobe_opcode_t));
+ out:
+ spin_unlock_irq(&kprobe_lock);
+ return ret;
+}
+
+void unregister_kprobe(struct kprobe *p)
+{
+ spin_lock_irq(&kprobe_lock);
+ *p->addr = p->opcode;
+ list_del(&p->list);
+ flush_icache_range(p->addr, p->addr + sizeof(kprobe_opcode_t));
+ spin_unlock_irq(&kprobe_lock);
+}
+
+static int __init init_kprobes(void)
+{
+ int i;
+
+ /* FIXME allocate the probe table, currently defined statically */
+ /* initialize all list heads */
+ for (i = 0; i < KPROBE_TABLE_SIZE; i++)
+ INIT_LIST_HEAD(&kprobe_table[i]);
+
+ return 0;
+}
+__initcall(init_kprobes);
+
+EXPORT_SYMBOL_GPL(register_kprobe);
+EXPORT_SYMBOL_GPL(unregister_kprobe);
|
|
From: Mark H. <ma...@os...> - 2003-02-21 16:28:14
|
On Thu, 2003-02-20 at 17:54, Gao, Kevin wrote:
> Now I have update the faultset file of e100 tese code.
> Add a base parameters for all the faultset.
> You could only change the base address to your e100
> bar address.
> Furthermore, the fith-tool newest version is needed.
> please goto fith-toll/fith-utility directory to update it.
>
> -Kevin
Thanks, I think I'm getting closer. From the lspci I used the first
address. I modified base in scb_cu_resume.fsml to ff8ff000.
01:09.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
Subsystem: Intel Corp. EtherExpress PRO/100+ Management Adapter
Flags: bus master, medium devsel, latency 64, IRQ 18
Memory at ff8ff000 (32-bit, non-prefetchable) [size=4K]
I/O ports at ecc0 [size=64]
Memory at ff700000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at ff900000 [disabled] [size=1M]
Capabilities: [dc] Power Management version 2
Here is some of what I got in my /var/log/messages file, is this what I should be seeing?
Feb 21 07:40:55 markh2 kernel:
Feb 21 07:40:55 markh2 last message repeated 2 times
Feb 21 07:40:55 markh2 kernel: cs_scb_cu_resume: *************CU_RESUME*****************
Feb 21 07:40:55 markh2 kernel: cs_scb_cu_resume: ###########The val is 0x20##########
Feb 21 07:40:55 markh2 kernel:
Feb 21 07:40:56 markh2 last message repeated 2 times
Feb 21 07:40:56 markh2 kernel: cs_scb_cu_resume: *************CU_RESUME*****************
Feb 21 07:40:56 markh2 kernel: cs_scb_cu_resume: ###########The val is 0x20##########
Feb 21 07:40:56 markh2 kernel:
Feb 21 07:40:57 markh2 kernel: ume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
Feb 21 07:40:57 markh2 last message repeated 2 times
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: *****************Read*******************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ***********Change*****************
Feb 21 07:40:57 markh2 kernel: cs_scb_cu_resume: ###Before change the val is 0x0###
Feb 21 07:40:57 markh2 kernel:
>
> -----Original Message-----
> From: Louis Zhuang [mailto:lou...@li...]
> Sent: 2003?2?21? 8:40
> To: Mark Haverkamp
> Cc: Kevin Gao; FI...@ta...
> Subject: RE: [Fault-injection-developer] RE: e100 frame reception test res
> ult draft.
>
>
> The address is e100 device BAR0+2 (MMIO base address). In e100 hardware
> spec, the address is for cu command register. Please lspci to get your
> e100 MMIO base address.
--
Mark Haverkamp <ma...@os...>
|
|
From: Gao, K. <kev...@in...> - 2003-02-21 01:57:21
|
Now I have update the faultset file of e100 tese code. Add a base parameters for all the faultset. You could only change the base address to your e100 bar address. Furthermore, the fith-tool newest version is needed. please goto fith-toll/fith-utility directory to update it. -Kevin -----Original Message----- From: Louis Zhuang [mailto:lou...@li...] Sent: 2003?2?21? 8:40 To: Mark Haverkamp Cc: Kevin Gao; FI...@ta... Subject: RE: [Fault-injection-developer] RE: e100 frame reception test res ult draft. The address is e100 device BAR0+2 (MMIO base address). In e100 hardware spec, the address is for cu command register. Please lspci to get your e100 MMIO base address. On Fri, 2003-02-21 at 01:58, Mark Haverkamp wrote: > Sorry to keep bothering you guys, Now that I'm past the previous test, I > started looking at the e100 code just posted. I did a bk pull of the > fith-tool directory and built the e100 fault set code. I tried the > example in you mail and just my luck, it didn't seem to work. > > I am getting: pf_arm: Reason: Address is not present. > > Looking at scb_cu_resume.fsml, the trigger address is 0xfb101002. > What is this address? Does it depend on which pci slot the card is > plugged into? > > Thanks, > Mark. > > > > On Wed, 2003-02-19 at 23:01, Gao, Kevin wrote: > > I have submitted all the test code of e100 into sourceforge. > > You can download the as > > bk://fau...@fa.../fith-tool/ > > > > The test code is in the directory: ./fith-tool/fith_test/fault_set/e100. > > Using example: > > insert module : fi_core, fi_pf, e100, > > # cd ./fith-tool/fith_test/fault_set/e100 > > #make > > # insmod scb_cu_resume.ko > > # ficl -i scb_cu_resume.fsml > > # /etc/init.d/network start > > > > Now use command dmesg to see the log info or see the message in > > /var/log/messages. > > > > -Kevin > > > > -----Original Message----- > > From: Louis Zhuang [mailto:lou...@li...] > > Sent: 2003?2?20? 8:26 > > To: Mark Haverkamp > > Cc: Rusty Lynch; Stanley Wang; Kevin Gao; Frank Wang; FITHML > > Subject: Re: [Fault-injection-developer] RE: e100 frame reception test > > result draft. > > > > > > On Thu, 2003-02-20 at 00:26, Mark Haverkamp wrote: > > > If that includes the code too, that would be great. I'm interested in > > > seeing how a test of a driver is implemented. > > As you wish, test code are there (and simple). ;-) > > - Louis -- Yours truly, Louis Zhuang --------------- Fault Injection Test Harness Project BK tree: http://fault-injection.bkbits.net/linux-2.5 Home Page: http://sf.net/projects/fault-injection |
|
From: Mark H. <ma...@os...> - 2003-02-20 15:56:06
|
On Wed, 2003-02-19 at 16:38, Gao, Kevin wrote: > Based on your message, I think that is because > the code of FITH is outdated. > Please download the newest version of FITH. > Thanks > > -Kevin This helped. It looks like everything passed. Thanks, Mark. ************Start FITH test at 08:02:23 20-02-03 Thursday!************ ------------------------------------------------------------------- Original PPIO readb function works normally! Injecting faults into PPIO readb successful! Original PPIO readw function works normally! Injecting faults into PPIO readw successful! Original PPIO readl function works normally! Injecting faults into PPIO readl successful! Original PPIO writeb function works normally! Injecting faults into PPIO writeb successful! Original PPIO writew function works normally! Injecting faults into PPIO writew successful! Original PPIO writel function works normally! Injecting faults into PPIO writel successful! ------------------------------------------------------------------- Original MMIO readb function works normally! Injecting faults into MMIO readb successful! Original MMIO readw function works normally! Injecting faults into MMIO readw successful! Original MMIO readl function works normally! Injecting faults into MMIO readl successful! Original MMIO writeb function works normally! Injecting faults into MMIO writeb successful! Original MMIO writew function works normally! Injecting faults into MMIO writew successful! Original MMIO writel function works normally! Injecting faults into MMIO writel successful! ------------------------------------------------------------------- Precondition function test successful! Skip function test successful! Stop function test successful! Protection_mask function test successful! No corrupt action function test successful! ------------------------------------------------------------------- IO_address_zero test passed IO_address_overrange test passed MMIO_address_zero test passed MMIO_address_overrange test passed Corrupt 8 bit to 16 bit test passed Corrupt 16 bit to 32 bit test passed Same trigger in one faultset test passed Invalid trigger mode (HZ) test passed Invalid trigger mode (skip) test passed Invalid trigger mode (stop) test passed ------------------------------------------------------------------- **********FITH FUNCTIONALITY TEST RESULT********** Inject faults into I/O read passed! Inject faults into I/O write passed! Inject faults into MMI/O read passed! Inject faults into MMI/O write passed! Faultset preconditon test passed! Faultset skip pattern test passed! Faultset stop pattern test passed! Faultset hardware protect test passed! Trigger without action test passed! The whole boundary test passed! ************************************************** **********Complete FITH test at 08:02:52 20-02-03 Thursday!********** -- Mark Haverkamp <ma...@os...> |
|
From: Gao, K. <kev...@in...> - 2003-02-20 07:59:26
|
The test result of e100 tested by FITH is as follow:
1. When driver reads the SCB command register, we set the value of SCB
command register to CU_RESUME(or other command but not zero), the
driver only check whether the value is zero.
Just because we cannot distinguish the read and write operation when =
driver access this register, so we cannot guarantee the detailed
access order that we intercept. Now the newest FITH minimal can do
it properly, so we will test this issue again.
2. The driver always sets 'S(uspend)' bit to every TCB when it will be
sent. So only one TCB package will be sent when there is a CU_RESUME
command. I think the performance is not good.
We should negotiate with EID's colleague, and knows the real reason
to do that.
3. When driver writes the 'CU_RESME' command into SCB command register,
we set the 'I(nterrupt)' bit to 1. According to the information we
get we find that driver never clear the 'I' bit.
Just because driver always sets 'S' bit to current TCB, so 'I' bit
can ignored. And when we tests this instance, The net translation
works properly, so driver ignore 'i' bit is acceptable.
4. When driver writes the 'CU_RESUME' command into SCB command =
register,
we set the 'U(nderrun)' bit to 1. The driver ignores this issue.
Driver should check this bit before writing 'CU_RESUME' command, so
we should set 'U' bit when driver reads the SCB status register.
5. When driver writes the 'CU_RESUME' command into SCB command =
register,
we set the 'C(omplete)' bit to 1, and 'OK' bit to 1, driver ignores
this issue.
Driver should check this bit, before writing 'CU_RESUME' command,=20
so this operation is reasonable.
6. When driver writes the 'CU_RESUME' command into SCB command =
register,
we set the 'C(omplete)' bit to 0, and 'OK' bit to 1. The network =
will
break after transmit package for short time. =20
Driver should check this bit, before writing 'CU_RESUME' command, so
we think drvier should ignore this corrupt operation. We will test =
it
again to proofing it.=20
We have no idea for it, and we should verify it again.
7. When driver writes the 'CU_RESUME' command into SCB command =
register,
we set the 'C(omplete)' bit to 1, and 'OK' bit to 0. Driver will not
set 'S' bit to current TCB.
We think the proper way driver deals with this corruption is ignore
it. But maybe some error from our TCB tracking code. So we will =
revise
the code, and test again to find the root cause.=20
We have no idea for it, and we should verify it again.
8.When driver reads SCB status register, we change the TCB status=20
register (OK =3D 0, C=3D0) which was just transmitted, After =
succesfully
sending several package, driver will read status register forever.
The driver check =A1=B0C=A1=B1 bit only. If not set, it will wait =
until the
=A1=B0C=A1=B1 bit is set. If =A1=B0C=A1=B1 bit will never be set, the =
TCP pool will=20
be empty after a while. And driver can also receive packet now.
9. After driver writes the CU_RESUME(CU_START, RU_START, RU_RESUME) to
SCB command register, we set CU_RESUME command (current value should
be 0) to SCB command register when driver read SCB command register,
we found that driver do not read the command register after writing
command to check.
Before driver writes command to SCB command register, it must check
whether it is 0. if not, the driver should wait for a moment and=20
check again. The driver should also have a timer, so that when =
timeout,
the SCB command register is still not zero, the driver should quit =
the
operation, and give the warning report.
=20
10.When driver writes the CU_RESUME(CU_START, RU_START, RU_RESUME) to =
SCB
command register, we corrupt the value to 0, and after it, if driver
reads SCB command register to check, we corrupt the command to=20
CU_RESUME. After do the fault injection, the send functionality will =
hanged.=20
When writes CU_RESUME command, the device cannot accept. The driver=20
should give a warning report.
=20
11.When driver reads SCB status register, we change the TCB status=20
register (OK =3D 1, C=3D0) which was just transmitted, After =
succesfully=20
sending several package, driver will read status register forever.
The same issue of 8.
=20
12.When driver reads SCB status register, we change the TCB status =
register
(OK =3D 0, C=3D1) which was just transmitted, the driver will ignore =
it.
The driver never checks the 'OK' bit in TCB status register.
=20
13.When driver reads SCB status register, we set the TCB 'U'nderrun bit =
which was just transmitted, After succesfully sending several =
package,
driver will read status register forever.
We should check it again.
14.Set =A1=AES=A1=AF bit of RFD which is under received when driver =
reads the SCB
status register. Driver always send a RU_START command.
The e100 driver checks the hardware status and reacts properly =20
15.Set =A1=AES=A1=AF bit of RFD which has been received when driver =
reads the SCB
status register. Driver ignores the operation.
The 'S' bit is set by driver and read by hardware. Hence the driver=20
doesn't care it.=20
16.Set both =A1=AEC=A1=AF and =A1=AEOK=A1=AF bit of RFD to zero when =
driver reads the
SCB status register, Driver cannot receive any package and read the
RFD forever.
If the 'C' bit equals zero, the driver will treat this rfd as an=20
incomplete packet and just wait untile 'C' equals one.=20
17.Set =A1=AEC=A1=AF bit of RFD to 0, and set =A1=AEOK=A1=AF bit of RFD =
to 1 when driver
reads the SCB status register, the result is the same as process =
2.5.
The same issue as 16.
18.Set =A1=AEC=A1=AF bit of RFD to 1, and set =A1=AEOK=A1=AF bit of RFD =
to 0 when driver
reads the SCB status register, driver will hanged, cannot receive =
any
package.
When driver find current package is not OK, it will ignore the =
package
and track next package of the RFL.
19.Set =A1=AECRC=A1=AF bit of RFD to 1 when driver reads the SCB status =
register,
the driver ignores this operation.
The driver should check this bit.
20.Set =A1=AEAlignment error=A1=AF bit of RFD to 1 when driver reads =
the SCB=20
status register, the driver ignores this operation.
The driver should check this bit.
21.Set =A1=AERun out of buffer=A1=AF bit of RFD to 1 when driver reads =
the=20
SCB status register, the driver ignores this operation.
=20
The driver should check this bit.=20
22.Set =A1=AEFrame too short=A1=AF bit of RFD to 1 when driver reads =
the SCB
status register, the driver ignores this operation.
The driver should check this bit.=20
-Kevin
|
|
From: Gao, K. <kev...@in...> - 2003-02-20 07:03:46
|
I have submitted all the test code of e100 into sourceforge. You can download the as bk://fau...@fa.../fith-tool/ The test code is in the directory: ./fith-tool/fith_test/fault_set/e100. Using example: insert module : fi_core, fi_pf, e100, # cd ./fith-tool/fith_test/fault_set/e100 #make # insmod scb_cu_resume.ko # ficl -i scb_cu_resume.fsml # /etc/init.d/network start Now use command dmesg to see the log info or see the message in /var/log/messages. -Kevin -----Original Message----- From: Louis Zhuang [mailto:lou...@li...] Sent: 2003?2?20? 8:26 To: Mark Haverkamp Cc: Rusty Lynch; Stanley Wang; Kevin Gao; Frank Wang; FITHML Subject: Re: [Fault-injection-developer] RE: e100 frame reception test result draft. On Thu, 2003-02-20 at 00:26, Mark Haverkamp wrote: > If that includes the code too, that would be great. I'm interested in > seeing how a test of a driver is implemented. As you wish, test code are there (and simple). ;-) - Louis |
|
From: Louis Z. <lou...@li...> - 2003-02-20 06:04:50
|
FYI. So our DR/DBP will wait for Vamsi's coming kprobes against 2.5.62. -----Forwarded Message----- > From: Vamsi Krishna S . <va...@in...> > To: Louis Zhuang <lou...@li...> > Cc: Frank Wang <fra...@in...>, Stanley Wang <sta...@in...>, Rusty Lynch <ru...@li...> > Subject: Re: about debug execption in kprobes > Date: 20 Feb 2003 11:33:55 +0530 > > On Wed, Feb 19, 2003 at 05:49:49PM +0800, Louis Zhuang wrote: > > Dear Vamsi, > > I found current kernel had changed debug execption from trap gate to > > int gate. It would conflict with your kprobes. Because our some code > > depend on your kprobes, I'd like to know what is your opion about that. > > Looking forward to your reply. > > > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0302.1/0081.html > > -- > I like it. kprobes too turns trap 1 into an interrupt gate. So, this will > make kprobes patch slightly smaller. kprobes also turns trap 1 into a > ring 3 accessible trap, but I doubt that is really needed at the moment. > > I will send out a kprobes patch against 2.5.62. > > Thanks for pointing this out. > --Vamsi. > -- > Vamsi Krishna S. > Linux Technology Center, > IBM Software Lab, Bangalore. > Ph: +91 80 5044959 > Internet: va...@in... -- Yours truly, Louis Zhuang --------------- Fault Injection Test Harness Project BK tree: http://fault-injection.bkbits.net/linux-2.5 Home Page: http://sf.net/projects/fault-injection |
|
From: Louis Z. <lou...@li...> - 2003-02-20 01:47:46
|
http://linux.bkbits.net:8080/linux-2.5 || ||------------------------------------------------ || || \/(pulls from) || bk://fau...@fa.../2.5-fi || || \/ (pulls from) || bk://fau...@fa.../2.5-kprobes || || || || \/(pulls from) \/(pulls from) bk://fau...@fa.../2.5-fi-extern 2.5-fi repo put main stuffs in FITH, incluing fi core, kmmio, kirq, page-fault interceptor (mmio interceptor), fake irq and code segments and testing. 2.5-kprobes will be our tree for tracing kprobes. 2.5-fi-extern will include all 2.5-fi stuffs and other add-ons which depends on kprobes (DR, DBP). P.S. the linux-2.5 repo in fault-injection.bkbits.net will be out-of-date as soon as 2.5-fi-extern is ready. -- Yours truly, Louis Zhuang --------------- Fault Injection Test Harness Project BK tree: http://fault-injection.bkbits.net/linux-2.5 Home Page: http://sf.net/projects/fault-injection |
|
From: Rusty L. <ru...@li...> - 2003-02-20 01:03:32
|
On Wed, 2003-02-19 at 16:39, Louis Zhuang wrote:
> On Wed, 2003-02-19 at 09:08, Rusty Lynch wrote:
> > > > Cool! It is already a truth in my local development machine. I'd like to
> > > > see that... IMHO, I'd like to split more trees, for example,
> > > > original linux-2.5 =======> fi1 ===============||
> > > > || ||===> fi-all
> > > > ||==> kprobes ==> fi2 ===||
> > > >
> > > > fi1 tree is the FITH stuffs independent, fi2 tree is FITH stuffs
> > > > dependent on kprobes, fi-all is only an integrated tree.
> > > >
> > > > - Louis
> >
> > hmmm... What changes would you make on top of the kprobes tree that does
> > not have any dependency on the core fault injection code?
> Oh, you are right. so dependency diagram should be
> original linux-2.5 =======> fi1
> || ||===> fi2
> ||==> kprobes ===========||
>
> >
> > My biggest concern (even with my original suggestion) is that the
> > available fault injection bk trees would be confusing for both the
> > casual observer and developers trying to get involved. I would really
> > like to have only one tree that is _the_ fault injection tree, and then
> > a couple more trees that experiment with some additional code based on
> > external dependencies.
> In fact, "fi1" includes almost all things in FITH, including fi_core,
> kmmio, MMIO interceptor, kirq, fake irq interceptor, code segments,
> testing. Only DR and DBP will be put into . I admit the name is
> confusing... maybe we can change "fi1" to "fi" and change "fi2" to
> "fi-ext"...
lets use "fi" for the main (no external dependencies) bk tree, and
fi-extern for the tree that pulls from fi and kprobes. Hopefully we
only ever have one external tree to pull from.
--rustyl
|
|
From: Gao, K. <kev...@in...> - 2003-02-20 00:41:26
|
Based on your message, I think that is because the code of FITH is outdated. Please download the newest version of FITH. Thanks -Kevin -----Original Message----- From: Mark Haverkamp [mailto:ma...@os...] Sent: 2003?2?20? 0:16 To: Louis Zhuang Cc: Kevin Gao; FITHML Subject: RE: [Fault-injection-developer] FITH test ABAT has updated. On Tue, 2003-02-18 at 16:33, Louis Zhuang wrote: > On Wed, 2003-02-19 at 00:49, Mark Haverkamp wrote: > > OK, I assume that what you want showed up in dmesg. If this isn't the > > right data let me know where to look. > > > > > > > > FI_TEST: 309 jiffies = 90033991 > > #310 fi_test : COMMAND_IO_READ > > #311 fi_test : Expect read 0X5A* from parellel port register! > > > > #312 fi_test : 0XFF was read from parellel port register! > Oh... it is the evil. fi_test assume your parellel is on 0x378. your can > change the port address in fi_test.c:36 > > - Louis Thanks. I checked my BIOS setup and the parallel port was disabled. I enabled it and tried the echo command and this time it looks like it worked. Feb 19 08:21:02 markh2 kernel: FI_TEST: 77 jiffies = 2189976 Feb 19 08:21:02 markh2 kernel: #78 fi_test : COMMAND_IO_READ Feb 19 08:21:02 markh2 kernel: #79 fi_test : Expect read 0X5A* from parellel port register! Feb 19 08:21:02 markh2 kernel: Feb 19 08:21:02 markh2 kernel: #80 fi_test : 0X5A was read from parellel port register! Unfortunately, the test run still has lots of failures. ************Start FITH test at 07:47:50 19-02-03 Wednesday!************ ------------------------------------------------------------------- Original PPIO readb function works abnormally! Test abandoned! Original PPIO readw function works abnormally! Test abandoned! Original PPIO readl function works abnormally! Test abandoned! Original PPIO writeb function works abnormally! Test abandoned! Original PPIO writew function works abnormally! Test abandoned! Original PPIO writel function works abnormally! Test abandoned! ------------------------------------------------------------------- Original MMIO readb function works abnormally! Test abandoned! Original MMIO readw function works abnormally! Test abandoned! Original MMIO readl function works abnormally! Test abandoned! Original MMIO writeb function works abnormally! Test abandoned! Original MMIO writew function works abnormally! Test abandoned! Original MMIO writel function works abnormally! Test abandoned! ------------------------------------------------------------------- Precondition function test failed! Test abandoned! Skip function test failed! Test abandoned! Stop function test failed! Test abandoned! Protection_mask function test failed! Test abandoned! No corrupt action function test failed! Test abandoned! ------------------------------------------------------------------- IO_address_zero test passed IO_address_overrange test passed MMIO_address_zero test passed MMIO_address_overrange test passed Corrupt 8 bit to 16 bit test failed Corrupt 16 bit to 32 bit test failed Same trigger in one faultset test passed Invalid trigger mode (HZ) test failed Invalid trigger mode (skip) test failed Invalid trigger mode (stop) test failed ------------------------------------------------------------------- **********FITH FUNCTIONALITY TEST RESULT********** Original I/O read function works abnormally! Original I/O write function works abnormally! Original MMI/O read function works abnormally! Original MMI/O write function works abnormally! Faultset preconditon test failed! Faultset trigger skip test failed! Faultset stop pattern test failed! Faultset hardware protect test failed! Trigger without action test failed! The whole boundary test failed! ************************************************** **********Complete FITH test at 07:48:06 19-02-03 Wednesday!********** Here is my /var/log/messages output if it helps. Feb 19 07:47:45 markh2 kernel: #0 fi_test : mmio_address = d88fc000 Feb 19 07:47:50 markh2 kernel: FI_TEST: 1 jiffies = 197742 Feb 19 07:47:50 markh2 kernel: #2 fi_test : COMMAND_IO_READ Feb 19 07:47:50 markh2 kernel: #3 fi_test : Expect read 0X5A* from parellel port register! Feb 19 07:47:50 markh2 kernel: Feb 19 07:47:50 markh2 kernel: #4 fi_test : 0X5A was read from parellel port register! Feb 19 07:47:50 markh2 kernel: Feb 19 07:47:50 markh2 kernel: FI_TEST: 5 jiffies = 197825 Feb 19 07:47:50 markh2 kernel: #6 fi_test : COMMAND_IO_READW Feb 19 07:47:50 markh2 kernel: #7 fi_test : Expect read 0X5A* from parellel port register! Feb 19 07:47:50 markh2 kernel: Feb 19 07:47:50 markh2 kernel: #8 fi_test : 0X5A was read from parellel port register! Feb 19 07:47:50 markh2 kernel: Feb 19 07:47:50 markh2 kernel: FI_TEST: 9 jiffies = 197909 Feb 19 07:47:50 markh2 kernel: #10 fi_test : COMMAND_IO_READL Feb 19 07:47:50 markh2 kernel: #11 fi_test : Expect read 0X5A* from parellel port register! Feb 19 07:47:50 markh2 kernel: Feb 19 07:47:50 markh2 kernel: #12 fi_test : 0X5A was read from parellel port register! Feb 19 07:47:50 markh2 kernel: Feb 19 07:47:51 markh2 kernel: FI_TEST: 13 jiffies = 197993 Feb 19 07:47:51 markh2 kernel: #14 fi_test : COMMAND_IO_WRITE Feb 19 07:47:51 markh2 kernel: #15 fi_test : Write 0X5A* to parellel port register! Feb 19 07:47:51 markh2 kernel: Feb 19 07:47:51 markh2 kernel: #16 fi_test : 0X5A was write to parellel port register! Feb 19 07:47:51 markh2 kernel: Feb 19 07:47:51 markh2 kernel: FI_TEST: 17 jiffies = 198076 Feb 19 07:47:51 markh2 kernel: #18 fi_test : COMMAND_IO_WRITEW Feb 19 07:47:51 markh2 kernel: #19 fi_test : Write 0X5A* to parellel port register! Feb 19 07:47:51 markh2 kernel: Feb 19 07:47:51 markh2 kernel: #20 fi_test : 0X5A was write to parellel port register! Feb 19 07:47:51 markh2 kernel: Feb 19 07:47:51 markh2 kernel: FI_TEST: 21 jiffies = 198161 Feb 19 07:47:51 markh2 kernel: #22 fi_test : COMMAND_IO_WRITEL Feb 19 07:47:51 markh2 kernel: #23 fi_test : Write 0X5A* to parellel port register! Feb 19 07:47:51 markh2 kernel: Feb 19 07:47:51 markh2 kernel: #24 fi_test : 0X5A was write to parellel port register! Feb 19 07:47:51 markh2 kernel: Feb 19 07:47:51 markh2 kernel: FI_TEST: 25 jiffies = 198252 Feb 19 07:47:51 markh2 kernel: #26 fi_test : COMMAND_MMIO_READ Feb 19 07:47:51 markh2 kernel: #27 fi_test : Expect read 0X5A* from MMI/O address Feb 19 07:47:51 markh2 kernel: #28 fi_test : 0X5A was read from MMI/O address Feb 19 07:47:51 markh2 kernel: FI_TEST: 29 jiffies = 198336 Feb 19 07:47:51 markh2 kernel: #30 fi_test : COMMAND_MMIO_READW Feb 19 07:47:51 markh2 kernel: #31 fi_test : Expect read 0X5A* from MMI/O address Feb 19 07:47:51 markh2 kernel: #32 fi_test : 0X5A5A was read from MMI/O address Feb 19 07:47:51 markh2 kernel: FI_TEST: 33 jiffies = 198420 Feb 19 07:47:51 markh2 kernel: #34 fi_test : COMMAND_MMIO_READL Feb 19 07:47:51 markh2 kernel: #35 fi_test : Expect read 0X5A* from MMI/O address Feb 19 07:47:51 markh2 kernel: #36 fi_test : 0X5A5A5A5A was read from MMI/O address Feb 19 07:47:51 markh2 kernel: FI_TEST: 37 jiffies = 198504 Feb 19 07:47:51 markh2 kernel: #38 fi_test : COMMAND_MMIO_WRITE Feb 19 07:47:51 markh2 kernel: #39 fi_test : Write 0X5A* to MMI/O address Feb 19 07:47:51 markh2 kernel: #40 fi_test : 0X5A was write to MMI/O address Feb 19 07:47:51 markh2 kernel: FI_TEST: 41 jiffies = 198589 Feb 19 07:47:51 markh2 kernel: #42 fi_test : COMMAND_MMIO_WRITEW Feb 19 07:47:51 markh2 kernel: #43 fi_test : Write 0X5A* to MMI/O address Feb 19 07:47:51 markh2 kernel: #44 fi_test : 0X5A5A was write to MMI/O address Feb 19 07:47:51 markh2 kernel: FI_TEST: 45 jiffies = 198673 Feb 19 07:47:51 markh2 kernel: #46 fi_test : COMMAND_MMIO_WRITEL Feb 19 07:47:51 markh2 kernel: #47 fi_test : Write 0X5A* to MMI/O address Feb 19 07:47:51 markh2 kernel: #48 fi_test : 0X5A5A5A5A was write to MMI/O address Feb 19 07:47:51 markh2 kernel: trigger_ctl_store: Invalid command format: add, 8 tokens found Feb 19 07:47:51 markh2 kernel: FI_TEST: 49 jiffies = 198788 Feb 19 07:47:51 markh2 kernel: #50 fi_test : COMMAND_IO_READ Feb 19 07:47:51 markh2 kernel: #51 fi_test : Expect read 0X5A* from parellel port register! Feb 19 07:47:51 markh2 kernel: Feb 19 07:47:51 markh2 kernel: #52 fi_test : 0X5A was read from parellel port register! Feb 19 07:47:51 markh2 kernel: Feb 19 07:47:51 markh2 kernel: del_trigger_by_name: trigger precondition does not exist Feb 19 07:47:51 markh2 kernel: add_trigger: Unable to arm the trigger, unregister skip_pattern Feb 19 07:47:51 markh2 kernel: FI_TEST: 53 jiffies = 198904 Feb 19 07:47:51 markh2 kernel: #54 fi_test : COMMAND_IO_READ Feb 19 07:47:51 markh2 kernel: #55 fi_test : Expect read 0X5A* from parellel port register! Feb 19 07:47:51 markh2 kernel: Feb 19 07:47:51 markh2 kernel: #56 fi_test : 0X5A was read from parellel port register! Feb 19 07:47:51 markh2 kernel: Feb 19 07:47:52 markh2 kernel: del_trigger_by_name: trigger skip_pattern does not exist Feb 19 07:47:52 markh2 kernel: add_trigger: Unable to arm the trigger, unregister stop_pattern Feb 19 07:47:52 markh2 kernel: FI_TEST: 57 jiffies = 199047 Feb 19 07:47:52 markh2 kernel: #58 fi_test : COMMAND_IO_READ Feb 19 07:47:52 markh2 kernel: #59 fi_test : Expect read 0X5A* from parellel port register! Feb 19 07:47:52 markh2 kernel: Feb 19 07:47:52 markh2 kernel: #60 fi_test : 0X5A was read from parellel port register! Feb 19 07:47:52 markh2 kernel: Feb 19 07:47:52 markh2 kernel: del_trigger_by_name: trigger stop_pattern does not exist Feb 19 07:47:52 markh2 kernel: trigger_ctl_store: Invalid command format: add, 11 tokens found Feb 19 07:47:52 markh2 kernel: FI_TEST: 61 jiffies = 199161 Feb 19 07:47:52 markh2 kernel: #62 fi_test : COMMAND_IO_READ Feb 19 07:47:52 markh2 kernel: #63 fi_test : Expect read 0X5A* from parellel port register! Feb 19 07:47:52 markh2 kernel: Feb 19 07:47:52 markh2 kernel: #64 fi_test : 0X5A was read from parellel port register! Feb 19 07:47:52 markh2 kernel: Feb 19 07:47:52 markh2 kernel: del_trigger_by_name: trigger hw_protected does not exist Feb 19 07:47:52 markh2 kernel: add_trigger: Unable to arm the trigger, unregister no_action Feb 19 07:47:52 markh2 kernel: FI_TEST: 65 jiffies = 199275 Feb 19 07:47:52 markh2 kernel: #66 fi_test : COMMAND_IO_READ Feb 19 07:47:52 markh2 kernel: #67 fi_test : Expect read 0X5A* from parellel port register! Feb 19 07:47:52 markh2 kernel: Feb 19 07:47:52 markh2 kernel: #68 fi_test : 0X5A was read from parellel port register! Feb 19 07:47:52 markh2 kernel: Feb 19 07:47:52 markh2 kernel: del_trigger_by_name: trigger no_action does not exist Feb 19 07:47:53 markh2 kernel: add_trigger: Unable to arm the trigger, unregister io_overrange Feb 19 07:47:56 markh2 kernel: add_trigger: Unable to arm the trigger, unregister 8_16 Feb 19 07:47:56 markh2 kernel: FI_TEST: 69 jiffies = 203528 Feb 19 07:47:56 markh2 kernel: #70 fi_test : COMMAND_IO_READW Feb 19 07:47:56 markh2 kernel: #71 fi_test : Expect read 0X5A* from parellel port register! Feb 19 07:47:56 markh2 kernel: Feb 19 07:47:56 markh2 kernel: #72 fi_test : 0X5A was read from parellel port register! Feb 19 07:47:56 markh2 kernel: Feb 19 07:47:56 markh2 kernel: del_trigger_by_name: trigger 8_16 does not exist Feb 19 07:47:57 markh2 kernel: FI_TEST: 73 jiffies = 204636 Feb 19 07:47:57 markh2 kernel: #74 fi_test : COMMAND_MMIO_READL Feb 19 07:47:57 markh2 kernel: #75 fi_test : Expect read 0X5A* from MMI/O address Feb 19 07:47:57 markh2 kernel: Feb 19 07:47:57 markh2 last message repeated 5 times Feb 19 07:47:57 markh2 kernel: #76 fi_test : 0X5A5AEF23 was read from MMI/O address Feb 19 07:47:58 markh2 kernel: add_trigger: Unable to arm the trigger, unregister two_in_one1 Feb 19 07:47:58 markh2 kernel: add_trigger: Unable to arm the trigger, unregister two_in_one2 Feb 19 07:47:59 markh2 kernel: add_trigger: Unable to arm the trigger, unregister invalid1 Feb 19 07:48:00 markh2 kernel: add_trigger: Unable to arm the trigger, unregister invalid2 Feb 19 07:48:01 markh2 kernel: add_trigger: Unable to arm the trigger, unregister invalid3 -- Mark Haverkamp <ma...@os...> |
|
From: Louis Z. <lou...@li...> - 2003-02-20 00:40:04
|
On Wed, 2003-02-19 at 09:08, Rusty Lynch wrote:
> > > Cool! It is already a truth in my local development machine. I'd like to
> > > see that... IMHO, I'd like to split more trees, for example,
> > > original linux-2.5 =======> fi1 ===============||
> > > || ||===> fi-all
> > > ||==> kprobes ==> fi2 ===||
> > >
> > > fi1 tree is the FITH stuffs independent, fi2 tree is FITH stuffs
> > > dependent on kprobes, fi-all is only an integrated tree.
> > >
> > > - Louis
>
> hmmm... What changes would you make on top of the kprobes tree that does
> not have any dependency on the core fault injection code?
Oh, you are right. so dependency diagram should be
original linux-2.5 =======> fi1
|| ||===> fi2
||==> kprobes ===========||
>
> My biggest concern (even with my original suggestion) is that the
> available fault injection bk trees would be confusing for both the
> casual observer and developers trying to get involved. I would really
> like to have only one tree that is _the_ fault injection tree, and then
> a couple more trees that experiment with some additional code based on
> external dependencies.
In fact, "fi1" includes almost all things in FITH, including fi_core,
kmmio, MMIO interceptor, kirq, fake irq interceptor, code segments,
testing. Only DR and DBP will be put into . I admit the name is
confusing... maybe we can change "fi1" to "fi" and change "fi2" to
"fi-ext"...
|
|
From: Louis Z. <lou...@li...> - 2003-02-20 00:25:58
|
On Thu, 2003-02-20 at 00:26, Mark Haverkamp wrote: > If that includes the code too, that would be great. I'm interested in > seeing how a test of a driver is implemented. As you wish, test code are there (and simple). ;-) - Louis |
|
From: Rusty L. <ru...@li...> - 2003-02-19 18:09:38
|
> > Cool! It is already a truth in my local development machine. I'd like to
> > see that... IMHO, I'd like to split more trees, for example,
> > original linux-2.5 =======> fi1 ===============||
> > || ||===> fi-all
> > ||==> kprobes ==> fi2 ===||
> >
> > fi1 tree is the FITH stuffs independent, fi2 tree is FITH stuffs
> > dependent on kprobes, fi-all is only an integrated tree.
> >
> > - Louis
hmmm... What changes would you make on top of the kprobes tree that does
not have any dependency on the core fault injection code?
My biggest concern (even with my original suggestion) is that the
available fault injection bk trees would be confusing for both the
casual observer and developers trying to get involved. I would really
like to have only one tree that is _the_ fault injection tree, and then
a couple more trees that experiment with some additional code based on
external dependencies.
--rustyl
|
|
From: Rusty L. <ru...@li...> - 2003-02-19 16:40:26
|
On Wed, 2003-02-19 at 08:26, Mark Haverkamp wrote: > On Tue, 2003-02-18 at 16:12, Rusty Lynch wrote: > > Kevin, > > > > Could you publish a test plan with detailed test procedures for > > recreating your e100 test cases. For the purposes of the fault > > injection project, it is actually more valuable to see a practical > > example of how to utilize the fault injection features to perform useful > > device driver testing then it is to publish the results of testing. > > If that includes the code too, that would be great. I'm interested in > seeing how a test of a driver is implemented. > > Mark. > Ah, yes. Code is a must, even if it is a shell script that is reading/writing to sysfs files. As a mater of fact, lets aim for all test cases to be suitable for inclusion into LTP (http://ltp.sourceforge.net) which has some not so strict guidelines for how to create a test case. --rustyl |
|
From: Mark H. <ma...@os...> - 2003-02-19 16:28:11
|
On Tue, 2003-02-18 at 16:12, Rusty Lynch wrote: > Kevin, >=20 > Could you publish a test plan with detailed test procedures for > recreating your e100 test cases. For the purposes of the fault > injection project, it is actually more valuable to see a practical > example of how to utilize the fault injection features to perform usefu= l > device driver testing then it is to publish the results of testing. =20 If that includes the code too, that would be great. I'm interested in seeing how a test of a driver is implemented. Mark. >=20 > (Don't get me wrong, test results are a good thing, especially if you > find a reproducible bug.) >=20 > --rustyl >=20 > On Wed, 2003-02-19 at 01:35, Wang, Stanley wrote: > > =20 > >=20 > > -----Original Message----- > > From: Gao, Kevin=20 > > Sent: 2003-02-19 17:01 > > To: Zhuang, Louis; Wang, Frank; Wang, Stanley > > Subject: e100 frame reception test result draft. > >=20 > >=20 > > E100 frame reception test has been done, the result draft is as follo= w: > >=20 > > any comment? :) > >=20 > > =20 > >=20 > > -Kevin > >=20 > > =20 > >=20 > > 1. Set =91S=92 bit of RFD which is under received when driver rea= ds the > > SCB status register. Driver always send a RU_START command.=20 > >=20 > > =20 > >=20 > > OK. The e100 driver checks the hardware status and reacts properly := ) > >=20 > > =20 > >=20 > > 2. Set =91S=92 bit of RFD which has been received when driver rea= ds the > > SCB status register. Driver ignores the operation.=20 > >=20 > > =20 > >=20 > > OK. The 'S' bit is set by driver and read by hardware. Hence the driv= er > > doesn't care it.=20 > >=20 > > <?xml:namespace prefix =3D o ns =3D "urn:schemas-microsoft-com:office= :office" /> > >=20 > >=20 > > 3. Set both =91C=92 and =91OK=92 bit of RFD to zero when driver r= eads the > > SCB status register, the network cannot start, and driver will hanged= , a > > timeout will throw out.=20 > >=20 > > If the 'C' bit equals zero, the driver will treat this rfd as an inco= mplete > > packet and just wait untile 'C' equals one.=20 > >=20 > > =20 > >=20 > > 4. Set =91C=92 bit of RFD to 0, and set =91OK=92 bit of RFD to 1 = when driver > > reads the SCB status register, the result is the same as process 2.=20 > >=20 > > =20 > >=20 > > process 2 or 3 ? > >=20 > > =20 > >=20 > > =20 > >=20 > > 5. Set =91C=92 bit of RFD to 1, and set =91OK=92 bit of RFD to 0 = when driver > > reads the SCB status register, the result is the same as process 2.=20 > >=20 > > =20 > >=20 > > process 2 or 3 ?=20 > >=20 > > =20 > >=20 > > 6. Set =91CRC=92 bit of RFD to 1 when driver reads the SCB status > > register, the driver ignores this operation.=20 > >=20 > > =20 > >=20 > > The driver should check this bit. > >=20 > > =20 > >=20 > > =20 > >=20 > > 7. Set =91Alignment error=92 bit of RFD to 1 when driver reads th= e SCB > > status register, the driver ignores this operation.=20 > >=20 > > =20 > >=20 > > The driver should check this bit.=20 > >=20 > > =20 > >=20 > > 8. Set =91Run out of buffer=92 bit of RFD to 1 when driver reads = the SCB > > status register, the driver ignores this operation. > >=20 > > =20 > >=20 > > The driver should check this bit. > >=20 > > 9. Set =91Frame too short=92 bit of RFD to 1 when driver reads th= e SCB > > status register, the driver ignores this operation. > >=20 > > The driver should check this bit. > > =20 > > =20 > > =20 > >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Fault-injection-developer mailing list > Fau...@li... > https://lists.sourceforge.net/lists/listinfo/fault-injection-developer --=20 Mark Haverkamp <ma...@os...> |
25 messages has been excluded from this view by a project administrator.
