- 19 Dec, 2013 25 commits
-
-
Douglas Gilbert authored
update sg MAINTAINERS file entry: web site and documentation entry Signed-off-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Saurav Kashyap authored
Signed-off-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by:
-
Saurav Kashyap authored
Signed-off-by:
-
Armen Baloyan authored
Signed-off-by:
Armen Baloyan <armen.baloyan@qlogic.com> Signed-off-by:
-
Sawan Chandak authored
Signed-off-by:
Sawan Chandak <sawan.chandak@qlogic.com> Signed-off-by:
-
Chad Dupuis authored
Signed-off-by:
Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by:
-
Sawan Chandak authored
Signed-off-by:
-
Chad Dupuis authored
Signed-off-by:
-
Armen Baloyan authored
[SCSI] qla2xxx: Add changes to obtain ISPFX00 adapters product information in accordance with firmware update. Signed-off-by:
-
Armen Baloyan authored
Signed-off-by:
-
Atul Deshmukh authored
Signed-off-by:
Atul Deshmukh <atul.deshmukh@qlogic.com> Signed-off-by:
-
Joe Carnuccio authored
Signed-off-by:
Joe Carnuccio <joe.carnuccio@qlogic.com> Signed-off-by:
-
Joe Carnuccio authored
Signed-off-by:
-
Armen Baloyan authored
Signed-off-by:
-
Chad Dupuis authored
If we become disconnected from the PCI bus/PCIe fabric, there can be long delays in register reads which can cause erroneous decisions to be made and cause a soft lockup if a lock is held too long. As a preventative measure, check for a disconnection (register reads that return -1) and then disable the board if we find ourselves in this condition. For now, check in our interrupt handlers and the per adapter one second timer. Signed-off-by:
-
Chad Dupuis authored
Signed-off-by:
-
Chad Dupuis authored
[SCSI] Revert "qla2xxx: Ramp down queue depth for attached SCSI devices when driver resources are low." This reverts commit 3c290d0bSigned-off-by:
-
Saurav Kashyap authored
[SCSI] qla2xxx: Don't consider the drivers knocked out of IDC participation for future reset recovery process. Signed-off-by:
-
Chad Dupuis authored
Signed-off-by:
-
Joe Carnuccio authored
Signed-off-by:
-
Sawan Chandak authored
Signed-off-by:
-
Chad Dupuis authored
If the execute firmware command fails we do not stop the rest of the initialization process which will continue to fail so if we encounter an error simply short circuit the process. Signed-off-by:
-
Armen Baloyan authored
Signed-off-by:
-
Stephen M. Cameron authored
If a fifo full condition is encountered, i/o requests will stack up in the h->reqQ queue. The only thing which empties this queue is start_io, which only gets called when new i/o requests come in. If none are forthcoming, i/o in h->reqQ will be stalled. To fix this, whenever fifo full condition is encountered, this is recorded, and the interrupt handler examines this to see if a fifo full condition was recently encountered when a command completes and will call start_io to prevent i/o's in h->reqQ from getting stuck. I've only ever seen this problem occur when running specialized test programs that pound on the the CCISS_PASSTHRU ioctl. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
-
Stephen M. Cameron authored
Cap CCISS_BIG_PASSTHRU as well. If an attempt is made to exceed this, ioctl() will return -1 with errno == EAGAIN. This is to prevent a userland program from exhausting all of pci_alloc_consistent memory. I've only seen this problem when running a special test program designed to provoke it. 20 concurrent commands via the passthru ioctls (not counting SG_IO) should be more than enough. Signed-off-by:
-
- 16 Dec, 2013 12 commits
-
-
Stephen M. Cameron authored
Signed-off-by:
Scott Teel <scott.teel@hp.com> Acked-by:
-
Stephen M. Cameron authored
We were leaking a command buffer if a DMA mapping error was encountered in the CCISS_BIG_PASSTHRU ioctl. Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
The hardware guys tell us that after initiating a software reset via the doorbell register we need to wait 5 seconds before attempting to talk to the board *at all*. This means that we cannot watch the board to verify it transitions from "ready" to to "not ready" then back "ready", since this transition will most likely happen during those 5 seconds (though we can still verify the reset happens by watching the "driver version" field get cleared.) Signed-off-by:
-
Stephen M. Cameron authored
There's no point in trying since it can't work, and if you do try, it will just hang the system on shutdown. Signed-off-by:
-
Aaron Lu authored
Migrate sr to make use of block layer runtime PM. Accordingly, the SCSI bus layer runtime PM callback is simplified as all SCSI drivers implementing runtime PM now use the block layer's request-based mechanism. Note that due to the device will be polled by kernel at a constant interval, if the autosuspend delay is set longer than the polling interval then the device will never suspend. Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Dan Carpenter authored
We should cap the size of memcpy() because it comes from the network and can't be trusted. Fixes: 26ffd7b4 ('[SCSI] qla4xxx: Add support to set CHAP entries') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Vikas Chaudhary <vikas.chaudhary@qlogic.com> Signed-off-by:
-
Adheer Chandravanshi authored
Signed-off-by:
Adheer Chandravanshi <adheer.chandravanshi@qlogic.com> Signed-off-by:
-
Harish Zunjarrao authored
Added support to display and update additional network parameters through iscsiadm. Signed-off-by:
Harish Zunjarrao <harish.zunjarrao@qlogic.com> Signed-off-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
-
Harish Zunjarrao authored
Added support to display and update additional network parameters through iscsiadm. Signed-off-by:
-
Harish Zunjarrao authored
Remove explicit values assignment for net param enums. Signed-off-by:
-
Akinobu Mita authored
Instead of repeatedly calling driver_create_file() to create driver attribute files, This achieves the same thing by constructing an array of driver_attribute and setting it to bus_type->drv_groups. This change simplifies both creation and destruction of the attribute files, and also removes sparse warning caused by driver_attributes which are unnecessarily declared as global. Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Acked-by:
-
- 15 Dec, 2013 3 commits
-
-
Linus Torvalds authored
-
Matias Bjorling authored
For NUMA systems, initializing the blk-mq layer and using per node hctx. We initialize submit queues to 1, while blk-mq nr_hw_queues is initialized to the number of NUMA nodes. This makes the null_init_hctx function overwrite memory outside of what it allocated. In my case it lead to writing garbage into struct request_queue's mq_map. Signed-off-by:
Matias Bjorling <m@bjorling.me> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Sergey Senozhatsky authored
Since commit ec39f64b ("drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups") radeon_hwmon_init() is using hwmon_device_register_with_groups(), which sets `rdev' as a device private driver_data, while hwmon_attributes_visible() and radeon_hwmon_show_temp_thresh() are still waiting for `drm_device'. Fix them by using dev_get_drvdata(), in order to avoid this oops: BUG: unable to handle kernel paging request at 0000000000001e28 IP: [<ffffffffa02ae8b4>] hwmon_attributes_visible+0x18/0x3d [radeon] PGD 15057e067 PUD 151a8e067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Call Trace: internal_create_group+0x114/0x1d9 sysfs_create_group+0xe/0x10 sysfs_create_groups+0x22/0x5f device_add+0x34f/0x501 device_register+0x15/0x18 hwmon_device_register_with_groups+0xb5/0xed radeon_hwmon_init+0x56/0x7c [radeon] radeon_pm_init+0x134/0x7e5 [radeon] radeon_modeset_init+0x75f/0x8ed [radeon] radeon_driver_load_kms+0xc6/0x187 [radeon] drm_dev_register+0xf9/0x1b4 [drm] drm_get_pci_dev+0x98/0x129 [drm] radeon_pci_probe+0xa3/0xac [radeon] pci_device_probe+0x6e/0xcf driver_probe_device+0x98/0x1c4 __driver_attach+0x5c/0x7e bus_for_each_dev+0x7b/0x85 driver_attach+0x19/0x1b bus_add_driver+0x104/0x1ce driver_register+0x89/0xc5 __pci_register_driver+0x58/0x5b drm_pci_init+0x86/0xea [drm] radeon_init+0x97/0x1000 [radeon] do_one_initcall+0x7f/0x117 load_module+0x1583/0x1bb4 SyS_init_module+0xa0/0xaf Signed-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Alexander Deucher <Alexander.Deucher@amd.com> Signed-off-by:
-
