Re: Target mode support for qlogic chipsets isp2422/2432/5422/5432
Hey- this is great stuff. This means I can finally give up on my stuff for linux now that there's some better and more integral stuff in place. Woo Hoo! On 10/23/07, Seokmann Ju <[EMAIL PROTECTED]> wrote: > Thayumanavar Sachithanantham wrote: > > Hi All, > > > > Does the recent target mode support added for tgt support target mode > > for qla chipset (qla24xx series)? > I'm in the middle of adding the target mode support for qla24xx and newer > series on top of the recent target mode patch (submitted by Tomonori). > As an estimate, the patch will be submitted within a couple of weeks. > > > Can anyone say what isp chipset qla2462 belong to? ( i don't have 2462 > > with this and i need this info if possible). > The QLA2462 has a ISP2422. > > Thank you, > Seokmann > - > 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: FC - NPIV in 2.6.23-rc2
> > some sought of documentation for this, please let me know. > NPIV is a feature to provide multiple path available on one physical port and > it has implemented based on the multiport ID (MID) capability on the switch. > So, you have to have the switch with MID capable on the configuration to > support NPIV, besides the controller. > No, if the switch doesn't suport NP-IV, the 24XX f/w will come up in Public Loop mode (FL). - 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: generating a Linux WWN?
>
> The generation algorithm is whatever makes people happy. I would
> probably pick a fixed prefix like 0x6C 0x69 0x63 ("lin"), something that
> doesn't conflict with IEEE org ids for a long time to come. Then,
> get_random_bytes() or hash some useful machine characteristics for the
> rest of the bytes.
The "probably" here is kind of amusing.
Look, Linux development has the moolah (look at all the money IBM and
SGI and others have shoveled in)- why don't you get a Linux block of
OUIs from the IEEE and set up an RSS-like feed so the Open Source
community can get WWNs with that OUI and a incrementing serial number
as needed- that would be a *real* service. I've thought about doing
this, but I'd have to fork over at least 1700$USD to get an official
IEEE OUI and over the last ten years I've already spent far too much
of my own money on open source support.
Heck, maybe even the IEEE would comp you on OUIs.
-
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: generating a Linux WWN?
> But having a WWN generator in the kernel, although not terribly > difficult to write, makes it possible to create an inconsistent > storage domain. It is that possibility which troubles me, > due to the intention of SAS WWNs. But one should make sure that you *do* create a consistent storage domain. If you can seed the system with a couple dozen free WWNs for use when/if needed, why not? People are content to believe that UUID generation is sufficiently unique, and for the bit space it occupies that's probably a reasonable clain. But you can't jam that into the smaller bit space WWNs. For smaller bit spaces like 64 bit WWNs, you cannot, as you correctly point out, generate reliably unique numbers all by youself. The closest you could probably come is using a type 5 WWN with a known single OUI and then use "seconds since January 1 2007" as a serial number in the 36 bit VID space that gives you about 8 years before it wraps- the likely collision rate here would be pretty low. A much better choice is to get real stamped serial number WWNs. I also hold with some of the other folks on this discussion that some of this is policy that the admin should be allowed to choose. After they've segmented the company's main fabric by choosing unwisely and forgetting to practice safe zoning we'll choose to buy them a drink or two. - 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: [Scst-devel] Problems with SCST and QLA 2432 FC Cards
Unfortunately, 24xx+ cards have very different interface, so add support for them is almost the same as write another driver. Not completely- but close. Feel free to grab ftp://ftp.feral.com/pub/isp/isp_dist.tgz as an example for code to add to scst. - 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: [Scst-devel] Problems with SCST and QLA 2432 FC Cards
That´s a very nice initiativ! Though I believe the most important target driver to develope is one for a PCI-Express HBA. I believe QLA24xx stands for PCI-X, doesn´t it? And the PCI-Express HBA is called QLE-something? But maybe with this driver we will come closer to a PCI-Express HBA target driver? 2422 -> PCI-X 2432 -> PCI-E - 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: Very slow writes with mptsas
The FreeBSD problem was fixed by Scott Long a couple of days ago by
doing some cut through SAS stuff that enabled Write Cache for SATA
drives. Why LSI-Logic couldn't just blitheringly synthesize mode page
8 is beyond me, but okay.
I dunno whether the issue here is the same one Scott tackled- probably
given the messages. Eric- you listening in on this?
-matt
On 6/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hello
I'm seeing very slow writes on a Dell Precision 690 with the Dell SAS5
adapter, serving a RAID1 array of SATA-II disks.
It's very similar to the problem in FreeBSD, described here:
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2007-03/msg00756.html
I'm running FC6 with the latest kernel.
Reads are quite fast, writes terribly slow.
dmesg and lspci out below.
Is the Linux driver suffering from a similar problem?
Adam
SCSI subsystem initialized
Fusion MPT base driver 3.04.03
Copyright (c) 1999-2007 LSI Logic Corporation
Fusion MPT SAS Host driver 3.04.03
ACPI: PCI Interrupt :05:0b.0[A] -> GSI 24 (level, low) -> IRQ 24
mptbase: Initiating ioc0 bringup
ioc0: SAS1068: Capabilities={Initiator}
scsi0 : ioc0: LSISAS1068, FwRev=00063200h, Ports=1, MaxQ=511, IRQ=24
scsi 0:0:0:0: Direct-Access ATA WDC WD5000KS-75M 2E08 PQ: 0
ANSI: 5
scsi 0:0:1:0: Direct-Access ATA HDS725050KLA360 AB5A PQ: 0
ANSI: 5
scsi 0:1:0:0: Direct-Access Dell VIRTUAL DISK 1028 PQ: 0
ANSI: 5
SCSI device sda: 976562176 512-byte hdwr sectors (50 MB)
sda: Write Protect is off
sda: Mode Sense: 03 00 00 08
SCSI device sda: write cache: disabled, read cache: enabled, doesn't
support DPO or FUA
SCSI device sda: 976562176 512-byte hdwr sectors (50 MB)
sda: Write Protect is off
sda: Mode Sense: 03 00 00 08
SCSI device sda: write cache: disabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 sda2 sda3
sd 0:1:0:0: Attached scsi disk sda
There are no cache-related options in the controller BIOS.
00:00.0 Host bridge: Intel Corporation 5000X Chipset Memory Controller
Hub (rev 12)
00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4
Port 2 (rev 12)
00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4
Port 3 (rev 12)
00:04.0 PCI bridge: Intel Corporation 5000X Chipset PCI Express x16 Port
4-7 (rev 12)
00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4
Port 5 (rev 12)
00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4
Port 6 (rev 12)
00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4
Port 7 (rev 12)
00:10.0 Host bridge: Intel Corporation 5000 Series Chipset Error
Reporting Registers (rev 12)
00:10.1 Host bridge: Intel Corporation 5000 Series Chipset Error
Reporting Registers (rev 12)
00:10.2 Host bridge: Intel Corporation 5000 Series Chipset Error
Reporting Registers (rev 12)
00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved
Registers (rev 12)
00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved
Registers (rev 12)
00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers
(rev 12)
00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers
(rev 12)
00:1b.0 Audio device: Intel Corporation 631xESB/632xESB High Definition
Audio Controller (rev 09)
00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI
Express Root Port 1 (rev 09)
00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset
UHCI USB Controller #1 (rev 09)
00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset
UHCI USB Controller #2 (rev 09)
00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset
UHCI USB Controller #3 (rev 09)
00:1d.3 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset
UHCI USB Controller #4 (rev 09)
00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset
EHCI USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC
Interface Controller (rev 09)
00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller
(rev 09)
00:1f.2 SATA controller: Intel Corporation 631xESB/632xESB SATA Storage
Controller AHCI (rev 09)
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus
Controller (rev 09)
01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express
Upstream Port (rev 01)
01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to
PCI-X Bridge (rev 01)
02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express
Downstream Port E1 (rev 01)
02:01.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express
Downstream Port E2 (rev 01)
05:0b.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X
Fusion-MPT SAS (rev 01)
07:00.0 VGA compatible controller: nVidia Corporation Quadro FX 3500
(rev a1)
0b:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752
Gigabit Ethernet PCI Express (rev 02)
0
RESEND: [ PATCH ] externalize (new) scsi timer function (fwd)
-- Forwarded message -- Date: Mon, 22 Jan 2001 17:19:49 -0800 (PST) From: Matthew Jacob <[EMAIL PROTECTED]> To: Linus Torvalds <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RESEND: [ PATCH ] externalize (new) scsi timer function I sent this about a month ago. I think it's important. For what it's worth, Doug Gilbert (and Eric Youngdale) thought it was a good idea too. Can you please drop it in? - Late in the game, and possibly questionable, but it would be helpful to have the (new) scsi timer functions externalized so that loadable HBA modules can easily see them. This is needed because, particularly for Fibre Channel, it's only the HBA that knows when a command is actually sent to the device as opposed to being (temporarily) queued up locally while some Fibre Channel or SCSI reset wreckage is being cleared. The time limit for a command should be while it's actually active- not while it's waiting to be started. The alternative of returning commands as having not been queued doesn't work as well because of race conditions. You can, with several type os HBA, get cases of having queued up one or more commands and after returning success to the midlayer, still get an interrupt that says, "that command you thought I started? Ooops... Sorry. I lied. I couldn't get it started, but it's really okay to start it now...". At any rate- it's a minor change, which I've been using for a bit, which really only is an aid to the case that you have a loadable module that wants this symbol (natuarally, resident drivers don't care). The only real downside to any of this is that effectively use the scsi_add_timer to restart a timer is that you have to use a portion of the Scsi_Cmnd that is not marked as public. An alternative could be to change the midlayer to add a function to pause and restart the timer. -matt --- linux.orig/drivers/scsi/scsi_syms.c Wed Nov 29 18:19:45 2000 +++ linux/drivers/scsi/scsi_syms.c Wed Nov 29 18:18:35 2000 @@ -91,3 +91,10 @@ EXPORT_SYMBOL(scsi_devicelist); EXPORT_SYMBOL(scsi_device_types); +/* + * Externalize timers so that HBAs can safely start/restart commands. + */ +extern void scsi_add_timer(Scsi_Cmnd *, int, void ((*) (Scsi_Cmnd *))); +extern int scsi_delete_timer(Scsi_Cmnd *); +EXPORT_SYMBOL(scsi_add_timer); +EXPORT_SYMBOL(scsi_delete_timer); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
