aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/ide.h
diff options
context:
space:
mode:
authorTejun Heo <tj@kernel.org>2010-06-29 04:07:13 -0400
committerTejun Heo <tj@kernel.org>2010-06-29 04:07:13 -0400
commit7e11629d0efec829cbf62366143ba1081944a70e (patch)
tree946f6383f420fafc89550ad2f7efbdfee441ccbb /include/linux/ide.h
parent18aa9effad4adb2c1efe123af4eb24fec9f59b30 (diff)
workqueue: use shared worklist and pool all workers per cpu
Use gcwq->worklist instead of cwq->worklist and break the strict association between a cwq and its worker. All works queued on a cpu are queued on gcwq->worklist and processed by any available worker on the gcwq. As there no longer is strict association between a cwq and its worker, whether a work is executing can now only be determined by calling [__]find_worker_executing_work(). After this change, the only association between a cwq and its worker is that a cwq puts a worker into shared worker pool on creation and kills it on destruction. As all workqueues are still limited to max_active of one, this means that there are always at least as many workers as active works and thus there's no danger for deadlock. The break of strong association between cwqs and workers requires somewhat clumsy changes to current_is_keventd() and destroy_workqueue(). Dynamic worker pool management will remove both clumsy changes. current_is_keventd() won't be necessary at all as the only reason it exists is to avoid queueing a work from a work which will be allowed just fine. The clumsy part of destroy_workqueue() is added because a worker can only be destroyed while idle and there's no guarantee a worker is idle when its wq is going down. With dynamic pool management, workers are not associated with workqueues at all and only idle ones will be submitted to destroy_workqueue() so the code won't be necessary anymore. Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'include/linux/ide.h')
0 files changed, 0 insertions, 0 deletions
4 IR + 4 IT ... contexts, quirks 0x11 when loading the driver. If you have no supported controller, many PCI, CardBus and even some Express cards which are fully compliant to OHCI-1394 specification are available. If it requires no driver for Windows operating systems, it most likely is. Only specialized shops have cards which are not compliant, they are based on TI PCILynx chips and require drivers for Windows operating systems. The mentioned kernel log message contains the string "physUB" if the controller implements a writable Physical Upper Bound register. This is required for physical DMA above 4 GB (but not utilized by Linux yet). 2) Establish a working FireWire cable connection: Any FireWire cable, as long at it provides electrically and mechanically stable connection and has matching connectors (there are small 4-pin and large 6-pin FireWire ports) will do. If an driver is running on both machines you should see a line like:: firewire_core 0000:15:00.1: created device fw1: GUID 00061b0020105917, S400 on both machines in the kernel log when the cable is plugged in and connects the two machines. 3) Test physical DMA using firescope: On the debug host, make sure that /dev/fw* is accessible, then start firescope:: $ firescope Port 0 (/dev/fw1) opened, 2 nodes detected FireScope --------- Target : <unspecified> Gen : 1 [Ctrl-T] choose target [Ctrl-H] this menu [Ctrl-Q] quit ------> Press Ctrl-T now, the output should be similar to: 2 nodes available, local node is: 0 0: ffc0, uuid: 00000000 00000000 [LOCAL] 1: ffc1, uuid: 00279000 ba4bb801 Besides the [LOCAL] node, it must show another node without error message. 4) Prepare for debugging with early OHCI-1394 initialization: 4.1) Kernel compilation and installation on debug target Compile the kernel to be debugged with CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking: Provide code for enabling DMA over FireWire early on boot) enabled and install it on the machine to be debugged (debug target). 4.2) Transfer the System.map of the debugged kernel to the debug host Copy the System.map of the kernel be debugged to the debug host (the host which is connected to the debugged machine over the FireWire cable). 5) Retrieving the printk buffer contents: With the FireWire cable connected, the OHCI-1394 driver on the debugging host loaded, reboot the debugged machine, booting the kernel which has CONFIG_PROVIDE_OHCI1394_DMA_INIT enabled, with the option ohci1394_dma=early. Then, on the debugging host, run firescope, for example by using -A:: firescope -A System.map-of-debug-target-kernel Note: -A automatically attaches to the first non-local node. It only works reliably if only connected two machines are connected using FireWire. After having attached to the debug target, press Ctrl-D to view the complete printk buffer or Ctrl-U to enter auto update mode and get an updated live view of recent kernel messages logged on the debug target. Call "firescope -h" to get more information on firescope's options. Notes ----- Documentation and specifications: http://halobates.de/firewire/ FireWire is a trademark of Apple Inc. - for more information please refer to: https://en.wikipedia.org/wiki/FireWire