scsi: qla2xxx: Fix apparent cut-n-paste error.
commit 093df73771bac8a37d607c0e705d157a8cef4c5c introduces two bodies of code that look similar but with s/req/rsp/ in the second instance. But in one case, it looks like this conversion was missed. Signed-off-by: Dave Jones <da...@codemonkey.org.uk> diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c index 8521cfe302e9..ad4edc13ebcf 100644 --- a/drivers/scsi/qla2xxx/qla_os.c +++ b/drivers/scsi/qla2xxx/qla_os.c @@ -466,7 +466,7 @@ static void qla2x00_free_queues(struct qla_hw_data *ha) continue; rsp = ha->rsp_q_map[cnt]; - clear_bit(cnt, ha->req_qid_map); + clear_bit(cnt, ha->rsp_qid_map); ha->rsp_q_map[cnt] = NULL; spin_unlock_irqrestore(>hardware_lock, flags); qla2x00_free_rsp_que(ha, rsp); -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
blk-mq vs kmemleak
After a fuzzing run recently, I noticed that the machine had oom'd, and
killed everything, but there was still 3GB of memory still in use, that
I couldn't even reclaim with /proc/sys/vm/drop_caches
So I enabled kmemleak. After applying this..
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index cf79f110157c..6dc18dbad9ec 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -553,8 +553,8 @@ static struct kmemleak_object *create_object(unsigned long
ptr, size_t size,
object = kmem_cache_alloc(object_cache, gfp_kmemleak_mask(gfp));
if (!object) {
- pr_warning(Cannot allocate a kmemleak_object structure\n);
- kmemleak_disable();
+ //pr_warning(Cannot allocate a kmemleak_object structure\n);
+ //kmemleak_disable();
return NULL;
}
otherwise it would disable itself within a minute of runtime.
I notice now that I'm seeing a lot of traces like this..
unreferenced object 0x8800ba8202c0 (size 320):
comm kworker/u4:1, pid 38, jiffies 4294741176 (age 46887.690s)
hex dump (first 32 bytes):
21 43 65 87 00 00 00 00 00 00 00 00 00 00 00 00 !Ce.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
backtrace:
[8969b80e] kmemleak_alloc+0x4e/0xb0
[891b3e37] kmem_cache_alloc+0x107/0x200
[8916528d] mempool_alloc_slab+0x1d/0x30
[89165963] mempool_alloc+0x63/0x180
[8945f85a] scsi_sg_alloc+0x4a/0x50
[89323f0e] __sg_alloc_table+0x11e/0x180
[8945dc03] scsi_alloc_sgtable+0x43/0x90
[8945dc81] scsi_init_sgtable+0x31/0x80
[8945dd1a] scsi_init_io+0x4a/0x1c0
[8946da59] sd_init_command+0x59/0xe40
[8945df81] scsi_setup_cmnd+0xf1/0x160
[8945e75c] scsi_queue_rq+0x57c/0x6a0
[892f60b8] __blk_mq_run_hw_queue+0x1d8/0x390
[892f5e5e] blk_mq_run_hw_queue+0x9e/0x120
[892f7524] blk_mq_insert_requests+0xd4/0x1a0
[892f8273] blk_mq_flush_plug_list+0x123/0x140
unreferenced object 0x8800ba824800 (size 640):
comm trinity-c2, pid 3687, jiffies 4294843075 (age 46785.966s)
hex dump (first 32 bytes):
21 43 65 87 00 00 00 00 00 00 00 00 00 00 00 00 !Ce.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
backtrace:
[8969b80e] kmemleak_alloc+0x4e/0xb0
[891b3e37] kmem_cache_alloc+0x107/0x200
[8916528d] mempool_alloc_slab+0x1d/0x30
[89165963] mempool_alloc+0x63/0x180
[8945f85a] scsi_sg_alloc+0x4a/0x50
[89323f0e] __sg_alloc_table+0x11e/0x180
[8945dc03] scsi_alloc_sgtable+0x43/0x90
[8945dc81] scsi_init_sgtable+0x31/0x80
[8945dd1a] scsi_init_io+0x4a/0x1c0
[8946da59] sd_init_command+0x59/0xe40
[8945df81] scsi_setup_cmnd+0xf1/0x160
[8945e75c] scsi_queue_rq+0x57c/0x6a0
[892f60b8] __blk_mq_run_hw_queue+0x1d8/0x390
[892f5e5e] blk_mq_run_hw_queue+0x9e/0x120
[892f7524] blk_mq_insert_requests+0xd4/0x1a0
[892f8273] blk_mq_flush_plug_list+0x123/0x140
unreferenced object 0x8800a9fe6780 (size 2560):
comm kworker/1:1H, pid 171, jiffies 4294843118 (age 46785.923s)
hex dump (first 32 bytes):
21 43 65 87 00 00 00 00 00 00 00 00 00 00 00 00 !Ce.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
backtrace:
[8969b80e] kmemleak_alloc+0x4e/0xb0
[891b3e37] kmem_cache_alloc+0x107/0x200
[8916528d] mempool_alloc_slab+0x1d/0x30
[89165963] mempool_alloc+0x63/0x180
[8945f85a] scsi_sg_alloc+0x4a/0x50
[89323f0e] __sg_alloc_table+0x11e/0x180
[8945dc03] scsi_alloc_sgtable+0x43/0x90
[8945dc81] scsi_init_sgtable+0x31/0x80
[8945dd1a] scsi_init_io+0x4a/0x1c0
[8946da59] sd_init_command+0x59/0xe40
[8945df81] scsi_setup_cmnd+0xf1/0x160
[8945e75c] scsi_queue_rq+0x57c/0x6a0
[892f60b8] __blk_mq_run_hw_queue+0x1d8/0x390
[892f66b2] blk_mq_run_work_fn+0x12/0x20
[8908eba7] process_one_work+0x147/0x420
[8908f209] worker_thread+0x69/0x470
The sizes vary, but the hex dump is always the same.
What's the usual completion path where these would get deallocated ?
I'm wondering if there's just some annotation missing to appease kmemleak,
because I'm seeing thousands of these.
Or it could be a real leak, but it seems surprising no-one else is complaining.
Dave
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: blk-mq vs kmemleak
On Fri, Jul 03, 2015 at 10:04:00AM -0700, Bart Van Assche wrote: On 07/03/15 09:11, Dave Jones wrote: After a fuzzing run recently, I noticed that the machine had oom'd, and killed everything, but there was still 3GB of memory still in use, that I couldn't even reclaim with /proc/sys/vm/drop_caches ... I'm wondering if there's just some annotation missing to appease kmemleak, because I'm seeing thousands of these. Or it could be a real leak, but it seems surprising no-one else is complaining. Dave, with which kernel version has this behavior been observed ? Linus' current tree Dave -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
block: remove dead code in scsi_ioctl:blk_verify_command
filter gets assigned the address of blk_default_cmd_filter on entry to this function, so the !filter condition can never be true. Signed-off-by: Dave Jones da...@redhat.com diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c index 26487972ac54..9c28a5b38042 100644 --- a/block/scsi_ioctl.c +++ b/block/scsi_ioctl.c @@ -205,10 +205,6 @@ int blk_verify_command(unsigned char *cmd, fmode_t has_write_perm) if (capable(CAP_SYS_RAWIO)) return 0; - /* if there's no filter set, assume we're filtering everything out */ - if (!filter) - return -EPERM; - /* Anybody who can open the device can do a read-safe command */ if (test_bit(cmd[0], filter-read_ok)) return 0; -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
suspicious self-assignment in lpfc
Looking through coverity reports, and it flagged lpfc_read_fcf_conn_tbl() due to the following patch.. commit df0d085fdd2e7c39d1249c2d4ad6b3e176efb60c Author: James Smart james.sm...@emulex.com Date: Fri May 31 17:05:08 2013 -0400 [SCSI] lpfc 8.3.40: Fixed FCoE connection list vlan identifier and add FCF list debug Signed-off-by: James Smart james.sm...@emulex.com Signed-off-by: James Bottomley jbottom...@parallels.com diff --git a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c index 0f6e2548f35d..0309cc15aad6 100644 --- a/drivers/scsi/lpfc/lpfc_hbadisc.c +++ b/drivers/scsi/lpfc/lpfc_hbadisc.c @@ -6158,12 +6158,44 @@ lpfc_read_fcf_conn_tbl(struct lpfc_hba *phba, memcpy(conn_entry-conn_rec, conn_rec[i], sizeof(struct lpfc_fcf_conn_rec)); conn_entry-conn_rec.vlan_tag = - le16_to_cpu(conn_entry-conn_rec.vlan_tag) 0xFFF; + conn_entry-conn_rec.vlan_tag; conn_entry-conn_rec.flags = - le16_to_cpu(conn_entry-conn_rec.flags); + conn_entry-conn_rec.flags; list_add_tail(conn_entry-list, phba-fcf_conn_rec_list); Now that we're not caring about endianness, those two assignments are redundant. I gather this has passed testing, because surely someone would have complained by now, but can they be removed, or should they be doing something else entirely ? Dave -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LSF/MM TOPIC] Fixing large block devices on 32 bit
On Fri, Jan 31, 2014 at 11:02:58AM -0800, James Bottomley wrote: it will only be a couple of years before 16TB devices are available. By then, I bet that most arm (and other exotic CPU) Linux based personal file servers are still going to be 32 bit, so they're not going to be able to take this generation (or beyond) of drives. 1. Try to pretend that CONFIG_LBDAF is supposed to cap out at 16TB and there's nothing we can do about it ... this won't be at all popular with arm based file server manufacturers. Some of the higher end home-NAS's have already moved from arm/ppc - x86_64[1] Unless ARM64 starts appearing at a low enough price point, I wouldn't be surprised to see the smaller vendors do a similar move just to stay competitive. (probably while keeping 'legacy' product lines for a while at a cheaper pricepoint that won't take bigger disks). Dave [1] http://forum.synology.com/wiki/index.php/What_kind_of_CPU_does_my_NAS_have -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
libsrp: remove unreachable kfree
srp_iu_pool_alloc implements what seems like a standard common exit path with
gotos
but there's only one way to reach it. Additionally the kfree(q-items) is
unreachable.
fold the error path back into the if.
Signed-off-by: Dave Jones da...@fedoraproject.org
diff --git a/drivers/scsi/libsrp.c b/drivers/scsi/libsrp.c
index 0707ecdbaa32..f45758f15381 100644
--- a/drivers/scsi/libsrp.c
+++ b/drivers/scsi/libsrp.c
@@ -55,9 +55,12 @@ static int srp_iu_pool_alloc(struct srp_queue *q, size_t max,
q-pool = kcalloc(max, sizeof(struct iu_entry *), GFP_KERNEL);
if (!q-pool)
return -ENOMEM;
+
q-items = kcalloc(max, sizeof(struct iu_entry), GFP_KERNEL);
- if (!q-items)
- goto free_pool;
+ if (!q-items) {
+ kfree(q-pool);
+ return -ENOMEM;
+ }
spin_lock_init(q-lock);
kfifo_init(q-queue, (void *) q-pool, max * sizeof(void *));
@@ -68,11 +71,6 @@ static int srp_iu_pool_alloc(struct srp_queue *q, size_t max,
iue++;
}
return 0;
-
- kfree(q-items);
-free_pool:
- kfree(q-pool);
- return -ENOMEM;
}
static void srp_iu_pool_free(struct srp_queue *q)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
strange comparison in be2iscsi
A few years ago, in 4183122dbc7c489f11971c5afa8e42011bca7fa2 this code was added to drivers/scsi/be2iscsi/be_main.c + if (abrt_task-sc-device-lun != abrt_task-sc-device-lun) + continue; Which doesn't make a lot of sense. What was the intent here ? Dave -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
self assignment bug in aix94xx
2908d778(James Bottomley2006-08-29 09:22:51 -0500 515) scb-ssp_task.retry_count = scb-ssp_task.retry_count; Is this supposed to maybe be.. scb-ssp_task.retry_count = task-ssp_task.retry_count; ? (This and a whole bunch of similar bugs found with Coverity.) Dave -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: strange comparison in be2iscsi
On Thu, Oct 24, 2013 at 04:47:21AM -0400, Dave Jones wrote: A few years ago, in 4183122dbc7c489f11971c5afa8e42011bca7fa2 this code was added to drivers/scsi/be2iscsi/be_main.c + if (abrt_task-sc-device-lun != abrt_task-sc-device-lun) + continue; Which doesn't make a lot of sense. What was the intent here ? Also elsewhere we have this.. 6733b39a(Jayamohan Kallickal2009-09-05 07:36:35 +0530 1583) phys_addr.u.a64.address = 6733b39a(Jayamohan Kallickal2009-09-05 07:36:35 +0530 1584) *((unsigned long long *)(phys_addr.u.a64.address)); which looks like a pretty convoluted way to assign a var to itself. Dave -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SCSI] esas2r: ATTO Technology ExpressSAS 6G SAS/SATA RAID Adapter Driver
+struct esas2r_adapter {
+struct esas2r_target targetdb[ESAS2R_MAX_TARGETS];
+struct esas2r_target *targetdb_end;
...
+u8 fw_coredump_buff[ESAS2R_FWCOREDUMP_SZ];
+void esas2r_reset_chip(struct esas2r_adapter *a)
+{
+if (!esas2r_is_adapter_present(a))
+return;
+
+/*
+ * Before we reset the chip, save off the VDA core dump. The VDA core
+ * dump is located in the upper 512KB of the onchip SRAM. Make sure
+ * to not overwrite a previous crash that was saved.
+ */
+if ((a-flags2 AF2_COREDUMP_AVAIL)
+ !(a-flags2 AF2_COREDUMP_SAVED)
+ a-fw_coredump_buff) {
+esas2r_read_mem_block(a,
+ a-fw_coredump_buff,
+ MW_DATA_ADDR_SRAM + 0x8,
+ ESAS2R_FWCOREDUMP_SZ);
Comparing an array (fw_coredump_buff) to null probably isn't what you intended
here.
Dave
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
fix swapped arguments in aic7xxx:ahc_find_pci_device
The prototype for ahc_9005_subdevinfo_valid shows that the caller has the arguments in the wrong order. 637 ahc_9005_subdevinfo_valid(uint16_t device, uint16_t vendor, 638 uint16_t subdevice, uint16_t subvendor) Signed-off-by: Dave Jones da...@fedoraproject.org diff --git a/drivers/scsi/aic7xxx/aic7xxx_pci.c b/drivers/scsi/aic7xxx/aic7xxx_pci.c index 6917b4f..22d5a94 100644 --- a/drivers/scsi/aic7xxx/aic7xxx_pci.c +++ b/drivers/scsi/aic7xxx/aic7xxx_pci.c @@ -692,7 +692,7 @@ ahc_find_pci_device(ahc_dev_softc_t pci) * ID as valid. */ if (ahc_get_pci_function(pci) 0 - ahc_9005_subdevinfo_valid(vendor, device, subvendor, subdevice) + ahc_9005_subdevinfo_valid(device, vendor, subdevice, subvendor) SUBID_9005_MFUNCENB(subdevice) == 0) return (NULL); -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v2 2/2] scsi: 64-bit port of buslogic driver
On Mon, Jun 24, 2013 at 02:26:00PM -0600, Khalid Aziz wrote:
@@ -821,7 +821,7 @@ struct blogic_ccb {
unsigned char cdblen; /* Byte 2 */
unsigned char sense_datalen;/* Byte 3 */
u32 datalen;/* Bytes 4-7 */
-u32 data; /* Bytes 8-11 */
+void *data; /* Bytes 8-11 */
The comment (and subsequent ones for this struct) are now wrong on 64-bit.
More of a concern though is that above this struct is this...
/*
Define the 32 Bit Mode Command Control Block (CCB) structure. The first 40
bytes are defined by and common to both the MultiMaster Firmware and the
FlashPoint SCCB Manager.
Is it safe to change this if the firmware/3rd party sw is expecting it to be a
u32 ?
Dave
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: at drivers/scsi/scsi_lib.c:1196 scsi_setup_fs_cmnd during RAID5 startup.
3.10 seems to have a problem with dirty RAID5 sets. I've got a machine that panics on boot during RAID5 activation. After switching the BUG_ON to a WARN_ON, I was able to get this over serial console.. md/raid:md0: not clean -- starting background reconstruction md/raid:md0: device sdd1 operational as raid disk 2 md/raid:md0: device sdc1 operational as raid disk 1 md/raid:md0: device sdb1 operational as raid disk 0 md/raid:md0: allocated 3300kB md/raid:md0: raid level 5 active with 3 out of 3 devices, algorithm 2 md0: detected capacity change from 0 to 499847790592 md: resync of RAID array md0 md: minimum _guaranteed_ speed: 1000 KB/sec/disk. md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for resync. md: using 128k window, over a total of 244066304k. md: resuming resync of md0 from checkpoint. WARNING: at drivers/scsi/scsi_lib.c:1196 scsi_setup_fs_cmnd+0xa3/0xb0() Modules linked in: raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx kvm_amd xor kvm snd_hda_codec_realtek raid6_pq snd_hda_intel snd_hda_codec btusb microcode snd_pcm bluetooth edac_core pcspkr serio_raw snd_page_alloc snd_timer snd soundcore rfkill r8169 mii sr_mod cdrom pata_atiixp radeon backlight drm_kms_helper ttm CPU: 1 PID: 160 Comm: kworker/1:1H Not tainted 3.10.0-rc5+ #2 Hardware name: Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H, BIOS F12a 04/23/2010 Workqueue: kblockd blk_delay_work 81a4499d 8801225f5bb8 816aeb63 8801225f5bf0 810432b0 880123039148 8801233e8b00 8801225f5fd8 880123039148 880123071290 8801225f5c00 8104339a Call Trace: [816aeb63] dump_stack+0x19/0x1b [810432b0] warn_slowpath_common+0x70/0xa0 [8104339a] warn_slowpath_null+0x1a/0x20 [8145d7f3] scsi_setup_fs_cmnd+0xa3/0xb0 [8146bb80] sd_prep_fn+0x330/0xf60 [813059cc] blk_peek_request+0x13c/0x320 [8145db12] scsi_request_fn+0x52/0x540 [81301ae9] ? blk_delay_work+0x19/0x40 [813018f2] __blk_run_queue+0x32/0x40 [81301af5] blk_delay_work+0x25/0x40 [810690f1] process_one_work+0x211/0x6f0 [81069085] ? process_one_work+0x1a5/0x6f0 [810696ec] worker_thread+0x11c/0x390 [810695d0] ? process_one_work+0x6f0/0x6f0 [81071c8d] kthread+0xed/0x100 [81071ba0] ? insert_kthread_work+0x80/0x80 [816bee5c] ret_from_fork+0x7c/0xb0 [81071ba0] ? insert_kthread_work+0x80/0x80 ---[ end trace 22d5bd5ee9fceb9e ]--- 3.9 boots fine, and puts it into recovery mode.. $ cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 sdd1[2] sdb1[0] sdc1[1] 488132608 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU] [] resync = 0.7% (1762712/244066304) finish=73.3min speed=55084K/sec unused devices: none -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at drivers/scsi/scsi_lib.c:1196 scsi_setup_fs_cmnd during RAID5 startup.
On Wed, Jun 12, 2013 at 03:43:46PM -0400, Dave Jones wrote: 3.10 seems to have a problem with dirty RAID5 sets. I've got a machine that panics on boot during RAID5 activation. After switching the BUG_ON to a WARN_ON, I was able to get this over serial console.. md/raid:md0: not clean -- starting background reconstruction md/raid:md0: device sdd1 operational as raid disk 2 md/raid:md0: device sdc1 operational as raid disk 1 md/raid:md0: device sdb1 operational as raid disk 0 md/raid:md0: allocated 3300kB md/raid:md0: raid level 5 active with 3 out of 3 devices, algorithm 2 md0: detected capacity change from 0 to 499847790592 md: resync of RAID array md0 md: minimum _guaranteed_ speed: 1000 KB/sec/disk. md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for resync. md: using 128k window, over a total of 244066304k. md: resuming resync of md0 from checkpoint. WARNING: at drivers/scsi/scsi_lib.c:1196 scsi_setup_fs_cmnd+0xa3/0xb0() https://lkml.org/lkml/2013/5/19/75 I think my favorite part of this month old thread is.. in that case we could have waited for a long time Jens? Dave -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
fix cciss locking bug.
do_cciss_intr takes the controller lock on entry, and if something goes wrong, it calls fail_all_cmds which tries to take the same lock. Signed-off-by: Dave Jones [EMAIL PROTECTED] diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index 7d70496..1c57583 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -2756,6 +2756,7 @@ static irqreturn_t do_cciss_intr(int irq, void *dev_id) printk(KERN_WARNING cciss: controller cciss%d failed, stopping.\n, h-ctlr); + spin_unlock_irqrestore(CCISS_LOCK(h-ctlr), flags); fail_all_cmds(h-ctlr); return IRQ_HANDLED; } -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Add ACCUSYS RAID driver for Linux i386/x86-64
On Mon, Oct 22, 2007 at 07:02:53PM -0700, David Miller wrote:
From: Peter Chan [EMAIL PROTECTED]
Date: Tue, 23 Oct 2007 09:45:48 +0800
Add linux-scsi and linux-kernel in mail group.
Please do not post your driver as a RAR attachment,
not only are most Linux folks not familiar with this
archive format, it is also an attachment type rejected
by just about every large email service provider out
there.
Before resubmitting this in a different format, this looks
like it will need quite a bit of work before it's
in mergable state.
Just from a quick skim..
* Why are there separate drivers for i386 and x86-64 ?
(With i386 and x86-64 now being one arch/ this makes even
less sense)
Typically in Linux we have one driver capable of driving
the hardware, regardless of which architecture it's running on.
The differences between the two seem to be locking related,
which makes this look even more odd.
* lots of #ifdef LINUX_VERSION_CODE 2.5.0 and similar.
These should just be removed.
* None of this should be necessary..
#include linux/version.h
#if defined(CONFIG_MODVERSIONS) !defined(MODVERSIONS)
#define MODVERSIONS
#endif
/* modversions.h should be before module.h */
#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 0)
#if defined(MODVERSIONS)
#include config/modversions.h
#endif
#endif
* Don't use absolute paths in includes
#include /usr/src/linux/drivers/scsi/scsi.h
#include /usr/src/linux/drivers/scsi/hosts.h
#include /usr/src/linux/drivers/scsi/constants.h
#include /usr/src/linux/drivers/scsi/sd.h
There's no guarantee (or need) for kernel source to be there.
* Instead of reinventing a linked list implementation, use
the one from linux/list.h
* Use linux/types.h instead of reinventing your own.
* Remove pointless wrappers like..
#define iowrite32 writel
#define ioread32 readl
and just use the functions directly.
* This raises some eyebrows..
#include /usr/src/linux/drivers/scsi/scsi_module.c
Asides from the absolute path problem, no new drivers
should be using this file. There's even a helpful comment
inside that file telling you this.
* This isn't nice..
#define AllocRequestIndex(ResIndex)\
{\
/*DISABLE_IRQ();*/\
AllocRequest++;\
if (RequestHead == NULL) PANIC(Request FULL);\
ResIndex = RequestHead;\
ResIndex-InUsed = TRUE;\
RequestHead = RequestHead-Next;\
/*ENABLE_IRQ();*/\
}
Drivers should never panic the box unless something
seriously critical is happening. An allocation failure
doesn't sound particularly catastrophic.
* You don't need to redefine the SCSI opcodes, they are
already defined for you in scsi/scsi.h
I stopped reading at this point. There's probably more lurking
under that, and scripts/checkpatch.pl will probably pick up
another bunch of nits.
Dave
--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
aic build failure in latest linus git tree.
CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh CHK include/linux/compile.h make -C drivers/scsi/aic7xxx/aicasm *** Install db development libraries gcc -I/usr/include -I. aicasm.c aicasm_symbol.c aicasm_gram.c aicasm_macro_gram.c aicasm_scan.c aicasm_macro_scan.c -o aicasm -ldb aicasm_symbol.c:48:19: error: aicdb.h: No such file or directory aicasm_symbol.c:63: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token aicasm_symbol.c: In function ‘symbol_delete’: aicasm_symbol.c:86: error: ‘symtable’ undeclared (first use in this function) aicasm_symbol.c:86: error: (Each undeclared identifier is reported only once aicasm_symbol.c:86: error: for each function it appears in.) aicasm_symbol.c:87: error: ‘DBT’ undeclared (first use in this function) aicasm_symbol.c:87: error: expected ‘;’ before ‘key’ aicasm_symbol.c:89: error: ‘key’ undeclared (first use in this function) aicasm_symbol.c: In function ‘symtable_open’: aicasm_symbol.c:133: error: ‘symtable’ undeclared (first use in this function) aicasm_symbol.c:134: error: ‘DB_HASH’ undeclared (first use in this function) aicasm_symbol.c: In function ‘symtable_close’: aicasm_symbol.c:147: error: ‘symtable’ undeclared (first use in this function) aicasm_symbol.c:148: error: ‘DBT’ undeclared (first use in this function) aicasm_symbol.c:148: error: expected ‘;’ before ‘key’ aicasm_symbol.c:149: error: expected ‘;’ before ‘data’ aicasm_symbol.c:151: error: ‘key’ undeclared (first use in this function) aicasm_symbol.c:151: error: ‘data’ undeclared (first use in this function) aicasm_symbol.c:151: error: ‘R_FIRST’ undeclared (first use in this function) aicasm_symbol.c: In function ‘symtable_get’: aicasm_symbol.c:169: error: ‘DBT’ undeclared (first use in this function) aicasm_symbol.c:169: error: expected ‘;’ before ‘key’ aicasm_symbol.c:170: error: expected ‘;’ before ‘data’ aicasm_symbol.c:173: error: ‘key’ undeclared (first use in this function) aicasm_symbol.c:176: error: ‘symtable’ undeclared (first use in this function) aicasm_symbol.c:176: error: ‘data’ undeclared (first use in this function) aicasm_symbol.c: In function ‘symtable_dump’: aicasm_symbol.c:472: error: ‘DBT’ undeclared (first use in this function) aicasm_symbol.c:472: error: expected ‘;’ before ‘key’ aicasm_symbol.c:473: error: expected ‘;’ before ‘data’ aicasm_symbol.c:477: error: ‘symtable’ undeclared (first use in this function) aicasm_symbol.c:486: error: ‘R_FIRST’ undeclared (first use in this function) aicasm_symbol.c:487: error: ‘key’ undeclared (first use in this function) aicasm_symbol.c:487: error: ‘data’ undeclared (first use in this function) aicasm_symbol.c:524: error: ‘R_NEXT’ undeclared (first use in this function) make[4]: *** [aicasm] Error 1 make[3]: *** [drivers/scsi/aic7xxx/aicasm/aicasm] Error 2 make[2]: *** [drivers/scsi/aic7xxx] Error 2 make[1]: *** [drivers/scsi] Error 2 make: *** [drivers] Error 2 -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[GDTH] Remove pre 2.6 ifdefs
Signed-off-by: Dave Jones [EMAIL PROTECTED]
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 55e4d2d..bfba877 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -392,12 +392,7 @@
#include linux/proc_fs.h
#include linux/time.h
#include linux/timer.h
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,6)
#include linux/dma-mapping.h
-#else
-#define DMA_32BIT_MASK 0xULL
-#define DMA_64BIT_MASK 0xULL
-#endif
#ifdef GDTH_RTC
#include linux/mc146818rtc.h
@@ -409,12 +404,7 @@
#include asm/io.h
#include asm/uaccess.h
#include linux/spinlock.h
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
#include linux/blkdev.h
-#else
-#include linux/blk.h
-#include sd.h
-#endif
#include scsi.h
#include scsi/scsi_host.h
@@ -655,7 +645,6 @@ static int probe_eisa_isa = 0;
static int force_dma32 = 0;
/* parameters for modprobe/insmod */
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,11)
module_param_array(irq, int, NULL, 0);
module_param(disable, int, 0);
module_param(reserve_mode, int, 0);
@@ -668,20 +657,7 @@ module_param(virt_ctr, int, 0);
module_param(shared_access, int, 0);
module_param(probe_eisa_isa, int, 0);
module_param(force_dma32, int, 0);
-#else
-MODULE_PARM(irq, i);
-MODULE_PARM(disable, i);
-MODULE_PARM(reserve_mode, i);
-MODULE_PARM(reserve_list, 4- __MODULE_STRING(MAX_RES_ARGS) i);
-MODULE_PARM(reverse_scan, i);
-MODULE_PARM(hdr_channel, i);
-MODULE_PARM(max_ids, i);
-MODULE_PARM(rescan, i);
-MODULE_PARM(virt_ctr, i);
-MODULE_PARM(shared_access, i);
-MODULE_PARM(probe_eisa_isa, i);
-MODULE_PARM(force_dma32, i);
-#endif
+
MODULE_AUTHOR(Achim Leubner);
MODULE_LICENSE(GPL);
@@ -710,7 +686,6 @@ static void gdth_delay(int milliseconds)
}
}
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
static void gdth_scsi_done(struct scsi_cmnd *scp)
{
TRACE2((gdth_scsi_done()\n));
@@ -748,42 +723,6 @@ int __gdth_execute(struct scsi_device *sdev, gdth_cmd_str
*gdtcmd, char *cmnd,
kfree(scp);
return rval;
}
-#else
-static void gdth_scsi_done(Scsi_Cmnd *scp)
-{
-TRACE2((gdth_scsi_done()\n));
-
-scp-request.rq_status = RQ_SCSI_DONE;
-if (scp-request.waiting)
-complete(scp-request.waiting);
-}
-
-int __gdth_execute(struct scsi_device *sdev, gdth_cmd_str *gdtcmd, char *cmnd,
- int timeout, u32 *info)
-{
-Scsi_Cmnd *scp = scsi_allocate_device(sdev, 1, FALSE);
-unsigned bufflen = gdtcmd ? sizeof(gdth_cmd_str) : 0;
-DECLARE_COMPLETION_ONSTACK(wait);
-int rval;
-
-if (!scp)
-return -ENOMEM;
-scp-cmd_len = 12;
-scp-use_sg = 0;
-scp-SCp.this_residual = IOCTL_PRI; /* priority */
-scp-request.rq_status = RQ_SCSI_BUSY;
-scp-request.waiting = wait;
-scsi_do_cmd(scp, cmnd, gdtcmd, bufflen, gdth_scsi_done, timeout*HZ, 1);
-wait_for_completion(wait);
-
-rval = scp-SCp.Status;
-if (info)
-*info = scp-SCp.Message;
-
-scsi_release_command(scp);
-return rval;
-}
-#endif
int gdth_execute(struct Scsi_Host *shost, gdth_cmd_str *gdtcmd, char *cmnd,
int timeout, u32 *info)
@@ -2243,29 +2182,17 @@ static int __init gdth_search_drives(int hanum)
printk(GDT-HA %d: Vendor: %s Name: %s\n,
hanum,oemstr-text.oem_company_name,ha-binfo.type_string);
/* Save the Host Drive inquiry data */
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
strlcpy(ha-oem_name,oemstr-text.scsi_host_drive_inquiry_vendor_id,
sizeof(ha-oem_name));
-#else
-strncpy(ha-oem_name,oemstr-text.scsi_host_drive_inquiry_vendor_id,7);
-ha-oem_name[7] = '\0';
-#endif
} else {
/* Old method, based on PCI ID */
TRACE2((gdth_search_drives(): CACHE_READ_OEM_STRING_RECORD
failed\n));
printk(GDT-HA %d: Name: %s\n,
hanum,ha-binfo.type_string);
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
if (ha-oem_id == OEM_ID_INTEL)
strlcpy(ha-oem_name,Intel , sizeof(ha-oem_name));
else
strlcpy(ha-oem_name,ICP, sizeof(ha-oem_name));
-#else
-if (ha-oem_id == OEM_ID_INTEL)
-strcpy(ha-oem_name,Intel );
-else
-strcpy(ha-oem_name,ICP);
-#endif
}
/* scanning for host drives */
@@ -2674,17 +2601,10 @@ static void gdth_copy_internal_data(int hanum,Scsi_Cmnd
*scp,
return;
}
local_irq_save(flags);
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
address = kmap_atomic(sl-page, KM_BIO_SRC_IRQ) + sl-offset;
memcpy(address,buffer,cpnow);
flush_dcache_page(sl-page);
kunmap_atomic(address, KM_BIO_SRC_IRQ);
-#else
-address = kmap_atomic(sl-page, KM_BH_IRQ) + sl-offset;
-memcpy(address,buffer,cpnow);
-flush_dcache_page(sl-page);
-kunmap_atomic(address, KM_BH_IRQ);
-#endif
local_irq_restore(flags);
if (cpsum
Re: [patch 10/28] Fix |/|| confusion in fusion driver
On Thu, May 10, 2007 at 11:00:53PM -0700, Andrew Morton wrote:
From: Dirk Mueller [EMAIL PROTECTED]
This patch corrects a |/|| confusion in mptscsih_copy_sense_data. Using ||
means that the data that ends up being written is (almost always) 1,
instead of being bit-wise or'ed.
Andrew, the last time this was posted, Eric picked up on some other
flaws in the same area. James asked him to followup with a patch, but
unless I'm mistaken, that never arrived.
This diff should replace the one in your tree until Eric has an
equivalent or better.
Signed-off-by: Dave Jones [EMAIL PROTECTED]
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index d25d3be..165f81d 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -436,7 +436,7 @@ typedef struct _MPT_SAS_MGMT {
typedef struct _mpt_ioctl_events {
u32 event; /* Specified by define above */
u32 eventContext; /* Index or counter */
- int data[2];/* First 8 bytes of Event Data */
+ u32 data[2];/* First 8 bytes of Event Data */
} MPT_IOCTL_EVENTS;
/*
diff --git a/drivers/message/fusion/mptscsih.c
b/drivers/message/fusion/mptscsih.c
index fa0f776..3bd94f1 100644
--- a/drivers/message/fusion/mptscsih.c
+++ b/drivers/message/fusion/mptscsih.c
@@ -2463,11 +2463,11 @@ mptscsih_copy_sense_data(struct scsi_cmnd *sc,
MPT_SCSI_HOST *hd, MPT_FRAME_HDR
ioc-events[idx].event =
MPI_EVENT_SCSI_DEVICE_STATUS_CHANGE;
ioc-events[idx].eventContext =
ioc-eventContext;
- ioc-events[idx].data[0] = (pReq-LUN[1] 24)
||
- (MPI_EVENT_SCSI_DEV_STAT_RC_SMART_DATA
16) ||
- (sc-device-channel 8) ||
sc-device-id;
+ ioc-events[idx].data[0] = (pReq-LUN[1] 24)
|
+ (MPI_EVENT_SCSI_DEV_STAT_RC_SMART_DATA
16) |
+ (sc-device-channel 8) |
sc-device-id;
- ioc-events[idx].data[1] = (sense_data[13]
8) || sense_data[12];
+ ioc-events[idx].data[1] = (sense_data[13]
8) | sense_data[12];
ioc-eventContext++;
if (hd-ioc-pcidev-vendor ==
--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Asynchronous scsi scanning
On Thu, May 17, 2007 at 03:30:43PM -0600, Matthew Wilcox wrote: On Thu, May 17, 2007 at 03:43:26PM -0400, Benjamin LaHaise wrote: On Thu, May 17, 2007 at 01:39:54PM -0600, Matthew Wilcox wrote: On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote: Hmmm, actually those other users could easily write and maintain a 20-line patch that does the wait for async scans thing for them using /proc/scsi/scsi in any case. How about the three users who're bothered by this extra module being built maintain a one-line patch to Kconfig and leave well enough alone? The module has an added bonus that it doesn't require any new tools to make work. Doing it via sysfs/procfs means a new rev of whatever tool generates the boot initrd, plus fixing up boot scripts. Loading a module can be done via a simple option to the existing boot tools. That was what James and I thought. However, the distros seem unhappy with it. Of course, they won't actually *comment* on it, they just disable the async scan and won't talk about why. FWIW, Fedora 7 has it enabled, and afaik, Peter (mkinitrd maintainer) is happy with the current situation. It's my understanding that the latest ubuntu release has it enabled too, though obviously I can't speak for whether or not they're happy with the status quo. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 make defconfig build a single, lonely module?
On Sun, May 13, 2007 at 11:22:55AM -0400, Robert P. J. Day wrote: not a big deal, but is there a reason that a make defconfig on my x86 system ends up selecting and building a single module? Building modules, stage 2. MODPOST 1 modules CC drivers/scsi/scsi_wait_scan.mod.o LD [M] drivers/scsi/scsi_wait_scan.ko is there something special about that module? just curious. My guess is that someone was paranoid and wanted not to have to answer a zillion my machine won't boot any more questions when async scsi scanning was added. This might further clarify.. --- The scsi_wait_scan module is only really useful if async scanning is enabled. Signed-off-by: Dave Jones [EMAIL PROTECTED] diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index e62d23f..0f6c370 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -244,7 +244,7 @@ config SCSI_SCAN_ASYNC config SCSI_WAIT_SCAN tristate default m - depends on SCSI + depends on SCSI_SCAN_ASYNC depends on MODULES menu SCSI Transports -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 make defconfig build a single, lonely module?
On Sun, May 13, 2007 at 11:10:55AM -0500, James Bottomley wrote: diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index e62d23f..0f6c370 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -244,7 +244,7 @@ config SCSI_SCAN_ASYNC config SCSI_WAIT_SCAN tristate default m - depends on SCSI + depends on SCSI_SCAN_ASYNC No. SCSI_SCAN_ASYNC is a bool ... if you depend on it, you'll force the wait scan to be built in, which isn't the idea at all. hmm? with my change... $ make defconfig $ grep SCSI_SCAN_ASYNC .config # CONFIG_SCSI_SCAN_ASYNC is not set $ grep SCSI_WAIT_SCAN .config edit .config to remove the CONFIG_SCSI_SCAN_ASYNC line $ make oldconfig answer 'y' for CONFIG_SCSI_SCAN_ASYNC $ grep SCSI_SCAN_ASYNC .config CONFIG_SCSI_SCAN_ASYNC=y $ grep SCSI_WAIT_SCAN .config CONFIG_SCSI_WAIT_SCAN=m Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 make defconfig build a single, lonely module?
On Sun, May 13, 2007 at 11:18:35AM -0500, James Bottomley wrote: On Sun, 2007-05-13 at 11:10 -0500, James Bottomley wrote: -depends on SCSI +depends on SCSI_SCAN_ASYNC No. SCSI_SCAN_ASYNC is a bool ... if you depend on it, you'll force the wait scan to be built in, which isn't the idea at all. Plus SCSI_SCAN_ASYNC only sets the *default* for async scanning. You can alter this at boot time, so you could need the wait scan module even with it set to N. Ah, good point. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] cpqfc: fix for Using too much stach in 2.6 kernel
On Thu, Aug 04, 2005 at 11:38:30AM +0200, Rolf Eike Beer wrote:
+ ulFibreFrame = kmalloc((2048/4), GFP_KERNEL);
The size bug was already found by Dave Jones. This never should be written
this way (not your fault). The array should have been [2048/sizeof(ULONG)].
wasteful. We only ever use 2048 bytes of this array, so doubling
its size on 64bit is pointless, unless you make changes later on
in the driver. (Which I think don't make sense, as we just copy
32 64byte chunks).
Ermm, actually this looks totally bogus..
CpqTsGetSFQEntry() ...
if( total_bytes = 2048 )
{
memcpy( ulDestPtr,
fcChip-SFQ-QEntry[consumerIndex],
64 ); // each SFQ entry is 64 bytes
ulDestPtr += 16; // advance pointer to next 64 byte block
}
we're trashing the last 48 bytes of every copy we make.
Does this driver even work ?
Dave
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] cpqfc: fix for Using too much stach in 2.6 kernel
On Thu, Aug 04, 2005 at 05:56:14PM +0200, Rolf Eike Beer wrote: Am Donnerstag, 4. August 2005 17:40 schrieb Dave Jones: On Thu, Aug 04, 2005 at 11:38:30AM +0200, Rolf Eike Beer wrote: + ulFibreFrame = kmalloc((2048/4), GFP_KERNEL); The size bug was already found by Dave Jones. This never should be written this way (not your fault). The array should have been [2048/sizeof(ULONG)]. wasteful. We only ever use 2048 bytes of this array, so doubling its size on 64bit is pointless, unless you make changes later on in the driver. (Which I think don't make sense, as we just copy 32 64byte chunks). No, this is how it should have been before. This way it would have been clear where the magic 4 came from. It's pointless to fix this, without fixing also CpqTsGetSFQEntry() ... we're trashing the last 48 bytes of every copy we make. Does this driver even work ? No, ulDestPtr ist ULONG* so we increase it by sizeof(ULONG)*16 which is 64. Duh, yes. That is broken on 64-bit however, where it will advance 128 bytes instead of 64 bytes. Dave - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] cpqfc: fix for Using too much stach in 2.6 kernel
On Thu, Aug 04, 2005 at 10:09:51AM +0530, Saripalli, Venkata Ramanamurthy (STSD) wrote: - ULONG ulFibreFrame[2048/4]; // max DWORDS in incoming FC This is 512 ulongs, which is 2KB. + ulFibreFrame = kmalloc((2048/4), GFP_KERNEL); You're replacing it with a 512 byte buffer. Dave - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/1] Whitelist-Entry (FORCELUN) for SGS Thomson Microelectronics Cytronix 6in1 card reader in scsi_devinfo.c
On Wed, Mar 09, 2005 at 01:03:32AM -0800, Andrew Morton wrote: From: Hanno Boeck [EMAIL PROTECTED] I have a usb-cardreader here that needs some FORCELUN-entries in scsi_devinfo.c. lsusb says about the device: Bus 001 Device 003: ID 0483:1307 SGS Thomson Microelectronics Cytronix 6in1 card reader Signed-off-by: Andrew Morton [EMAIL PROTECTED] The problem with these devices is there are so many of them, (The Fedora kernel had over a dozen additions to the whitelist at one point), and there were still devices getting reported that weren't detected. There's no way to stay on top of the amount of these things that are being produced. There are only two sane solutions that I see 1) Have usb-storage tell the scsi layer Its a card reader, scan all luns or 2) enable scanning of all luns, and blacklist any devices that misbehave. I chose (2) in the Fedora kernel, and so far, only 1 device got picked up that needed adding to the blacklist. Dave - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
blacklist microtek scanmaker III
To try and escape the madness of adding a zillion USB card readers
to the SCSI whitelist, I flipped the scan all lun's by default switch
in the fedora kernel recently to see just what breaks, in the hope
of moving from a whitelist solution to a blacklist.
Here's the first (hopefully of not too many) devices that broke.
(See https://bugzilla.redhat.com/beta/show_bug.cgi?id=149402 for more info)
Signed-off-by: Dave Jones [EMAIL PROTECTED]
--- linux-2.6.10/drivers/scsi/scsi_devinfo.c~ 2005-02-23 14:27:53.0
-0500
+++ linux-2.6.10/drivers/scsi/scsi_devinfo.c2005-02-23 14:29:06.0
-0500
@@ -63,6 +63,7 @@ static struct {
{MAXTOR, XT-4170S, B5A, BLIST_NOLUN}, /* locks up */
{MAXTOR, XT-8760S, B7B, BLIST_NOLUN}, /* locks up */
{MEDIAVIS, RENO CD-ROMX2A, 2.03, BLIST_NOLUN},/* responds to
all lun */
+ {MICROTEK, ScanMakerIII, 2.30, BLIST_NOLUN}, /* responds to
all lun */
{NEC, CD-ROM DRIVE:841, 1.0, BLIST_NOLUN},/* locks up */
{PHILIPS, PCA80SC, V4-2, BLIST_NOLUN},/* responds to all lun
*/
{RODIME, RO3000S, 2.33, BLIST_NOLUN}, /* locks up */
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
