Aboo Valappil wrote: > Thanks Arjan for clearing it about SG. I think i am fine with the > page_address() for now. > > I managed to finish my virtual scsi device driver. Everything seems to > be working fine (Reading, writing , etc). But i can not mount a file > system created on it. From my verification, the driver seems to be doing > its job. I verified the read and write to the disk by partitioning the > device, using dd, etc. Seems to work fine. But i can not mount the file > system created on it. READ(6+10), WRITE(6+10) and READ_CAPACITY(10) is all you should need initially. It may be useful to compare what your driver does with the scsi_debug driver which is also a virtual SCSI (disk) target (IOW a ram disk). See: http://www.torque.net/sg/sdebug26.html The fdisk, mkfs, mount sequence works with the scsi_debug driver. Try making the virtual disk image sizes for scsi_debug and your driver the same, then read (with dd) and compare both images after the mkfs. You could also check the first 63 sectors after the fdisk stage. > (I am sorry if i am taking too much of your time and posting wrong > questions in the mailing list. Please guide me on this, this is the only > mailing list which responded to my question. I am not a professional > kernel developer and this is not my full time job but rather just a hobby). > > I attached the outputs below, can some one advice what could be wrong here? > I partitioned the drive as follows. Please not that it shows one head, 8 > sectors. I am not sure where it is getting this info. (I do not see any > SCSI commands issued to the driver for MODE_SENSE for disk geometry page). The kernel just makes them up. The head/cylinder/sector stuff is just fiction anyway. The disk geometry mode page is obsolete, but keep your mode page logic as it is useful in other situations. Doug Gilbert > [root@localhost scsitap]# fdisk -l /dev/sdb > > Disk /dev/sdb: 104 MB, 104858112 bytes > 1 heads, 8 sectors/track, 25600 cylinders > Units = cylinders of 8 * 512 = 4096 bytes > > Device Boot Start End Blocks Id System > /dev/sdb1 2 21975 87896 83 Linux > > > [root@localhost scsitap]# mkfs /dev/sdb1 > mke2fs 1.37 (21-Mar-2005) > Filesystem label= > OS type: Linux > Block size=1024 (log=0) > Fragment size=1024 (log=0) > 22000 inodes, 87896 blocks > 4394 blocks (5.00%) reserved for the super user > First data block=1 > Maximum filesystem blocks=67371008 > 11 block groups > 8192 blocks per group, 8192 fragments per group > 2000 inodes per group > Superblock backups stored on blocks: > 8193, 24577, 40961, 57345, 73729 > > Writing inode tables: done > Writing superblocks and filesystem accounting information: done > > This filesystem will be automatically checked every 39 mounts or > 180 days, whichever comes first. Use tune2fs -c or -i to override. > > [root@localhost scsitap]# mount -o ro /dev/sdb1 /mnt > mount: wrong fs type, bad option, bad superblock on /dev/sdb1, > missing codepage or other error > In some cases useful info is found in syslog - try > dmesg | tail or so > > EXT2-fs error (device sdb1): ext2_check_descriptors: Block bitmap for > group 0 not in group (block 0)! > EXT2-fs: group descriptors corrupted! > > Aboo > > > > Arjan van de Ven wrote: >> [note: you forgot to put in a link to your sourcecode, which greatly >> reduces our ability to give you good answers; please fix this] >> >>> 1. In 2.6 kernel, even if I set the sg_tablesize to SG_NONE, the >>> mid-layer is still queuing commands with use_sg=1. There is no way to >>> disable this SG at all? >>> >> >> in 2.6 everything is now going via the ONE sg codepath yes. The dual >> code path stuff was just incredibly fragile and a bad idea. >> >> >> >> >>> address=page_address(sg[i].page) + sg[i].offset; >>> >>> Is this the right way? I am assuming that sg[i].page will be mapped >>> in to kernel address space as this address is created by SCSI >>> mid-layer. Is that right? Or do I have to use kmap? I tried replacing >>> page_address with kmap/kunmap. But as soon as call kunmap to unmap, >>> the kernal panics! Any thoughts? >>> >> >> kmap doesn't take struct page as argument. >> >> but.... if you show us the real code we can give you better >> suggestions. >> >> >>> 3. Do I have to disable bottom halves before calling scsi_done()? It >>> seems that the kernel panics when I call scsi_done if I use spin_lock >>> instead of spin_lock_bh(). This is one of my spin_locks created for >>> protecting a data structure. >>> >> >> you don't need any locks before calling the done method. >> >> > > - > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
