| /linux-4.4.14/arch/powerpc/kernel/ |
| D | irq.c | 99 unsigned long happened; in get_irq_happened() local
102 : "=r" (happened) : "i" (offsetof(struct paca_struct, irq_happened))); in get_irq_happened()
104 return happened; in get_irq_happened()
142 unsigned char happened = local_paca->irq_happened; in __check_irq_replay() local
162 if ((happened & PACA_IRQ_DEC) || decrementer_check_overflow()) in __check_irq_replay()
167 if (happened & PACA_IRQ_EE) in __check_irq_replay()
176 if (happened & PACA_IRQ_EE_EDGE) in __check_irq_replay()
180 if (happened & PACA_IRQ_DBELL) in __check_irq_replay()
184 if (happened & PACA_IRQ_DBELL) { in __check_irq_replay()
193 if (happened & PACA_IRQ_HMI) in __check_irq_replay()
|
| /linux-4.4.14/drivers/usb/usbip/ |
| D | usbip_event.c | 119 int happened = 0; in usbip_event_happened() local
123 happened = 1; in usbip_event_happened()
126 return happened; in usbip_event_happened()
|
| D | usbip_protocol.txt | 300 | | | otherwise some kind of error happened.
|
| /linux-4.4.14/Documentation/networking/ |
| D | xfrm_sync.txt | 149 the change happened as a result of an update.
155 happened) is set to inform the user what happened.
|
| D | lapb-module.txt | 221 what has happened. In all cases the LAPB link can be regarded as being
|
| D | netdev-FAQ.txt | 97 Q: I sent a patch and I'm wondering what happened to it. How can I tell
|
| /linux-4.4.14/arch/arm/kernel/ |
| D | hyp-stub.S | 60 strne \reg1, [\reg2, \reg3] @ record what happened and give up
|
| /linux-4.4.14/Documentation/ABI/obsolete/ |
| D | sysfs-block-zram | 30 failed reads happened on this device.
38 failed writes happened on this device.
|
| /linux-4.4.14/Documentation/parisc/ |
| D | debugging | 36 where exactly it happened. If you're lucky the IAOQ will point to the
|
| /linux-4.4.14/fs/pstore/ |
| D | Kconfig | 22 messages, even if no oops or panic happened.
|
| /linux-4.4.14/Documentation/device-mapper/ |
| D | log-writes.txt | 10 exactly as it happened originally.
51 which isn't quite what happened and wouldn't be caught during the log replay.
|
| /linux-4.4.14/Documentation/usb/ |
| D | persist.txt | 19 has no way to know what has actually happened. Perhaps the same
57 has happened; look for lines saying "root hub lost power or was reset".
151 happened and will continue to use the partition tables, inodes, and
|
| D | rio.txt | 28 replace it with a fresh one. In my case, what happened is I lost two 16kb
|
| /linux-4.4.14/Documentation/ABI/testing/ |
| D | sysfs-block-zram | 51 failed reads happened on this device.
58 failed writes happened on this device.
|
| /linux-4.4.14/Documentation/leds/ |
| D | ledtrig-oneshot.txt | 7 happened, than the trigger turns the LED on and than keeps it off for a
|
| /linux-4.4.14/arch/frv/kernel/ |
| D | break.S | 321 # return to where the interrupt happened
356 # return to where the trap happened
|
| /linux-4.4.14/Documentation/arm/ |
| D | kernel_user_helpers.txt | 143 Return zero if *ptr was changed or non-zero if no exchange happened.
236 changed or non-zero if no exchange happened.
|
| /linux-4.4.14/arch/openrisc/ |
| D | Kconfig | 113 the last exception has happened in delay slot.
|
| /linux-4.4.14/Documentation/timers/ |
| D | timers-howto.txt | 86 that may have happened for other reasons, or at the
|
| /linux-4.4.14/Documentation/input/ |
| D | rotary-encoder.txt | 65 should have happened, unless it flipped back on half the way. The
|
| D | joystick-api.txt | 118 presses happened at the same time, and similar.
161 The other reason is that you want to know all what happened, and not
|
| D | input.txt | 280 'time' is the timestamp, it returns the time at which the event happened.
|
| /linux-4.4.14/Documentation/frv/ |
| D | kernel-ABI.txt | 174 another flag and resume execution at the point the interrupt happened.
216 determines that the interrupt shouldn't actually have happened. It
|
| /linux-4.4.14/Documentation/filesystems/ |
| D | inotify.txt | 43 which happened first. A single queue trivially gives you ordering. Such
|
| D | hpfs.txt | 211 open inode (rarely happened)
|
| D | porting | 125 FS_SINGLE is gone (actually, that had happened back when ->get_sb()
|
| /linux-4.4.14/Documentation/acpi/ |
| D | video_extension.txt | 78 it doesn't even know this happened).
|
| /linux-4.4.14/Documentation/x86/ |
| D | exception-tables.txt | 183 file. But first we want to find out what happened to our code in the
225 What happened? The assembly directives
|
| /linux-4.4.14/Documentation/scheduler/ |
| D | sched-domains.txt | 35 at the time the scheduler_tick() happened and iterates over all sched domains
|
| D | completion.txt | 118 call to complete() - if the call to complete() happened before the call
|
| /linux-4.4.14/Documentation/laptops/ |
| D | sony-laptop.txt | 136 happened to me, this driver could do very bad things to your
|
| /linux-4.4.14/arch/arc/kernel/ |
| D | entry-compact.S | 385 ; paranoid check, given A1 was active when A2 happened, preempt count
|
| /linux-4.4.14/Documentation/ |
| D | oops-tracing.txt | 72 happened in).
106 make fs/buffer.s # or whatever file the bug happened in
|
| D | md-cluster.txt | 90 or other events that happened while waiting for the TOKEN may have made
|
| D | kasan.txt | 120 The header of the report discribe what kind of bug happened and what kind of
|
| D | dma-buf-sharing.txt | 119 the buffer must have happened before map_dma_buf can be called.
208 - at least one map_dma_buf has happened,
|
| D | adding-syscalls.txt | 23 userspace that something has happened, then returning a new file
|
| D | md.txt | 411 happened while the array was read-only). When using version-1
|
| D | memory-barriers.txt | 608 the load from b as having happened before the load from a. In such a
2644 their own loads and stores as if they had happened in program order.
|
| /linux-4.4.14/Documentation/sound/alsa/ |
| D | Procfile.txt | 210 happened.
|
| /linux-4.4.14/Documentation/ABI/stable/ |
| D | sysfs-driver-ib_srp | 116 target. Differs from orig_dgid if port redirection has happened.
|
| /linux-4.4.14/Documentation/isdn/ |
| D | README.x25 | 20 this is experimental code, don't blame me if that happened to you.
|
| D | README | 224 an incoming call happened (RING) and
|
| D | INTERFACE | 536 -1 = An error happened. (Invalid parameters for example.)
|
| /linux-4.4.14/Documentation/i2c/ |
| D | dev-interface | 161 what happened. The 'write' transactions return 0 on success; the
|
| /linux-4.4.14/Documentation/prctl/ |
| D | seccomp_filter.txt | 102 the syscall happened (i.e. it will not point to the syscall
|
| /linux-4.4.14/Documentation/s390/ |
| D | driver-model.txt | 180 event - the event that happened. This can be one of CIO_GONE,
|
| D | s390dbf.txt | 92 happened before the oops. After an oops you can reactivate the debug feature
|
| D | Debugging390.txt | 1831 happened. Provided they have an identical copy of this program with debugging
|
| /linux-4.4.14/Documentation/hid/ |
| D | uhid.txt | 146 maintenance actions happened).
|
| /linux-4.4.14/Documentation/ide/ |
| D | ChangeLog.ide-cd.1994-2004 | 46 * Fix usage count leak in cdrom_open, which happened
|
| D | ChangeLog.ide-tape.1995-2002 | 47 * we won't cause an interrupt timeout, as happened
|
| /linux-4.4.14/Documentation/nfc/ |
| D | nfc-hci.txt | 279 error that happened within shdlc or below. If the problem occurs during shdlc
|
| /linux-4.4.14/Documentation/RCU/ |
| D | stallwarn.txt | 240 problem really has happened, and seems to be most likely to
|
| D | whatisRCU.txt | 260 if an update happened while in the critical section, and incur
|
| /linux-4.4.14/scripts/ |
| D | spelling.txt | 474 happend||happened
|
| /linux-4.4.14/Documentation/virtual/uml/ |
| D | UserModeLinux-HOWTO.txt | 3178 happened, so I have to go look at the sigcontent struct in frame 8:
3397 writes to the idle thread's stack. That was the thing that happened
3546 the code the access happened shows that it happened near line 110 of
3593 Looking at the source shows that the fault happened during a call to
3679 that happened. The rest of the structure looks fine, so this probably
3680 is not a case of data corruption. It happened on purpose somehow.
|
| /linux-4.4.14/Documentation/sound/oss/ |
| D | Introduction | 322 port. This has happened to me when playing long files
|
| /linux-4.4.14/arch/m68k/ifpsp060/src/ |
| D | isp.S | 496 # here, we sort out all of the special cases that may have happened.
|
| /linux-4.4.14/kernel/trace/ |
| D | Kconfig | 347 events happened, as well as their results.
|
| /linux-4.4.14/Documentation/scsi/ |
| D | ChangeLog.megaraid | 147 for some reason. It happened randomly.
|
| /linux-4.4.14/Documentation/powerpc/ |
| D | hvcs.txt | 523 after a reboot. What happened?
|
| /linux-4.4.14/Documentation/development-process/ |
| D | 4.Coding | 148 happened?
|
| /linux-4.4.14/Documentation/power/ |
| D | pci.txt | 691 its struct pci_driver object. Once that has happened, the "legacy" PM callbacks
935 resume of the device has happened as a result of a spurious event.
|
| /linux-4.4.14/Documentation/virtual/kvm/ |
| D | timekeeping.txt | 424 condition has happened.
|
| /linux-4.4.14/scripts/dtc/ |
| D | dtc-lexer.lex.c_shipped | 1252 * possible that this happened because the user
|
| /linux-4.4.14/scripts/genksyms/ |
| D | lex.lex.c_shipped | 921 * possible that this happened because the user
|
| /linux-4.4.14/scripts/kconfig/ |
| D | zconf.lex.c_shipped | 1401 * possible that this happened because the user
|
| /linux-4.4.14/Documentation/trace/ |
| D | ftrace.txt | 479 This gets set if so many events happened within a nested
605 why a latency happened. Here is a typical trace.
|
| /linux-4.4.14/Documentation/cdrom/ |
| D | cdrom-standard.tex | 594 independently of the ideas of the respective author who happened to
|
| /linux-4.4.14/drivers/scsi/aic7xxx/ |
| D | aic7xxx.seq | 967 * If we happened to stop on the last segment, then
|
| D | aic79xx.seq | 1788 * If we happened to stop on the last segment, then
|