From gavin at FreeBSD.org Sun Mar 1 10:51:20 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sun Mar 1 10:51:32 2009 Subject: kern/132206: [mpt] system panics on boot when mirroring and 2nd drive is resyncing Message-ID: <200903011851.n21IpJYf069600@freefall.freebsd.org> Old Synopsis: mpt driver: system panics on boot when mirroring and 2nd drive is resyncing New Synopsis: [mpt] system panics on boot when mirroring and 2nd drive is resyncing Responsible-Changed-From-To: freebsd-i386->freebsd-scsi Responsible-Changed-By: gavin Responsible-Changed-When: Sun Mar 1 18:48:04 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=132206 From bugmaster at FreeBSD.org Mon Mar 2 03:07:41 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 2 03:12:22 2009 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200903021106.n22B6xYo057436@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri o kern/131032 scsi [panic] hald causing panic in scsi_sg o kern/130735 scsi [cam] [patch] pass M_NOWAIT to the malloc() call insid o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/126866 scsi [isp] [panic] kernel panic on card initialization o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping o kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/40895 scsi wierd kernel / device driver bug o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 34 problems total. From linimon at FreeBSD.org Mon Mar 2 04:44:19 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Mar 2 04:44:31 2009 Subject: kern/132250: [ciss] ciss driver does not support more then 15 drives Message-ID: <200903021244.n22CiHQq039927@freefall.freebsd.org> Old Synopsis: ciss driver does not support more then 15 drives New Synopsis: [ciss] ciss driver does not support more then 15 drives Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 2 12:43:52 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132250 From josh at tcbug.org Mon Mar 2 10:16:04 2009 From: josh at tcbug.org (Josh Paetzel) Date: Mon Mar 2 10:16:31 2009 Subject: twa driver and 3ware 9690SA issues Message-ID: <09CE3D22-431A-433F-9CAF-6896FF77DDB1@tcbug.org> This is somewhat of a repost from questions@, and I'm currently engaged with 3ware about this issue. I have several 3ware 9690SA SAS RAID controllers. This item is very similar to their 9650SE controller. It uses the same firmware and driver, the difference being it can handle SAS drives. Up until this point all of the arrays we've used with these drives have been RAID 1 arrays with 7200 RPM SATA drives, but recently we've started using 15,000 MBA series Fujitsu SAS drives in places. The arrays have always been detected as: da0: Fixed Direct Access SCSI-5 device da0: 100.000MB/s transfers Which wasn't that much of an issue, as SATA drives aren't capable of sustained sequential 100 MB/sec transfers anyways, but the SAS drives we are getting are supposedly capable of 180 Megs/sec and I'm not seeing it. I'm unsure of how to eliminate caching from the equation, simple tests like dd if=/dev/zero of=testfile bs=8m count=1000 seem to support what dmesg reports by returning 96 Meg/sec transfer rates 3ware has had me verify the savestor performance profile is set to performance, write-caching is enabled, and that I'm using the latest driver and firmware. root@erlang / ->tw_cli /c0 show Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-1 OK - - - 135.031 ON ON VPort Status Unit Size Type Phy Encl-Slot Model ------------------------------------------------------------------------------ p0 OK u0 136.98 GB SAS 0 - FUJITSU MBA3147RC p1 OK u0 136.98 GB SAS 1 - FUJITSU MBA3147RC Name OnlineState BBUReady Status Volt Temp Hours LastCapTest --------------------------------------------------------------------------- bbu On Yes OK OK OK 0 xx-xxx- xxxx At this point I'd be happy to somehow verify the 100 MB/sec reported by dmesg as either the real link speed, or as a bogus number. This issue may have trickle down to 9650SE and 9550 series controllers, those also report 100 MB/sec links for me with SATA drives, and while that's well over the sequential capability of current SATA drives, it could be affecting cache transfer rates...not to mention RAID array configurations. This test can't be considered at all conclusive, as I ran it on a production server: root@markov / ->tw_cli /c0 show Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-10 OK - - 64K 596.025 ON OFF Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 298.09 GB 625142448 WD-WCARW4254676 p1 OK u0 298.09 GB 625142448 WD-WCARW3480367 p2 OK u0 298.09 GB 625142448 WD-WCARW4254675 p3 OK u0 298.09 GB 625142448 WD-WCARW3479101 root@markov / ->grep da0 /var/run/dmesg.boot da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 100.000MB/s transfers da0: 610330MB (1249955840 512 byte sectors: 255H 63S/T 77806C) Trying to mount root from ufs:/dev/da0s1a root@markov /home/jpaetzel ->dd if=/dev/zero of=test bs=8m count=100 100+0 records in 100+0 records out 838860800 bytes transferred in 6.923690 secs (121158052 bytes/sec) Kind of what I expect, and faster than 100 Megs/sec Thanks, Josh Paetzel From scottl at samsco.org Mon Mar 2 11:44:17 2009 From: scottl at samsco.org (Scott Long) Date: Mon Mar 2 11:44:23 2009 Subject: twa driver and 3ware 9690SA issues In-Reply-To: <09CE3D22-431A-433F-9CAF-6896FF77DDB1@tcbug.org> References: <09CE3D22-431A-433F-9CAF-6896FF77DDB1@tcbug.org> Message-ID: <49AC370A.1040700@samsco.org> Josh Paetzel wrote: > This is somewhat of a repost from questions@, and I'm currently engaged > with 3ware about this issue. > > I have several 3ware 9690SA SAS RAID controllers. This item is very > similar to their 9650SE controller. It uses the same firmware and > driver, the difference being it can handle SAS drives. Up until this > point all of the arrays we've used with these drives have been RAID 1 > arrays with 7200 RPM SATA drives, but recently we've started using > 15,000 MBA series Fujitsu SAS drives in places. > > The arrays have always been detected as: > > da0: Fixed Direct Access SCSI-5 device > da0: 100.000MB/s transfers This 100.000MB/s number is fictitious. The driver is just filling in a dummy value. Filling in the real number would require the driver being able to query the card for the negotiated bus speed. I have no idea if that's possible for TWA given the programming information that is public for the card. > > Which wasn't that much of an issue, as SATA drives aren't capable of > sustained sequential 100 MB/sec transfers anyways, but the SAS drives we > are getting are supposedly capable of 180 Megs/sec and I'm not seeing > it. I'm unsure of how to eliminate caching from the equation, simple > tests like dd if=/dev/zero of=testfile bs=8m count=1000 seem to support > what dmesg reports by returning 96 Meg/sec transfer rates > FreeBSD limits individual I/O segments through the CAM subsystem to 64K. It can safely be raised to 128K via some patches that I have, and you will see a corresponding improvement in performance. I don't believe that it can be safely raised above that for the TWA controllers. Scott From josh at tcbug.org Mon Mar 2 11:52:19 2009 From: josh at tcbug.org (Josh Paetzel) Date: Mon Mar 2 11:52:25 2009 Subject: twa driver and 3ware 9690SA issues In-Reply-To: <49AC370A.1040700@samsco.org> References: <09CE3D22-431A-433F-9CAF-6896FF77DDB1@tcbug.org> <49AC370A.1040700@samsco.org> Message-ID: <49E31E02-E9B0-48EB-8B7A-0517C6501FC2@tcbug.org> On Mar 2, 2009, at 1:44 PM, Scott Long wrote: > Josh Paetzel wrote: >> This is somewhat of a repost from questions@, and I'm currently >> engaged with 3ware about this issue. >> I have several 3ware 9690SA SAS RAID controllers. This item is >> very similar to their 9650SE controller. It uses the same firmware >> and driver, the difference being it can handle SAS drives. Up >> until this point all of the arrays we've used with these drives >> have been RAID 1 arrays with 7200 RPM SATA drives, but recently >> we've started using 15,000 MBA series Fujitsu SAS drives in places. >> The arrays have always been detected as: >> da0: Fixed Direct Access SCSI-5 device >> da0: 100.000MB/s transfers > > This 100.000MB/s number is fictitious. The driver is just filling > in a > dummy value. Filling in the real number would require the driver > being > able to query the card for the negotiated bus speed. I have no idea > if that's possible for TWA given the programming information that is > public for the card. > >> Which wasn't that much of an issue, as SATA drives aren't capable >> of sustained sequential 100 MB/sec transfers anyways, but the SAS >> drives we are getting are supposedly capable of 180 Megs/sec and >> I'm not seeing it. I'm unsure of how to eliminate caching from the >> equation, simple tests like dd if=/dev/zero of=testfile bs=8m >> count=1000 seem to support what dmesg reports by returning 96 Meg/ >> sec transfer rates > > FreeBSD limits individual I/O segments through the CAM subsystem to > 64K. It can safely be raised to 128K via some patches that I have, > and > you will see a corresponding improvement in performance. I don't > believe that it can be safely raised above that for the TWA > controllers. > > Scott I'd like to try the patches. Where can I get them from? Thanks, Josh Paetzel From andrew at modulus.org Mon Mar 2 14:51:04 2009 From: andrew at modulus.org (Andrew Snow) Date: Mon Mar 2 14:51:12 2009 Subject: twa driver and 3ware 9690SA issues In-Reply-To: <09CE3D22-431A-433F-9CAF-6896FF77DDB1@tcbug.org> References: <09CE3D22-431A-433F-9CAF-6896FF77DDB1@tcbug.org> Message-ID: <49AC5EB3.4020601@modulus.org> Josh Paetzel wrote: > Which wasn't that much of an issue, as SATA drives aren't capable of > sustained sequential 100 MB/sec transfers anyways As Scott said, this number is not reflective of actual negotiated rate, and is nothing to worry about. > u0 RAID-10 OK - - 64K 596.025 ON OFF > 838860800 bytes transferred in 6.923690 secs (121158052 bytes/sec) > Kind of what I expect, and faster than 100 Megs/sec Well, that's a RAID10 and capable of doing much faster than 120MB/s. Sorry, but you cannot expect anywhere near close to the theoretical unformatted maximum media transfer rate of the disks you're testing, especially under FreeBSD and UFS. Testing the raw disks doesn't necessarily help either because then there's no operating system read-ahead or write-caching, which is necessary to lower the latency between access requests. I don't believe you're getting any SCSI or 3ware problems - just FreeBSD kernel and filesystem issues. UFS is performance is a bit bizarre: for example I see faster sequential write speeds than read speeds! ZFS improves the situation alot and I get much closer to the theoritical max with my drives. To give you an idea of how much more efficient ZFS is: I had a 16 disk 3ware SATA RAID6, with UFS, and battery-backed cache. I converted to a 14 disk ZFS software RAIDZ2 with a smaller 3ware mirrored boot disk. Quick benchmarked using dd as follows: Creating a 6GB file: UFS+3ware=308mb/s ZFS=357mb/s Reading a 6GB file: UFS+3ware=113mb/s ZFS=424mb/s - Andrew From josh at tcbug.org Mon Mar 2 19:06:02 2009 From: josh at tcbug.org (Josh Paetzel) Date: Mon Mar 2 19:06:09 2009 Subject: twa driver and 3ware 9690SA issues In-Reply-To: <49AC5EB3.4020601@modulus.org> References: <09CE3D22-431A-433F-9CAF-6896FF77DDB1@tcbug.org> <49AC5EB3.4020601@modulus.org> Message-ID: <89312829-73A5-463B-8F9C-8CC30FB262B1@tcbug.org> On Mar 2, 2009, at 4:33 PM, Andrew Snow wrote: > Josh Paetzel wrote: >> Which wasn't that much of an issue, as SATA drives aren't capable >> of sustained sequential 100 MB/sec transfers anyways > > As Scott said, this number is not reflective of actual negotiated > rate, and is nothing to worry about. Great, thanks. > >> u0 RAID-10 OK - - 64K 596.025 >> ON OFF >> 838860800 bytes transferred in 6.923690 secs (121158052 bytes/sec) >> Kind of what I expect, and faster than 100 Megs/sec > > Well, that's a RAID10 and capable of doing much faster than 120MB/s. > Hrmm, I was under the impression that a single read or write would only see the sequential transfer rate of one side of the stripe set, and that would be fairly close to 120 Megs/sec. > Sorry, but you cannot expect anywhere near close to the theoretical > unformatted maximum media transfer rate of the disks you're testing, > especially under FreeBSD and UFS. > No need to apologize. > Testing the raw disks doesn't necessarily help either because then > there's no operating system read-ahead or write-caching, which is > necessary to lower the latency between access requests. > > I don't believe you're getting any SCSI or 3ware problems - just > FreeBSD kernel and filesystem issues. > > UFS is performance is a bit bizarre: for example I see faster > sequential write speeds than read speeds! ZFS improves the situation > alot and I get much closer to the theoritical max with my drives. > > To give you an idea of how much more efficient ZFS is: I had a 16 > disk 3ware SATA RAID6, with UFS, and battery-backed cache. I > converted to a 14 disk ZFS software RAIDZ2 with a smaller 3ware > mirrored boot disk. > > Quick benchmarked using dd as follows: > > Creating a 6GB file: UFS+3ware=308mb/s ZFS=357mb/s > Reading a 6GB file: UFS+3ware=113mb/s ZFS=424mb/s > > > > - Andrew ZFS probably isn't an option for me. A lot of these systems max out at 8 gigs of RAM, and postgresql eats a huge chunk of that, also the controllers on the motherboard don't always report back drive failures to the OS, as well as have occasional failures detecting new drives when we need to hot swap, as well as having my biggest concern, no battery backed cache. :( My main question has been answered, the link speed that the driver reports is imaginary. Thanks, Josh Paetzel From aoyama at peach.ne.jp Wed Mar 4 10:11:13 2009 From: aoyama at peach.ne.jp (Daisuke Aoyama) Date: Wed Mar 4 10:11:19 2009 Subject: iSCSI initiator StatSN Message-ID: Hello, I'm now writing an iSCSI target designed for multipath failover cluster node. I noticed that FreeBSD initiator (2.1.0) was not able to be connected. So I have two questions. My target send StatSN=0(taken from ExpStatSN in request) at first response. But next request still have ExpStatSN=0 in PDU. What value does expect for StatSN? An initial version of the target is send-pr as PR 132016. The latest version is uploaded on my site pointed by PR. I want to replace the distfile because of many bugs. Does anyone known how to replace the file in this PR? Thanks, -- Daisuke Aoyama From aoyama at peach.ne.jp Sun Mar 8 13:34:40 2009 From: aoyama at peach.ne.jp (Daisuke Aoyama) Date: Sun Mar 8 13:34:53 2009 Subject: Tester wanted for multipath failover iSCSI target software Message-ID: Hello, I'm looking for test users for new iSCSI target software designed for multipath failover cluster nodes. I'm very interested in the virtual machine such as Hyper-V. So I'm also tuning the target for using VMs. I need an environmental report in particular other than FreeBSD 7.1 RELEASE p3 i386/PAE kernel w/ZFS. I welcome the report with other initiators below. If you are interested in this software, please download it from the following site. The tarball contains configure script to build it. Please read README and INSTALL in the tarball for more detail. Tested Initiators: o Microsoft Windows Server 2008 (builtin) o Microsoft iSCSI Initiator 2.08 on WS2003 o Intel iSCSI Remote Boot 2.1.22 o Sun VirtualBOX 2.1.2 (builtin) o VMware ESXi 3.5 Update 3 (builtin) Key Features: o MCS/MPIO for failover (up to 255 concurrent sessions) o SPC-3 Persistent Reservation for cluster nodes o 64bit LBA for over 2TB o Header/Data digest by CRC32C o CHAP w/Mutual authentication o Multiple LUNs and ACLs for portals (experimental features) o iSCSI boot with Intel PRO/1000 Server Adapters o virtual DVDROM/DLT emulator o pass-through device via CAM Known Issues: o globalSAN iSCSI Initiator for Mac OSX does not establish data I/O because of unexpected data segment length. I will plan to fix it in the near future. o FreeBSD initiator can't connect to the target because of StatSN error. I don't know a reason. Here is release 20090308: http://shell.peach.ne.jp/aoyama/archives/342 Later version will be uploaded in this blog. If you need anything other than Japanese, please use translator service. Thanks, -- Daisuke Aoyama From bugmaster at FreeBSD.org Mon Mar 9 10:15:17 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 9 10:17:20 2009 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200903091715.n29HFB3n045381@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132250 scsi [ciss] ciss driver does not support more then 15 drive o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri o kern/131032 scsi [panic] hald causing panic in scsi_sg o kern/130735 scsi [cam] [patch] pass M_NOWAIT to the malloc() call insid o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/126866 scsi [isp] [panic] kernel panic on card initialization o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping o kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/40895 scsi wierd kernel / device driver bug o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 35 problems total. From gavin at FreeBSD.org Mon Mar 9 13:39:22 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Mon Mar 9 13:39:29 2009 Subject: amd64/132394: [isp] - bad underruns with QLogic qla2300 and amd64 Message-ID: <200903092039.n29KdHlA009868@freefall.freebsd.org> Synopsis: [isp] - bad underruns with QLogic qla2300 and amd64 Responsible-Changed-From-To: freebsd-amd64->freebsd-scsi Responsible-Changed-By: gavin Responsible-Changed-When: Mon Mar 9 20:38:45 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=132394 From jtn at jtn.cx Mon Mar 9 14:53:17 2009 From: jtn at jtn.cx (Jason T. Nelson) Date: Mon Mar 9 14:53:23 2009 Subject: iSCSI initiator lockups Message-ID: <20090309212720.GA49294@jtn.cx> I'm running into some odd headaches regarding what looks like iSCSI initiators going to sleep for approximately 30 seconds before returning to life and pumping a ton of information back to the target. While this is happening, system load climbs up alarmingly fast. Looking at tcpdumps in Wireshark, it shows what appears to be a nearly exact 30 second delay where the initiator stops talking to the target server, then abruptly restarts. Currently 8 machines are talking to 2 servers with 4 targets a piece, and while its working, we get good throughput. Activity is moderately high, as we are using the iSCSI targets as spool disks in an email cluster. As it appears that iscsi-target is a single-threaded process, would it be valuable to put each target in its own process on its own port? At any rate, this is causing serious problems on the mail processing machines. -- Jason T. Nelson GPG key 0xFF676C9E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-scsi/attachments/20090309/8b13460c/attachment.pgp From danny at cs.huji.ac.il Tue Mar 10 05:41:19 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Tue Mar 10 05:41:32 2009 Subject: iSCSI initiator lockups In-Reply-To: <20090309212720.GA49294@jtn.cx> References: <20090309212720.GA49294@jtn.cx> Message-ID: > > --ikeVEW9yuYc//A+q > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > I'm running into some odd headaches regarding what looks like iSCSI initiat= > ors > going to sleep for approximately 30 seconds before returning to life and > pumping a ton of information back to the target. While this is happening, > system load climbs up alarmingly fast. Looking at tcpdumps in Wireshark, it > shows what appears to be a nearly exact 30 second delay where the initiator > stops talking to the target server, then abruptly restarts. Currently > 8 machines are talking to 2 servers with 4 targets a piece, and while its= > =20 > working, we get good throughput. Activity is moderately high, as we are=20 > using the iSCSI targets as spool disks in an email cluster. As it appears > that iscsi-target is a single-threaded process, would it be valuable to > put each target in its own process on its own port? At any rate, this is > causing serious problems on the mail processing machines. > can you send me the output of sysctl net.iscsi chears, danny From danny at cs.huji.ac.il Wed Mar 11 00:34:42 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Wed Mar 11 00:34:55 2009 Subject: iSCSI initiator lockups In-Reply-To: Your message of Tue, 10 Mar 2009 15:44:59 -0400 . Message-ID: > > --VbJkn9YxBvnuCH5J > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > In our last exciting episode, Danny Braniss (danny@cs.huji.ac.il) said: > > I guess it's time to fix this. > > danny > > Thank you very much for the pointer to the newer version; we have seen a=20 > marked improvement with none of the 30 second studdering. I appreciate > your rapid assistance! Good, can you send me the info of the target/s you are using to add to the list of supported targets? Cheers, danny From aoyama at peach.ne.jp Wed Mar 11 03:26:12 2009 From: aoyama at peach.ne.jp (Daisuke Aoyama) Date: Wed Mar 11 03:26:30 2009 Subject: Tester wanted for multipath failover iSCSI target software References: Message-ID: Hi all, Now istgt is a part of ports. (net/istgt) FreeBSD issue is solved by danny's patch. After applying the patch, iscontrol can connect to istgt. Here is release 20090309 latest committed to ports. http://shell.peach.ne.jp/aoyama/archives/345 If you need anything other than Japanese, please use translation such as google translate. Thanks, -- Daisuke Aoyama From petefrench at ticketswitch.com Wed Mar 11 03:52:25 2009 From: petefrench at ticketswitch.com (Pete French) Date: Wed Mar 11 03:52:37 2009 Subject: Tester wanted for multipath failover iSCSI target software In-Reply-To: Message-ID: > Now istgt is a part of ports. (net/istgt) > FreeBSD issue is solved by danny's patch. > After applying the patch, iscontrol can connect to istgt. I am interested in giving this a try, though not immediately as I am away from the office at the moment. Do I need to apply a patch to iscontrol to make it work though ? I can't work it out from your statement above. > Here is release 20090309 latest committed to ports. > http://shell.peach.ne.jp/aoyama/archives/345 Than ks. Is the intent to integrate with the base system eventually rather than have it in ports ? It would be nice to have a native implementation which could then be integrated with ZFS. Will let you know how I get on... -pete. From danny at cs.huji.ac.il Wed Mar 11 04:39:52 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Wed Mar 11 04:40:05 2009 Subject: Tester wanted for multipath failover iSCSI target software In-Reply-To: References: Message-ID: > > Now istgt is a part of ports. (net/istgt) > > FreeBSD issue is solved by danny's patch. > > After applying the patch, iscontrol can connect to istgt. > > I am interested in giving this a try, though not immediately as I > am away from the office at the moment. Do I need to apply a patch > to iscontrol to make it work though ? I can't work it out from your > statement above. english version: (ungoogled :-) the latest is in: http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz and if you already have 2.1, apply: --- iscsi.c.orig 2008-09-21 10:01:50.000000000 +0300 +++ iscsi.c 2009-03-11 13:29:04.250472000 +0200 @@ -62,7 +62,7 @@ #include #include -static char *iscsi_driver_version = "2.1.0"; +static char *iscsi_driver_version = "2.1.1"; static struct isc_softc isc; --- isc_sm.c.orig 2008-07-19 14:04:23.000000000 +0300 +++ isc_sm.c 2009-03-11 13:30:20.672791000 +0200 @@ -508,7 +508,7 @@ sn->cmd++; case ISCSI_WRITE_DATA: - bhs->ExpStSN = htonl(sn->stat); + bhs->ExpStSN = htonl(sn->stat + 1); break; default: ---------------------------------------------------------------------------- danny From aoyama at peach.ne.jp Wed Mar 11 05:13:03 2009 From: aoyama at peach.ne.jp (Daisuke Aoyama) Date: Wed Mar 11 05:13:15 2009 Subject: Tester wanted for multipath failover iSCSI target software References: Message-ID: <34849EA9C0D3417C9784824CC0080090@artemis> >I am interested in giving this a try, though not immediately as I >am away from the office at the moment. Do I need to apply a patch >to iscontrol to make it work though ? I can't work it out from your >statement above. Yes, you need. >Than ks. Is the intent to integrate with the base system eventually >rather than have it in ports ? It would be nice to have a native >implementation which could then be integrated with ZFS. istgt is still under development. so I don't think integration. before thinking, I should work to fix more bugs. thank you. -- Daisuke Aoyama From antik at bsd.ee Thu Mar 12 01:07:20 2009 From: antik at bsd.ee (Andrei Kolu) Date: Thu Mar 12 01:07:27 2009 Subject: Tester wanted for multipath failover iSCSI target software In-Reply-To: <34849EA9C0D3417C9784824CC0080090@artemis> References: <34849EA9C0D3417C9784824CC0080090@artemis> Message-ID: <49B8BE06.1010105@bsd.ee> Daisuke Aoyama wrote: >> I am interested in giving this a try, though not immediately as I >> am away from the office at the moment. Do I need to apply a patch >> to iscontrol to make it work though ? I can't work it out from your >> statement above. > > Yes, you need. > >> Than ks. Is the intent to integrate with the base system eventually >> rather than have it in ports ? It would be nice to have a native >> implementation which could then be integrated with ZFS. > > istgt is still under development. > so I don't think integration. > before thinking, I should work to fix more bugs. > > I have tested "net/istgt" for couple of days with Windows XP and it works more reliable than NetBSD "net/iscsi-target". With NetBSD implementation sometimes I lost partition filesystem information after disconnecting server from network or rebooting my computer. Is there any particular testcases you want to perform? Tested on FreeBSD 7.1-STABLE #0: Wed Mar 11 22:29:33 EET 2009 P.S. Strange, but I can't find istgt in ports anymore... From psuganya at hcl.in Thu Mar 12 06:07:03 2009 From: psuganya at hcl.in (sathees) Date: Thu Mar 12 06:07:10 2009 Subject: how do i identify the version of SCSI that my disk supports Message-ID: <22475632.post@talk.nabble.com> Hi.. I want to know the version of SCSI that my disk supports.. how can i know that by using the command.. I have used the INQUIRY but still i can't find the version from the version descriptor field..as because the values for this field is zero -- View this message in context: http://www.nabble.com/how-do-i-identify-the-version-of-SCSI-that-my-disk-supports-tp22475632p22475632.html Sent from the freebsd-scsi mailing list archive at Nabble.com. From petefrench at ticketswitch.com Thu Mar 12 06:09:04 2009 From: petefrench at ticketswitch.com (Pete French) Date: Thu Mar 12 06:09:17 2009 Subject: Tester wanted for multipath failover iSCSI target software In-Reply-To: <49B8BE06.1010105@bsd.ee> Message-ID: > I have tested "net/istgt" for couple of days with Windows XP and it > works more reliable than NetBSD "net/iscsi-target". > With NetBSD implementation sometimes I lost partition filesystem > information after disconnecting server from network or rebooting my > computer. I am just trying it against the latest FreeBSD initiator. One thing I have noticed compared to the netbsd target is that it appears to have somewhat higer performance. cerrainly the speed that gstat says data is comming off the disc during a scrub is faster than with iscsi_target. On the other hand I have got some errors that I am trying to get to the bottom of. I set up a zpool laast night on a remote disc using the netbsd initiator and copied about 50 gig of data to it as lots of small files. I then switched to the istgt initiator this morning and am running a scrub on the pool. But it is telling me that there are a sigificant number of errors on the disc, which I wasnt expecting. I am now trying to find out if that is due to write errors using the taret last night, or read errors with the new target this morning. BTW, is there any way to get istgt to accept connections without needing to specify the initator string ? I am new to all these options for iSCSI having only used the simple netbsd one before. cheers, -pete. From aoyama at peach.ne.jp Thu Mar 12 06:21:56 2009 From: aoyama at peach.ne.jp (Daisuke Aoyama) Date: Thu Mar 12 06:22:08 2009 Subject: Tester wanted for multipath failover iSCSI target software References: <34849EA9C0D3417C9784824CC0080090@artemis> <49B8BE06.1010105@bsd.ee> Message-ID: Hi, Thank you for reporting. >I have tested "net/istgt" for couple of days with Windows XP and it >works more reliable than NetBSD "net/iscsi-target". >With NetBSD implementation sometimes I lost partition filesystem >information after disconnecting server from network or rebooting my >computer. Yes, it is one of differences. istgt reports connected information such as SCSI port to the initiator for discriminating multipath and failover path. As a side effect, perhaps more accurate identification is possible. >Is there any particular testcases you want to perform? If you use it as usual, it is tested enough. If I had to say, I want to know how much a CPU usage on the target machine. Because istgt is more complicated than iscsi-target. >Tested on FreeBSD 7.1-STABLE #0: Wed Mar 11 22:29:33 EET 2009 Did you use the target with ZFS? or UFS? Did you use MCS feature? Thanks, -- Daisuke Aoyama From aoyama at peach.ne.jp Thu Mar 12 06:42:54 2009 From: aoyama at peach.ne.jp (Daisuke Aoyama) Date: Thu Mar 12 06:43:01 2009 Subject: Tester wanted for multipath failover iSCSI target software References: Message-ID: <8F8EA08BAC924788A58736AADB2849BA@artemis> Thank you for reporting. >On the other hand I have got some errors that I am trying to get to the >bottom of. I set up a zpool laast night on a remote disc using the >netbsd initiator and copied about 50 gig of data to it as lots of small >files. I then switched to the istgt initiator this morning and am running >a scrub on the pool. But it is telling me that there are a sigificant >number >of errors on the disc, which I wasnt expecting. I am now trying to find >out if that is due to write errors using the taret last night, or read >errors >with the new target this morning. I'm very interested in this case. >BTW, is there any way to get istgt to accept connections without needing to >specify the initator string ? I am new to all these options for iSCSI >having only used the simple netbsd one before. sorry for no documents. special word "ALL" matches any initiator name/IPs. you can find more sample in istgt.large.conf.sample. [InitiatorGroup256] Comment "ALL initiators from ALL IP" InitiatorName ALL Netmask ALL Thanks, -- Daisuke Aoyama From aoyama at peach.ne.jp Thu Mar 12 06:52:55 2009 From: aoyama at peach.ne.jp (Daisuke Aoyama) Date: Thu Mar 12 06:53:08 2009 Subject: how do i identify the version of SCSI that my disk supports References: <22475632.post@talk.nabble.com> Message-ID: <3646CF8FF05F431D992698D2F1CF2A2E@artemis> Hi, >Hi.. I want to know the version of SCSI that my disk supports.. how can i >know that by using the command.. I have used the INQUIRY but still i can't >find the version from the version descriptor field..as because the values >for this field is zero Did you see VERSION field (offset 2 of standard inquiry data)? -- Daisuke Aoyama From petefrench at ticketswitch.com Thu Mar 12 06:55:38 2009 From: petefrench at ticketswitch.com (Pete French) Date: Thu Mar 12 06:55:50 2009 Subject: Tester wanted for multipath failover iSCSI target software In-Reply-To: <8F8EA08BAC924788A58736AADB2849BA@artemis> Message-ID: > Thank you for reporting. ... > I'm very interested in this case. Well, I just finihsed doing a 'zpool scrub' on the disc image mounted locally on the machine which was running istgt. That still shows some errors - but only 36 of them, compares to the 9000+ I get when running the scrub mounted remotely! I am going to do the whole test again just using istgt this time to see what happens. Some more information about my setup: Both machines are amd64 - running kernels from March 9th. The client has the latest version of iscsi_initiator on it as well. The server is using a file as the disc image, and the file is stored on a pair of terrabyte SATA drives in a mirrored zpool. > special word "ALL" matches any initiator name/IPs. > you can find more sample in istgt.large.conf.sample. Ah, thanks, thats helps a lot :-) I will let you know what happens witha new test. -pete. From petefrench at ticketswitch.com Thu Mar 12 07:39:11 2009 From: petefrench at ticketswitch.com (Pete French) Date: Thu Mar 12 07:39:24 2009 Subject: Tester wanted for multipath failover iSCSI target software In-Reply-To: <8F8EA08BAC924788A58736AADB2849BA@artemis> Message-ID: Oh dear.... doing the test again caused the client machine to panic, with the following message: panic: solaris assert: 0 == dmu_buf_hold(os, lr->lr_foid, boff, zgd, &db), file /usr/src/sys/modules/zfs/../../cddl/controb/opensolaris/uts/common/fs/zfs/zfs_nops.c, line: 955 (that was copied out by hand so there might be typos). Since that was on the client side it makes me think there is a mproblem with the initiator. But the same test to the netbsd-target works fine, so it's some interaction between the two bits of software I guess. -pete. From psuganya at hcl.in Thu Mar 12 21:39:20 2009 From: psuganya at hcl.in (sathees) Date: Thu Mar 12 21:39:27 2009 Subject: how do i identify the version of SCSI that my disk supports In-Reply-To: <3646CF8FF05F431D992698D2F1CF2A2E@artemis> References: <22475632.post@talk.nabble.com> <3646CF8FF05F431D992698D2F1CF2A2E@artemis> Message-ID: <22490123.post@talk.nabble.com> Daisuke Aoyama wrote: > > Hi, > >>Hi.. I want to know the version of SCSI that my disk supports.. how can i >>know that by using the command.. I have used the INQUIRY but still i can't >>find the version from the version descriptor field..as because the values >>for this field is zero > > Did you see VERSION field (offset 2 of standard inquiry data)? > ya i have seen that field .. the version field is set to 03h which i > decoded as SPC. But i want to know which version od SAS that my device > supports..Can you give me a hint > > -- > Daisuke Aoyama > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > > -- View this message in context: http://www.nabble.com/how-do-i-identify-the-version-of-SCSI-that-my-disk-supports-tp22475632p22490123.html Sent from the freebsd-scsi mailing list archive at Nabble.com. From aoyama at peach.ne.jp Fri Mar 13 09:04:17 2009 From: aoyama at peach.ne.jp (Daisuke Aoyama) Date: Fri Mar 13 09:04:23 2009 Subject: Tester wanted for multipath failover iSCSI target software References: Message-ID: <9D628199E66F424A80D214FA277EEEA3@artemis> > Oh dear.... doing the test again caused the client machine to panic, > with the following message: > > panic: solaris assert: 0 == dmu_buf_hold(os, lr->lr_foid, boff, zgd, &db), > file > /usr/src/sys/modules/zfs/../../cddl/controb/opensolaris/uts/common/fs/zfs/zfs_nops.c, > line: 955 > I have not read the message in my experience. Do you have encountered frequency? -- Daisuke Aoyama From aoyama at peach.ne.jp Fri Mar 13 09:11:05 2009 From: aoyama at peach.ne.jp (Daisuke Aoyama) Date: Fri Mar 13 09:11:11 2009 Subject: how do i identify the version of SCSI that my disk supports References: <22475632.post@talk.nabble.com><3646CF8FF05F431D992698D2F1CF2A2E@artemis> <22490123.post@talk.nabble.com> Message-ID: >>>Hi.. I want to know the version of SCSI that my disk supports.. how can i >>>know that by using the command.. I have used the INQUIRY but still i >>>can't >>>find the version from the version descriptor field..as because the values >>>for this field is zero >> >> Did you see VERSION field (offset 2 of standard inquiry data)? >> ya i have seen that field .. the version field is set to 03h which i >> decoded as SPC. But i want to know which version od SAS that my device >> supports..Can you give me a hint I don't know why you need version of SAS. I think it is transport and physical interconnect specification. Do you need physical port access to the unit? I'm sorry, I don't have information about it. -- Daisuke Aoyama From petefrench at ticketswitch.com Fri Mar 13 09:30:25 2009 From: petefrench at ticketswitch.com (Pete French) Date: Fri Mar 13 09:30:37 2009 Subject: Tester wanted for multipath failover iSCSI target software In-Reply-To: <9D628199E66F424A80D214FA277EEEA3@artemis> Message-ID: > I have not read the message in my experience. > Do you have encountered frequency? Only once. I did not try it again because that is our work server. I did two testrs, copying files. 1) Using iscsi-target ... copies OK, but ZFS pool has errors 2) Using istgt - causes the panic described. The copy is 53 gigabytes of small files. -pete. From psuganya at hcl.in Fri Mar 13 23:29:33 2009 From: psuganya at hcl.in (sathees) Date: Fri Mar 13 23:29:40 2009 Subject: how do i identify the version of SCSI that my disk supports In-Reply-To: References: <22475632.post@talk.nabble.com> <3646CF8FF05F431D992698D2F1CF2A2E@artemis> <22490123.post@talk.nabble.com> Message-ID: <22509811.post@talk.nabble.com> Daisuke Aoyama wrote: > >>>>Hi.. I want to know the version of SCSI that my disk supports.. how can i >>>>know that by using the command.. I have used the INQUIRY but still i >>>>can't >>>>find the version from the version descriptor field..as because the values >>>>for this field is zero >>> >>> Did you see VERSION field (offset 2 of standard inquiry data)? >>> ya i have seen that field .. the version field is set to 03h which i >>> decoded as SPC. But i want to know which version od SAS that my device >>> supports..Can you give me a hint > > I don't know why you need version of SAS. > I think it is transport and physical interconnect specification. > Do you need physical port access to the unit? > I'm sorry, I don't have information about it. > > -- > Daisuke Aoyama > > thanks for your reply > I have got a hint from you... > I will try..:handshake: > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > > -- View this message in context: http://www.nabble.com/how-do-i-identify-the-version-of-SCSI-that-my-disk-supports-tp22475632p22509811.html Sent from the freebsd-scsi mailing list archive at Nabble.com. From bugmaster at FreeBSD.org Mon Mar 16 04:07:03 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 16 04:09:14 2009 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200903161107.n2GB71O4043383@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/132394 scsi [isp] - bad underruns with QLogic qla2300 and amd64 o kern/132250 scsi [ciss] ciss driver does not support more then 15 drive o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri o kern/131032 scsi [panic] hald causing panic in scsi_sg o kern/130735 scsi [cam] [patch] pass M_NOWAIT to the malloc() call insid o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/126866 scsi [isp] [panic] kernel panic on card initialization o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping o kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/40895 scsi wierd kernel / device driver bug o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 36 problems total. From jhb at freebsd.org Thu Mar 19 13:50:06 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Mar 19 13:50:19 2009 Subject: kern/128245: [scsi] "inquiry data fails comparison at DV1 step" [regression] Message-ID: <200903192050.n2JKo5Wr021842@freefall.freebsd.org> The following reply was made to PR kern/128245; it has been noted by GNATS. From: John Baldwin To: bug-followup@freebsd.org, andy@demos.su Cc: scottl@freebsd.org Subject: Re: kern/128245: [scsi] "inquiry data fails comparison at DV1 step" [regression] Date: Thu, 19 Mar 2009 16:05:01 -0400 Can you retry with the latest stable/7 (RELENG_7) as Scott has recently fixed a few issues that might be related? -- John Baldwin From aoyama at peach.ne.jp Sun Mar 22 17:31:20 2009 From: aoyama at peach.ne.jp (Daisuke Aoyama) Date: Sun Mar 22 17:31:28 2009 Subject: istgt now supports command queuing in disk type Message-ID: Hello. New release was uploaded in my blog. The command queuing improves especially sequential read by MCS(multiple connections per session) round robin. In my post, I uploaded the screen shots using CrystalDiskMark which is one of popular benchmark in Japan. You can download CrystalDiskMark(multilingual) from: http://crystalmark.info/?lang=en I got the result about 1.5x-3x faster than previous 20090314. If test data was cached, it reached over 200MB/s. Known Issue and Limitations: o queuing is only supported in single initiator environment. o LUN thread might have deadlock when an error has occurred. o write command is still slow. o timeout may occur when using MCS. o single connection may be slower than without queuing. Here is release 20090323: http://shell.peach.ne.jp/aoyama/archives/376 The screen shots show difference between QueueDepth 16 and 0 (disabled queuing). The command queuing is disabled by default. If you want to use it, please add QueueDepth key in the LogicalUnit section of your configuration. for example: [LogicalUnit1] # Queuing 0=disabled, 1-255=enabled with specified depth. QueueDepth 16 Thanks. -- Daisuke Aoyama From bugmaster at FreeBSD.org Mon Mar 23 04:07:04 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 23 04:09:14 2009 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200903231107.n2NB73L4004137@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/132394 scsi [isp] - bad underruns with QLogic qla2300 and amd64 o kern/132250 scsi [ciss] ciss driver does not support more then 15 drive o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri o kern/131032 scsi [panic] hald causing panic in scsi_sg o kern/130735 scsi [cam] [patch] pass M_NOWAIT to the malloc() call insid o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/126866 scsi [isp] [panic] kernel panic on card initialization o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping o kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/40895 scsi wierd kernel / device driver bug o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 36 problems total. From lev at FreeBSD.org Mon Mar 23 13:16:42 2009 From: lev at FreeBSD.org (Lev Serebryakov) Date: Mon Mar 23 13:16:49 2009 Subject: istgt now supports command queuing in disk type In-Reply-To: References: Message-ID: <754391506.20090323225858@serebryakov.spb.ru> Hello, Daisuke. You wrote 23 ????? 2009 ?., 03:31:12: > I got the result about 1.5x-3x faster than previous 20090314. > If test data was cached, it reached over 200MB/s. I have one question: what do you mean when write, that this software is intended to use with ZFS? Could it be used to provide access to raw (disk) devices? Is it safe? Ok, it can have bugs, but is it as safe as access to file placed on ZFS (you test it in such configuration, am I right?)? -- // Black Lion AKA Lev Serebryakov From danny at cs.huji.ac.il Tue Mar 24 02:57:50 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Tue Mar 24 02:57:55 2009 Subject: Intel Integrated RAID iir not working under 7.2 Message-ID: Hi, After turning debuging on, it seems that the iir driver is loosing an interrupt while probing: ... gdt_next(0xc7666000) gdt_mpr_test_busy(0xc7666000) gdt_intr(0xc7666000) gdt_mpr_get_status(0xc7666000) gdt_mpr_intr(0xc7666000) gdt_free_ccb(0xc7666000, 0xc767e444) gdt_sync_event(0xc7666000, 3, 5, 0xc767e444) gdt_next(0xc7666000) gdt_mpr_test_busy(0xc7666000) run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config panic: run_interrupt_driven_config_hooks: waited too long btw, older (7.0/7.1) still works. any ideas? thanks, danny From aoyama at peach.ne.jp Thu Mar 26 10:36:40 2009 From: aoyama at peach.ne.jp (Daisuke Aoyama) Date: Thu Mar 26 10:36:46 2009 Subject: istgt now supports command queuing in disk type References: Message-ID: Hello, I sent change request of ports version. (just now was committed when I wrote mail) What's new? (from 20090323) o starting to support multipath I/O by VMware ESXi (Fix/MRU/RR) o wildcard address listen and translate IP (useful on DHCP) o utilization efficiency of the command queuing was improved o task abort handling in cluster nodes o reduce deadlock and timeout risk (from 20090314) o support command queuing o shrink pre-allocated SCSI sense data buffer from 64K to 4K. o allow full specify "eui." and "naa." like "iqn." o if small PDU, write as one buffer. and many bug fixes The command queuing is disabled by default. If you want to use it, please add QueueDepth key in the LogicalUnit section of your configuration. for example: [LogicalUnit1] # Queuing 0=disabled, 1-255=enabled with specified depth. QueueDepth 16 If you have any problem with command queuing, comment out or specify 0 to disable it. Disabled version is about the same behavior as 20090314. To use wildcard address, edit your configuration like this: [PortalGroup1] # for IPv6 Portal DA1 [::]:3260 # for IPv4 Portal DA1 0.0.0.0:3260 Do not use mix with other IPs. After this change you can see TargetAddress as connected IP. IP address family connected by discovery session is important. If you need IPv6 target address, should use IPv6 in discovery. Also if you need IPv4 target address, should use IPv4. The istgt will reply only one IP address of multiple wildcard address to the initiator. Here is release 20090326: http://shell.peach.ne.jp/aoyama/archives/386 -- Daisuke Aoyama From danny at cs.huji.ac.il Fri Mar 27 00:44:14 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Mar 27 00:44:28 2009 Subject: amr driver broken since March 12 Message-ID: at least for me :-) [and sorry for the cross posting] old (March 12 , i know need the svn rev number but...) dmesg | grep amr amr0: mem 0xfbef0000-0xfbefffff,0xfe580000-0xfe5fffff irq 27 at device 0.0 on pci4 amr0: [ITHREAD] amr0: delete logical drives supported by controller amr0: Firmware 414I, BIOS A100, 128MB RAM amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 34857MB (71387136 sectors) RAID 0 (optimal) amrd1: on amr0 amrd1: 280024MB (573489152 sectors) RAID 5 (optimal) and a resent 7.2 (same host): amr0: mem 0xfbef0000-0xfbefffff,0xfe580000-0xfe5fffff irq 27 at device 0.0 on pci4 amr0: [ITHREAD] amr0: delete logical drives supported by controller amr0: Firmware 414I, BIOS A100, 128MB RAM amr0: adapter is busy amr0: adapter is busy amr0: delete logical drives supported by controller (probe0:amr0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:amr0:0:6:0): CAM Status: SCSI Status Error (probe0:amr0:0:6:0): SCSI Status: Check Condition (probe0:amr0:0:6:0): ILLEGAL REQUEST asc:24,0 (probe0:amr0:0:6:0): Invalid field in CDB (probe0:amr0:0:6:0): Unretryable error btw, since I also have similar problems with another kind of raid card (iir), I suspect some related changes are the cause. danny From scottl at samsco.org Fri Mar 27 06:53:25 2009 From: scottl at samsco.org (Scott Long) Date: Fri Mar 27 06:53:31 2009 Subject: amr driver broken since March 12 In-Reply-To: References: Message-ID: <49CCDA41.4060101@samsco.org> Danny Braniss wrote: > at least for me :-) > [and sorry for the cross posting] > > old (March 12 , i know need the svn rev number but...) None of the commit activity on March 12 is jumping out at me as being suspicious. However, you are now the second person who has told me about AMR problems in 7.1 recently. If you have a precise svn change number, it would help greatly. Scott From danny at cs.huji.ac.il Fri Mar 27 08:52:35 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Mar 27 08:52:48 2009 Subject: amr driver broken since March 12 In-Reply-To: <49CCDA41.4060101@samsco.org> References: <49CCDA41.4060101@samsco.org> Message-ID: > Danny Braniss wrote: > > at least for me :-) > > [and sorry for the cross posting] > > > > old (March 12 , i know need the svn rev number but...) > > None of the commit activity on March 12 is jumping out at me as being > suspicious. However, you are now the second person who has told me > about AMR problems in 7.1 recently. If you have a precise svn change > number, it would help greatly. > > Scott my bad. the last working amr/iir is from March 12. I first detected the problem sometime later, but not later than March 23. So it has to be changes in that time frame. both drivers are showing similar symptoms: waiting for not busy the iir goes on for ever, and it's the cam that eventually panics, run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config (actually not 100% true, depending if WITNESS is on or off, it sometimes just hangs). the amr seems to time out: amr0: adapter is busy thanks for looking into the problem, danny From scottl at samsco.org Fri Mar 27 09:06:32 2009 From: scottl at samsco.org (Scott Long) Date: Fri Mar 27 09:06:45 2009 Subject: amr driver broken since March 12 In-Reply-To: References: <49CCDA41.4060101@samsco.org> Message-ID: <49CCF95F.1050307@samsco.org> Danny Braniss wrote: >> Danny Braniss wrote: >>> at least for me :-) >>> [and sorry for the cross posting] >>> >>> old (March 12 , i know need the svn rev number but...) >> None of the commit activity on March 12 is jumping out at me as being >> suspicious. However, you are now the second person who has told me >> about AMR problems in 7.1 recently. If you have a precise svn change >> number, it would help greatly. >> >> Scott > my bad. the last working amr/iir is from March 12. > I first detected the problem sometime later, but not later than March 23. > So it has to be changes in that time frame. > > both drivers are showing similar symptoms: > waiting for not busy > the iir goes on for ever, and it's the cam that eventually panics, > run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config > (actually not 100% true, depending if WITNESS is on or off, it sometimes > just hangs). > the amr seems to time out: > amr0: adapter is busy > > thanks for looking into the problem, > > danny > > Ok, here are a series of revisions to step through, in forward order. Make sure that you are starting with at least revision 189568. Then, update to exactly the revision numbers below, recompile the kernel, and test: 190087 190091 From lambert at lambertfam.org Fri Mar 27 09:40:12 2009 From: lambert at lambertfam.org (Scott Lambert) Date: Fri Mar 27 09:40:33 2009 Subject: amr driver broken since March 12 In-Reply-To: References: <49CCDA41.4060101@samsco.org> Message-ID: <20090327162915.GQ80292@sysmon.tcworks.net> On Fri, Mar 27, 2009 at 06:52:32PM +0300, Danny Braniss wrote: > > Danny Braniss wrote: > > > at least for me :-) > > > [and sorry for the cross posting] > > > > > > old (March 12 , i know need the svn rev number but...) > > > > None of the commit activity on March 12 is jumping out at me as being > > suspicious. However, you are now the second person who has told me > > about AMR problems in 7.1 recently. If you have a precise svn change > > number, it would help greatly. > > > > Scott (Long) > > my bad. the last working amr/iir is from March 12. > I first detected the problem sometime later, but not later than March 23. > So it has to be changes in that time frame. I think Scott Long was actually asking if you could try to cvsup (or csup) to a date between those two and see if the problem shows there. If you go for, (23 - 12/2) + 12, something like March 17, it would help to narrow what changes could be causing the problem. If you see the problem with a March 17 kernel, you can split the time between March 12 and 17 and try again. Then just keep cutting the search space in half until you can pretty much say "This is the commit that broke things for me." It's not always possible for someone to take the time to do the binary search for the actual commit which broke things for them. But when they can, it really helps the developers. Just cutting it down from 11 days to 5 or 6 days can probably be a big help. -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org From danny at cs.huji.ac.il Sat Mar 28 12:04:22 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sat Mar 28 12:04:28 2009 Subject: amr driver broken since March 12 In-Reply-To: <49CCF95F.1050307@samsco.org> References: <49CCDA41.4060101@samsco.org> <49CCF95F.1050307@samsco.org> Message-ID: > Danny Braniss wrote: > >> Danny Braniss wrote: > >>> at least for me :-) > >>> [and sorry for the cross posting] > >>> > >>> old (March 12 , i know need the svn rev number but...) > >> None of the commit activity on March 12 is jumping out at me as being > >> suspicious. However, you are now the second person who has told me > >> about AMR problems in 7.1 recently. If you have a precise svn change > >> number, it would help greatly. > >> > >> Scott > > my bad. the last working amr/iir is from March 12. > > I first detected the problem sometime later, but not later than March 23. > > So it has to be changes in that time frame. > > > > both drivers are showing similar symptoms: > > waiting for not busy > > the iir goes on for ever, and it's the cam that eventually panics, > > run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config > > (actually not 100% true, depending if WITNESS is on or off, it sometimes > > just hangs). > > the amr seems to time out: > > amr0: adapter is busy > > > > thanks for looking into the problem, > > > > danny > > > > > > Ok, here are a series of revisions to step through, in forward order. > Make sure that you are starting with at least revision 189568. Then, > update to exactly the revision numbers below, recompile the kernel, and > test: > > 190087 > 190091 > it seems March 12 was a bit off :-) it took some time, but I managed to close the gap: 189100 ok 189150 fails I will continue tomorrow, but this should be helpful. cheers, danny From scottl at samsco.org Sat Mar 28 16:45:03 2009 From: scottl at samsco.org (Scott Long) Date: Sat Mar 28 16:45:15 2009 Subject: amr driver broken since March 12 In-Reply-To: References: <49CCDA41.4060101@samsco.org> <49CCF95F.1050307@samsco.org> Message-ID: <49CEB652.8060003@samsco.org> Danny Braniss wrote: > it seems March 12 was a bit off :-) > it took some time, but I managed to close the gap: > 189100 ok > 189150 fails > I will continue tomorrow, but this should be helpful. > > 189150 is in the middle of a big string of related commits. Try updating to the following change numbers and retesting: 189088 189107 189161 If the last one does not work, try editing /sys/dev/amr/amr.c to change #define AMR_ENABLE_CAM 1 to #define AMR_ENABLE_CAM 0 Scott From juri_mian at yahoo.com Sat Mar 28 20:30:27 2009 From: juri_mian at yahoo.com (Juri Mianovich) Date: Sat Mar 28 20:30:39 2009 Subject: quick questions RE: Intel Integrated Server RAID and FreeBSD Message-ID: <457449.75324.qm@web45609.mail.sp1.yahoo.com> (originally posted in freebsd-fs, but on second thought I think this is the appropriate list) Hello, I am considering this motherboard: http://www.intel.com/products/server/motherboards/S5000PSL/S5000PSL-overview.htm The Intel S5000 PSL Server board, with "Intel Integrated Server RAID". I plan on using the onboard raid for a simple boot mirror. I have two quick questions: 1. What chipset/controller is this "Intel Integrated Server RAID" and is it well supported in FreeBSD ? Will sysinstall recognize it ? Is there a CLI tool ofr viewing status once FreeBSD is running ? 2. Is this _real_ hardware raid ? As in, FreeBSD will know _nothing_ about the raid and will simply see one disk (which is a mirror) ? I am seeing discussion that I don't understand about how this is somehow software raid, but If it's all built on the board ... ? Performance isn't a real issue since it is just a boot mirror. I just want to hide the raid layer from the OS and do my raid work (rebuilds, etc.) through the BIOS. Thanks. From danny at cs.huji.ac.il Sat Mar 28 23:42:50 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sat Mar 28 23:43:08 2009 Subject: amr driver broken since March 12 In-Reply-To: <49CEB652.8060003@samsco.org> References: <49CCDA41.4060101@samsco.org> <49CCF95F.1050307@samsco.org> <49CEB652.8060003@samsco.org> Message-ID: > Danny Braniss wrote: > > it seems March 12 was a bit off :-) > > it took some time, but I managed to close the gap: > > 189100 ok > > 189150 fails > > I will continue tomorrow, but this should be helpful. > > > > > > 189150 is in the middle of a big string of related commits. Try > updating to the following change numbers and retesting: > > 189088 > 189107 > 189161 > > If the last one does not work, try editing /sys/dev/amr/amr.c to change > > #define AMR_ENABLE_CAM 1 > > to > > #define AMR_ENABLE_CAM 0 > > Scott 189161 works, also for the iir now what? danny From scottl at samsco.org Sat Mar 28 23:52:40 2009 From: scottl at samsco.org (Scott Long) Date: Sat Mar 28 23:52:47 2009 Subject: amr driver broken since March 12 In-Reply-To: References: <49CCDA41.4060101@samsco.org> <49CCF95F.1050307@samsco.org> <49CEB652.8060003@samsco.org> Message-ID: <49CF1A94.6040703@samsco.org> Danny Braniss wrote: >> Danny Braniss wrote: >>> it seems March 12 was a bit off :-) >>> it took some time, but I managed to close the gap: >>> 189100 ok >>> 189150 fails >>> I will continue tomorrow, but this should be helpful. >>> >>> >> 189150 is in the middle of a big string of related commits. Try >> updating to the following change numbers and retesting: >> >> 189088 >> 189107 >> 189161 >> >> If the last one does not work, try editing /sys/dev/amr/amr.c to change >> >> #define AMR_ENABLE_CAM 1 >> >> to >> >> #define AMR_ENABLE_CAM 0 >> >> Scott > > 189161 works, also for the iir > now what? > Next set to try: 189219 189229 189253 189402 189531 189569 189591 Scott From danny at cs.huji.ac.il Sun Mar 29 01:00:42 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sun Mar 29 01:00:55 2009 Subject: amr driver broken since March 12 In-Reply-To: <49CF1A94.6040703@samsco.org> References: <49CCDA41.4060101@samsco.org> <49CCF95F.1050307@samsco.org> <49CEB652.8060003@samsco.org> <49CF1A94.6040703@samsco.org> Message-ID: > Danny Braniss wrote: > >> Danny Braniss wrote: > >>> it seems March 12 was a bit off :-) > >>> it took some time, but I managed to close the gap: > >>> 189100 ok > >>> 189150 fails > >>> I will continue tomorrow, but this should be helpful. > >>> > >>> > >> 189150 is in the middle of a big string of related commits. Try > >> updating to the following change numbers and retesting: > >> > >> 189088 > >> 189107 > >> 189161 > >> > >> If the last one does not work, try editing /sys/dev/amr/amr.c to change > >> > >> #define AMR_ENABLE_CAM 1 > >> > >> to > >> > >> #define AMR_ENABLE_CAM 0 > >> > >> Scott > > > > 189161 works, also for the iir > > now what? > > > > Next set to try: > > 189219 broken > 189229 broken any point in going on? danny > 189253 > 189402 > 189531 > 189569 > 189591 > > Scott From scottl at samsco.org Sun Mar 29 07:23:19 2009 From: scottl at samsco.org (Scott Long) Date: Sun Mar 29 07:23:38 2009 Subject: amr driver broken since March 12 In-Reply-To: References: <49CCDA41.4060101@samsco.org> <49CCF95F.1050307@samsco.org> <49CEB652.8060003@samsco.org> <49CF1A94.6040703@samsco.org> Message-ID: <49CF8432.5090201@samsco.org> Danny Braniss wrote: >> Danny Braniss wrote: >>>> Danny Braniss wrote: >>>>> it seems March 12 was a bit off :-) >>>>> it took some time, but I managed to close the gap: >>>>> 189100 ok >>>>> 189150 fails >>>>> I will continue tomorrow, but this should be helpful. >>>>> >>>>> >>>> 189150 is in the middle of a big string of related commits. Try >>>> updating to the following change numbers and retesting: >>>> >>>> 189088 >>>> 189107 >>>> 189161 >>>> >>>> If the last one does not work, try editing /sys/dev/amr/amr.c to change >>>> >>>> #define AMR_ENABLE_CAM 1 >>>> >>>> to >>>> >>>> #define AMR_ENABLE_CAM 0 >>>> >>>> Scott >>> 189161 works, also for the iir >>> now what? >>> >> Next set to try: >> >> 189219 > broken >> 189229 > broken Ok, so 189161 works, 189219 doesn't, correct? If so, did you also make the change to amr.c yet? Scott From ivoras at freebsd.org Sun Mar 29 11:05:03 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sun Mar 29 11:05:20 2009 Subject: quick questions RE: Intel Integrated Server RAID and FreeBSD In-Reply-To: <457449.75324.qm@web45609.mail.sp1.yahoo.com> References: <457449.75324.qm@web45609.mail.sp1.yahoo.com> Message-ID: Juri Mianovich wrote: > 1. What chipset/controller is this "Intel Integrated Server RAID" and is it well supported in FreeBSD ? Will sysinstall recognize it ? Is there a CLI tool ofr viewing > status once FreeBSD is running ? AFAIK (I don't use it) it's recognized but people often have problems with it. > 2. Is this _real_ hardware raid ? As in, FreeBSD will know _nothing_ about the raid and will simply see one disk (which is a mirror) ? I am seeing discussion that I > don't understand about how this is somehow software raid, but If it's all built on the board ... ? No, it's a soft-RAID, driven by ataraid. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-scsi/attachments/20090329/c71fa29f/signature.pgp From lists at jnielsen.net Sun Mar 29 16:00:04 2009 From: lists at jnielsen.net (John Nielsen) Date: Sun Mar 29 16:00:11 2009 Subject: quick questions RE: Intel Integrated Server RAID and FreeBSD In-Reply-To: <457449.75324.qm@web45609.mail.sp1.yahoo.com> References: <457449.75324.qm@web45609.mail.sp1.yahoo.com> Message-ID: <200903291900.01865.lists@jnielsen.net> On Saturday 28 March 2009 11:17:31 pm Juri Mianovich wrote: > The Intel S5000 PSL Server board, with "Intel Integrated Server RAID". > I plan on using the onboard raid for a simple boot mirror. > > I have two quick questions: > > 1. What chipset/controller is this "Intel Integrated Server RAID" and > is it well supported in FreeBSD ? Will sysinstall recognize it ? Is > there a CLI tool ofr viewing status once FreeBSD is running ? I'm not sure about the specific controller but it looks like it should be supported. If you set up a mirror in the BIOS before booting sysinstall it will likely be recognized as ar0. Note that the individual disks will ALSO be visible. atacontrol / ataraid are the tools you would use to administer such a thing. > 2. Is this _real_ hardware raid ? As in, FreeBSD will know _nothing_ > about the raid and will simply see one disk (which is a mirror) ? I am > seeing discussion that I don't understand about how this is somehow > software raid, but If it's all built on the board ... ? This is software RAID. The BIOS knows enough to manipulate and boot from arrays, and if you use the Intel driver / software on Windows it will do its thing there as well. The two pieces of software use the same metadata, etc. so the transition is more or less seamless as long as the driver and related services are installed and working properly under Windows. Under FreeBSD, the Intel metadata format is one of many understood and supported by the ataraid(4) driver, which basically just extends ata(4). You should be able to boot, monitor array status and make repairs using atacontrol and friends. > Performance isn't a real issue since it is just a boot mirror. I just > want to hide the raid layer from the OS and do my raid work (rebuilds, > etc.) through the BIOS. I haven't used this particular board but I have used Intel RAID in the past and share the view that software RAID is best handled at the OS level and not at the driver/BIOS level. You as the administrator have a better idea of and more control over what is going on, plus your RAID format (and therefore future integrity) is not tied to one vendor (or line, or specific card, etc.). FreeBSD's gmirror (geom_mirror) is an excellent tool; well-documented and well-integrated into the OS. It is possible to boot from gmirror volumes, monitor array status manually or automatically (via periodic scripts), etc. The only compelling potential reasons I can think of to use the onboard RAID are: 1) You need to see the same volumes across multiple OS'es (FreeBSD and Windows for example). Windows obviously doesn't understand FreeBSD's gmirror, etc (but it probably doesn't understand the filesystem either..). Since you didn't mention Windows I don't expect this is an issue. 2) You want to install to an array directly from sysinstall without any manual prep. Since you did mention sysinstall this could be more relevant. Unfortunately the currently shipping installer doesn't offer anything in the way of creating RAID or other non-vanilla volumes. The most straightforward way around this is to prep the gmirror disk(s) before running sysinstall by booting to a rescue CD or attaching the disk(s) to a system currently running FreeBSD, Or you can install FreeBSD to the primary disk, manually create your mirror and partitions on the secondary disk, dump/restore everything over, switch boot order and insert the former primary into the array. IIRC PC-BSD supports RAID creation at boot time, so that might give you more options. HTH, JN From bugmaster at FreeBSD.org Mon Mar 30 04:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 30 04:09:10 2009 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200903301106.n2UB6x7q054893@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/132394 scsi [isp] - bad underruns with QLogic qla2300 and amd64 o kern/132250 scsi [ciss] ciss driver does not support more then 15 drive o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri o kern/131032 scsi [panic] hald causing panic in scsi_sg o kern/130735 scsi [cam] [patch] pass M_NOWAIT to the malloc() call insid o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/126866 scsi [isp] [panic] kernel panic on card initialization o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping o kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/40895 scsi wierd kernel / device driver bug o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 36 problems total. From samflanker at gmail.com Mon Mar 30 05:29:19 2009 From: samflanker at gmail.com (Vladimir Ermakov) Date: Mon Mar 30 05:29:28 2009 Subject: aac does not respond with SCHED_ULE Message-ID: <49D0A829.1070702@gmail.com> continuation of the old topic http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/028037.html Hi, all. Describe my problem: Using the logical drive (RAID-10) on Adaptec 5805 [firmware build: 16501]. Try to read a file from this logical drive. As a result, the controller does not respond. I found a reason. The problem in using the scheduler SCHED_ULE with the aac driver. Shows the results of my experiments. system | scheduler | operation | result 7.1-RELEASE amd64 | SCHED_ULE | read a file | failed (controller does not respond) 7.1-RELEASE amd64 | SCHED_4BSD | read a file | passed ===================================== # uname -a FreeBSD sys3 7.1-RELEASE-p4 FreeBSD 7.1-RELEASE-p4 #8: Mon Mar 30 11:38:10 CEST 2009 root@sys3:/usr/obj/usr/src/sys/SYS3 amd64 # cat /var/db/mysql/ibdata1 > /dev/null # less /var/log/messages Mar 22 20:20:12 sys3 kernel: aac0: COMMAND 0xffffffff808599e0 TIMEOUT AFTER 50 SECONDS Mar 22 20:20:12 sys3 kernel: aac0: COMMAND 0xffffffff808569c0 TIMEOUT AFTER 50 SECONDS Mar 22 20:20:32 sys3 kernel: aac0: COMMAND 0xffffffff80859dd0 TIMEOUT AFTER 70 SECONDS Mar 22 20:20:32 sys3 kernel: aac0: COMMAND 0xffffffff808599e0 TIMEOUT AFTER 70 SECONDS Mar 22 20:20:32 sys3 kernel: aac0: COMMAND 0xffffffff808569c0 TIMEOUT AFTER 70 SECONDS Mar 22 20:20:52 sys3 kernel: aac0: COMMAND 0xffffffff80859dd0 TIMEOUT AFTER 90 SECONDS Mar 22 20:20:52 sys3 kernel: aac0: COMMAND 0xffffffff808599e0 TIMEOUT AFTER 90 SECONDS Mar 22 20:20:52 sys3 kernel: aac0: COMMAND 0xffffffff808569c0 TIMEOUT AFTER 90 SECONDS Mar 22 20:21:12 sys3 kernel: aac0: COMMAND 0xffffffff80859dd0 TIMEOUT AFTER 111 SECONDS Mar 22 20:21:12 sys3 kernel: aac0: COMMAND 0xffffffff808599e0 TIMEOUT AFTER 111 SECONDS Mar 22 20:21:12 sys3 kernel: aac0: COMMAND 0xffffffff808569c0 TIMEOUT AFTER 111 SECONDS # arcconf GETCONFIG 1 Controllers found: 1 ---------------------------------------------------------------------- Controller information ---------------------------------------------------------------------- Controller Status : Optimal Channel description : SAS/SATA Controller Model : Adaptec 5805 Controller Serial Number : xxxxxxxxxxxxxxx Physical Slot : 6 Temperature : 82 C/ 179 F (Normal) Installed memory : 512 MB Copyback : Disabled Background consistency check : Disabled Automatic Failover : Enabled Global task priority : High Performance Mode : Default/Dynamic Stayawake period : Disabled Spinup limit internal drives : 0 Spinup limit external drives : 0 Defunct disk drive count : 0 Logical devices/Failed/Degraded : 1/0/0 -------------------------------------------------------- Controller Version Information -------------------------------------------------------- BIOS : 5.2-0 (16501) Firmware : 5.2-0 (16501) Driver : 5.2-0 (16501) Boot Flash : 5.2-0 (16501) -------------------------------------------------------- Controller Battery Information -------------------------------------------------------- Status : Optimal Over temperature : No Capacity remaining : 100 percent Time remaining (at current draw) : 1 days, 20 hours, 7 minutes *** THX /Vladimir Ermakov From samflanker at gmail.com Mon Mar 30 06:10:26 2009 From: samflanker at gmail.com (Vladimir Ermakov) Date: Mon Mar 30 06:10:32 2009 Subject: aac does not respond with SCHED_ULE In-Reply-To: <49D0A829.1070702@gmail.com> References: <49D0A829.1070702@gmail.com> Message-ID: <49D0B6C0.6070106@gmail.com> Vladimir Ermakov wrote: > continuation of the old topic > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/028037.html > > Hi, all. > > Describe my problem: > Using the logical drive (RAID-10) on Adaptec 5805 [firmware build: > 16501]. Try to read a file from this logical drive. As a result, the > controller does not respond. > > I found a reason. The problem in using the scheduler SCHED_ULE with > the aac driver. > Shows the results of my experiments. > > system | scheduler | operation | result > 7.1-RELEASE amd64 | SCHED_ULE | read a file | failed (controller > does not respond) > 7.1-RELEASE amd64 | SCHED_4BSD | read a file | passed > sorry, my experiment with 7.1-RELEASE amd64 (SCHED_4BSD) is crashed # ls -halt ibdata1 -rw-rw---- 1 mysql mysql 256G Mar 22 23:23 ibdata1 # cat ibdata1 | pv -brt > /dev/null 13GB 0:01:15 [ 0B/s ] controller does not respond, system -> freeze differences: system | result 7.1-RELEASE amd64 with SCHED_ULE | read only 6.5GB of file 7.1-RELEASE amd64 with SCHED_4BSD | read only 13GB of file /Vladimir Ermakov