From bugmaster at FreeBSD.org Mon Jun 2 11:07:00 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 2 11:07:33 2008 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200806021106.m52B6xpm093298@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/40895 scsi wierd kernel / device driver bug o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/60598 scsi wire down of scsi devices conflicts with config o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/120487 scsi [sg] scsi_sg incompatible with scanners o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/123666 scsi [aac] aac(4) will not work with Adaptec SAS RAID 3805 o kern/123674 scsi [ahc] ahc driver dumping 10 problems total. From romain at blogreen.org Thu Jun 5 16:00:17 2008 From: romain at blogreen.org (Romain =?iso-8859-1?Q?Tarti=E8re?=) Date: Thu Jun 5 16:00:18 2008 Subject: kern/123666: [aac] aac(4) will not work with Adaptec SAS RAID 3805 controller Message-ID: <200806051600.m55G0Gij057004@freefall.freebsd.org> The following reply was made to PR kern/123666; it has been noted by GNATS. From: Romain =?iso-8859-1?Q?Tarti=E8re?= To: Alexander Titaev Cc: bug-followup@FreeBSD.org, romain@blogreen.org Subject: Re: kern/123666: [aac] aac(4) will not work with Adaptec SAS RAID 3805 controller Date: Thu, 5 Jun 2008 17:58:33 +0200 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sorry for late answer. After more tests, the problem is specific to the motherboard we are using: MSI RC410-M2 rev. 1.0 with the controller plugged in the PCI Express port originaly used with the video card. Since it is the only port the controller can be plugged-in, we cannot try on another port. The controller works on 7.0-STABLE / 8.0-CURRENT on my home machine with a different motherboard. Any leads / tests / hacks / ideas are welcome! Kind regards, Romain --=20 Romain Tarti=E8re http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =3Dnon-HTML=3D PGP/GPG encrypted/signed e-mail much appreciated) --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhIDSgACgkQ2OmjP/9W/0M34wCcC3fh2wtQFoKpyK9jlzSTecmU CUsAn1pTTEYAc47Jxxfkopx7+grR4kLl =jj9k -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From emaste at freebsd.org Fri Jun 6 21:20:04 2008 From: emaste at freebsd.org (Ed Maste) Date: Fri Jun 6 21:20:06 2008 Subject: kern/123666: [aac] aac(4) will not work with Adaptec SAS RAID 3805 controller Message-ID: <200806062120.m56LK42D073873@freefall.freebsd.org> The following reply was made to PR kern/123666; it has been noted by GNATS. From: Ed Maste To: Alexander Titaev , bug-followup@FreeBSD.org Cc: freebsd-scsi@FreeBSD.org Subject: Re: kern/123666: [aac] aac(4) will not work with Adaptec SAS RAID 3805 controller Date: Fri, 6 Jun 2008 17:15:51 -0400 > but in 7.0-STABLE all worked fine > > msk-srv# uname -mr > 7.0-STABLE amd64 > msk-srv# dmesg | grep ^aa > aac0: mem 0xd8400000-0xd85fffff irq 18 at device 14.0 o= > n pci11 > aac0: Enabling 64-bit address support > aac0: Enable Raw I/O > aac0: Enable 64-bit array > aac0: New comm. interface enabled > aac0: [ITHREAD] > aac0: Adaptec 3805, aac driver 2.0.0-1 > aacp0: on aac0 > aacp1: on aac0 > aacp2: on aac0 > aacd0: on aac0 > aacd0: 953690MB (1953157120 sectors) > aacd1: on aac0 > aacd1: 5722190MB (11719045120 sectors) It looks like this followup was to the wrong PR; kern/123666 is about a failure of the driver to attach. Your issue is that your RAID-5 array is larger than 2TB and the driver in 7.0-RELEASE is missing support for that; it is fixed in RELENG_7 and will be in 7.1. -Ed From emaste at freebsd.org Fri Jun 6 21:27:57 2008 From: emaste at freebsd.org (Ed Maste) Date: Fri Jun 6 21:27:59 2008 Subject: kern/123666: [aac] aac(4) will not work with Adaptec SAS RAID 3805 controller In-Reply-To: <200805290530.m4T5U869051120@freefall.freebsd.org> References: <200805290530.m4T5U869051120@freefall.freebsd.org> Message-ID: <20080606211550.GA34820@sandvine.com> > but in 7.0-STABLE all worked fine > > msk-srv# uname -mr > 7.0-STABLE amd64 > msk-srv# dmesg | grep ^aa > aac0: mem 0xd8400000-0xd85fffff irq 18 at device 14.0 o= > n pci11 > aac0: Enabling 64-bit address support > aac0: Enable Raw I/O > aac0: Enable 64-bit array > aac0: New comm. interface enabled > aac0: [ITHREAD] > aac0: Adaptec 3805, aac driver 2.0.0-1 > aacp0: on aac0 > aacp1: on aac0 > aacp2: on aac0 > aacd0: on aac0 > aacd0: 953690MB (1953157120 sectors) > aacd1: on aac0 > aacd1: 5722190MB (11719045120 sectors) It looks like this followup was to the wrong PR; kern/123666 is about a failure of the driver to attach. Your issue is that your RAID-5 array is larger than 2TB and the driver in 7.0-RELEASE is missing support for that; it is fixed in RELENG_7 and will be in 7.1. -Ed From bugmaster at FreeBSD.org Mon Jun 9 11:07:06 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 9 11:07:41 2008 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200806091107.m59B75sE070870@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/40895 scsi wierd kernel / device driver bug o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/60598 scsi wire down of scsi devices conflicts with config o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/120487 scsi [sg] scsi_sg incompatible with scanners o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/123666 scsi [aac] aac(4) will not work with Adaptec SAS RAID 3805 o kern/123674 scsi [ahc] ahc driver dumping 10 problems total. From weimin.pan at hp.com Mon Jun 9 18:34:26 2008 From: weimin.pan at hp.com (Pan, Weimin) Date: Mon Jun 9 18:34:30 2008 Subject: How to directly pass a dma physical address and length from SCSI upper layer to LLD without mapping the dma memory to kernel pages Message-ID: <6B24EEDBA38D764293B27C04FE414CC64E40604C07@G1W0491.americas.hpqcorp.net> SCSI upper layer can pass a scatterlist to middle layer and LLD. Normally the page_link, length, and offset is set in the scatterlist. LLD will convert to dma_address from pages by itself. That means the dma physical address has to map to kernel memory space before it can be passed to LLD for data transfer. If I have a large dma memroy and it doesn't need to be touched by kernel or user mode Apps, it is a performance penalty to force to do that. Is there a way to directly pass a dma physical address from upper layer to LLD (like use dma_address in a scatterlist)? I looked at a couple of LLD drivers and none of them handle this kind of situation. From ken at kdm.org Mon Jun 9 20:56:41 2008 From: ken at kdm.org (Kenneth D. Merry) Date: Mon Jun 9 20:56:44 2008 Subject: How to directly pass a dma physical address and length from SCSI upper layer to LLD without mapping the dma memory to kernel pages In-Reply-To: <6B24EEDBA38D764293B27C04FE414CC64E40604C07@G1W0491.americas.hpqcorp.net> References: <6B24EEDBA38D764293B27C04FE414CC64E40604C07@G1W0491.americas.hpqcorp.net> Message-ID: <20080609201723.GA95850@nargothrond.kdm.org> On Mon, Jun 09, 2008 at 18:18:16 +0000, Pan, Weimin wrote: > SCSI upper layer can pass a scatterlist to middle layer and LLD. Normally the page_link, length, and offset is set in the scatterlist. LLD will convert to dma_address from pages by itself. That means the dma physical address has to map to kernel memory space before it can be passed to LLD for data transfer. If I have a large dma memroy and it doesn't need to be touched by kernel or user mode Apps, it is a performance penalty to force to do that. > > Is there a way to directly pass a dma physical address from upper layer to LLD (like use dma_address in a scatterlist)? > I looked at a couple of LLD drivers and none of them handle this kind of situation. In theory, you can pass a physical address in a CAM CCB if you set the CAM_DATA_PHYS flag on the CCB. It looks like quite a few drivers in the tree support that flag, or at least look at it. So take a look at whichever driver you're using, and see if it looks at that flag in the CCB. Ken -- Kenneth Merry ken@kdm.org From scottl at samsco.org Wed Jun 11 13:30:59 2008 From: scottl at samsco.org (Scott Long) Date: Wed Jun 11 13:31:02 2008 Subject: How to directly pass a dma physical address and length from SCSI upper layer to LLD without mapping the dma memory to kernel pages In-Reply-To: <20080609201723.GA95850@nargothrond.kdm.org> References: <6B24EEDBA38D764293B27C04FE414CC64E40604C07@G1W0491.americas.hpqcorp.net> <20080609201723.GA95850@nargothrond.kdm.org> Message-ID: <484FD38B.3050906@samsco.org> Kenneth D. Merry wrote: > On Mon, Jun 09, 2008 at 18:18:16 +0000, Pan, Weimin wrote: >> SCSI upper layer can pass a scatterlist to middle layer and LLD. Normally the page_link, length, and offset is set in the scatterlist. LLD will convert to dma_address from pages by itself. That means the dma physical address has to map to kernel memory space before it can be passed to LLD for data transfer. If I have a large dma memroy and it doesn't need to be touched by kernel or user mode Apps, it is a performance penalty to force to do that. >> >> Is there a way to directly pass a dma physical address from upper layer to LLD (like use dma_address in a scatterlist)? >> I looked at a couple of LLD drivers and none of them handle this kind of situation. > > In theory, you can pass a physical address in a CAM CCB if you set the > CAM_DATA_PHYS flag on the CCB. > > It looks like quite a few drivers in the tree support that flag, or at > least look at it. > > So take a look at whichever driver you're using, and see if it looks at > that flag in the CCB. > > Ken Most drivers will honor CAM_DATA_PHYS by itself, but don't honor it in conjunction with CAM_SCATTER_VALID. CAM_SG_LIST_PHYS is only supported by the AHC and AHD drivers (and it's not clear to me what the difference is between the two sets of flags). That said, modifying drivers to support physical S/G lists isn't all that hard, and it's something that will happen more and more with the planned changes to moving physio to unmapped physical addresses. Scott From derekverlee at comcast.net Fri Jun 13 00:56:51 2008 From: derekverlee at comcast.net (Derek VerLee) Date: Fri Jun 13 00:56:55 2008 Subject: target mode Message-ID: <4851C202.4030204@comcast.net> Hello I'm curious about what is and isn't possible using scsi target mode in FreeBSD, both in principle and given the current state of the architecture. In particular I am curious if it is possible to use a scsi card in target mode, to "export" drives, such as a geom array, to be accessed by another computer over a physical scsi connect. I believe this is what iscsi support aims at, however i'm interested in other scsi interfaces, such as parrellel or perhaps SAS. Searching the archives and web somewhat, I have seen other people ask this a couple times but haven't found a definite answer. This would be to perhaps re-purpose an older computer, or an inexpensive one, to act much like an external raid (but perhaps potentially more flexible). Is is possible now? If not, could it be done with some hacking and coding? How crazy would you have to be to try? _derek From scottl at samsco.org Fri Jun 13 01:14:07 2008 From: scottl at samsco.org (Scott Long) Date: Fri Jun 13 01:14:10 2008 Subject: target mode In-Reply-To: <4851C202.4030204@comcast.net> References: <4851C202.4030204@comcast.net> Message-ID: <4851C9CE.8030806@samsco.org> Derek VerLee wrote: > > Hello > I'm curious about what is and isn't possible using scsi target mode in > FreeBSD, both in principle and given the current state of the > architecture. In particular I am curious if it is possible to use a > scsi card in target mode, to "export" drives, such as a geom array, to > be accessed by another computer over a physical scsi connect. I believe > this is what iscsi support aims at, however i'm interested in other scsi > interfaces, such as parrellel or perhaps SAS. Searching the archives > and web somewhat, I have seen other people ask this a couple times but > haven't found a definite answer. > > This would be to perhaps re-purpose an older computer, or an inexpensive > one, to act much like an external raid (but perhaps potentially more > flexible). > > Is is possible now? If not, could it be done with some hacking and > coding? How crazy would you have to be to try? > Short answer is yes, it's possible to export logical disks with what is in the tree and a minimal amount of setup and configuration. The target mode support is split into 2 layers. There is the kernel driver that handles the basic parallel scsi wire protocol (i.e. selection, reconnection, etc) in conjunction with the HBA driver, and acts as a conduit for the command protocol. Above that is the userland driver that talks to the kernel target driver and handles the scsi command protocol, i.e. inquiries, read/write, etc. There is a skeletal but fully functional upper layer in /usr/share/examples/scsi_target. It can generate suitable responses to inquiry and TUR commands, and can be pointed at a file to use as the backing store for a virtual disk. I'd suggest reading the man page in there and playing with it; it's simple but it works and is a good demonstration of the possibilities that exist. Not all HBA drivers support target mode, however. For parallel SCSI, the AHC driver is probably the best choice since it was the reference platform for all of the target mode code. Scott From karsten at photor.de Fri Jun 13 20:50:13 2008 From: karsten at photor.de (Karsten Rothemund) Date: Fri Jun 13 20:50:15 2008 Subject: Page Fault with amd0 on FreeBSD-7 Message-ID: <20080613205009.GA79046@www.photor.de> Hello List, I don't know, if this is the right list to post on. If not: sorry. I wanted to update my FreeBSD-6 to -7 and tried to boot disk 1. I got a page fault. So I used the csup-tool to go up to 7 (the usual procedure: csup make buildworld make buildkernel make installkernel reboot <---- OOOOPS! Page Fault again. (make installworld) (mergemaster) (reboot) (rebuild ports) I wrote down some information (by hand): Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x4 fault code = supervisor read, page not present (-- stack- and frame pointer, code segment --) processor eflags = interrupt enabled, resume, IOPL = 0 current process = 20 (irq9: amd0) trap number = 12 The interesting information for me was the "amd0". This is for the Tekram DC-390 SCSI card, which is for my CDROM, CD-writer and for the scanner. All of them are not vital at the momenti but I need them. So I decided (it was an advice or hint in a forum) to compile a kernel without amd. That kernel works quite OK - but without CDROM and scanner. I completed the installation/update with no problems and now I recompile/reinstall al the ports I need. I also tried to kldload the amd module by hand. Result: no page fault but also no function (no devices even after reseting the scsi bus). This is the status now. Now I am here to ask, if I can help to fix the bug (if there is one). The forum people told me, that there have been some changes in the kernel code affecting SCSI or CAM. First thing: what should I do to provide helpful information. (DEBUG-options in kernel etc). I must say I do not have a lot experience in kernel debuging but I am willing to learn. Greetings from the Baltic Sea, Karsten PS: information about the machine: ATHLON 700, 512MB RAM, Tekram DC-390 csup at the beginning of this week. worf# uname -a FreeBSD worf.mydomain.home 7.0-STABLE FreeBSD 7.0-STABLE #45: Fri Jun 6 21:28:03 CEST 2008 root@worf.mydomain.home:/usr/obj/usr/src/sys/ATHLON i386 -- Karsten Rothemund /"\ PGP-Key: 0x7019CAA5 \ / Fingerprint: E752 C759 B9B2 2057 E42F \ ASCII Ribbon Campaign 50EE 47AC A7CE 7019 CAA5 / \ Against HTML Mail and News -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-scsi/attachments/20080613/f0f0f69b/attachment.pgp From bugmaster at FreeBSD.org Mon Jun 16 11:07:03 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 16 11:08:08 2008 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200806161107.m5GB72sL036839@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/40895 scsi wierd kernel / device driver bug o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/60598 scsi wire down of scsi devices conflicts with config o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/120487 scsi [sg] scsi_sg incompatible with scanners o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/123666 scsi [aac] aac(4) will not work with Adaptec SAS RAID 3805 o kern/123674 scsi [ahc] ahc driver dumping 10 problems total. From linimon at FreeBSD.org Tue Jun 17 17:52:18 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Jun 17 17:52:26 2008 Subject: kern/124667: [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi-driver with TEKRAM DC-390 [regression] Message-ID: <200806171752.m5HHqImB097231@freefall.freebsd.org> Old Synopsis: FreeBSD-7 kernel page faults at amd-scsi-driver with TEKRAM DC-390 New Synopsis: [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi-driver with TEKRAM DC-390 [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jun 17 17:50:51 UTC 2008 Responsible-Changed-Why: Possibly for the scsi mailing list. http://www.freebsd.org/cgi/query-pr.cgi?pr=124667 From bugmaster at FreeBSD.org Mon Jun 23 11:07:01 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 23 11:07:37 2008 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200806231107.m5NB71w3065089@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/40895 scsi wierd kernel / device driver bug o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/60598 scsi wire down of scsi devices conflicts with config o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/120487 scsi [sg] scsi_sg incompatible with scanners o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/123666 scsi [aac] aac(4) will not work with Adaptec SAS RAID 3805 o kern/123674 scsi [ahc] ahc driver dumping 10 problems total. From mb at lunetics.com Thu Jun 26 06:23:56 2008 From: mb at lunetics.com (Lunetics Networks) Date: Thu Jun 26 06:24:01 2008 Subject: aac0 / adaptec 4805SAS problem / Timeout Message-ID: <0d4601c8d73e$679b3bf0$36d1b3d0$@com> Hello. I got the following problem with Freebsd 7.0-Release. I got a Adaptec 4805 SAS controller + 6 Samsung Sata Harddisks (HD250HJ). Almost all few hours, the system freezes for like 1-2 minutes and I see the following output in the messages log: Jun 26 01:49:32 friedhelm kernel: aac0: COMMAND 0xc64e5300 TIMEOUT AFTER 72 SECONDS Jun 26 01:49:32 friedhelm kernel: aac0: COMMAND 0xc64e7080 TIMEOUT AFTER 65 SECONDS Jun 26 01:49:32 friedhelm kernel: aac0: COMMAND 0xc64e8000 TIMEOUT AFTER 45 SECONDS Jun 26 01:49:32 friedhelm kernel: aac0: COMMAND 0xc64ea0c0 TIMEOUT AFTER 45 SECONDS Jun 26 01:49:32 friedhelm kernel: aac0: COMMAND 0xc64ea940 TIMEOUT AFTER 43 SECONDS Jun 26 01:49:32 friedhelm kernel: aac0: COMMAND 0xc64e4d40 TIMEOUT AFTER 43 SECONDS Jun 26 01:49:32 friedhelm kernel: aac0: COMMAND 0xc64e5180 TIMEOUT AFTER 43 SECONDS Jun 26 01:49:32 friedhelm kernel: aac0: COMMAND 0xc64e5600 TIMEOUT AFTER 43 SECONDS Any idea what causes this? Attached some output from dmesg and arcconf. aac0: mem 0xdfe00000-0xdfffffff irq 18 at device 14.0 on pci6 aac0: New comm. interface enabled aac0: [ITHREAD] aac0: Adaptec 4805SAS, aac driver 2.0.0-1 aac0: Error 5 sending VMIoctl command aacd0: on aac0 aacd0: 953186MB (1952124928 sectors) and some Infos from Arcconf: arcconf getconfig 1 Controllers found: 1 ---------------------------------------------------------------------- Controller information ---------------------------------------------------------------------- Controller Status : Optimal Channel description : SAS/SATA Controller Model : Adaptec 4805SAS Controller Serial Number : 6A110CA43F9 Physical Slot : 0 Temperature : 33 C/ 91 F (Normal) Installed memory : 128 MB Copyback : Disabled Background consistency check : Enabled Automatic Failover : Enabled Defunct disk drive count : 0 Logical devices/Failed/Degraded : 1/0/1 -------------------------------------------------------- Controller Version Information -------------------------------------------------------- BIOS : 5.2-0 (15323) Firmware : 5.2-0 (15323) Driver : 0.0-0 (0) Boot Flash : 5.2-0 (15323) -------------------------------------------------------- Controller Battery Information -------------------------------------------------------- Status : Not Installed ---------------------------------------------------------------------- Logical device information ---------------------------------------------------------------------- Logical device number 0 Logical device name : imgserver RAID level : 6 XOR Status of logical device : Degraded Size : 953186 MB Stripe-unit size : 256 KB Read-cache mode : Enabled Write-cache mode : Disabled (write-through) Write-cache setting : Enabled (write-back) Partitioned : Yes Protected by Hot-Spare : No Bootable : Yes Failed stripes : Yes -------------------------------------------------------- Logical device segment information -------------------------------------------------------- Segment 0 : Present (0,0) Segment 1 : Present (0,1) Segment 2 : Present (0,2) Segment 3 : Present (0,3) Segment 4 : Present (0,4) Segment 5 : Present (0,5) ---------------------------------------------------------------------- Physical Device information ---------------------------------------------------------------------- Device #0 Device is a Hard drive State : Online Supported : Yes Transfer Speed : SATA 1.5 Gb/s Reported Channel,Device : 0,0 Vendor : SAMSUNG Model : HD250HJ Firmware : FH100-06 Size : 238475 MB Write Cache : Enabled (write-back) FRU : None S.M.A.R.T. : No Device #1 Device is a Hard drive State : Online Supported : Yes Transfer Speed : SATA 1.5 Gb/s Reported Channel,Device : 0,1 Vendor : SAMSUNG Model : HD250HJ Firmware : FH100-06 Size : 238475 MB Write Cache : Enabled (write-back) FRU : None S.M.A.R.T. : No Device #2 Device is a Hard drive State : Online Supported : Yes Transfer Speed : SATA 1.5 Gb/s Reported Channel,Device : 0,2 Vendor : SAMSUNG Model : HD250HJ Firmware : FH100-05 Size : 238475 MB Write Cache : Enabled (write-back) FRU : None S.M.A.R.T. : No Device #3 Device is a Hard drive State : Online Supported : Yes Transfer Speed : SATA 1.5 Gb/s Reported Channel,Device : 0,3 Vendor : SAMSUNG Model : HD250HJ Firmware : FH100-05 Size : 238475 MB Write Cache : Enabled (write-back) FRU : None S.M.A.R.T. : No Device #4 Device is a Hard drive State : Online Supported : Yes Transfer Speed : SATA 1.5 Gb/s Reported Channel,Device : 0,4 Vendor : SAMSUNG Model : HD250HJ Firmware : FH100-05 Size : 238475 MB Write Cache : Enabled (write-back) FRU : None S.M.A.R.T. : No Device #5 Device is a Hard drive State : Online Supported : Yes Transfer Speed : SATA 1.5 Gb/s Reported Channel,Device : 0,5 Vendor : SAMSUNG Model : HD250HJ Firmware : FH100-05 Size : 238475 MB Write Cache : Enabled (write-back) FRU : None S.M.A.R.T. : No arcconf getlogs 1 DEVICE Controllers found: 1 arcconf getlogs 1 EVENT Controllers found: 1 arcconf getlogs 1 DEAD Controllers found: 1 From bugmaster at FreeBSD.org Mon Jun 30 11:07:04 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 30 11:07:29 2008 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200806301107.m5UB73Dr095873@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/40895 scsi wierd kernel / device driver bug o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/60598 scsi wire down of scsi devices conflicts with config o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/120487 scsi [sg] scsi_sg incompatible with scanners o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/123666 scsi [aac] aac(4) will not work with Adaptec SAS RAID 3805 o kern/123674 scsi [ahc] ahc driver dumping 10 problems total. From danny at cs.huji.ac.il Mon Jun 30 15:48:46 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Mon Jun 30 15:48:49 2008 Subject: iscsi target failure ... Message-ID: Hi, I'm trying to get the iscsi_initiator to handle errors in a better way, and so far if if I report to the cam via XPT_DONE, with status = CAM_REQ_ABORTED the kernel panics after printing many g_vfs_done():da1s1d[WRITE(offset=6428672, length=2048)]error = 5 (the offset= changes), so I was wandering, is there a better (CAM_REQ_CMP_ERR?) status? the return when a terminal error has occurred? danny From sbruno at miralink.com Mon Jun 30 16:18:39 2008 From: sbruno at miralink.com (Sean Bruno) Date: Mon Jun 30 16:18:42 2008 Subject: iscsi target failure ... In-Reply-To: References: Message-ID: <486901AB.2030804@miralink.com> Danny Braniss wrote: > Hi, > I'm trying to get the iscsi_initiator to handle errors in a better way, > and so far if if I report to the cam via XPT_DONE, with status = > CAM_REQ_ABORTED > the kernel panics after printing many > g_vfs_done():da1s1d[WRITE(offset=6428672, length=2048)]error = 5 > (the offset= changes), > so I was wandering, is there a better (CAM_REQ_CMP_ERR?) status? the return > when > a terminal error has occurred? > > danny > > > _______________________________________________ > 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" > Are you talking about the macro XPT_DONE() or the CAM status XPT_DONE? Also, is there a spot in the code that you are specifically looking at? Sean From danny at cs.huji.ac.il Mon Jun 30 16:35:04 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Mon Jun 30 16:35:08 2008 Subject: iscsi target failure ... In-Reply-To: Your message of Mon, 30 Jun 2008 08:54:19 -0700 . Message-ID: > Danny Braniss wrote: > > Hi, > > I'm trying to get the iscsi_initiator to handle errors in a better way, > > and so far if if I report to the cam via XPT_DONE, with status = > > CAM_REQ_ABORTED > > the kernel panics after printing many > > g_vfs_done():da1s1d[WRITE(offset=6428672, length=2048)]error = 5 > > (the offset= changes), > > so I was wandering, is there a better (CAM_REQ_CMP_ERR?) status? the return > > when > > a terminal error has occurred? > > > > danny > Are you talking about the macro XPT_DONE() or the CAM status XPT_DONE? > > Also, is there a spot in the code that you are specifically looking at? > Hi Sean, in iscsi_subr.c/iscsi_cleanup -> _scsi_done->[macro]XPT_DONE() From sbruno at miralink.com Mon Jun 30 18:06:43 2008 From: sbruno at miralink.com (Sean Bruno) Date: Mon Jun 30 18:06:47 2008 Subject: iscsi target failure ... In-Reply-To: References: Message-ID: <486920AD.2070206@miralink.com> Danny Braniss wrote: >> Danny Braniss wrote: >> >>> Hi, >>> I'm trying to get the iscsi_initiator to handle errors in a better way, >>> and so far if if I report to the cam via XPT_DONE, with status = >>> CAM_REQ_ABORTED >>> the kernel panics after printing many >>> g_vfs_done():da1s1d[WRITE(offset=6428672, length=2048)]error = 5 >>> (the offset= changes), >>> so I was wandering, is there a better (CAM_REQ_CMP_ERR?) status? the return >>> when >>> a terminal error has occurred? >>> >>> danny >>> > > >> Are you talking about the macro XPT_DONE() or the CAM status XPT_DONE? >> >> Also, is there a spot in the code that you are specifically looking at? >> >> > > Hi Sean, > in iscsi_subr.c/iscsi_cleanup -> _scsi_done->[macro]XPT_DONE() > > > How are you attempting to make the failure occur with the initiator? Just pulling the cable or some such operation while running an write? Sean