RE: Number of devices that SCSI can support
You will want to check the BIOS settings on the Qlogic HBA, if you are running into a problem. Also, there may be limitations that are inherent to the storage to which you are connecting. Regards, Frank -Original Message- From: [EMAIL PROTECTED] on behalf of Matthew Wilcox Sent: Tue 1/8/2008 9:22 PM To: Vinay Venkataraghavan Cc: linux-scsi@vger.kernel.org Subject: Re: Number of devices that SCSI can support On Tue, Jan 08, 2008 at 04:55:46PM -0800, Vinay Venkataraghavan wrote: Is there a limit on the number of devices that SCSI supports. In other words, I have a QLogic HBA card, and I am connecting to a SAN which has 64 targets. I've personally had over five hundred LUNs. You shouldn't be hitting a limit here. I am running 2.6.9-42. That sounds like a Red Hat Enterprise kernel. Perhaps you should contact them for support? -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - 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 - 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: Number of devices that SCSI can support
On Tue, 2008-01-08 at 19:22 -0700, Matthew Wilcox wrote: On Tue, Jan 08, 2008 at 04:55:46PM -0800, Vinay Venkataraghavan wrote: Is there a limit on the number of devices that SCSI supports. In other words, I have a QLogic HBA card, and I am connecting to a SAN which has 64 targets. I've personally had over five hundred LUNs. You shouldn't be hitting a limit here. I believe the largest test that's been run was the old OSDL CGL workgroup ... they went up to 4096. However, LUN support depends on the driver and HBA parameters as well (some choose to have arbitrary limits). So, firstly, if the inquiry strings appear (as in you see a scsiX:X:X:64 and above in dmesg) then I'd look at udev issues. If the inquiry strings don't appear, it's probably a device or driver programmed limit. James - 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] libata: eliminate the home grown dma padding in favour of that provided by the block layer
On Wed, 2008-01-09 at 14:13 +0900, Tejun Heo wrote: James Bottomley wrote: Also, DMA alignment at block layer isn't enough for ATA. ATA needs drain buffers for ATAPI commands with variable length response. :-( OK, where is this in the libata code? The dma_pad size is only 4 bytes, so this drain, I assume is only a word long? Given the word alignment requirements of ATA doesn't this still mean it's only draining up to the word boundary anyway (so the code is still correct)? Patch is acked but not merged yet. http://git.kernel.org/?p=linux/kernel/git/tj/libata-dev.git;a=commit;h=6cd22a0febc74bebe52d58eb22271b8770892a2d The full function can be read from the following. It's ata_sg_setup_extra(). http://git.kernel.org/?p=linux/kernel/git/tj/libata-dev.git;a=blob;f=drivers/ata/libata-core.c;h=d763c072e6cefc724ea24cb68a7adf47b340f054;hb=6cd22a0febc74bebe52d58eb22271b8770892a2d OK, but that patch was sent to the mailing list on 4 Jan ... five days after this one. It's a little hard to take unposted patches into account ... It's a fairly comprehensive merge clash ... where is this drain patch on the upstream track? because currently ipr and aic94xx panic the system without the dma padding removal (I just figured -rc6 was a bit late for major surgery like this, but I was planning a backport if it stood up in 2.6.24). James - 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: [linux-pm] Re: [RFC] Implementation of SCSI dynamic power management
On Tue, 8 Jan 2008, Pavel Machek wrote: In fact suspend methods already do take an argument specifying the reason they were called. It wouldn't be hard to add a couple of extra PM_EVENT_* values for manual suspend and autosuspend. The problem is that resume methods don't take a corresponding argument. Well, you could store the value in struct device or something. There's other problem: if autosuspend is != NULL, you know device supports autosuspend. If you call existing suspend(PMSG_AUTOSUSPEND), and driver does not support it, it will crash and burn. That's right. The problem doesn't arise in SCSI because there only the sd driver supports suspend at all -- and now it supports autosuspend as well. In USB I had to add an extra supports_autosuspend bitflag to the usb_driver structure. Alan Stern - 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: Number of devices that SCSI can support
On Wed, Jan 09, 2008 at 09:05:52AM -0600, James Bottomley wrote: On Tue, 2008-01-08 at 19:22 -0700, Matthew Wilcox wrote: On Tue, Jan 08, 2008 at 04:55:46PM -0800, Vinay Venkataraghavan wrote: Is there a limit on the number of devices that SCSI supports. In other words, I have a QLogic HBA card, and I am connecting to a SAN which has 64 targets. I've personally had over five hundred LUNs. You shouldn't be hitting a limit here. I believe the largest test that's been run was the old OSDL CGL workgroup ... they went up to 4096. However, LUN support depends on the driver and HBA parameters as well (some choose to have arbitrary limits). I was using a qlogic HBA for my tests, so I don't think this is the problem -- although the original poster claims to have 64 targets, and I had only one target with 128 luns (attached 4 times). -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - 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: Number of devices that SCSI can support
On Wed, 09 Jan 2008, Matthew Wilcox wrote: On Wed, Jan 09, 2008 at 09:05:52AM -0600, James Bottomley wrote: On Tue, 2008-01-08 at 19:22 -0700, Matthew Wilcox wrote: On Tue, Jan 08, 2008 at 04:55:46PM -0800, Vinay Venkataraghavan wrote: Is there a limit on the number of devices that SCSI supports. In other words, I have a QLogic HBA card, and I am connecting to a SAN which has 64 targets. I've personally had over five hundred LUNs. You shouldn't be hitting a limit here. I believe the largest test that's been run was the old OSDL CGL workgroup ... they went up to 4096. However, LUN support depends on the driver and HBA parameters as well (some choose to have arbitrary limits). I was using a qlogic HBA for my tests, so I don't think this is the problem -- although the original poster claims to have 64 targets, and I had only one target with 128 luns (attached 4 times). -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. Not sure what's going on as well, perhaps some logs could help... But the inbox qla2xxx driver in RHEL4 set's an HBA's scsi_host-max_id count to 512 (also verified with several test rings), so there shouldn't be a problem handling 64 distinct targets (FC ports). - 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: [RFC] Implementation of SCSI dynamic power management
Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern: When all the devices under a host are suspended, the LLD is informed (via a new autosuspend method in the host template) so that it can put the host adapter in a low-power state. Likewise, a new autoresume method is called when the host adapter needs to return to full power. An implementation of these methods for the usb-storage driver will be posted in a followup patch. This has an interesting implication. As the storage driver can share a device with in principle any other usb driver, we must audit all usb drivers if we wish to adopt this patch. All a device's interfaces must be resumed when the storage interface is resumed. To resume a storage device no memory must be allocated because that could deadlock. Regards Oliver - 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: AHCI finds disks; no /dev/sd inodes bound?
Jon Watte [EMAIL PROTECTED] writes: Any help or pointers to self-help would be appreciated! The usual mistake is to not enable CONFIG_BLK_DEV_SD -Andi - 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: AHCI finds disks; no /dev/sd inodes bound?
Yes, that turns out to be the case. Thanks for the quick sanity check! I wonder if it's possible to magically turn that on when selecting AHCI support in menuconfig? That way, it'd be harder for someone else to make the same mistake. Cheers, / h+ On Jan 9, 2008 8:45 AM, Andi Kleen [EMAIL PROTECTED] wrote: Jon Watte [EMAIL PROTECTED] writes: Any help or pointers to self-help would be appreciated! The usual mistake is to not enable CONFIG_BLK_DEV_SD -Andi -- -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. - 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: [RFC] Implementation of SCSI dynamic power management
On Wed, 9 Jan 2008, Oliver Neukum wrote: This has an interesting implication. As the storage driver can share a device with in principle any other usb driver, we must audit all usb drivers if we wish to adopt this patch. All a device's interfaces must be resumed when the storage interface is resumed. To resume a storage device no memory must be allocated because that could deadlock. Maybe people shouldn't enable autosuspend for their swap device... What happens during normal system resume if a driver (not just USB!) needs to allocate memory before the swap device has been resumed? Alan Stern - 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: AHCI finds disks; no /dev/sd inodes bound?
On Wed, 2008-01-09 at 09:21 -0800, Jon Watte wrote: Yes, that turns out to be the case. Thanks for the quick sanity check! I wonder if it's possible to magically turn that on when selecting AHCI support in menuconfig? That way, it'd be harder for someone else to make the same mistake. We've had several discussions on this. However, AHCI is used in a lot of systems for CD-ROM support only. The resolution last time was to add this to the help text for ATA: If you want to use a ATA hard disk, ATA tape drive, ATA CD-ROM or any other ATA device under Linux, say Y and make sure that you know the name of your ATA host adapter (the card inside your computer that speaks the ATA protocol, also called ATA controller), because you will be asked for it. NOTE: ATA enables basic SCSI support; *however*, 'SCSI disk support', 'SCSI tape support', or 'SCSI CDROM support' may also be needed, depending on your hardware configuration. The bottom line is that working out how to configure your own kernel is really hard (even I haven't done it from scratch for ages ... I usually steal a distro config as the basis for my choices). On Jan 9, 2008 8:45 AM, Andi Kleen [EMAIL PROTECTED] wrote: Jon Watte [EMAIL PROTECTED] writes: Any help or pointers to self-help would be appreciated! The usual mistake is to not enable CONFIG_BLK_DEV_SD -Andi James - 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: [RFC] Implementation of SCSI dynamic power management
Am Mittwoch, 9. Januar 2008 18:22:51 schrieb Alan Stern: On Wed, 9 Jan 2008, Oliver Neukum wrote: This has an interesting implication. As the storage driver can share a device with in principle any other usb driver, we must audit all usb drivers if we wish to adopt this patch. All a device's interfaces must be resumed when the storage interface is resumed. To resume a storage device no memory must be allocated because that could deadlock. Maybe people shouldn't enable autosuspend for their swap device... Good advice, but not sufficient to avoid this problem. The vm may write out normal dirty cached pages to scsi devices, which affects storage. What happens during normal system resume if a driver (not just USB!) needs to allocate memory before the swap device has been resumed? I have no idea. I guess these code paths have a sync in the suspend path, so a lot of clean pages will be available. Regards Oliver - 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: AHCI finds disks; no /dev/sd inodes bound?
Stefan Richter wrote: On Wed, 2008-01-09 at 09:21 -0800, Jon Watte wrote: I wonder if it's possible to magically turn that on when selecting AHCI support in menuconfig? That way, it'd be harder for someone else to make the same mistake. (We also don't select EXT3.) Perhaps a better analogy: Ethernet options don't automatically turn on IP support. -- Stefan Richter -=-==--- ---= -=--= http://arcgraph.de/sr/ - 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: AHCI finds disks; no /dev/sd inodes bound?
Stefan Richter wrote: The select SCSI in libata's Kconfig option is not of great help with that issue and is misguided and unnecessary as well. +comment Serial and Parallel ATA need SCSI command sets + depends on SCSI=n menuconfig ATA tristate Serial ATA (prod) and Parallel ATA (experimental) drivers ... - select SCSI + depends on SCSI ... - NOTE: ATA enables basic SCSI support; *however*, - 'SCSI disk support', 'SCSI tape support', or - 'SCSI CDROM support' may also be needed, - depending on your hardware configuration. + NOTE: 'SCSI disk support', 'SCSI tape support', or + 'SCSI CDROM support' is also required if you have + ATA disks, tapes, or CD/DVD-ROM/R/Ws respectively. ... -- Stefan Richter -=-==--- ---= -=--= http://arcgraph.de/sr/ - 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: stex driver panic in kernel 2.6.23
On Wed, Oct 24 2007, James Bottomley wrote: On Wed, 2007-10-24 at 12:17 -0700, Andrew Morton wrote: On Wed, 24 Oct 2007 11:59:30 -0700 Ed Lin [EMAIL PROTECTED] wrote: The shared tag issue was not fixed yet. Kernel panic happened while running I/O test in kernel 2.6.23 (information attached). After applying the patch I posted (or the version James modified), panic disappeared. Switch back to standard kernel, panic again. Did either of those patches get merged in 2.6.24-rc1? No ... Jens did one instead (commit f3da54ba140c6427fa4a32913e1bf406f41b5dda), which now looks like it might not have fixed the issue. I think there's one more bug there, for shared maps. For the locking to work, only the tag map and tag bit map may be shared (incidentally, I was just explaining this to Nick yesterday, but I apparently didn't review the code well enough myself). But we also share the busy list! The busy_list must be queue private, or we need a block_queue_tag covering lock as well. So we have to move the busy_list to the queue. This'll work fine, and it'll actually also fix a problem with blk_queue_invalidate_tags() which will invalidate tags across all shared queues. This is a bit confusing, the low level driver should call it for each queue seperately since otherwise you cannot kill tags on just a single queue for eg a hard drive that stops responding. Since the function has no callers currently, it's not an issue. Please test. With this patch the stex driver passed I/O test. So maybe this problem is fixed finally. Thanks. Please apply. Ed Lin - 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
stex driver panic in kernel 2.6.23
The shared tag issue was not fixed yet. Kernel panic happened while running I/O test in kernel 2.6.23 (information attached). After applying the patch I posted (or the version James modified), panic disappeared. Switch back to standard kernel, panic again. Please reconsider this issue. Thanks. Ed Lin Panic 1 Unable to handle kernel NULL pointer dereference at 0038 RIP: [80356f09] cfq_remove_request+0x18/0x1ac PGD 1545f067 PUD 233d9067 PMD 0 Oops: [1] SMP CPU 1 Modules linked in: e1000 stex ata_piix libata Pid: 80, comm: kblockd/1 Not tainted 2.6.23 #2 RIP: 0010:[80356f09] [80356f09] cfq_remove_request+0x18/0x1ac RSP: 0018:810037cd1d20 EFLAGS: 00010082 RAX: 81003e823ec0 RBX: 8100227b2068 RCX: 81003e860c00 RDX: 000101042821 RSI: 8100227b2068 RDI: 8100227b2068 RBP: 8100227b2068 R08: 810037cd R09: R10: R11: 804296cb R12: R13: 81003e99e148 R14: 0004 R15: 8100329d9290 FS: () GS:810037e9ccc0() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 0038 CR3: 1cc28000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process kblockd/1 (pid: 80, threadinfo 810037cd, task 810037c1f860) Stack: 8100010097d0 8100227b2068 81003e860c00 81003e99e148 0004 8100329d9290 803570c4 8100329d9238 8100227b2068 81003e860c00 Call Trace: [803570c4] cfq_dispatch_insert+0x27/0x52 [803578d1] cfq_dispatch_requests+0x1cb/0x3bf [8034e130] elv_next_request+0x3f/0x13f [804246e5] scsi_dispatch_cmd+0x18f/0x273 [80429734] scsi_request_fn+0x69/0x352 [80356ab7] cfq_kick_queue+0x0/0x38 [80356ad9] cfq_kick_queue+0x22/0x38 [8023ee06] run_workqueue+0xca/0x160 [8023f71f] worker_thread+0x0/0xa5 [8023f71f] worker_thread+0x0/0xa5 [8023f78c] worker_thread+0x6d/0xa5 [8024283d] autoremove_wake_function+0x0/0x2e [8023f71f] worker_thread+0x0/0xa5 [8023f71f] worker_thread+0x0/0xa5 [802424c4] kthread+0x3d/0x61 [8020c6b8] child_rip+0xa/0x12 [80242487] kthread+0x0/0x61 [8020c6ae] child_rip+0x0/0x12 Code: 49 39 7c 24 38 0f 84 d6 00 00 00 48 8b 55 00 48 8b 45 08 48 RIP [80356f09] cfq_remove_request+0x18/0x1ac RSP 810037cd1d20 CR2: 0038 Panic 2 Unable to handle kernel NULL pointer dereference at 0038 RIP: [80356f09] cfq_remove_request+0x18/0x1ac PGD 50c6067 PUD 16b13067 PMD 0 Oops: [1] SMP CPU 1 Modules linked in: e1000 stex ata_piix libata Pid: 5811, comm: cmp Not tainted 2.6.23 #5 RIP: 0010:[80356f09] [80356f09] cfq_remove_request+0x18/0x1ac RSP: 0018:81002532f748 EFLAGS: 00010096 RAX: 81003ea14a80 RBX: 810026f5c188 RCX: 81003e67da00 RDX: 0001000fc8b4 RSI: 810026f5c188 RDI: 810026f5c188 RBP: 810026f5c188 R08: 0143d37f R09: 0003 R10: 0003 R11: 804296cb R12: R13: 81003ea01848 R14: 0004 R15: 81003ead7180 FS: 2b6b5ebceb00() GS:810037e9ccc0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0038 CR3: 07c4c000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process cmp (pid: 5811, threadinfo 81002532e000, task 8100347dd180) Stack: 00287817 810026f5c188 81003e67da00 81003ea01848 0004 81003ead7180 803570c4 81000b367cd8 81003ead7128 810026f5c188 81003e67da00 Call Trace: [803570c4] cfq_dispatch_insert+0x27/0x52 [803578d1] cfq_dispatch_requests+0x1cb/0x3bf [8034e130] elv_next_request+0x3f/0x13f [80429734] scsi_request_fn+0x69/0x352 [8034e2da] elv_insert+0xaa/0x1b5 [803524b0] __make_request+0xd2/0x5a1 [80306618] ext2_get_block+0x0/0x705 [80350294] generic_make_request+0x183/0x221 [80352a24] submit_bio+0x59/0xce [80306618] ext2_get_block+0x0/0x705 [8025cc6c] __pagevec_lru_add+0xd1/0xe4 [802a451a] mpage_bio_submit+0x22/0x29 [802a530c] mpage_readpages+0x11b/0x15f [80306618] ext2_get_block+0x0/0x705 [8025a6f7] __alloc_pages+0xaa/0x372 [8025c33d] __do_page_cache_readahead+0x1c6/0x2cb [802554df] sync_page+0x0/0x4b [8055b611] io_schedule+0x28/0x36 [80234847] current_fs_time+0x1e/0x24 [8025c67b] ondemand_readahead+0xb9/0x137 [80255a80]
Re: [RFC] Implementation of SCSI dynamic power management
On Wed, 9 Jan 2008, Oliver Neukum wrote: Am Mittwoch, 9. Januar 2008 18:22:51 schrieb Alan Stern: On Wed, 9 Jan 2008, Oliver Neukum wrote: This has an interesting implication. As the storage driver can share a device with in principle any other usb driver, we must audit all usb drivers if we wish to adopt this patch. All a device's interfaces must be resumed when the storage interface is resumed. To resume a storage device no memory must be allocated because that could deadlock. Maybe people shouldn't enable autosuspend for their swap device... Good advice, but not sufficient to avoid this problem. The vm may write out normal dirty cached pages to scsi devices, which affects storage. For now, I think the best approach is head-in-the-sand. There aren't a lot of USB storage devices partnered with other functions at the moment. But it might be a good idea for all USB drivers to use GFP_NOIO in their resume pathways. Alan Stern - 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: AHCI finds disks; no /dev/sd inodes bound?
Stefan Richter wrote: Those systems (servers) typically have enough memory to tolerate a few extra KB of code without problems. In fact most PCs these days have. It would be a stupid solution nevertheless. (We also don't select EXT3.) It's not the prettiest solution, but it would reduce the number of support incidents. And, after all, reducing the number of support incidents is the goal of usability. Not selecting EXT3 is a little more understandable, because there are many options -- cramfs, xfs, reiserfs, etc, depending on target. However, the number of people who DO want SATA support but DO NOT want SD block device support is... uh.. anyone? Solving the problem bigger and better, by factoring SD into a mid-level menu, and maybe calling it something non-SCSI, would probably be even better. And even more work. OK, I'll go hide now and try not to fan any flames. And thanks again to Andi for nailing my problem right away! Cheers, / h+ - 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
question on sd_open()
Hello, is there a way to distinguish calls to sd_open() from mount() from calls to open() ? Regards Oliver - 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: AHCI finds disks; no /dev/sd inodes bound?
Matthew Wilcox wrote: OK, how about this? config BLK_DEV_ATA_SD tristate ATA disc support select BLK_DEV_SD config BLK_DEV_ATA_SR tristate ATA CDROM support select BLK_DEV_SR It's probably OK for many uses. However, this further obfuscates the fact that libata uses Linux' SCSI midlayer and highlevel. Which is a bad thing. For example, there are further configuration options in the SCSI menu which influence the SCSI midlayer and highlevel, and therefore influence the software stack which drives the ATA disks and ATA CD-ROMs. Hence this change does not make the configuration menu more logical. Help text left as an exercise for the reader. A pro pos, the help texts and prompts for the SCSI midlayer and highlevel options are... suboptimal. At least as long as these help texts and prompts aren't changed¹ to say what they really do, your BLK_DEV_ATA_SD and BLK_DEV_ATA_SR are actually very nice to have. --- ¹) No patch attached. I posted something a while ago. -- Stefan Richter -=-==--- ---= -=--= http://arcgraph.de/sr/ - 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
Linux scsi / usb-mass-storage and HP printer cardreader bug + fix
Hi All,
First of all sorry for the somewhat massive cross-posting, I've spend a
significant amount of time hunting down this bug, and so far the response has
been less the overwhelming.
The problem is with the HP PSC 1350 (my printer and confirmed by 2 others) and
atleast also the HP PSC 1610 (confirmed by Guillaume Bedot, in the CC).
The cardreader of the multi function printers will crash and from that moment
on no longer communicate in any sane way, if you try to read the last sector of
an sdcard* in a read that is more then 1 sector, so trying to read 8 sectors
starting at sector capicity-8 will crash it, as will reading 2 sectors starting
at sector capicity-2, however reading the last sector in a one 1 sector read
will succeed! (* xdcards seem to be fine).
I haven't tried if it will crash on larger then 1 sector writes which include
the last sector too, I immediately added code to not do that in both the read
and write paths. I have tested reading and writing the end of the disk with
this kludge in and it works.
I currently have a somewhat ugly proof of concept patch for this, which adds
another type of usb-massstorage quirk. When this quirk flag is set, the
usb-massstorage driver modifies READ_10 and WRITE_10 commands of more then 1
sector which includes the last sector to become one sector less. I've been told
by scsi subsystem developers that doing a shorter read / write then requested
is not a problem, the scsi subsystem is designed to handle getting less then it
asked for and will send a seperate request for the last sector.
I and 3 others (2 on a PSC 1350 too, one on a PSC1610) have tested this patch
with success. I'm not asking for this patch to be included to the kernel as is,
I'm asking for the now known workaround for this to be added to the kernel in
someway!
Perhaps its an idea to add the posibility to have a scsi command filter
function / callback to the scsi or usb-massstorage subsystem, and then add a
mechanism to set this filter depending on usb id's and if added to the scsi
layer, a mechanism to set it based on scsi device and manufacturer
identification strings. Such a mechanism might be usefull in the future to work
around other broken hardware too, and has the added advantage of not having
todo much changes to the normal code path, keep that readable.
I'm willing to come up with a patch for such a filter mechanism, provided I get
some pointers where this is best added.
Thanks Regards,
Hans
p.s.
I've also included the fedora-kernel list in the addressee's because I was
hoping that maybe someone can take one of these printers to the kernel hackfest
in the weekend's fudcon and take a look at this.
This patch makes the cardreader on the HP PSC 1350 multifunction printer work,
it adds a new US_FL_ flag + handling, and a new UNUSUAL_DEV_MULTI macro to
support multifunction devices.
The difference between this version and the previous v2 version is that this
version also adds an unusual_devs entry for the psc1610, which also needs this
patch for its cardreader to function.
Signed-off-by: Hans de Goede [EMAIL PROTECTED]
diff -up linux-2.6.23.9/include/scsi/sd.h.psc1350 linux-2.6.23.9/include/scsi/sd.h
--- linux-2.6.23.9/include/scsi/sd.h.psc1350 2008-01-09 21:58:52.0 +0100
+++ linux-2.6.23.9/include/scsi/sd.h 2008-01-09 21:59:06.0 +0100
@@ -47,6 +47,8 @@ struct scsi_disk {
};
#define to_scsi_disk(obj) container_of(obj,struct scsi_disk,cdev)
+#ifdef __SD_C__
+
static int sd_revalidate_disk(struct gendisk *disk);
static void sd_rw_intr(struct scsi_cmnd * SCpnt);
static int sd_probe(struct device *);
@@ -61,6 +63,8 @@ static void scsi_disk_release(struct cla
static void sd_print_sense_hdr(struct scsi_disk *, struct scsi_sense_hdr *);
static void sd_print_result(struct scsi_disk *, int);
+#endif
+
#define sd_printk(prefix, sdsk, fmt, a...)\
(sdsk)-disk ? \
sdev_printk(prefix, (sdsk)-device, [%s] fmt, \
diff -up linux-2.6.23.9/include/linux/usb_usual.h.psc1350 linux-2.6.23.9/include/linux/usb_usual.h
--- linux-2.6.23.9/include/linux/usb_usual.h.psc1350 2008-01-09 21:58:52.0 +0100
+++ linux-2.6.23.9/include/linux/usb_usual.h 2008-01-09 21:59:06.0 +0100
@@ -48,7 +48,22 @@
US_FLAG(IGNORE_DEVICE, 0x0800) \
/* Don't claim device */ \
US_FLAG(CAPACITY_HEURISTICS, 0x1000) \
- /* sometimes sizes is too big */
+ /* sometimes sizes is too big */ \
+ US_FLAG(LAST_SECTOR_BUG, 0x2000) \
+ /* The cardreader of the HP PSC 1350 all-in-one \
+ printer / scanner / cardreader. Has a nasty \
+ bug where the cardreader part will return an \
+ error when the last sector of a SD card gets \
+ read in a read command of more then 1 sector \
+ once this has happened the cardreader will \
+ return nothing but errors. This bug gets \
+ triggered on every sd-card insertion with \
+ newer kernels, because the partition code \
+ now
Re: AHCI finds disks; no /dev/sd inodes bound?
On Wed, Jan 09, 2008 at 10:41:59PM +0100, Stefan Richter wrote: Matthew Wilcox wrote: OK, how about this? config BLK_DEV_ATA_SD tristate ATA disc support select BLK_DEV_SD config BLK_DEV_ATA_SR tristate ATA CDROM support select BLK_DEV_SR It's probably OK for many uses. However, this further obfuscates the fact that libata uses Linux' SCSI midlayer and highlevel. Which is a bad thing. For example, there are People are not interested in how libata is implemented internally. They just want their SATA interfaces to work. Kconfig is also not an educational facility or high level design description of the code, but a pragmatic tool to get the job done. further configuration options in the SCSI menu which influence the SCSI midlayer and highlevel, and therefore influence the software stack which drives the ATA disks and ATA CD-ROMs. Hence this change does not make the configuration menu more logical. I think Matthew's patch with appropiate help texts is a good idea. -Andi - 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: Number of devices that SCSI can support
Thank you all for responding. While I agree that the scsi stack in linux should be capable of supporting many targets, I still see this problem all the time. It seemed to consistently happen on /dev/sdbm which corresponds to the 65th lun or target. My SAN configuration consists of: 4 targets with 16 luns each = 4 * 16 = 64 total devices. But I ran another test by changing my targets information and saw this issue for /dev/sdbm As mentioned on this thread, I am attaching some more information. Looks like SCSI inquiry is going through, and the inquiry succeeds. As you can see from the attached message below the /sys/class/scsi_device file also gets created: at /sys/class/scsi_device/1\:0\:3\:15/device/ and below this we find all the related entries such as: block/ dumpqueue_depth state delete generic/rescan timeout detach_statemodel rev type device_blocked power/ scsi_level vendor So from this information it looks like the scsi mid layer had detected that particular lun. But the /dev/sdbm device has not been created. It was also mentioned that it could be a udev problem. The other curious issue is that if take the major number and the minor number from this entry and manually create the device file as such: mknod /dev/sdbm 68 0 it works after I rescan all the targets and luns and I am able to perform I/O on this lun. Any other ideas. Thanks, Vinay - Original Message From: Andrew Vasquez [EMAIL PROTECTED] To: Vinay Venkataraghavan [EMAIL PROTECTED] Cc: James Bottomley [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; Matthew Wilcox [EMAIL PROTECTED] Sent: Wednesday, January 9, 2008 7:49:33 AM Subject: Re: Number of devices that SCSI can support On Wed, 09 Jan 2008, Matthew Wilcox wrote: On Wed, Jan 09, 2008 at 09:05:52AM -0600, James Bottomley wrote: On Tue, 2008-01-08 at 19:22 -0700, Matthew Wilcox wrote: On Tue, Jan 08, 2008 at 04:55:46PM -0800, Vinay Venkataraghavan wrote: Is there a limit on the number of devices that SCSI supports. In other words, I have a QLogic HBA card, and I am connecting to a SAN which has 64 targets. I've personally had over five hundred LUNs. You shouldn't be hitting a limit here. I believe the largest test that's been run was the old OSDL CGL workgroup ... they went up to 4096. However, LUN support depends on the driver and HBA parameters as well (some choose to have arbitrary limits). I was using a qlogic HBA for my tests, so I don't think this is the problem -- although the original poster claims to have 64 targets, and I had only one target with 128 luns (attached 4 times). -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. Not sure what's going on as well, perhaps some logs could help... But the inbox qla2xxx driver in RHEL4 set's an HBA's scsi_host-max_id count to 512 (also verified with several test rings), so there shouldn't be a problem handling 64 distinct targets (FC ports). - 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 Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs - 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: [linux-usb-devel] Linux scsi / usb-mass-storage and HP printer cardreader bug + fix
On Wed, Jan 09, 2008 at 10:44:49PM +0100, Hans de Goede wrote: First of all sorry for the somewhat massive cross-posting, I've spend a significant amount of time hunting down this bug, and so far the response has been less the overwhelming. The cardreader of the multi function printers will crash and from that moment on no longer communicate in any sane way, if you try to read the last sector of an sdcard* in a read that is more then 1 sector, so trying to read 8 sectors starting at sector capicity-8 will crash it, as will reading 2 sectors starting at sector capicity-2, however reading the last sector in a one 1 sector read will succeed! (* xdcards seem to be fine). To continue the history on this we over in usb-storage land looked at this and think it belongs in the SCSI layer. We don't like changing commands in-flight; it has, historically, caused us all sorts of issues in the past. Furthermore, this seems like the likely sort of off-by-one bug that can affect many types of devices, not just USB. I'd really like to see this in sd_mod -- I have no objection to requiring an HCD to set a flag to indicate that it should be used, if really desired. But, it seems to me to be a much easier change to make where the command originated rather than in mid-flight. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver P: Nine more messages in admin.policy. M: I know, I'm typing as fast as I can! -- Pitr and Mike User Friendly, 11/27/97 pgp7WbiNzH5gI.pgp Description: PGP signature
Re: [PATCH 0/7] sg_ring: a ring of scatterlist arrays
On Tue, 2008-01-08 at 11:39 +1100, Rusty Russell wrote: On Tuesday 08 January 2008 02:48:23 James Bottomley wrote: We're always open to new APIs (or more powerful and expanded old ones). The way we've been doing the sg_chain conversion is to slide API layers into the drivers so sg_chain becomes a simple API flip when we turn it on. Unfortunately sg_ring doesn't quite fit nicely into this. Hi James, Well, it didn't touch any drivers. The only ones which needed altering were those which wanted to use large scatter-gather lists. You think of the subtlety of sg-chain conversion as a feature; it's a bug :) No, I think of the side effect of hiding scatterlist manipulations inside accessors as a feature because it insulates the drivers from the details of the implementation. The other thing I note is that the problem you're claiming to solve with sg_ring (the ability to add extra scatterlists to the front or the back of an existing one) is already solved with sg_chain, so the only real advantage of sg_ring was that it contains explicit counts, which sg_table (in -mm) also introduces. I just converted virtio using latest Linus for fair comparison Erm, but that's not really a fair comparison; you need the sg_table code in git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git branch sg as well. Actually, I think it's a wash. Now callers need to set up an sg_table as well. It will save the count_sg() calls though. , and it's still pretty ugly. sg_ring needs more work to de-scsi it. sg_table is almost sg_ring except it retains all the chaining warts. But we hit the same problems: 1) sg_chain loses information. The clever chain packaging makes reading easy, but manipulation is severely limited. You can append to your own chains by padding, but not someone elses. This works for SCSI, but what about the rest of us? And don't even think of joining mapped chains: it will almost work. OK, but realistically some of your criticisms are way outside of the design intent. Scatterlists (and now sg_chains) are the way the block subsystem hands pages to its underlying block devices. James, scatterlists are used for more than the block subsystem. I know you're designing for that, but we can do better. Because a single sg_ring is trivially convertable to and from a scatterlist *, the compatibility story is nice. You can implement a subsystem (say, the block layer) with sg_ring, and still hand out struct scatterlist arrays for backwards compat: old code won't ask for v. long scatterlist arrays anyway. Now we have sg_chaining, we can actually convert complex sg_rings into sg chains when someone asks, as my most recent patch does. I think that's one abstraction too many, but it provides a transition path. There have never until now been any requirements to join already dma_map_sg() converted scatterlists ... that would wreak havoc with the way we reuse the list plus damage the idempotence of map/unmap. What is the use case you have for this? (This was, admittedly, a made-up example). 2) sg_chain's end marker is only for reading non-dma elements, not for mapped chains, nor for writing into chains. Plus it's a duplicate of the num arg, which is still passed around for efficiency. (virtio had to implement count_sg() because I didn't want those two redundant num args). 3) By overloading struct scatterlist, it's invisible what code has been converted to chains, and which hasn't. Too clever by half! No it's not ... that's the whole point. Code not yet converted to use the API accessors is by definition unable to use chaining. Code converted to use the accessors by design doesn't care (and so is converted to chains). But you've overloaded the type: what's the difference between: /* Before conversion */ int foo(struct scatterlist *, int); And: /* After conversion */ int foo(struct scatterlist *, int); You have to wade through the implementation to see the difference: does this function take a chained scatterlist or an array scatterlist? Then you add insult to injury by implementing sg_chain() *which doesn't handle chained scatterlists!*. sg_ring would not have required any change to existing drivers, just those that want to use long sg lists. And then it's damn obvious which are which. Which, by definition, would have been pretty much all of them. But it would have started with none of them, and it would have been done over time. Eventually we might have had a flag day to remove raw scatterlist arrays. 4) sg_chain missed a chance to combine all the relevent information (max, num, num_dma and the sg array). sg_table comes close, but you still can't join them (no max information, and even if there were, what if it's full?). Unlike
[PATCH] sym53_8xx_2: fixes two bugs related to chip reset
From: Krzysztof Helt [EMAIL PROTECTED]
This patch fixes two bugs pointed by James Bottomley:
1. the if (!sym_data-io_reset). That variable is only ever filled
by a stack based completion. If we find it non empty it means
this code has been entered twice and we have a severe problem,
so that should just become a BUG_ON(!sym_data-io_reset).
2. sym_data-io_reset should be set to NULL before the routine is
exited otherwise the PCI recovery code could end up completing
what will be a bogus pointer into the stack.
Big thanks to James Bottomley for help with the patch.
Signed-off-by: Krzysztof Helt [EMAIL PROTECTED]
---
I do not know if I understood correctly all James' tips.
diff -urp linux-ref/drivers/scsi/sym53c8xx_2/sym_glue.c
linux-new/drivers/scsi/sym53c8xx_2/sym_glue.c
--- linux-ref/drivers/scsi/sym53c8xx_2/sym_glue.c 2007-12-23
20:39:44.0 +0100
+++ linux-new/drivers/scsi/sym53c8xx_2/sym_glue.c 2008-01-09
22:22:30.0 +0100
@@ -609,22 +609,22 @@ static int sym_eh_handler(int op, char *
*/
#define WAIT_FOR_PCI_RECOVERY 35
if (pci_channel_offline(pdev)) {
- struct completion *io_reset;
int finished_reset = 0;
init_completion(eh_done);
spin_lock_irq(shost-host_lock);
/* Make sure we didn't race */
if (pci_channel_offline(pdev)) {
- if (!sym_data-io_reset)
- sym_data-io_reset = eh_done;
- io_reset = sym_data-io_reset;
+ BUG_ON(!sym_data-io_reset);
+ sym_data-io_reset = eh_done;
} else {
finished_reset = 1;
}
spin_unlock_irq(shost-host_lock);
if (!finished_reset)
- finished_reset = wait_for_completion_timeout(io_reset,
+ finished_reset = wait_for_completion_timeout
+ (sym_data-io_reset,
WAIT_FOR_PCI_RECOVERY*HZ);
+ sym_data-io_reset = NULL;
if (!finished_reset)
return SCSI_FAILED;
}
@@ -1879,7 +1879,6 @@ static void sym2_io_resume(struct pci_de
spin_lock_irq(shost-host_lock);
if (sym_data-io_reset)
complete_all(sym_data-io_reset);
- sym_data-io_reset = NULL;
spin_unlock_irq(shost-host_lock);
}
--
Sprawdz, ktore komorki sa najmodniejsze!
Kliknij http://link.interia.pl/f1cd4
-
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: AHCI finds disks; no /dev/sd inodes bound?
Andi Kleen wrote: On Wed, Jan 09, 2008 at 10:41:59PM +0100, Stefan Richter wrote: However, this further obfuscates the fact that libata uses Linux' SCSI midlayer and highlevel. Which is a bad thing. For example, there are People are not interested in how libata is implemented internally. They just want their SATA interfaces to work. Kconfig is also not an educational facility or high level design description of the code, but a pragmatic tool to get the job done. I did not talk about education or design decription. I did talk about appropriately showing what the Kconfig options do. Kconfig is the tool to configure the Linux build environment before building the program. In particular, we are talking about how to present the configuration of the Linux ATA component, which happens - to have a build-time dependence on the Linux SCSI midlayer and - to be not very useful at runtime if certain Linux SCSI highlevel components aren't present as well. The Kconfig menu layouts, prompts, and help texts are there to inform/ educate/ guide the user when configuring the build environment, with the goal that he safely and efficiently gets to a working software configuration. If some internals of the implementation are not entirely invisible to users at run-time, then we should provide information about them. Or change the implementation so that these internals become truly invisible at runtime use, if that is preferable, all things considered. Furthermore, people who use Kconfig are _not_ people who just want their SATA interfaces to work. These are specifically people who need to or want to create an own configuration before build time, for what ever reason. /These/ are the people to which the Kconfig menus and texts must be tailored for. People who just want their SATA interfaces to work _and_ cannot or don't want to spend time with configuring the kernel build environment can be served to. We give them ready-made .config files or kernels. Or in short: Setting BLK_DEV_SD=y does not mean make my disk work. It means enable building one of the program parts which are necessary to make my disk work. And however hard you try, you can't transform it to truly take on the former meaning. Therefore better stay true to the actual meaning. -- Stefan Richter -=-==--- ---= -=--= http://arcgraph.de/sr/ - 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: AHCI finds disks; no /dev/sd inodes bound?
Stefan Richter wrote: The Kconfig menu layouts, prompts, and help texts are there to inform/ educate/ guide the user when configuring the build environment, with the goal that he safely and efficiently gets to a working software configuration. It might have been not entirely clear from my earlier postings, but I (and others) actually made alternative suggestions how to improve the menus. Namely, split the SCSI menu and get to the following order of prompts: Do you have HDDs? (Then you need this option here, except in this and that very special case.) Do you have an IDE or SATA controller? I see your attention is beginning to slip, but let me ask one more thing --- do you have one of those SCSI controllers? No? Thought so. No need to use the buggy and conceptually problematic select keyword anywhere. -- Stefan Richter -=-==--- ---= -=-=- http://arcgraph.de/sr/ - 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] sym53_8xx_2: fixes two bugs related to chip reset
On Wed, 2008-01-09 at 23:59 +0100, Krzysztof Helt wrote:
From: Krzysztof Helt [EMAIL PROTECTED]
This patch fixes two bugs pointed by James Bottomley:
1. the if (!sym_data-io_reset). That variable is only ever filled
by a stack based completion. If we find it non empty it means
this code has been entered twice and we have a severe problem,
so that should just become a BUG_ON(!sym_data-io_reset).
2. sym_data-io_reset should be set to NULL before the routine is
exited otherwise the PCI recovery code could end up completing
what will be a bogus pointer into the stack.
Big thanks to James Bottomley for help with the patch.
Signed-off-by: Krzysztof Helt [EMAIL PROTECTED]
Well done .. there's actually just one problem remaining:
---
I do not know if I understood correctly all James' tips.
diff -urp linux-ref/drivers/scsi/sym53c8xx_2/sym_glue.c
linux-new/drivers/scsi/sym53c8xx_2/sym_glue.c
--- linux-ref/drivers/scsi/sym53c8xx_2/sym_glue.c 2007-12-23
20:39:44.0 +0100
+++ linux-new/drivers/scsi/sym53c8xx_2/sym_glue.c 2008-01-09
22:22:30.0 +0100
@@ -609,22 +609,22 @@ static int sym_eh_handler(int op, char *
*/
#define WAIT_FOR_PCI_RECOVERY35
if (pci_channel_offline(pdev)) {
- struct completion *io_reset;
int finished_reset = 0;
init_completion(eh_done);
spin_lock_irq(shost-host_lock);
/* Make sure we didn't race */
if (pci_channel_offline(pdev)) {
- if (!sym_data-io_reset)
- sym_data-io_reset = eh_done;
- io_reset = sym_data-io_reset;
+ BUG_ON(!sym_data-io_reset);
+ sym_data-io_reset = eh_done;
} else {
finished_reset = 1;
}
spin_unlock_irq(shost-host_lock);
if (!finished_reset)
- finished_reset = wait_for_completion_timeout(io_reset,
+ finished_reset = wait_for_completion_timeout
+ (sym_data-io_reset,
WAIT_FOR_PCI_RECOVERY*HZ);
+ sym_data-io_reset = NULL;
This has to be cleared under the host_lock to forestall the (tiny) race
where the pci recovery code checks the value of sym_data-io_reset, we
change it to null and then the pci recovery code completes a NULL
pointer.
Other than this one problem, the code looks fine.
James
-
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: AHCI finds disks; no /dev/sd inodes bound?
On Thu, Jan 10, 2008 at 12:03:59AM +0100, Stefan Richter wrote: Andi Kleen wrote: On Wed, Jan 09, 2008 at 10:41:59PM +0100, Stefan Richter wrote: However, this further obfuscates the fact that libata uses Linux' SCSI midlayer and highlevel. Which is a bad thing. For example, there are People are not interested in how libata is implemented internally. They just want their SATA interfaces to work. Kconfig is also not an educational facility or high level design description of the code, but a pragmatic tool to get the job done. I did not talk about education or design decription. I did talk about appropriately showing what the Kconfig options do. That's high level design description -Andi - 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: AHCI finds disks; no /dev/sd inodes bound?
Andi Kleen wrote: On Thu, Jan 10, 2008 at 12:03:59AM +0100, Stefan Richter wrote: Kconfig is also not an educational facility or high level design description of the code, but a pragmatic tool to get the job done. I did not talk about education or design decription. I did talk about appropriately showing what the Kconfig options do. That's high level design description ...of the Kconfig option. But it's not a design description of the code which we are configuring. (Even though intelligent beings might be able to draw conclusions about the code, based on what config options are offered.) -- Stefan Richter -=-==--- ---= -=-=- http://arcgraph.de/sr/ - 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 0/7] sg_ring: a ring of scatterlist arrays
On Thursday 10 January 2008 09:10:37 James Bottomley wrote: On Tue, 2008-01-08 at 11:39 +1100, Rusty Russell wrote: On Tuesday 08 January 2008 02:48:23 James Bottomley wrote: We're always open to new APIs (or more powerful and expanded old ones). The way we've been doing the sg_chain conversion is to slide API layers into the drivers so sg_chain becomes a simple API flip when we turn it on. Unfortunately sg_ring doesn't quite fit nicely into this. Hi James, Well, it didn't touch any drivers. The only ones which needed altering were those which wanted to use large scatter-gather lists. You think of the subtlety of sg-chain conversion as a feature; it's a bug :) No, I think of the side effect of hiding scatterlist manipulations inside accessors as a feature because it insulates the drivers from the details of the implementation. I completely disagree. Abstractions add complexity, and that costs. They steal information from their users, and as they build up like sediment they make debugging and understanding harder. For example, an array is simple and well understood. An abstraction would just buy confusion and YA thing to learn. When a single array was no longer sufficient, I figured a linked-list of arrays was the simplest replacement. Easy to understand and accepted practice (tho rings are a bit exotic). Because the implementation is the interface, authors can see what is legal. More concretely, you're already regarding your abstractions as too expensive, which is why sg_chain() doesn't handle chained sgs. Result: you've got a complex implementation and a complex interface with a complex abstraction. sg_chains suck for manipulation, and AFAICT that's inherent. Here, take a look at the sg_ring conversion of scsi_alloc_sgtable and scsi_free_sgtable and you can see why I'm unhappy with the sg_chain code: [...] Hope that clarifies, Actually, not really. If I want to continue the competition, I can just point out that your sg_ring code is bigger than those corresponding segments are after the sg_table conversion of scsi_lib.c ... However, this is pointless. No, it's exactly the point. These details *matter*. The implementation *matters*. sg_table moves this code out of scsi_lib (good!), but still demonstrates how much of a PITA they are to manipulate. As for being able to make arbitrary changes in future without hitting drivers: this is the Kernel ABI pipe dream writ small. OK, I give in with -ETIMEDOUT. I'll go away now and do something productive :) Cheers, Rusty. - 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
sata_nv does not function in kernel 2.6.20.21
Hello Storage Controller Experts, I am writing this mail to you to request your assistance in resolving a functionality regression in my sata_nv controller driver in recent Linux kernels. I am hoping you can assist me in finding a solution to this because my TV tuner card is dependent on some fixes in the newer kernels but using the newer kernels causes some of my storage volumes to be unreadable, thereby putting me in a catch-22 situation. Please let me know if any other omitted information is required for diagnostics. Sorry for the delay in contacting you promptly but: 1) I attempted to contact the maintainer listed directly in the driver source code and he never replied. 2) I was holding out the mistaken hope that the problem was transient and would be resolved without my intervention. Disclaimer: I am sure one of you will notice I am using the nvidia binary video graphics driver on this system... I say this to provide full disclosure that I am aware of the implications and of course I am willing to disable the driver for diagnostic purposes. I have tried running the system without the driver loaded and did not find any change in behavior but if you think it is part of the problem please let me know. I am using the Supermicro H8DCE motherboard. Some (not all) of the SATA channels quit working due to some kind of resource conflict when I upgrade to any kernel above 2.6.20.xx series, in my case I am running 2.6.20.21 SMP x86_64 presently. The boot error which appears in dmesg for the missing SATA channels on 2.6.23.12 is pasted below and a compressed copy of my configuration file for 2.6.23.12 is attached. The dmesg for 2.6.20.21 is attached and note the configuration is the same except for being run through make oldconfig. Best Regards, Matthew Hall ACPI: PCI Interrupt Link [LT3D] enabled at IRQ 46 ACPI: PCI Interrupt :80:07.0[A] - Link [LT3D] - GSI 46 (level, low) - IRQ 46 sata_nv :80:07.0: Using ADMA mode PCI: Unable to reserve mem region #6:[EMAIL PROTECTED] for device :80:07.0 ACPI: PCI interrupt for device :80:07.0 disabled sata_nv: probe of :80:07.0 failed with error -16 ACPI: PCI Interrupt Link [LT2E] enabled at IRQ 45 ACPI: PCI Interrupt :80:08.0[A] - Link [LT2E] - GSI 45 (level, low) - IRQ 45 sata_nv :80:08.0: Using ADMA mode PCI: Unable to reserve mem region #6:[EMAIL PROTECTED] for device :80:08.0 ACPI: PCI interrupt for device :80:08.0 disabled sata_nv: probe of :80:08.0 failed with error -16 config-2.6.23.12.gz Description: Binary data dmesg-2.6.20.21.gz Description: Binary data
Re: sata_nv does not function in kernel 2.6.20.21
On Thu, Jan 10, 2008 at 02:47:33AM +, Matthew Hall wrote: I am using the Supermicro H8DCE motherboard. Some (not all) of the SATA channels quit working due to some kind of resource conflict when I upgrade to any kernel above 2.6.20.xx series, in my case I am running 2.6.20.21 SMP x86_64 presently. Could you provide an 'lspci -v' and a 'cat /proc/iomem' for both kernels please? This doesn't seem to be a scsi problem per se, so I'm adding linux-kernel and linux-ide -- can you drop linux-scsi from any reply please. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - 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: sata_nv does not function in kernel 2.6.20.21
Matthew Hall wrote: ACPI: PCI Interrupt Link [LT3D] enabled at IRQ 46 ACPI: PCI Interrupt :80:07.0[A] - Link [LT3D] - GSI 46 (level, low) - IRQ 46 sata_nv :80:07.0: Using ADMA mode PCI: Unable to reserve mem region #6:[EMAIL PROTECTED] for device :80:07.0 ACPI: PCI interrupt for device :80:07.0 disabled sata_nv: probe of :80:07.0 failed with error -16 ACPI: PCI Interrupt Link [LT2E] enabled at IRQ 45 ACPI: PCI Interrupt :80:08.0[A] - Link [LT2E] - GSI 45 (level, low) - IRQ 45 sata_nv :80:08.0: Using ADMA mode PCI: Unable to reserve mem region #6:[EMAIL PROTECTED] for device :80:08.0 ACPI: PCI interrupt for device :80:08.0 disabled sata_nv: probe of :80:08.0 failed with error -16 Error -16 is EBUSY, which causes the driver load to fail due to the Unable to reserve mem region message. This means that the sata_nv driver needed to use PCI BAR 6, but was unable to for some reason. Given that sata_nv uses devres like other libata drivers, IMO the likely cause is outside the ATA subsystem (PCI? ACPI?). One workaround to try is setting sata_nv module option 'adma' to zero (0), in the hopes that it ignores that final region and work anyway. Jeff - 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: AHCI finds disks; no /dev/sd inodes bound?
Matthew Wilcox wrote: On Wed, Jan 09, 2008 at 12:36:26PM -0800, Jon Watte wrote: Stefan Richter wrote: Those systems (servers) typically have enough memory to tolerate a few extra KB of code without problems. In fact most PCs these days have. It would be a stupid solution nevertheless. (We also don't select EXT3.) Not selecting EXT3 is a little more understandable, because there are many options -- cramfs, xfs, reiserfs, etc, depending on target. However, the number of people who DO want SATA support but DO NOT want SD block device support is... uh.. anyone? Solving the problem bigger and better, by factoring SD into a mid-level menu, and maybe calling it something non-SCSI, would probably be even better. And even more work. OK, how about this? config BLK_DEV_ATA_SD tristate ATA disc support select BLK_DEV_SD config BLK_DEV_ATA_SR tristate ATA CDROM support select BLK_DEV_SR Help text left as an exercise for the reader. Speaking as one who strongly objects to CONFIG_ATA unconditionally selecting SD or SR... I think you are on the right track. IMO a more clean and future-proof solution would be config ATA_PROT_ATA select SD config ATA_PROT_ATAPI (or ATAPI_PROT) select SR But that's just an example. Maybe the choices could be ATA_DISK and ATA_EVERYTHING_ELSE. :) The main points are * its not just CDROM support, but floppy/tape/etc. too for ATAPI * do not include sd or sr in the config name, it should be more generic, because SCSI will eventually be an optional module for libata. When libata talks to straight blkdev, we don't want this same problem to resurface! Jeff (very tired, so pardon any incoherence) - 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
[PATCH] Marvell 6440 SAS/SATA driver (draft)
The 88SE6440 driver :
The driver is based on bare code from Jeff Garzik. And it can work
under linux kernel 2.6.23.
By far, Can discover and find SAS HDD, but SATA is currently
unsupported. Command queue depth can be above 1.
Most error handling, and some phy handling code is notably missing.
contains the following updates:
--- mvsas_orig.c2007-12-06 19:21:32.0 -0500
+++ mvsas.c 2008-01-09 04:53:14.0 -0500
@@ -2,6 +2,7 @@
mvsas.c - Marvell 88SE6440 SAS/SATA support
Copyright 2007 Red Hat, Inc.
+ Copyright 2008 Marvell.
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
@@ -37,8 +38,10 @@
#include scsi/libsas.h
#include asm/io.h
-#define DRV_NAME mvsas
-#define DRV_VERSION 0.1
+#define DRV_NAME mvsas
+#define DRV_VERSION0.2
+#define _MV_DUMP 0
+#define MVS_PRINTK(_x_,...)printk(KERN_NOTICE DRV_NAME : _x_ , ##
__VA_ARGS__)
#define mr32(reg) readl(regs + MVS_##reg)
#define mw32(reg,val) writel((val), regs + MVS_##reg)
@@ -47,9 +50,42 @@
readl(regs + MVS_##reg);\
} while (0)
+#define MVS_BIT(x) (1L (x))
+
+#define PORT_TYPE_SATAMVS_BIT(0)
+#define PORT_TYPE_SAS MVS_BIT(1)
+
+#define READ_PORT_CONFIG_DATA(i) \
+ ((i3)?mr32(P4_CFG_DATA+(i-4)*8):mr32(P0_CFG_DATA+i*8))
+#define WRITE_PORT_CONFIG_DATA(i,tmp) \
+ {if(i3)mw32(P4_CFG_DATA+(i-4)*8,tmp);else mw32(P0_CFG_DATA+i*8,tmp);}
+#define WRITE_PORT_CONFIG_ADDR(i,tmp) \
+ {if(i3)mw32(P4_CFG_ADDR+(i-4)*8,tmp);else mw32(P0_CFG_ADDR+i*8,tmp);}
+
+#define READ_PORT_PHY_CONTROL(i) \
+ ((i3)?mr32(P4_SER_CTLSTAT+(i-4)*4):mr32(P0_SER_CTLSTAT+i*4))
+#define WRITE_PORT_PHY_CONTROL(i,tmp) \
+ {if(i3)mw32(P4_SER_CTLSTAT+(i-4)*4,tmp);else
mw32(P0_SER_CTLSTAT+i*4,tmp);}
+
+#define READ_PORT_VSR_DATA(i) \
+ ((i3)?mr32(P4_VSR_DATA+(i-4)*8):mr32(P0_VSR_DATA+i*8))
+#define WRITE_PORT_VSR_DATA(i,tmp) \
+ {if(i3)mw32(P4_VSR_DATA+(i-4)*8,tmp);else mw32(P0_VSR_DATA+i*8,tmp);}
+#define WRITE_PORT_VSR_ADDR(i,tmp) \
+ {if(i3)mw32(P4_VSR_ADDR+(i-4)*8,tmp);else mw32(P0_VSR_ADDR+i*8,tmp);}
+
+#define READ_PORT_IRQ_STAT(i) \
+ ((i3)?mr32(P4_INT_STAT+(i-4)*8):mr32(P0_INT_STAT+i*8))
+#define WRITE_PORT_IRQ_STAT(i,tmp) \
+ {if(i3)mw32(P4_INT_STAT+(i-4)*8,tmp);else mw32(P0_INT_STAT+i*8,tmp);}
+#define READ_PORT_IRQ_MASK(i) \
+ ((i3)?mr32(P4_INT_MASK+(i-4)*8):mr32(P0_INT_MASK+i*8))
+#define WRITE_PORT_IRQ_MASK(i,tmp) \
+ {if(i3)mw32(P4_INT_MASK+(i-4)*8,tmp);else mw32(P0_INT_MASK+i*8,tmp);}
+
/* driver compile-time configuration */
enum driver_configuration {
- MVS_TX_RING_SZ = 1024, /* TX ring size (12-bit) */
+ MVS_TX_RING_SZ = 512, /* TX ring size (12-bit) */
MVS_RX_RING_SZ = 1024, /* RX ring size (12-bit) */
/* software requires power-of-2
ring size */
@@ -89,7 +125,7 @@
MVS_GBL_CTL = 0x04, /* global control */
MVS_GBL_INT_STAT= 0x08, /* global irq status */
MVS_GBL_PI = 0x0C, /* ports implemented bitmask */
- MVS_GBL_PORT_TYPE = 0x00, /* port type */
+ MVS_GBL_PORT_TYPE = 0xa0, /* port type */
MVS_CTL = 0x100, /* SAS/SATA port configuration */
MVS_PCS = 0x104, /* SAS/SATA port control/status */
@@ -102,11 +138,12 @@
MVS_TX_LO = 0x124, /* TX (delivery) ring addr */
MVS_TX_HI = 0x128,
- MVS_RX_PROD_IDX = 0x12C, /* RX producer pointer */
- MVS_RX_CONS_IDX = 0x130, /* RX consumer pointer (RO) */
+ MVS_TX_PROD_IDX = 0x12C, /* TX producer pointer */
+ MVS_TX_CONS_IDX = 0x130, /* TX consumer pointer (RO) */
MVS_RX_CFG = 0x134, /* RX configuration */
MVS_RX_LO = 0x138, /* RX (completion) ring addr */
MVS_RX_HI = 0x13C,
+ MVS_RX_CONS_IDX = 0x140, /* RX consumer pointer (RO) */
MVS_INT_COAL= 0x148, /* Int coalescing config */
MVS_INT_COAL_TMOUT = 0x14C, /* Int coalescing timeout */
@@ -117,9 +154,12 @@
/* ports 1-3 follow after this */
MVS_P0_INT_STAT = 0x160, /* port0 interrupt status */
MVS_P0_INT_MASK = 0x164, /* port0 interrupt mask */
+ MVS_P4_INT_STAT = 0x200, /* Port 4 interrupt status */
+ MVS_P4_INT_MASK = 0x204, /* Port 4 interrupt enable/disable
mask */
/* ports 1-3 follow after this */
MVS_P0_SER_CTLSTAT = 0x180, /* port0 serial control/status */
+ MVS_P4_SER_CTLSTAT = 0x220, /* port4 serial control/status */
MVS_CMD_ADDR= 0x1B8,
Re: [PATCH] Marvell 6440 SAS/SATA driver (draft)
Ke Wei wrote: The 88SE6440 driver : The driver is based on bare code from Jeff Garzik. And it can work under linux kernel 2.6.23. By far, Can discover and find SAS HDD, but SATA is currently unsupported. Command queue depth can be above 1. Most error handling, and some phy handling code is notably missing. contains the following updates: --- mvsas_orig.c2007-12-06 19:21:32.0 -0500 +++ mvsas.c 2008-01-09 04:53:14.0 -0500 Fantastic! I'm delighted to see this is moving, and thanks much for getting the driver to that critical it works milestone. We should note for the linux-scsi audience and potential testers that the base driver upon which this is based is available on the sas branch of git://git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git I will give some substantive comments tomorrow (just got back from long trip). Two quick suggestions: 1) To make it easier for people to review and test the driver, I would suggest posting a diff against 2.6.24-rc7 (or 2.6.23), ignoring my original code. Thus, it would result in a patch 2) In future patches, include a Signed-off-by: line when you are ready for your patch to be included in the kernel. Thanks! Jeff - 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] Marvell 6440 SAS/SATA driver (draft)
Jeff Garzik wrote: 1) To make it easier for people to review and test the driver, I would suggest posting a diff against 2.6.24-rc7 (or 2.6.23), ignoring my original code. Thus, it would result in a patch Er, that sentence was incomplete. Continuing... Thus it would result in a patch that adds a new file drivers/scsi/mvsas.c to the 2.6.24-rc7 kernel, and modifies drivers/scsi/Makefile and drivers/scsi/Kconfig to enable this new driver. That is the format that developers and users are most familiar with, when reviewing (and testing) a new driver. But of course this is a draft, so these guidelines are certainly loose... Jeff - 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
