Re: [PATCH] zfcp: updates for -bk
On Tue, 2005-01-25 at 07:08 +0100, Heiko Carstens wrote: > > Originally this generic device was part of your adapter structure. Now > > you're trying to separate it and causing these problems. What it's > > Could you please elaborate where this patch does cause a problem? You're look to be breaking the simplicity rules. Object lifetimes are very tricky things to manage, so what I want you to explain is why you have to make this more difficult buy making the object separately managed instead of treating it as a sub object of the adapter which shares the adapter's lifetime rules. What's the justification for this? > > apparently telling us is that you have some problem with the object > > lifetime rules in your code. > > Why should this generic_services device have different lifetime rules > > from the object in which it used to reside? > > It doesn't. And this was not supposed to fix anything. It's just that > Andreas liked the code better with allocating the generic_services > struct device seperately. Please note that the lifetime of the adapter > device this struct device was embedded into is always longer than the > lifetime of the generic_services device. > Therefore I can't see why you complain about this piece of code. generic devices are supposed to represent existing kernel objects, which is why they're usually embedded in existing structures. It seems to be unique within the kernel to allocate a generic device without an enveloping structure (like a scsi_device, mca_device, pci_device etc), so I was wondering why you need to do it this way? Simplicity says that you want to manage the lifetimes of as few objects as you can get away with (SCSI tries to put all lifetime rules in either the mid-layer or the transport classes so the driver code doesn't usually have to worry about them). The reason being that lifetime rules are very easy to get wrong and have fairly nasty consequences if you do get them wrong (pointers into free'd memory etc.). James > Since I didn't get an answer to this: > http://marc.theaimsgroup.com/?l=linux-scsi&m=110551973013105&w=2 > my assumption was that it's that obvious to everyone else that I'm > wrong that it isn't even worth writing an answer. > Now I follow Greg's rules and still get complaints... > > Thanks, > Heiko > > - > 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: [PATCH] zfcp: updates for -bk
James, both Heiko and Andreas aren't available for several days. Let me try to answer your questions. > You're look to be breaking the simplicity rules. Object lifetimes are > very tricky things to manage, so what I want you to explain is why you > have to make this more difficult buy making the object separately > managed instead of treating it as a sub object of the adapter which > shares the adapter's lifetime rules. What's the justification for > this? Actually, you will find the adapter structure be an anchor for several other objects, or lists of them respectively. We tried to organize all the driver private data in a sane way. That means there is a tree of objects representing the SAN topology, including target ports and subordinate LUNs, many of which have an associated mid-layer structure. I can't imagine that anybody would ever argue to collapse all that into the adapter structure. So, why all the fuss about this particular object? The generic services object has nothing to do with the adapter. It's about fabric switch services, or certain well-known FC (target) ports, which can be accessed in the fabric through an adapter. It's not local but remote, like other targets, so to speak. We might also have chosen to call it "fabric switch". > generic devices are supposed to represent existing kernel objects, which > is why they're usually embedded in existing structures. It seems to be > unique within the kernel to allocate a generic device without an > enveloping structure (like a scsi_device, mca_device, pci_device etc), > so I was wondering why you need to do it this way? It gives us a separate subdirectory where to put all the (special) services ports instead of dumping them all into the adapter's directory among the other (commonplace) target ports. The latter appear by WWPN (64 bit, which is supposed to be much more persistent and descriptive), the former don't even have one, but need to be represented in a different way, namely by their well-known D_IDs (24 bit, descriptive in their own way because defined by FC standards). On the other hand, one might argue that we don't try to group commonplace target ports by node (which I won't advocate). Besides, given that the adapter structure is already refcounted, it might be confusing to have more than one refcount or struct device within one structure. > Simplicity says that you want to manage the lifetimes of as few objects > as you can get away with (SCSI tries to put all lifetime rules in either > the mid-layer or the transport classes so the driver code doesn't > usually have to worry about them). The reason being that lifetime rules > are very easy to get wrong and have fairly nasty consequences if you do > get them wrong (pointers into free'd memory etc.). Agreed. That would be our trade-off. Martin |-+> | | James Bottomley | | | <[EMAIL PROTECTED]| | | lEye.com>| | | Sent by: | | | [EMAIL PROTECTED]| | | .kernel.org | | || | || | | 25/01/2005 16:20 | | || |-+> >---| | | | To: Heiko Carstens/Germany/[EMAIL PROTECTED] | | cc: Greg KH <[EMAIL PROTECTED]>, SCSI Mailing List , Matthew Wilcox | |<[EMAIL PROTECTED]>, [EMAIL PROTECTED] | | Subject: Re: [PATCH] zfcp: updates for -bk | | | >---| On Tue, 2005-01-25 at 07:08 +0100, Heiko Carstens wrote: > > Originally this generic device was part of your adapter structure. Now > > you're trying to separate it and causing these problems. What it's > > Could you please elaborate where this patch does cause a problem? You're look to be breaking the simplicity rules. Object lifetimes are very tricky things to manage, so what I want you to explain is why you have to make this more difficult buy making the object separately managed instead of treating it as a sub object of the adapter which shares the adapter's lifetime rules. What's the justification for this? > > apparently telling us is that you have some problem with the object > > lifetime
aacraid 1.1.5-2372 waiting..
Hi, I have recently bought an Adaptec 2410SA raid controller and I am having some IO performance difficulties. Basically, whenever I access the configured RAID5 logical device the CPU appears to be spending most of it's time in the 'iowait' state (I am running 'top' and the 'wa' figure shoots up (I think that's what it's telling me?)) this occurs for both reads and writes and is having a very detrimental affect on everything else running on the system. After some extensive googling I have come across other people's reports of similar behaviour but I have been unable to find any solutions? My system configuration: - AMD Athlon XP 2000+ (133MHz FSB) 512MB DDR RAM (Dual channel) Asus A7N8X nForce2 motherboard (Rev 2.0 board with latest BIOS) Adaptec 2410SA using 7348 firmware (installed in a 32-bit PCI slot) 3xHitachi Deskstar 7K250 250GB drives (1 RAID5 logical device using default 64K stripe size containing 1 Ext3 partition made with appropriate 'stripe' option to mke2fs. Slackware 10 base installation updated with most of the latest packages available. Custom built 2.6.10 kernel (I have tried 2.4.26 as well) aacraid 1.1.5-2372 (I have also tried the stock linux 2.6.10 aacraid driver) The system appears to be running reasonably well apart from the dire performance, it always finds that array on boot, I can use the Adaptec Storage manager software etc. (Although the performance has prevented me using the RAID storage properly, at the moment it spends most of its time sitting in the system idle) I have tried lots of different things, changing the PCI slot, changing the PCI latencies of the controller and other PCI devices, various combinations of drivers and kernels, turning IOAPIC on/off for the motherboard.. I would really appreciate any assistance anyone can provide me with this problem, even if it's only further diagnostics that I can try. Thanks in advance. Peter Stokes - 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] zfcp: updates for -bk
On Tue, 2005-01-25 at 19:10 +0100, Martin Peschke3 wrote: > Actually, you will find the adapter structure be an anchor for several > other objects, or lists of them respectively. We tried to organize > all the driver private data in a sane way. That means there is a tree > of objects representing the SAN topology, including target ports and > subordinate LUNs, many of which have an associated mid-layer structure. > I can't imagine that anybody would ever argue to collapse all that into > the adapter structure. So, why all the fuss about this particular object? > The generic services object has nothing to do with the adapter. It's about > fabric switch services, or certain well-known FC (target) ports, which can > be accessed in the fabric through an adapter. It's not local but remote, > like other targets, so to speak. We might also have chosen to call it > "fabric switch". OK, take a look at this: http://marc.theaimsgroup.com/?l=linux-scsi&m=110546207223304 and tell me if it does everything you need. If it doesn't, you could try adding all the other bits to the fc transport class. 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] add iSCSI session creation sysfs attributes
James Bottomley wrote: On Mon, 2005-01-24 at 02:39 -0800, Mike Christie wrote: The attached patch built against scsi-misc-2.6 moves the target iSCSI attributes to a new structure representing a iSCSI session. The reason for doing this is to create a interface that allows the Sourceforge iSCSI driver to create and setup a session through sysfs (no more IOCTL at all in our driver), display session info, and at the same time share code and use the same interface HW iSCSI drivers would use. This no longer applies to the iscsi transport class because I converted it over to the generic framework. Could you look at the code in bk://linux-scsi.bkbits.net/scsi-rc-fixes-2.6 (or the patch on www.parisc-linux.org/~jejb/scsi_diffs) and reroll your patch against that? Will do. One question though. If a function like transport_add_device or transport_setup_device fails, how does the caller detect this? Thanks, 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] add iSCSI session creation sysfs attributes
On Tue, 2005-01-25 at 12:37 -0800, Mike Christie wrote: > Will do. One question though. If a function like > transport_add_device or transport_setup_device fails, > how does the caller detect this? It doesn't; the system runs degraded. 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: [Announce] Emulex lpfcdriver v8.0.20 available
On Thu, Jan 20, 2005 at 11:26:00AM -0500, [EMAIL PROTECTED] wrote: > > This sounds like a good idea, but I wonder if we have userland relying > > on those attributes already. But given that the fc transport class > > was mostly a joke before you encehanced it it might be worth breaking > > it.. > > You and James would have to give the approval for this one. I already > encountered issues with these attributes when then went from scsi_device > to scsi_target. The most significant hiccup was to udev and the projects > depending on it... Also, given the potential amount of change may be > needed to move to rports, I wouldn't want to pull the rug out from under > the other drivers until they are ready... James just returned from a long journey and he hasn't read the thread yet, but after a short discussion we agree that it's better to move the attributes over to the rnode. If we're seeing compatiblity problems we'll have to add symlinks. > > > -- james s ---end quoted text--- - 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] Change scsi send/completion logging back to terser output
Patch against latest scsi rc fixes.
Change scsi send/completion logging back to terser output:
print_command was renamed __scsi_print_command, but two print_command
calls were renamed to scsi_print_command rather than __scsi_print_command.
__scsi_print_command at one time did not print KERN_INFO prefix, change it
back to not print it.
Signed off by: Patrick Mansfield <[EMAIL PROTECTED]>
diff -uprN -X /home/patman/dontdiff
scsi-rc-fix-2.6.11-rc2/drivers/scsi/constants.c
terser-cmd/drivers/scsi/constants.c
--- scsi-rc-fix-2.6.11-rc2/drivers/scsi/constants.c Tue Jan 25 12:26:21 2005
+++ terser-cmd/drivers/scsi/constants.c Tue Jan 25 12:27:38 2005
@@ -342,7 +342,7 @@ void __scsi_print_command(unsigned char
{
int k, len;
- print_opcode_name(command, 0, 1);
+ print_opcode_name(command, 0, 0);
if (VARIABLE_LENGTH_CMD == command[0])
len = command[7] + 8;
else
diff -uprN -X /home/patman/dontdiff scsi-rc-fix-2.6.11-rc2/drivers/scsi/scsi.c
terser-cmd/drivers/scsi/scsi.c
--- scsi-rc-fix-2.6.11-rc2/drivers/scsi/scsi.c Tue Jan 25 11:08:54 2005
+++ terser-cmd/drivers/scsi/scsi.c Tue Jan 25 11:11:31 2005
@@ -424,7 +424,7 @@ void scsi_log_send(struct scsi_cmnd *cmd
* output in scsi_log_completion.
*/
printk(" ");
- scsi_print_command(cmd);
+ __scsi_print_command(cmd);
if (level > 3) {
printk(KERN_INFO "buffer = 0x%p, bufflen = %d,"
" done = 0x%p, queuecommand 0x%p\n",
@@ -492,7 +492,7 @@ void scsi_log_completion(struct scsi_cmn
printk("UNKNOWN");
}
printk(" %8x ", cmd->result);
- scsi_print_command(cmd);
+ __scsi_print_command(cmd);
if (status_byte(cmd->result) & CHECK_CONDITION) {
/*
* XXX The print_sense formatting/prefix
-
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: [Announce] Emulex lpfcdriver v8.0.20 available
I can easily disable the them. However, I won't sign up for dealing with this change in the other FC drivers as it could be rather extensive. A patch to back out the attributes would disable FC transport support in the other drivers. Their maintainers would need to re-add support. -- james s Christoph Hellwig wrote: > On Thu, Jan 20, 2005 at 11:26:00AM -0500, > [EMAIL PROTECTED] wrote: > > > This sounds like a good idea, but I wonder if we have > userland relying > > > on those attributes already. But given that the fc > transport class > > > was mostly a joke before you encehanced it it might be > worth breaking > > > it.. > > > > You and James would have to give the approval for this one. > I already > > encountered issues with these attributes when then went > from scsi_device > > to scsi_target. The most significant hiccup was to udev and > the projects > > depending on it... Also, given the potential amount of change may be > > needed to move to rports, I wouldn't want to pull the rug > out from under > > the other drivers until they are ready... > > James just returned from a long journey and he hasn't read > the thread yet, > but after a short discussion we agree that it's better to > move the attributes > over to the rnode. If we're seeing compatiblity problems > we'll have to > add symlinks. - 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
IP/ethernet/networking-over-SCSI.
For some purposes at the moment, working IP-over-SCSI could be rather handy... ;-). I can see some project(s) for this but I am not sure which actaully work. Many seem to want to have a particular SCSI board In short, I am stuck with a particular SCSI board in some machine(s) (e.g. 'pizzabox' small machines with onboard SCSI). Is there any implementation that just works over SG (scsi generic) interface etc. and hence controller independant? This would need to be happy to work cross-architectures (MIPS, PPC, i386, etc.). I would like any comments or pointers to working mechanisms/projects for this... Even just a 'manual tunnel' would be good -- i.e. a userspace program that listens for a TCP connection from localhost, carries that over SG, to listening/replying version at the other end, that carries the data to a TCP-connection TO localhost at the other end. In fact, at least so far as X11 goes, something similar that works at the UNIX socket layer would be nice, but then the 'reliability' needs to be implemented too, which is sortof reinventing the wheel, TCP does this anyway ;-), unless the SCSI connection with 'sg' can be considered truly reliable?? Comments welcome, please ;-). --S Iremonger <[EMAIL PROTECTED]> - 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: IP/ethernet/networking-over-SCSI.
On Tue, 25 Jan 2005 16:19:12 + (GMT) S Iremonger <[EMAIL PROTECTED]> wrote: > > For some purposes at the moment, working IP-over-SCSI could be rather > handy... ;-). You probably are looking for: http://linux-iscsi.sourceforge.net/ -- Stephen Hemminger <[EMAIL PROTECTED]> - 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: IP/ethernet/networking-over-SCSI.
On Tue, 2005-01-25 at 14:01, Stephen Hemminger wrote: > On Tue, 25 Jan 2005 16:19:12 + (GMT) > S Iremonger <[EMAIL PROTECTED]> wrote: > > > > > For some purposes at the moment, working IP-over-SCSI could be rather > > handy... ;-). > > You probably are looking for: > http://linux-iscsi.sourceforge.net/ this is scsi over ip he want a ip over scsi. ming - 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: IP/ethernet/networking-over-SCSI.
On Tue, 25 Jan 2005, Stephen Hemminger wrote: > On Tue, 25 Jan 2005 16:19:12 + (GMT) S Iremonger <[EMAIL PROTECTED]> > wrote: > > > > > For some purposes at the moment, working IP-over-SCSI could be rather > > handy... ;-). > > You probably are looking for: > http://linux-iscsi.sourceforge.net/ Nah, iscsi is SCSI protocol over IP. The original poster wants the reverse - IP over SCSI :) There was some work a long time ago to do this, mostly for curiosity sake: One link is http://w3.ualg.pt/~dubuf/ipscsi.html There's even RFC2143 that specifies a packet format for crazy people who want to do this. Few benefits of those that could be thought - u320 scsi is essentially 3gbps of bandwidth. SCSI has natural support for jumbo packets - SCSI packet can be 256kbytes in size. -alex - 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: IP/ethernet/networking-over-SCSI.
On Tue, Jan 25, 2005 at 11:01:13AM -0800, Stephen Hemminger wrote: > On Tue, 25 Jan 2005 16:19:12 + (GMT) > S Iremonger <[EMAIL PROTECTED]> wrote: > > > > > For some purposes at the moment, working IP-over-SCSI could be rather > > handy... ;-). > > You probably are looking for: > http://linux-iscsi.sourceforge.net/ That's SCSI-over-IP, a rather different concept ;-) I think he's looking for an implementation of http://www.faqs.org/rfcs/rfc2143.html I wonder if that's the same Ben Elliston who's now working on GCC ... -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain - 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: IP/ethernet/networking-over-SCSI.
Great! Now you can have ISCSI over SCSI! :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, January 25, 2005 2:07 PM To: Stephen Hemminger Cc: S Iremonger; linux-net@vger.kernel.org; linux-scsi@vger.kernel.org Subject: Re: IP/ethernet/networking-over-SCSI. On Tue, 25 Jan 2005, Stephen Hemminger wrote: > On Tue, 25 Jan 2005 16:19:12 + (GMT) S Iremonger <[EMAIL PROTECTED]> > wrote: > > > > > For some purposes at the moment, working IP-over-SCSI could be rather > > handy... ;-). > > You probably are looking for: > http://linux-iscsi.sourceforge.net/ Nah, iscsi is SCSI protocol over IP. The original poster wants the reverse - IP over SCSI :) There was some work a long time ago to do this, mostly for curiosity sake: One link is http://w3.ualg.pt/~dubuf/ipscsi.html There's even RFC2143 that specifies a packet format for crazy people who want to do this. Few benefits of those that could be thought - u320 scsi is essentially 3gbps of bandwidth. SCSI has natural support for jumbo packets - SCSI packet can be 256kbytes in size. -alex - 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: IP/ethernet/networking-over-SCSI.
Ok, now my head is starting to hurt! :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ming Zhang Sent: Tuesday, January 25, 2005 4:04 PM To: Guy Cc: [EMAIL PROTECTED]; 'Stephen Hemminger'; 'S Iremonger'; linux-net@vger.kernel.org; linux-scsi Subject: RE: IP/ethernet/networking-over-SCSI. On Tue, 2005-01-25 at 15:16, Guy wrote: > Great! Now you can have ISCSI over SCSI! :) u can have iscsi over scsi over iscsi! > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Tuesday, January 25, 2005 2:07 PM > To: Stephen Hemminger > Cc: S Iremonger; linux-net@vger.kernel.org; linux-scsi@vger.kernel.org > Subject: Re: IP/ethernet/networking-over-SCSI. > > On Tue, 25 Jan 2005, Stephen Hemminger wrote: > > > On Tue, 25 Jan 2005 16:19:12 + (GMT) S Iremonger <[EMAIL PROTECTED]> > > wrote: > > > > > > > > For some purposes at the moment, working IP-over-SCSI could be rather > > > handy... ;-). > > > > You probably are looking for: > > http://linux-iscsi.sourceforge.net/ > Nah, iscsi is SCSI protocol over IP. The original poster wants the reverse > - IP over SCSI :) > > There was some work a long time ago to do this, mostly for curiosity sake: > > One link is http://w3.ualg.pt/~dubuf/ipscsi.html > > There's even RFC2143 that specifies a packet format for crazy people who > want to do this. > > Few benefits of those that could be thought - u320 scsi is essentially > 3gbps of bandwidth. SCSI has natural support for jumbo packets - SCSI > packet can be 256kbytes in size. > > -alex > > - > 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 - 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: IP/ethernet/networking-over-SCSI.
On Tue, 2005-01-25 at 15:16, Guy wrote: > Great! Now you can have ISCSI over SCSI! :) u can have iscsi over scsi over iscsi! > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Tuesday, January 25, 2005 2:07 PM > To: Stephen Hemminger > Cc: S Iremonger; linux-net@vger.kernel.org; linux-scsi@vger.kernel.org > Subject: Re: IP/ethernet/networking-over-SCSI. > > On Tue, 25 Jan 2005, Stephen Hemminger wrote: > > > On Tue, 25 Jan 2005 16:19:12 + (GMT) S Iremonger <[EMAIL PROTECTED]> > > wrote: > > > > > > > > For some purposes at the moment, working IP-over-SCSI could be rather > > > handy... ;-). > > > > You probably are looking for: > > http://linux-iscsi.sourceforge.net/ > Nah, iscsi is SCSI protocol over IP. The original poster wants the reverse > - IP over SCSI :) > > There was some work a long time ago to do this, mostly for curiosity sake: > > One link is http://w3.ualg.pt/~dubuf/ipscsi.html > > There's even RFC2143 that specifies a packet format for crazy people who > want to do this. > > Few benefits of those that could be thought - u320 scsi is essentially > 3gbps of bandwidth. SCSI has natural support for jumbo packets - SCSI > packet can be 256kbytes in size. > > -alex > > - > 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 - 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
[2.6 patch] SCSI psi240i.c: make 4 functions static
This patch makes 4 needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/scsi/psi240i.c |8
drivers/scsi/psi240i.h |4
2 files changed, 4 insertions(+), 8 deletions(-)
This patch was already sent on:
- 15 Nov 2004
--- linux-2.6.10-rc1-mm5-full/drivers/scsi/psi240i.h.old2004-11-13
22:46:35.0 +0100
+++ linux-2.6.10-rc1-mm5-full/drivers/scsi/psi240i.h2004-11-13
23:09:48.0 +0100
@@ -309,11 +309,7 @@
#endif // PSI_EIDE_SCSIOP
// function prototypes
-int Psi240i_Detect (Scsi_Host_Template *tpnt);
int Psi240i_Command(Scsi_Cmnd *SCpnt);
-int Psi240i_QueueCommand (Scsi_Cmnd *SCpnt, void (*done)(Scsi_Cmnd *));
int Psi240i_Abort (Scsi_Cmnd *SCpnt);
int Psi240i_Reset (Scsi_Cmnd *SCpnt, unsigned int flags);
-int Psi240i_BiosParam (struct scsi_device *sdev, struct block_device
*bdev,
- sector_t capacity, int geom[]);
#endif
--- linux-2.6.10-rc1-mm5-full/drivers/scsi/psi240i.c.old2004-11-13
22:47:12.0 +0100
+++ linux-2.6.10-rc1-mm5-full/drivers/scsi/psi240i.c2004-11-13
22:47:59.0 +0100
@@ -390,7 +390,7 @@
* Returns:Status code.
*
/
-int Psi240i_QueueCommand (Scsi_Cmnd *SCpnt, void (*done)(Scsi_Cmnd *))
+static int Psi240i_QueueCommand (Scsi_Cmnd *SCpnt, void (*done)(Scsi_Cmnd *))
{
UCHAR *cdb = (UCHAR *)SCpnt->cmnd;
// Pointer to SCSI CDB
PADAPTER240Ipadapter = HOSTDATA (SCpnt->device->host);
// Pointer to adapter control structure
@@ -509,7 +509,7 @@
* Returns:Nothing.
*
**/
-void ReadChipMemory (void *pdata, USHORT base, USHORT length, USHORT port)
+static void ReadChipMemory (void *pdata, USHORT base, USHORT length, USHORT
port)
{
USHORT z, zz;
UCHAR *pd = (UCHAR *)pdata;
@@ -538,7 +538,7 @@
* Returns:Number of adapters found.
*
/
-int Psi240i_Detect (Scsi_Host_Template *tpnt)
+static int Psi240i_Detect (Scsi_Host_Template *tpnt)
{
int board;
int count = 0;
@@ -654,7 +654,7 @@
* Returns:zero.
*
/
-int Psi240i_BiosParam (struct scsi_device *sdev, struct block_device *dev,
+static int Psi240i_BiosParam (struct scsi_device *sdev, struct block_device
*dev,
sector_t capacity, int geom[])
{
POUR_DEVICE pdev;
-
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
[2.6 patch] SCSI ips.c: make some code static
This patch makes some needlessly global code static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- drivers/scsi/ips.c | 244 ++--- drivers/scsi/ips.h | 12 -- 2 files changed, 123 insertions(+), 133 deletions(-) This patch was already sent on: - 15 Nov 2004 - 21 Dec 2004 - 8 Jan 2005 --- linux-2.6.10-rc1-mm5-full/drivers/scsi/ips.h.old2004-11-13 22:29:51.0 +0100 +++ linux-2.6.10-rc1-mm5-full/drivers/scsi/ips.h2004-11-13 22:40:47.0 +0100 @@ -53,14 +53,6 @@ #include #include - /* Prototypes */ - extern int ips_detect(Scsi_Host_Template *); - extern int ips_release(struct Scsi_Host *); - extern int ips_eh_abort(Scsi_Cmnd *); - extern int ips_eh_reset(Scsi_Cmnd *); - extern int ips_queue(Scsi_Cmnd *, void (*) (Scsi_Cmnd *)); - extern const char * ips_info(struct Scsi_Host *); - /* * Some handy macros */ @@ -457,10 +449,10 @@ static void ips_select_queue_depth(struct Scsi_Host *, Scsi_Device *); static int ips_biosparam(Disk *disk, kdev_t dev, int geom[]); #else - int ips_proc_info(struct Scsi_Host *, char *, char **, off_t, int, int); + static int ips_proc_info(struct Scsi_Host *, char *, char **, off_t, int, int); static int ips_biosparam(struct scsi_device *sdev, struct block_device *bdev, sector_t capacity, int geom[]); - int ips_slave_configure(Scsi_Device *SDptr); + static int ips_slave_configure(Scsi_Device *SDptr); #endif /* --- linux-2.6.10-rc1-mm5-full/drivers/scsi/ips.c.old2004-11-13 22:28:43.0 +0100 +++ linux-2.6.10-rc1-mm5-full/drivers/scsi/ips.c2004-11-13 22:38:30.0 +0100 @@ -246,6 +246,117 @@ #endif /* + * Function prototypes + */ +static int ips_detect(Scsi_Host_Template *); +static int ips_release(struct Scsi_Host *); +static int ips_eh_abort(Scsi_Cmnd *); +static int ips_eh_reset(Scsi_Cmnd *); +static int ips_queue(Scsi_Cmnd *, void (*)(Scsi_Cmnd *)); +static const char *ips_info(struct Scsi_Host *); +static irqreturn_t do_ipsintr(int, void *, struct pt_regs *); +static int ips_hainit(ips_ha_t *); +static int ips_map_status(ips_ha_t *, ips_scb_t *, ips_stat_t *); +static int ips_send_wait(ips_ha_t *, ips_scb_t *, int, int); +static int ips_send_cmd(ips_ha_t *, ips_scb_t *); +static int ips_online(ips_ha_t *, ips_scb_t *); +static int ips_inquiry(ips_ha_t *, ips_scb_t *); +static int ips_rdcap(ips_ha_t *, ips_scb_t *); +static int ips_msense(ips_ha_t *, ips_scb_t *); +static int ips_reqsen(ips_ha_t *, ips_scb_t *); +static int ips_deallocatescbs(ips_ha_t *, int); +static int ips_allocatescbs(ips_ha_t *); +static int ips_reset_copperhead(ips_ha_t *); +static int ips_reset_copperhead_memio(ips_ha_t *); +static int ips_reset_morpheus(ips_ha_t *); +static int ips_issue_copperhead(ips_ha_t *, ips_scb_t *); +static int ips_issue_copperhead_memio(ips_ha_t *, ips_scb_t *); +static int ips_issue_i2o(ips_ha_t *, ips_scb_t *); +static int ips_issue_i2o_memio(ips_ha_t *, ips_scb_t *); +static int ips_isintr_copperhead(ips_ha_t *); +static int ips_isintr_copperhead_memio(ips_ha_t *); +static int ips_isintr_morpheus(ips_ha_t *); +static int ips_wait(ips_ha_t *, int, int); +static int ips_write_driver_status(ips_ha_t *, int); +static int ips_read_adapter_status(ips_ha_t *, int); +static int ips_read_subsystem_parameters(ips_ha_t *, int); +static int ips_read_config(ips_ha_t *, int); +static int ips_clear_adapter(ips_ha_t *, int); +static int ips_readwrite_page5(ips_ha_t *, int, int); +static int ips_init_copperhead(ips_ha_t *); +static int ips_init_copperhead_memio(ips_ha_t *); +static int ips_init_morpheus(ips_ha_t *); +static int ips_isinit_copperhead(ips_ha_t *); +static int ips_isinit_copperhead_memio(ips_ha_t *); +static int ips_isinit_morpheus(ips_ha_t *); +static int ips_erase_bios(ips_ha_t *); +static int ips_program_bios(ips_ha_t *, char *, uint32_t, uint32_t); +static int ips_verify_bios(ips_ha_t *, char *, uint32_t, uint32_t); +static int ips_erase_bios_memio(ips_ha_t *); +static int ips_program_bios_memio(ips_ha_t *, char *, uint32_t, uint32_t); +static int ips_verify_bios_memio(ips_ha_t *, char *, uint32_t, uint32_t); +static int ips_flash_copperhead(ips_ha_t *, ips_passthru_t *, ips_scb_t *); +static int ips_flash_bios(ips_ha_t *, ips_passthru_t *, ips_scb_t *); +static int ips_flash_firmware(ips_ha_t *, ips_passthru_t *, ips_scb_t *); +static void ips_free_flash_copperhead(ips_ha_t * ha); +static void ips_get_bios_version(ips_ha_t *, int); +static void ips_identify_controller(ips_ha_t *); +static void ips_chkstatus(ips_ha_t *, IPS_STATUS *); +static void ips_enable_int_copperhead(ips_ha_t *); +static void ips_enable_int_copperhead_memio(ips_ha_t *); +static void ips_enable_int_morpheus(ips_ha_t *); +static int ips_intr_copperhead(ips_ha_t *); +static int ips_intr_morpheus(ips_ha_t *); +static void ips_next(ips_ha_t *, int); +static void ipsintr_blocking(ips_ha_t *, struct ips_scb *); +static void
RE: How to add/drop SCSI drives from within the driver?
> > > After the new logical drives are created with "- - -" written to the > > scsi_host scan attribute, there is a highly noticeable delay before > device > > names (e.g., sda) appears in the /dev directory. If the management > > application tried to access the device immediately after creating new, > the > > access fails. Putting a 1 second delay helped, but of course this is not > a > > deterministic solution. > > > > What are the other possibilities? > > Well, how about hotplug. The device addition actually triggers a hot > plug event already (there's no need to add anything, it's done by the > mid-layer), so if you just listen for that, you'll know when the scan > has detected a device. After writing the "- - -" to the scan attribute, the management applications assume the udev has created the relevant entries in the /dev directly and try to use the devices _immediately_ and fail to see the devices Is there a hotplug event which would tell the management applications that the device nodes have actually been created now and ready to be used? I tried this simple script to re-create the failure. Assume there is one scsi disk, which is the installation disk. Now load the megaraid driver, with a few logical drive already created. # insmod megaraid_mm.ko; insmod megaraid_mbox.ko; ls -l /dev/sd* # ls -l /dev/sd*# all devices show up now Thanks -Atul - 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: How to add/drop SCSI drives from within the driver?
Atul - On Tue, Jan 25, 2005 at 11:27:36AM -0500, Mukker, Atul wrote: > After writing the "- - -" to the scan attribute, the management applications > assume the udev has created the relevant entries in the /dev directly and > try to use the devices _immediately_ and fail to see the devices > > Is there a hotplug event which would tell the management applications that > the device nodes have actually been created now and ready to be used? Read the udev man page section, the part right before "FILES". Try putting a script under /etc/dev.d/default/*.dev. Then you can get more specific with an /etc/dev.d/scsi/*.dev script or something else. I just tried something simple but did not get it working. Try [EMAIL PROTECTED] list for help. -- Patrick Mansfield - 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
[BK PATCH] SCSI updates for 2.6.11-rc2
This is mostly simple updates. There is one new feature: the move over to generic transport classes. This doesn't impact anything other than SCSI (although the idea is that it will in future) but it does introduce new abstractions in drivers/base (which I got Greg's sign off on). The patch is available from: bk://linux-scsi.bkbits.net/scsi-for-linus-2.6 The short changelog is: : o dpt_i2o: remove schedule_timeout() Adrian Bunk: o SCSI NCR_Q720.c: make some code static Alan Stern: o Fix reference to deallocated memory in sd.c Andi Kleen: o Add compat_ioctl to scsi host structure Christoph Hellwig: o osst: don't use obsolete SCSI APIs o cosmetic jazz_esp updates o update dec_esp with changes from mips CVS o update mips driver Kconfig bits Domen Puncer: o delete unused file dpt_osdutil.h Douglas Gilbert: o sd descriptor sense support o streamline block SG_IO error processing in sd o streamline block SG_IO error processing o sense data helpers lk 2.6.11-rc1-bk1 o sg descriptor sense cleanup lk 2.6.11-rc1-bk1 o scsi_debug dsense Geert Uytterhoeven: o SCSI NCR53C9x.c: some cleanups James Bottomley: o SCSI: Fix style nitpicks o move the SCSI transport classes over to the generic transport class o add a generic device transport class o Add attribute container to generic device model o fix use after potential free in scsi_cd_put Mark Haverkamp: o aacraid 2.6: add scsi synchronize cache support and the diffstat: b/drivers/base/Makefile |3 b/drivers/base/attribute_container.c | 274 +++ b/drivers/base/init.c |3 b/drivers/base/transport_class.c | 272 +++ b/drivers/scsi/Kconfig|4 b/drivers/scsi/NCR53C9x.c |4 b/drivers/scsi/NCR53C9x.h |2 b/drivers/scsi/NCR_Q720.c |4 b/drivers/scsi/aacraid/aachba.c | 113 + b/drivers/scsi/aacraid/aacraid.h | 24 ++ b/drivers/scsi/dec_esp.c | 396 +- b/drivers/scsi/dpt_i2o.c |1 b/drivers/scsi/hosts.c| 21 - b/drivers/scsi/jazz_esp.c | 49 ++-- b/drivers/scsi/oktagon_esp.c |2 b/drivers/scsi/osst.c | 198 - b/drivers/scsi/osst.h |4 b/drivers/scsi/scsi_debug.c |6 b/drivers/scsi/scsi_error.c | 93 +++ b/drivers/scsi/scsi_lib.c | 108 - b/drivers/scsi/scsi_priv.h|2 b/drivers/scsi/scsi_scan.c| 24 -- b/drivers/scsi/scsi_sysfs.c | 131 ++- b/drivers/scsi/scsi_transport_fc.c| 112 + b/drivers/scsi/scsi_transport_iscsi.c | 85 --- b/drivers/scsi/scsi_transport_spi.c | 139 +++ b/drivers/scsi/sd.c | 169 -- b/drivers/scsi/sg.c | 30 +- b/drivers/scsi/sr.c |4 b/include/linux/attribute_container.h | 61 + b/include/linux/transport_class.h | 77 ++ b/include/scsi/scsi_device.h |9 b/include/scsi/scsi_eh.h |6 b/include/scsi/scsi_host.h| 19 + b/include/scsi/scsi_transport.h | 33 -- b/include/scsi/scsi_transport_spi.h |1 drivers/scsi/dpt/dpt_osdutil.h| 358 -- 37 files changed, 1729 insertions(+), 1112 deletions(-) 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: How to add/drop SCSI drives from within the driver?
Thanks for the suggestion. After more exploration, looks like different distribution have different implementations for /sbin/hotplug. This may aggravate the issue for applications. For now, we will stick with a wait and watch after bus scan :-( Will probe the [EMAIL PROTECTED] list for more pointers Thanks === Atul Mukker Architect, Drivers and BIOS LSI Logic Corporation > -Original Message- > From: Patrick Mansfield [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 25, 2005 11:52 AM > To: Mukker, Atul > Cc: 'James Bottomley'; Linux Kernel; SCSI Mailing List > Subject: Re: How to add/drop SCSI drives from within the driver? > > Atul - > > On Tue, Jan 25, 2005 at 11:27:36AM -0500, Mukker, Atul wrote: > > After writing the "- - -" to the scan attribute, the management > > applications assume the udev has created the relevant > entries in the > > /dev directly and try to use the devices _immediately_ and > fail to see > > the devices > > > > Is there a hotplug event which would tell the management > applications > > that the device nodes have actually been created now and > ready to be used? > > Read the udev man page section, the part right before > "FILES". Try putting a script under /etc/dev.d/default/*.dev. > Then you can get more specific with an /etc/dev.d/scsi/*.dev > script or something else. > > I just tried something simple but did not get it working. > > Try [EMAIL PROTECTED] list for help. > > -- Patrick Mansfield > - 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
[Announce] megaraid_mbox 2.20.4.3 patch
Hello, Here is a patch for megaraid_mbox 2.20.4.3 and megaraid_mm 2.20.2.5. The patch includes following changes/fixes - sysfs support for drive addition/removal - Tape drive timeout issue - Made some code static I am attaching and inlining the patch. Thank you. Seokmann LSI Logic --- diff -Naur linux_bk/Documentation/scsi/ChangeLog.megaraid linux_bk.new/Documentation/scsi/ChangeLog.megaraid --- linux_bk/Documentation/scsi/ChangeLog.megaraid 2005-01-25 18:12:46.0 -0500 +++ linux_bk.new/Documentation/scsi/ChangeLog.megaraid 2005-01-25 18:21:48.525354048 -0500 @@ -1,3 +1,77 @@ +Release Date : Fri Jan 21 00:01:03 EST 2005 - Atul Mukker <[EMAIL PROTECTED]> +Current Version : 2.20.4.3 (scsi module), 2.20.2.5 (cmm module) +Older Version : 2.20.4.2 (scsi module), 2.20.2.4 (cmm module) + +i. Remove driver ioctl for logical drive to scsi address translation and + replace with the sysfs attribute. To remove drives and change + capacity, application shall now use the device attribute to get the + logical drive number for a scsi device. For adding newly created + logical drives, class device attribute would be required to uniquely + identify each controller. + - Atul Mukker <[EMAIL PROTECTED]> + + "James, I've been thinking about this a little more, and you may be on + to something here. Let each driver add files as such:" + + - Matt Domsch <[EMAIL PROTECTED]>, 12.15.2004 + linux-scsi mailing list + + + "Then, if you simply publish your LD number as an extra parameter of + the device, you can look through /sys to find it." + + - James Bottomley <[EMAIL PROTECTED]>, 01.03.2005 + linux-scsi mailing list + + + "I don't see why not ... it's your driver, you can publish whatever + extra information you need as scsi_device attributes; that was one of + the designs of the extensible attribute system." + + - James Bottomley <[EMAIL PROTECTED]>, 01.06.2005 + linux-scsi mailing list + +ii. Add AMI megaraid support - Brian King <[EMAIL PROTECTED]> + PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3, + PCI_VENDOR_ID_AMI, PCI_SUBSYS_ID_PERC3_DC, + +iii. Make some code static + - Adrian Bunk <[EMAIL PROTECTED]>, 11.15.2004 + linux-scsi mailing list + +iv. Added NEC ROMB support - NEC MegaRAID PCI Express ROMB controller + PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_MEGARAID_NEC_ROMB_2E, + PCI_SUBSYS_ID_NEC, PCI_SUBSYS_ID_MEGARAID_NEC_ROMB_2E, + +v. Fixed Tape drive issue : For any Direct CDB command to physical device + including tape, timeout value set by driver was 10 minutes. With this + value, most of command will return within timeout. However, for those + command like ERASE or FORMAT, it takes more than an hour depends on + capacity of the device and the command could be terminated before it + completes. + To address this issue, the 'timeout' field in the DCDB command will + have NO TIMEOUT (i.e., 4) value as its timeout on DCDB command. + + +Release Date : Thu Dec 9 19:10:23 EST 2004 + - Sreenivas Bagalkote <[EMAIL PROTECTED]> + +Current Version : 2.20.4.2 (scsi module), 2.20.2.4 (cmm module) +Older Version : 2.20.4.1 (scsi module), 2.20.2.3 (cmm module) + +i. Introduced driver ioctl that returns scsi address for a given ld. + + "Why can't the existing sysfs interfaces be used to do this?" + - Brian King ([EMAIL PROTECTED]) + + "I've looked into solving this another way, but I cannot see how + to get this driver-private mapping of logical drive number-> HCTL + without putting code something like this into the driver." + + "...and by providing a mapping a function to userspace, the driver + is free to change its mapping algorithm in the future if necessary .." + - Matt Domsch ([EMAIL PROTECTED]) + Release Date : Thu Dec 9 19:02:14 EST 2004 - Sreenivas Bagalkote <[EMAIL PROTECTED]> Current Version : 2.20.4.1 (scsi module), 2.20.2.3 (cmm module) diff -Naur linux_bk/drivers/scsi/megaraid/Kconfig.megaraid linux_bk.new/drivers/scsi/megaraid/Kconfig.megaraid --- linux_bk/drivers/scsi/megaraid/Kconfig.megaraid 2005-01-25 18:13:37.0 -0500 +++ linux_bk.new/drivers/scsi/megaraid/Kconfig.megaraid 2005-01-25 18:22:19.382663024 -0500 @@ -59,6 +59,7 @@ INTEL RAID Controller SRCU51L 1000:1960:8086:0520 FSC MegaRAID PCI Express ROMB 1000:0408:1734:1065 ACER MegaRAID ROMB-2E 1000:0408:1025:004D + NEC MegaRAID PCI Express ROMB 1000:0408:1033:8287 To compile this driver as a module, choose M here: the module will be called megaraid_mbox diff -Naur linux_bk/drivers/scsi/megaraid/mega_common.h linux_bk.new/drivers/scsi/megaraid/mega_common.h --- linux_bk/drivers/scsi/megaraid/mega_common.h 2005-01-25 18:13:37.0 -0500 +++ linux_bk.new/drivers/scsi/megaraid/mega_common.h 2005-01-2
