I am working on this driver that connects the hard disk over the network. There is a bug that if I enable two or more hard disks on the computer, only the first one gets the partitions looked over and identified. The result is, if I have 1 partition on hda and 1 partitions on hdb, as soon as I connect hda there is a partition that can be mounted. So hda1 gets a blkid xyz123 as soon as it mounts. But when I go ahead and mount hdb1 it also comes up with the same blkid and in fact, the driver is reading it from hda, not hdb. 

So I think I found the place where the driver is messing up. Below is a debug output including a dump_stack which I put at the first spot where it seems to be accessing the wrong device. 

Here is the code section:

    /*basically, this is just the request_queue processor. In the log output that
      follows, the second device, (hdb) has just been connected, right after hda
      was connected and hda1 was mounted to the system. */
    
    void nblk_request_proc(struct request_queue *q)
    {
    struct request *req;
    ndas_error_t err = NDAS_OK;
    
	dump_stack();

    while((req = NBLK_NEXT_REQUEST(q)) != NULL)
    {
    	dbgl_blk(8,&quot;processing queue request from slot %d&quot;,SLOT_R(req));
    	
        if (test_bit(NDAS_FLAG_QUEUE_SUSPENDED, &amp;(NDAS_GET_SLOT_DEV(SLOT_R(req))-&gt;queue_flags)))  {
            printk (&quot;ndas: Queue is suspended\n&quot;);
            /* Queue is suspended */
    #if ( LINUX_VERSION_CODE &gt;= KERNEL_VERSION(2,6,31) )
            blk_start_request(req);
    #else
            blkdev_dequeue_request(req);
    #endif


Here is a log output. I have added some comments to help understand what is happening and where the bad call seems to come up. 

      /* Just below here you can see &quot;slot&quot; mentioned many times. This is the 
         identification for the network case in which the hd is connected to the 
         network. So you will see slot 2 in this log because the first device has 
         already been connected and mounted. */
      
      kernel: [231644.155503] BL|4|slot_enable|/driver/block/ctrldev.c:281|adding disk: slot=2, first_minor=16, capacity=976769072|nd/dpcd1,64:15:44.38,3828:10
      kernel: [231644.155588] BL|3|ndop_open|/driver/block/ops.c:233|ing bdev=f6823400|nd/dpcd1,64:15:44.38,3720:10
      kernel: [231644.155598] BL|2|ndop_open|/driver/block/ops.c:247|slot =0x2|nd/dpcd1,64:15:44.38,3720:10
      kernel: [231644.155606] BL|2|ndop_open|/driver/block/ops.c:248|dev_t=0x3c00010|nd/dpcd1,64:15:44.38,3720:10
      kernel: [231644.155615] ND|3|ndas_query_slot|netdisk/nddev.c:791|slot=2 sdev=d33e2080|nd/dpcd1,64:15:44.38,3696:10
      kernel: [231644.155624] ND|3|ndas_query_slot|netdisk/nddev.c:817|ed|nd/dpcd1,64:15:44.38,3696:10
      kernel: [231644.155631] BL|3|ndop_open|/driver/block/ops.c:326|mode=1|nd/dpcd1,64:15:44.38,3720:10
      kernel: [231644.155640] BL|3|ndop_open|/driver/block/ops.c:365|ed open|nd/dpcd1,64:15:44.38,3724:10
      kernel: [231644.155653] BL|8|ndop_revalidate_disk|/driver/block/ops.c:2334|gendisk=c6afd800={major=60,first_minor=16,minors=0x10,disk_name=ndas-44700486-0,private_data=00000002,capacity=%lld}|nd/dpcd1,64:15:44.38,3660:10
      kernel: [231644.155668] BL|8|ndop_revalidate_disk|/driver/block/ops.c:2346|ed|nd/dpcd1,64:15:44.38,3652:10
      
      /* So at this point the hard disk is added (gendisk=c6...) and the identifications
         all match the network device. The driver is now about to begin scanning the 
         hard drive for existing partitions. the little &#39;ed&#39;, at the end of the previous
         line indicates that revalidate_disk has finished it&#39;s job. 

         Also, I think the request queue is indicated by the output dpcd1 near the very
         end of the line. 
    
         Now below we have entered the function that is pasted above. In the function
         you can see that the slot can be determined by the queue. And the log output
         after the stack dump shows it is from slot 1. (The first network drive that was
         already mounted.) */
      
            kernel: [231644.155677]  ndas-44700486-0:Pid: 467, comm: nd/dpcd1 Tainted: P           2.6.32-5-686 #1
      kernel: [231644.155711] Call Trace:
      kernel: [231644.155723]  [&lt;fc5a7685&gt;] ? nblk_request_proc+0x9/0x10c [ndas_block]
      kernel: [231644.155732]  [&lt;c11298db&gt;] ? __generic_unplug_device+0x23/0x25
      kernel: [231644.155737]  [&lt;c1129afb&gt;] ? generic_unplug_device+0x1e/0x2e
      kernel: [231644.155743]  [&lt;c1123090&gt;] ? blk_unplug+0x2e/0x31
      kernel: [231644.155750]  [&lt;c10cceec&gt;] ? block_sync_page+0x33/0x34
      kernel: [231644.155756]  [&lt;c108770c&gt;] ? sync_page+0x35/0x3d
      kernel: [231644.155763]  [&lt;c126d568&gt;] ? __wait_on_bit_lock+0x31/0x6a
      kernel: [231644.155768]  [&lt;c10876d7&gt;] ? sync_page+0x0/0x3d
      kernel: [231644.155773]  [&lt;c10876aa&gt;] ? __lock_page+0x76/0x7e
      kernel: [231644.155780]  [&lt;c1043f1f&gt;] ? wake_bit_function+0x0/0x3c
      kernel: [231644.155785]  [&lt;c1087b76&gt;] ? do_read_cache_page+0xdf/0xf8
      kernel: [231644.155791]  [&lt;c10d21b9&gt;] ? blkdev_readpage+0x0/0xc
      kernel: [231644.155796]  [&lt;c1087bbc&gt;] ? read_cache_page_async+0x14/0x18
      kernel: [231644.155801]  [&lt;c1087bc9&gt;] ? read_cache_page+0x9/0xf
      kernel: [231644.155808]  [&lt;c10ed6fc&gt;] ? read_dev_sector+0x26/0x60
      kernel: [231644.155813]  [&lt;c10ee368&gt;] ? adfspart_check_ICS+0x20/0x14c
      kernel: [231644.155819]  [&lt;c10ee138&gt;] ? rescan_partitions+0x17e/0x378
      kernel: [231644.155825]  [&lt;c10ee348&gt;] ? adfspart_check_ICS+0x0/0x14c
      kernel: [231644.155830]  [&lt;c10d26a3&gt;] ? __blkdev_get+0x225/0x2c7
      kernel: [231644.155836]  [&lt;c10ed7e6&gt;] ? register_disk+0xb0/0xfd
      kernel: [231644.155843]  [&lt;c112e33b&gt;] ? add_disk+0x9a/0xe8
      kernel: [231644.155848]  [&lt;c112dafd&gt;] ? exact_match+0x0/0x4
      kernel: [231644.155853]  [&lt;c112deae&gt;] ? exact_lock+0x0/0xd
      kernel: [231644.155861]  [&lt;fc5a8b80&gt;] ? slot_enable+0x405/0x4a5 [ndas_block]
      kernel: [231644.155868]  [&lt;fc5a8c63&gt;] ? ndcmd_enabled_handler+0x43/0x9e [ndas_block]
      kernel: [231644.155874]  [&lt;fc5a8c20&gt;] ? ndcmd_enabled_handler+0x0/0x9e [ndas_block]
      kernel: [231644.155891]  [&lt;fc54b22b&gt;] ? notify_func+0x38/0x4b [ndas_core]
      kernel: [231644.155906]  [&lt;fc561cba&gt;] ? _dpc_cancel+0x17c/0x626 [ndas_core]
      kernel: [231644.155919]  [&lt;fc562005&gt;] ? _dpc_cancel+0x4c7/0x626 [ndas_core]
      kernel: [231644.155933]  [&lt;fc561cba&gt;] ? _dpc_cancel+0x17c/0x626 [ndas_core]
      kernel: [231644.155941]  [&lt;c1003d47&gt;] ? kernel_thread_helper+0x7/0x10
      
      /* here are the output of the driver debugs. They show that this operation is
         being performed on the first devices request queue. */

      kernel: [231644.155948] BL|8|nblk_request_proc|/driver/block/block26.c:494|processing queue request from slot 1|nd/dpcd1,64:15:44.38,3408:10
      kernel: [231644.155959] BL|8|nblk_handle_io|/driver/block/block26.c:374|struct ndas_slot sd = NDAS GET SLOT DEV(slot 1)
      kernel: [231644.155966] |nd/dpcd1,64:15:44.38,3328:10
      kernel: [231644.155970] BL|8|nblk_handle_io|/driver/block/block26.c:458|case READA call ndas_read(slot=1, ndas_req)|nd/dpcd1,64:15:44.38,3328:10
      kernel: [231644.155979] ND|8|ndas_read|netdisk/nddev.c:824|read io: slot=1, cmd=0, req=x00|nd/dpcd1,64:15:44.38,3320:10
      

I hope this is enough background information. Maybe an obvious question at this moment is &quot;When and where are the request_queues assigned?&quot; 

Well that is handled a little bit before the add_disk function. adding disk, is the first line on the log output. 

    slot-&gt;disk = NULL;
    spin_lock_init(&amp;slot-&gt;lock);
    slot-&gt;queue = blk_init_queue(
        nblk_request_proc, 
        &amp;slot-&gt;lock
    );

As far as I know, this is the standard operation. So back to my original question. Can I find the request queue somewhere and make sure it is incremented or unique for each new device or does the Linux kernel only use one queue for each Major number? I want to discover why this driver is loading the same queue on two different block storages, and determine if that is causing the duplicate blkid during the initial registration process.

Thanks for looking at this situation for me. 

All Block Device Solutions on Gang of Coders

Total of 1 Block Device Solutions

How can I identify the request queue for a linux block device