interrupt-handling

问题 While studying workqueue, I came across WorkQueue flags & constants defined in kernel. I have following doubts which i could not understand. What exactly draining & rescuer mean here? WQ_DRAINING = 1 << 6, /* internal: workqueue is draining */ WQ_RESCUER = 1 << 7, /* internal: workqueue has rescuer */ The number of CPUs defined for unbound workqueues is 4. What if I have an octa core processor. How the unbounded wq will be bounded to cpus. How they decided which CPUs to run as they have now 8

问题 I'm trying to write a simple program that will replace standard keyboard interrupt with a custom one that will decrement a variable. However, it won't work without a call to the old handler. Here is my interrupt handler: handler proc push ax push di dec EF ;pushf ;when these to instructions commented keyboard interrupts handling hangs ;call [OLD] mov al,20h out 20h,al pop di pop ax iret handler endp What actions I should also execute in my handler to make it works without calling the old

问题 I have a java program which creates a lock file to ensure that no other executions run at the same time as it. If the program runs it creates the file, and upon exit, either successful or via an exception, the file is removed. But if the user hits Ctrl+C, closes the terminal, or in some other way interrupts execution, the file is not deleted. Is there any way to detect this interrupt command and ensure that the file is deleted in this case as well? 回答1: You might want to look into shutdown

问题 I'm writing something on the linux scheduler and I need to know which process was running before my interrupt came in.. is the current structure available? If I do current->pid while in the interrupt handler, do I get the pid of the process I interrupted? 回答1: You can, current->pid exists and is the process that was interrupted (may be the idle thread, or any). If you're writing inside the Linux scheduler, you should be very careful. current is changed by the scheduler as it chooses a new

问题 I wanted to know how interrupt handling works from the point any device is interrupted.I know of interrupt handling in bits and pieces and would like to have clear end to end picture of interrupt handing.Let me put across what little I know about interrupt handling. Suppose an FPGA device is interrupted through electrical lines and get some data .Device driver for this FPGA device already had code (Interrupt handler) registered using request_irq function. So now FPGA device have an IRQ line

问题 So I'm having trouble figuring out how to trigger a Timer interrupt (Every 200 cycles) and a button interrupt. When I hit the button interrupt all it seems to do is temporarily pause the counter for a split second and then continue counting. Then it never registers another button interrupt no matter how often I click it on PLP. What the button interrupt is suppose to do is set the register $a1 to 1 (or a non zero number) which is suppose to reset the counter. The Timer interrupt is suppose to

问题 The venerated book Linux Driver Development says that The flags argument passed to spin_unlock_irqrestore must be the same variable passed to spin_lock_irqsave . You must also call spin_lock_irqsave and spin_unlock_irqrestore in the same function; otherwise your code may break on some architectures. Yet I can't find any such restriction required by the official documentation bundled with the kernel code itself. And I find driver code that violates this guidance. Obviously it isn't a good idea

问题 Here is my c code char global_variable = 0; ISR(){ PORTA = global_variable; toggle_led;//to make sure that the interrupt is triggered } int main(){ while(1){ _delay_ms(500); gobal_variable++; PORTB = global_variable; } return 0; } The bottom line is that I have a global variable modified by the main function and read by both the main and ISR - interrupt handler . When the global variable is read by main I get the expected values, but in ISR I get the value that was first assigned to the

问题 I've read (and studied) about Interrupt Handling. What I always fail to understand, is how do we know where to return to (PC / IP) from the Interrupt Handler. As I understand it: An Interrupt is caused by a device (say the keyboard) The relevant handler is called - under the running process. That is, no context switch to the OS is performed. The Interrupt Handler finishes, and passes control back to the running application. The process depicted above, which is my understanding of Interrupt

问题 I have a problem with interrupt processing on the beaglebone black. I have written my own combination of a kernel module and a user-space driver to have access to gpios (see also https://github.com/Terstegge/gpio-bbb). With older kernels, everything was working fine. Using the most recent debian image (kernel 4.14.71-ti-r80), I get errors in the kernel log: [ 461.028013] gpio_bbb: Device /dev/gpio_bbb registered [ 507.507335] gpio_bbb: Requesting GPIO #30 [ 507.507370] Mode: f [ 507.507383]