From owner-freebsd-scsi Tue Jan 2 8: 0:13 2001 From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 2 08:00:11 2001 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by hub.freebsd.org (Postfix) with ESMTP id 5236337B400 for ; Tue, 2 Jan 2001 08:00:11 -0800 (PST) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by serenity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 14DTr8-000Ozo-00 for freebsd-scsi@freebsd.org; Tue, 2 Jan 2001 16:00:10 +0000 Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.11.1/8.11.1) id f02G09d28173 for freebsd-scsi@freebsd.org; Tue, 2 Jan 2001 16:00:09 GMT (envelope-from jcm) Date: Tue, 2 Jan 2001 16:00:09 +0000 From: j mckitrick To: freebsd-scsi@freebsd.org Subject: parallel port zip driver Message-ID: <20010102160009.A28117@dogma.freebsd-uk.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello all, I am working to find a problem in the parallel port zip plus driver, and I have a few questions about the scsi code above the driver. Concening the SCSI_STATUS values, csio->scsi_status seems to only have even-numbered values, according to scsi_all.h. In the process of debugging, if the zip driver returns 0x01, the scsi driver seems to choke without explaining why. There is so much code in scsi, cam, and aic7xxx that I am not sure where to look, so I thought maybe I would ask and maybe discover the problem much more quickly. jm -- ------------------------------------------------------------------------ Jonathon McKitrick -- jcm@freebsd-uk.eu.org They laugh because I'm different. I laugh because they're all the same. ------------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 3 10:20:46 2001 From owner-freebsd-scsi@FreeBSD.ORG Wed Jan 3 10:20:35 2001 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from fortune.excite.com (fortune-rwcmta.excite.com [198.3.99.203]) by hub.freebsd.org (Postfix) with ESMTP id 7B48637B402 for ; Wed, 3 Jan 2001 10:20:35 -0800 (PST) Received: from puffer ([199.172.153.109]) by fortune.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20010103182035.BRCO9490.fortune.excite.com@puffer>; Wed, 3 Jan 2001 10:20:35 -0800 Message-ID: <25976672.978546035224.JavaMail.imail@puffer> Date: Wed, 3 Jan 2001 10:20:35 -0800 (PST) From: Steve Bano To: andre.albsmeier@mchp.siemens.de, freebsd-scsi@freebsd.org Subject: Re: SCSI Problems: driver bug? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 24.94.4.86 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Okay, here it is in all its glory: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.2-STABLE #0: Sun Nov 26 19:59:32 UTC 2000 root@mybox:/usr/src/sys/compile/MYBOX Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (731.47-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383fbff real memory = 268369920 (262080K bytes) avail memory = 257949696 (251904K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170020, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc02ef000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 30.0 on pci0 pci2: on pcib2 fxp0: port 0x74c0-0x74ff mem 0xfeb00000-0xfebfffff,0xfeafa000-0xfeafafff irq 19 at device 3.0 on pci2 fxp0: Ethernet address 0D:0E:0A:0D:0B:0E pci2: at 4.0 irq 17 ahc0: port 0x7800-0x78ff mem 0xfeafb000-0xfeafbfff irq 16 at device 8.0 on pci2 aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xfff0-0xffff at device 31.1 on pci0 ata1: at 0x170 irq 15 on atapci0 pci0: (vendor=0x8086, dev=0x2413) at 31.3 irq 17 chip1: port 0xf400-0xf43f,0xf000-0xf0ff irq 17 at device 31.5 on pci0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppi0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 SMP: AP CPU #1 Launched! acd0: CDROM at ata1-master using PIO4 Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 34715MB (71096640 512 byte sectors: 255H 63S/T 4425C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 30, 16bit), Tagged Queueing Enabled da0: 8678MB (17774160 512 byte sectors: 255H 63S/T 1106C) WARNING: / was not properly dismounted On Sat, 30 Dec 2000 11:30:50 +0100, Andre Albsmeier wrote: > Show us your dmesg. > > > On Tue, 26-Dec-2000 at 14:23:52 -0800, Steve Bano wrote: > > Hello, > > > > One of my systems has crashed several times in the last couple > > of weeks, and I believe the problem may be a bug in the SCSI > > driver, as it looks like appearance of messages like the following > > in the logs are correlated with the crashes: > > > > kernel log messages: > > > (da1:ahc0:0:1:0): SCB 0x80 - timed out while idle, SEQADDR == 0x5 > > > STACK == 0x1, 0x10c, 0x164, 0x17a > > > SXFRCTL0 == 0x80 > > > SCB count = 255 > > > QINFIFO entries: > > > Waiting Queue entries: > > > Disconnected Queue entries: 14:66 20:79 23:11 12:69 31:104 1:10 30:39 > > 26:224 2:204 16:70 19:3 21:63 18:73 5:72 0:106 > > 4:32 24:249 29:80 8:250 7:88 11:100 9:225 13:113 10:110 22:76 27:75 15:222 > > 3:91 17:20 25:235 6:77 > > > QOUTFIFO entries: > > > Sequencer Free SCB List: 28 > > > Pending list: 242 64 13 68 66 231 36 46 123 117 79 241 78 11 69 41 104 10 > > 43 230 237 39 244 224 227 107 234 85 44 204 > > 121 114 54 4 101 29 70 98 49 226 3 118 82 129 31 108 125 218 96 9 63 232 93 > > 95 21 73 233 220 102 72 212 53 245 50 16 15 > > 106 12 32 65 249 26 251 83 0 22 84 67 58 86 80 250 236 92 248 89 38 88 203 > > 14 228 18 28 105 100 23 57 24 225 113 110 253 > > 47 127 76 59 215 62 119 75 30 222 90 111 2 115 91 81 51 20 25 235 77 247 94 > > 213 61 128 > > > Kernel Free SCB list: 37 87 19 217 229 240 124 214 71 221 60 216 254 5 7 > > 238 97 219 239 116 48 74 52 122 27 246 8 55 > > 99 202 112 17 252 126 40 109 211 243 56 223 1 33 201 6 35 34 45 200 42 103 > > 205 206 207 208 209 190 191 192 193 194 195 > > 196 197 198 199 180 181 182 183 184 185 186 187 188 189 170 171 172 173 174 > > 175 176 177 178 179 160 161 162 163 164 165 > > 166 167 168 169 150 151 152 153 154 155 156 157 158 159 140 141 142 143 144 > > 145 146 147 148 149 130 131 132 133 134 135 > > 136 137 138 139 120 > > > sg[0] - Addr 0x5863000 : Length 2048 > > > (da1:ahc0:0:1:0): Queuing a BDR SCB > > > (da1:ahc0:0:1:0): SCB 0x80 - timed out while idle, SEQADDR == 0x16c > > > STACK == 0x17a, 0x164, 0x17a, 0x2e > > > SXFRCTL0 == 0x88 > > > SCB count = 255 > > > QINFIFO entries: > > > Waiting Queue entries: > > > Disconnected Queue entries: 14:66 20:79 23:11 12:69 31:104 1:10 30:39 > > 26:224 2:204 16:70 19:3 21:63 18:73 5:72 0:106 > > 4:32 24:249 29:80 8:250 7:88 11:100 9:225 13:113 10:110 22:76 27:75 15:222 > > 3:91 17:20 25:235 6:77 > > > QOUTFIFO entries: > > > Sequencer Free SCB List: > > > Pending list: 242 64 13 68 66 231 36 46 123 117 79 241 78 11 69 41 104 10 > > 43 230 237 39 244 224 227 107 234 85 44 204 > > 121 114 54 4 101 29 70 98 49 226 3 118 82 129 31 108 125 218 96 9 63 232 93 > > 95 21 73 233 220 102 72 212 53 245 50 16 15 > > 106 12 32 65 249 26 251 83 0 22 84 67 58 86 80 250 236 92 248 89 38 88 203 > > 14 228 18 28 105 100 23 57 24 225 113 110 253 > > 47 127 76 59 215 62 119 75 30 222 90 111 2 115 91 81 51 20 25 235 77 247 94 > > 213 61 128 > > > Kernel Free SCB list: 37 87 19 217 229 240 124 214 71 221 60 216 254 5 7 > > 238 97 219 239 116 48 74 52 122 27 246 8 55 > > 99 202 112 17 252 126 40 109 211 243 56 223 1 33 201 6 35 34 45 200 42 103 > > 205 206 207 208 209 190 191 192 193 194 195 > > 196 197 198 199 180 181 182 183 184 185 186 187 188 189 170 171 172 173 174 > > 175 176 177 178 179 160 161 162 163 164 165 > > 166 167 168 169 150 151 152 153 154 155 156 157 158 159 140 141 142 143 144 > > 145 146 147 148 149 130 131 132 133 134 135 > > 136 137 138 139 120 > > > sg[0] - Addr 0x5863000 : Length 2048 > > > (da1:ahc0:0:1:0): no longer in timeout, status = 34b > > > ahc0: Issued Channel A Bus Reset. 128 SCBs aborted > > > > The system is an IBM M Pro, output of uname -a: > > > > FreeBSD mybox 4.2-STABLE FreeBSD 4.2-STABLE #0: Sun Nov 26 19:59:32 UTC 2000 > > root@mybox:/usr/src/sys/compile/MYBOX i386 > > > > Does this output look familiar to anybody? Could this be a kernel/SCSI bug, > > and if so, where would be the appropriate place to report it? > > > > Thanks, > > > > -Steve > > > > > > > > > > > > _______________________________________________________ > > Send a cool gift with your E-Card > > http://www.bluemountain.com/giftcenter/ > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-scsi" in the body of the message > > -- > BSD, from the people who brought you TCP/IP. _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 3 13:20:19 2001 From owner-freebsd-scsi@FreeBSD.ORG Wed Jan 3 13:20:17 2001 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by hub.freebsd.org (Postfix) with ESMTP id 2875C37B404 for ; Wed, 3 Jan 2001 13:20:16 -0800 (PST) Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com; Wed, 3 Jan 2001 16:19:39 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 3 Jan 2001 16:19:46 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E80511A13C@zwdld001.ca.nortel.com> From: "Kyle Brost" To: "'freebsd-scsi@freebsd.org'" Subject: UNSUBSCRIBE Date: Wed, 3 Jan 2001 16:19:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C075CA.DD52AB40" X-Orig: Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C075CA.DD52AB40 Content-Type: text/plain; charset="iso-8859-1" UNSUBSCRIBE ------_=_NextPart_001_01C075CA.DD52AB40 Content-Type: text/html; charset="iso-8859-1" UNSUBSCRIBE

UNSUBSCRIBE

------_=_NextPart_001_01C075CA.DD52AB40-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 4 18:26:32 2001 From owner-freebsd-scsi@FreeBSD.ORG Thu Jan 4 18:26:23 2001 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from hoteldns02.stsn.com (p142.usslc13.stsn.com [208.32.226.142]) by hub.freebsd.org (Postfix) with ESMTP id F03C137B404; Thu, 4 Jan 2001 18:26:17 -0800 (PST) Received: from caledonia.bikeworld.com ([10.0.208.219]) by hoteldns02.stsn.com (8.9.3/8.8.7) with SMTP id TAA16238; Thu, 4 Jan 2001 19:25:13 -0700 Message-Id: <4.3.2.7.2.20010104184802.019766c8@shrubbery.satx.bikeworld.net> X-Sender: chris@shrubbery.satx.bikeworld.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Jan 2001 18:51:06 -0600 To: Micah Anderson , "Salyzyn, Mark" From: Chris Snell Subject: Re: update Cc: "'Mike Smith'" , Micah Anderson , noah , freebsd-scsi@freebsd.org In-Reply-To: <20001226152519.X10704@riseup.net> References: <50DB155AD0CED411988E009027D61DB31D8116@otcexc01.otc.adaptec.com> <50DB155AD0CED411988E009027D61DB31D8116@otcexc01.otc.adaptec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Micah, Would it be of any help if I sent you the kernel config for our server that has one of these cards in it? As I said earlier, it's been working great for us. Also, when you tried this card in a different machine, did that machine have the same motherboard and BIOS? You mentioned that Debian works on your setup. Did you try installing it (Debian) and then hammering on the disks or did you just verify that it installed? Chris At 03:25 PM 12/26/2000 -0800, Micah Anderson wrote: >So I have tried pretty much everything, the alarm still goes off at the same >time during boot up, at asr0: major=154. I am trying a last experiment >today, if it doesn't work, I am sad to say that I am going to have to use >Debian since it works fine there. I have had this server for over a month >trying everything on the planet to get it to work, we need this server >running in a bad way and although I want to go with FreeBSD we unfortunately >are going to have to go with what works. > >Right now I am trying to recompile the kernel by pulling everything out of >the config file, except what is needed. It seems as if the problem has to do >with the FreeBSD scsi or asr driver. Because thats when things go, and if I >can boot off the CD without this happening, then something is funky. > >I was called by Ida at Adaptec to follow up on the call that I originally >placed, ID #2843, but I was given the wrong number to call her back. > >I've done practically everything in my power, besides getting a job at >adaptec or delving into the FreeBSD driver code, neither of which I can do >at this point. Do you guys have any other ideas, or suggestions where to go >next? > >Just a reminder, this is an adaptec 3200s, using freebsd 4.2, 4 IBM 9 gig >10,000 RPM LVD drives making up a Raid-5, using a nice Intel motherboard >(which has another adaptec on board controller, but I've tried the card in a >different machine with the drives, same results).... > >Micah > > > >On Mon, 18 Dec 2000, Salyzyn, Mark wrote: > > > Although I figure Adaptec's Tech Support would be the best to know about > > generic issues with drive access, the possibilities for this issue > could be: > > > > 1) No cable and/or drive cabinet domain validation, so one might have to > > roll the SCSI speed down a bit to compensate for cable and/or drive > > combination issues. > > 2) Some drives are more comfortable with either over (more than just > the two > > endpoints) or under (only the last drive or controller) termination. > > 3) Contact tech support for a later Firmware release, there may be known > > issues with your drives, cabinets and/or drive combinations that might have > > been addressed with either drive firmware, or controller firmware updates. > > Currently the customer has better access to Technical Support than I do at > > this moment :-( even though I virtually end up driving over top them each > > morning as I head to the parking lot ... > > > > In any case, I will report this to the Firmware engineers to see if they > > have any additional comments to add about this issue. > > > > Keep in mind that at initial negotiation, the speed is lower, the transfers > > less stressful, than at operating system time. Edge issues may surface as a > > result, sometimes appearing different from OS to OS. For instance, I > believe > > the ASR driver can request up to 58 (~4KB) scatter/gather elements in one > > request, allowing up to 256 requests/device. NT's scsiport driver, on the > > other hand, limits request to 64KB/each and only 16 requests/controller. > > Stresses vary. > > > > However, OS issues do not typically affect drive failures, which is > curious. > > I have an issue that comes up in FreeBSD, for instance, with the array > > performance in an impacted (read failures do not fail an array since data > > can be reconstructed) state since the requests take much longer to fulfill > > than in the genuine failed state. Impacted means every request still tries > > to be fulfilled by first trying to talk to the not-yet failed component. > > This has the catch-22 effect of not being able to mount the array head due > > to the protracted responses on some failed drive scenarios before the > > adapter has considered the component to be marked as failed. Pulling the > > errant drive might be the only way. Later adapter Firmware may deal with > > this through careful consideration of request response time. Tech support > > may supply a select fail-on-read firmware/NVRAM, or one can chose to > bump up > > the timeout in the SCSI layer. This issue, for instance, does not occur > > under Solaris because their SCSI layer is set to 2 minute timeouts. > > > > Sincerely -- Mark Salyzyn > > > > -----Original Message----- > > From: Mike Smith [mailto:msmith@freebsd.org] > > Sent: Monday, December 18, 2000 5:37 AM > > To: Micah Anderson > > Cc: noah; freebsd-scsi@freebsd.org; mark_salyzyn@adaptec.com > > Subject: Re: update > > > > > > > > Mark; I miscopied you on my previous reply to this message, sorry about > > that. Do you have any ideas? > > > > > On Sat, 16 Dec 2000, Mike Smith wrote: > > > > > > > > At "asr0: major=154" the raid card begins a high pitched beep > > indicating > > > > > that two of the drives have failed and that a rebuild of the raid is > > > > > required, but we've tested all of the drives and replaced the raid > > card > > > > > with a new one, and still get the same problem. The reason I'm asking > > > > > about possible software issues is that other OS's have worked on this > > raid > > > > > setup. > > > > > > > > I've copied Mark at Adaptec, who is the author and principle > maintainer > > > > of the 'asr' driver, since he's going to have the best idea of what's > > > > actually going on here. Without saying which OS' you've used, it's > > tough > > > > to know whether they simply aren't enabling the card alarm though. > > > > > > We have gone through exhaustive troubleshooting lengths to try to > > determine > > > what the problem is. I have swapped RAID cards, swapped cables, tried a > > > different motherboard, different powersupply in every possible > combination > > > of configuration. Each time I have to start from the beginning, > destroying > > > the RAID configuration and then creating a new one, which takes over an > > > hour, so this process has taken literally three weeks to try all the > > > potential configurations. > > > > > > The RAID alarm goes off on the card during the FreeBSD boot process, the > > OS > > > continues to boot, but the alarm continues. Rebooting and going into the > > > Adaptec setup tells us that a drive has failed, it is not the same drive > > > every time. During bootup after the RAID POST when the SMOR utility is > > > loading it will usually show the RAID-5 drive as well as the single > drive. > > > It is almost as if one of the drives of the RAID is pushed out of the > > RAID. > > > Individually, each drive works fine. If I install FreeBSD on a single > > drive, > > > without a RAID constructed things act as normal. These are IBM 10k RPM > > LVD > > > drives and I ran IBM's drive test utility on each one of them and it came > > > back with no errors. > > > > > > I have been able to install Debian Linux and use the card/drives without > > > this problem. I have called Adaptec to ask them about this and was > told to > > > try changing the drive speed from Ultra 3 to Ultra as well as change the > > > delay from the default to 30 seconds, all of these do not change the > > > behavior whatsoever. > > > > > > I have spoken with one other person who had a similar type of problem, > > > except what was happening to him was he was loading some DOS drivers, one > > of > > > which would wipe the RAID card configuration when it was loaded (ASAPI? I > > > can't recall right now)... I am wondering if there are some other drivers > > > that are being probed in the generic FreeBSD kernel that are doing a > > similar > > > thing to the config. > > > > > > > > > > > Have you tried running the Adaptec management software to check the > > > > status of the card? > > > > > > In FreeBSD? If there is such a thing it would be interesting to know > where > > > one could get it. The CD that was included with the card has no FreeBSD > > > anything on it - the website has no FreeBSD information or downloads > on it > > > (except for the breif mention that it is supported, but if you call for > > > support you can't get it). Or are you talking about the SMOR utility that > > > you can access from the BIOS? > > > > > > Thanks for any help that you can offer. > > > > > > Micah > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > On 12/15, Mike Smith wrote: > > > > > > > > > > > > > Hi, I'm working on trying to install FreeBSD 4.2 on a dual p3 700 > > with > > > > > > > an Adaptec 3200S raid card. From what I can tell everyone > that has > > tried > > > > > > > this card has had good luck. When we install FreeBSD (booting off > > cd) it > > > > > > > recognizes the card and installs on it perfectly, but when it > > loads the OS > > > > > > > off the raid it does something to damage the hardware raid, > > requiring us > > > > > > > to rebuild the RAID in the 3200S' bios. We're pretty sure that > > this isn't > > > > > > > a hardware problem. > > > > > > > > > > > > You haven't actually included anything that suggests that > there's a > > > > > > problem occurring, so it's somewhat difficult to guess what's going > > on. > > > > > > > > > > > > However, I don't lend much credibility to the suggestion that > > "FreeBSD > > > > > > does something to damage the hadware raid" - things just don't > > happen > > > > > > like that. > > > > > > > > > > > > I would be inclined to suspect that you probably have a suspect > > disk, or > > > > > > cabling/enclosure problems, but without more details it's hard > to be > > sure. > > > > > > > > > > > > > > > > > > -- > > > > > > ... every activity meets with opposition, everyone who acts has his > > > > > > rivals and unfortunately opponents also. But not because people > > want > > > > > > to be opponents, rather because the tasks and relationships force > > > > > > people to take different points of view. [Dr. Fritz Todt] > > > > > > V I C T O R Y N O T V E N G E A N C E > > > > > > > > > > > > > > > > > > > > > > -- > > > > > noah .. email for pgp/gpg key > > > > > > > > > > > > > -- > > > > ... every activity meets with opposition, everyone who acts has his > > > > rivals and unfortunately opponents also. But not because people want > > > > to be opponents, rather because the tasks and relationships force > > > > people to take different points of view. [Dr. Fritz Todt] > > > > V I C T O R Y N O T V E N G E A N C E > > > > > > > > > > > > > > > -- > > ... every activity meets with opposition, everyone who acts has his > > rivals and unfortunately opponents also. But not because people want > > to be opponents, rather because the tasks and relationships force > > people to take different points of view. [Dr. Fritz Todt] > > V I C T O R Y N O T V E N G E A N C E > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-scsi" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jan 5 9:46: 5 2001 From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 5 09:45:56 2001 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from riseup.net (riseup.net [216.162.197.233]) by hub.freebsd.org (Postfix) with ESMTP id 8CED237B400; Fri, 5 Jan 2001 09:45:55 -0800 (PST) Received: from micah by riseup.net with local (Exim 3.12 #1 (Debian)) id 14Eavh-0003a1-00; Fri, 05 Jan 2001 09:45:29 -0800 Date: Fri, 5 Jan 2001 09:45:29 -0800 From: Micah Anderson To: Chris Snell Cc: Micah Anderson , "Salyzyn, Mark" , 'Mike Smith' , noah , freebsd-scsi@freebsd.org Subject: Re: update Message-ID: <20010105094529.P7852@riseup.net> References: <50DB155AD0CED411988E009027D61DB31D8116@otcexc01.otc.adaptec.com> <50DB155AD0CED411988E009027D61DB31D8116@otcexc01.otc.adaptec.com> <20001226152519.X10704@riseup.net> <4.3.2.7.2.20010104184802.019766c8@shrubbery.satx.bikeworld.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010104184802.019766c8@shrubbery.satx.bikeworld.net>; from chris@bikeworld.com on Thu, Jan 04, 2001 at 06:51:06PM -0600 Sender: Micah Anderson Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chris, I would be interested in seeing your kernel config so I could comapre it to the one I made. When I tried the card in a different machine that machine had a totally different motherboard and BIOS. I have been finding that Debian does work, but it is sensitive. For example, if I try to boot from the RAID I get the same behavior, but if I boot from a separate IDE drive and just mount the raid partitions things are fine. I have a feeling that perhaps there is a RAID header at the beginning of the logicial volume that can be overwritten by a master boot record or a boot loader like Lilo, or Grub, or the FreeBSD loader...? Micah On Thu, 04 Jan 2001, Chris Snell wrote: > > Micah, > > Would it be of any help if I sent you the kernel config for our server that > has one of these cards in it? As I said earlier, it's been working great > for us. Also, when you tried this card in a different machine, did that > machine have the same motherboard and BIOS? You mentioned that Debian > works on your setup. Did you try installing it (Debian) and then hammering > on the disks or did you just verify that it installed? > > Chris > > At 03:25 PM 12/26/2000 -0800, Micah Anderson wrote: > >So I have tried pretty much everything, the alarm still goes off at the same > >time during boot up, at asr0: major=154. I am trying a last experiment > >today, if it doesn't work, I am sad to say that I am going to have to use > >Debian since it works fine there. I have had this server for over a month > >trying everything on the planet to get it to work, we need this server > >running in a bad way and although I want to go with FreeBSD we unfortunately > >are going to have to go with what works. > > > >Right now I am trying to recompile the kernel by pulling everything out of > >the config file, except what is needed. It seems as if the problem has to do > >with the FreeBSD scsi or asr driver. Because thats when things go, and if I > >can boot off the CD without this happening, then something is funky. > > > >I was called by Ida at Adaptec to follow up on the call that I originally > >placed, ID #2843, but I was given the wrong number to call her back. > > > >I've done practically everything in my power, besides getting a job at > >adaptec or delving into the FreeBSD driver code, neither of which I can do > >at this point. Do you guys have any other ideas, or suggestions where to go > >next? > > > >Just a reminder, this is an adaptec 3200s, using freebsd 4.2, 4 IBM 9 gig > >10,000 RPM LVD drives making up a Raid-5, using a nice Intel motherboard > >(which has another adaptec on board controller, but I've tried the card in a > >different machine with the drives, same results).... > > > >Micah > > > > > > > >On Mon, 18 Dec 2000, Salyzyn, Mark wrote: > > > > > Although I figure Adaptec's Tech Support would be the best to know about > > > generic issues with drive access, the possibilities for this issue > > could be: > > > > > > 1) No cable and/or drive cabinet domain validation, so one might have to > > > roll the SCSI speed down a bit to compensate for cable and/or drive > > > combination issues. > > > 2) Some drives are more comfortable with either over (more than just > > the two > > > endpoints) or under (only the last drive or controller) termination. > > > 3) Contact tech support for a later Firmware release, there may be known > > > issues with your drives, cabinets and/or drive combinations that might have > > > been addressed with either drive firmware, or controller firmware updates. > > > Currently the customer has better access to Technical Support than I do at > > > this moment :-( even though I virtually end up driving over top them each > > > morning as I head to the parking lot ... > > > > > > In any case, I will report this to the Firmware engineers to see if they > > > have any additional comments to add about this issue. > > > > > > Keep in mind that at initial negotiation, the speed is lower, the transfers > > > less stressful, than at operating system time. Edge issues may surface as a > > > result, sometimes appearing different from OS to OS. For instance, I > > believe > > > the ASR driver can request up to 58 (~4KB) scatter/gather elements in one > > > request, allowing up to 256 requests/device. NT's scsiport driver, on the > > > other hand, limits request to 64KB/each and only 16 requests/controller. > > > Stresses vary. > > > > > > However, OS issues do not typically affect drive failures, which is > > curious. > > > I have an issue that comes up in FreeBSD, for instance, with the array > > > performance in an impacted (read failures do not fail an array since data > > > can be reconstructed) state since the requests take much longer to fulfill > > > than in the genuine failed state. Impacted means every request still tries > > > to be fulfilled by first trying to talk to the not-yet failed component. > > > This has the catch-22 effect of not being able to mount the array head due > > > to the protracted responses on some failed drive scenarios before the > > > adapter has considered the component to be marked as failed. Pulling the > > > errant drive might be the only way. Later adapter Firmware may deal with > > > this through careful consideration of request response time. Tech support > > > may supply a select fail-on-read firmware/NVRAM, or one can chose to > > bump up > > > the timeout in the SCSI layer. This issue, for instance, does not occur > > > under Solaris because their SCSI layer is set to 2 minute timeouts. > > > > > > Sincerely -- Mark Salyzyn > > > > > > -----Original Message----- > > > From: Mike Smith [mailto:msmith@freebsd.org] > > > Sent: Monday, December 18, 2000 5:37 AM > > > To: Micah Anderson > > > Cc: noah; freebsd-scsi@freebsd.org; mark_salyzyn@adaptec.com > > > Subject: Re: update > > > > > > > > > > > > Mark; I miscopied you on my previous reply to this message, sorry about > > > that. Do you have any ideas? > > > > > > > On Sat, 16 Dec 2000, Mike Smith wrote: > > > > > > > > > > At "asr0: major=154" the raid card begins a high pitched beep > > > indicating > > > > > > that two of the drives have failed and that a rebuild of the raid is > > > > > > required, but we've tested all of the drives and replaced the raid > > > card > > > > > > with a new one, and still get the same problem. The reason I'm asking > > > > > > about possible software issues is that other OS's have worked on this > > > raid > > > > > > setup. > > > > > > > > > > I've copied Mark at Adaptec, who is the author and principle > > maintainer > > > > > of the 'asr' driver, since he's going to have the best idea of what's > > > > > actually going on here. Without saying which OS' you've used, it's > > > tough > > > > > to know whether they simply aren't enabling the card alarm though. > > > > > > > > We have gone through exhaustive troubleshooting lengths to try to > > > determine > > > > what the problem is. I have swapped RAID cards, swapped cables, tried a > > > > different motherboard, different powersupply in every possible > > combination > > > > of configuration. Each time I have to start from the beginning, > > destroying > > > > the RAID configuration and then creating a new one, which takes over an > > > > hour, so this process has taken literally three weeks to try all the > > > > potential configurations. > > > > > > > > The RAID alarm goes off on the card during the FreeBSD boot process, the > > > OS > > > > continues to boot, but the alarm continues. Rebooting and going into the > > > > Adaptec setup tells us that a drive has failed, it is not the same drive > > > > every time. During bootup after the RAID POST when the SMOR utility is > > > > loading it will usually show the RAID-5 drive as well as the single > > drive. > > > > It is almost as if one of the drives of the RAID is pushed out of the > > > RAID. > > > > Individually, each drive works fine. If I install FreeBSD on a single > > > drive, > > > > without a RAID constructed things act as normal. These are IBM 10k RPM > > > LVD > > > > drives and I ran IBM's drive test utility on each one of them and it came > > > > back with no errors. > > > > > > > > I have been able to install Debian Linux and use the card/drives without > > > > this problem. I have called Adaptec to ask them about this and was > > told to > > > > try changing the drive speed from Ultra 3 to Ultra as well as change the > > > > delay from the default to 30 seconds, all of these do not change the > > > > behavior whatsoever. > > > > > > > > I have spoken with one other person who had a similar type of problem, > > > > except what was happening to him was he was loading some DOS drivers, one > > > of > > > > which would wipe the RAID card configuration when it was loaded (ASAPI? I > > > > can't recall right now)... I am wondering if there are some other drivers > > > > that are being probed in the generic FreeBSD kernel that are doing a > > > similar > > > > thing to the config. > > > > > > > > > > > > > > Have you tried running the Adaptec management software to check the > > > > > status of the card? > > > > > > > > In FreeBSD? If there is such a thing it would be interesting to know > > where > > > > one could get it. The CD that was included with the card has no FreeBSD > > > > anything on it - the website has no FreeBSD information or downloads > > on it > > > > (except for the breif mention that it is supported, but if you call for > > > > support you can't get it). Or are you talking about the SMOR utility that > > > > you can access from the BIOS? > > > > > > > > Thanks for any help that you can offer. > > > > > > > > Micah > > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > On 12/15, Mike Smith wrote: > > > > > > > > > > > > > > > Hi, I'm working on trying to install FreeBSD 4.2 on a dual p3 700 > > > with > > > > > > > > an Adaptec 3200S raid card. From what I can tell everyone > > that has > > > tried > > > > > > > > this card has had good luck. When we install FreeBSD (booting off > > > cd) it > > > > > > > > recognizes the card and installs on it perfectly, but when it > > > loads the OS > > > > > > > > off the raid it does something to damage the hardware raid, > > > requiring us > > > > > > > > to rebuild the RAID in the 3200S' bios. We're pretty sure that > > > this isn't > > > > > > > > a hardware problem. > > > > > > > > > > > > > > You haven't actually included anything that suggests that > > there's a > > > > > > > problem occurring, so it's somewhat difficult to guess what's going > > > on. > > > > > > > > > > > > > > However, I don't lend much credibility to the suggestion that > > > "FreeBSD > > > > > > > does something to damage the hadware raid" - things just don't > > > happen > > > > > > > like that. > > > > > > > > > > > > > > I would be inclined to suspect that you probably have a suspect > > > disk, or > > > > > > > cabling/enclosure problems, but without more details it's hard > > to be > > > sure. > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > ... every activity meets with opposition, everyone who acts has his > > > > > > > rivals and unfortunately opponents also. But not because people > > > want > > > > > > > to be opponents, rather because the tasks and relationships force > > > > > > > people to take different points of view. [Dr. Fritz Todt] > > > > > > > V I C T O R Y N O T V E N G E A N C E > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > noah .. email for pgp/gpg key > > > > > > > > > > > > > > > > -- > > > > > ... every activity meets with opposition, everyone who acts has his > > > > > rivals and unfortunately opponents also. But not because people want > > > > > to be opponents, rather because the tasks and relationships force > > > > > people to take different points of view. [Dr. Fritz Todt] > > > > > V I C T O R Y N O T V E N G E A N C E > > > > > > > > > > > > > > > > > > > > -- > > > ... every activity meets with opposition, everyone who acts has his > > > rivals and unfortunately opponents also. But not because people want > > > to be opponents, rather because the tasks and relationships force > > > people to take different points of view. [Dr. Fritz Todt] > > > V I C T O R Y N O T V E N G E A N C E > > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jan 5 10:18:33 2001 From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 5 10:18:24 2001 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by hub.freebsd.org (Postfix) with ESMTP id CAA7137B400; Fri, 5 Jan 2001 10:18:23 -0800 (PST) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id KAA05436; Fri, 5 Jan 2001 10:18:22 -0800 (PST) Received: from otcexc01.otc.adaptec.com ([10.12.1.27]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id KAA12953; Fri, 5 Jan 2001 10:12:08 -0800 (PST) Received: by otcexc01.otc.adaptec.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Jan 2001 13:18:25 -0500 Message-ID: <50DB155AD0CED411988E009027D61DB31D816D@otcexc01.otc.adaptec.com> From: "Salyzyn, Mark" To: "'Micah Anderson'" , Chris Snell Cc: "'Mike Smith'" , noah , freebsd-scsi@freebsd.org, "Robinson, Kimberly" Subject: RE: update Date: Fri, 5 Jan 2001 13:18:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I feel this *must* be a controller firmware issue. To resolve this, our technical support department is going to need to duplicate this problem so our Firmware engineers can understand why the drives are going offline. It Feels like the combination of Hardware is making the Firmware `brittle' where subtle changes cause the issues to come and go. The controller Firmware contains *all* the smarts associated with the SCSI bus communications. Technical support may be able to supply you a different hardware versioned card with debugging (UART 115200 Baud) port installed to capture the needed information to resolve this. IMHO, this is the *best* way to resolve this to fruition. You have effectively swapped enough things around to have isolated away the hardware domain validation possibilities. In any case, escalating this to Adaptec Technical support to see if they have any other practical ideas. Sincerely -- Mark Salyzyn -----Original Message----- From: Micah Anderson [mailto:micah@indymedia.org] Sent: Friday, January 05, 2001 12:45 PM To: Chris Snell Cc: Micah Anderson; Salyzyn, Mark; 'Mike Smith'; noah; freebsd-scsi@freebsd.org Subject: Re: update Chris, I would be interested in seeing your kernel config so I could comapre it to the one I made. When I tried the card in a different machine that machine had a totally different motherboard and BIOS. I have been finding that Debian does work, but it is sensitive. For example, if I try to boot from the RAID I get the same behavior, but if I boot from a separate IDE drive and just mount the raid partitions things are fine. I have a feeling that perhaps there is a RAID header at the beginning of the logicial volume that can be overwritten by a master boot record or a boot loader like Lilo, or Grub, or the FreeBSD loader...? Micah On Thu, 04 Jan 2001, Chris Snell wrote: > > Micah, > > Would it be of any help if I sent you the kernel config for our server that > has one of these cards in it? As I said earlier, it's been working great > for us. Also, when you tried this card in a different machine, did that > machine have the same motherboard and BIOS? You mentioned that Debian > works on your setup. Did you try installing it (Debian) and then hammering > on the disks or did you just verify that it installed? > > Chris > > At 03:25 PM 12/26/2000 -0800, Micah Anderson wrote: > >So I have tried pretty much everything, the alarm still goes off at the same > >time during boot up, at asr0: major=154. I am trying a last experiment > >today, if it doesn't work, I am sad to say that I am going to have to use > >Debian since it works fine there. I have had this server for over a month > >trying everything on the planet to get it to work, we need this server > >running in a bad way and although I want to go with FreeBSD we unfortunately > >are going to have to go with what works. > > > >Right now I am trying to recompile the kernel by pulling everything out of > >the config file, except what is needed. It seems as if the problem has to do > >with the FreeBSD scsi or asr driver. Because thats when things go, and if I > >can boot off the CD without this happening, then something is funky. > > > >I was called by Ida at Adaptec to follow up on the call that I originally > >placed, ID #2843, but I was given the wrong number to call her back. > > > >I've done practically everything in my power, besides getting a job at > >adaptec or delving into the FreeBSD driver code, neither of which I can do > >at this point. Do you guys have any other ideas, or suggestions where to go > >next? > > > >Just a reminder, this is an adaptec 3200s, using freebsd 4.2, 4 IBM 9 gig > >10,000 RPM LVD drives making up a Raid-5, using a nice Intel motherboard > >(which has another adaptec on board controller, but I've tried the card in a > >different machine with the drives, same results).... > > > >Micah > > > > > > > >On Mon, 18 Dec 2000, Salyzyn, Mark wrote: > > > > > Although I figure Adaptec's Tech Support would be the best to know about > > > generic issues with drive access, the possibilities for this issue > > could be: > > > > > > 1) No cable and/or drive cabinet domain validation, so one might have to > > > roll the SCSI speed down a bit to compensate for cable and/or drive > > > combination issues. > > > 2) Some drives are more comfortable with either over (more than just > > the two > > > endpoints) or under (only the last drive or controller) termination. > > > 3) Contact tech support for a later Firmware release, there may be known > > > issues with your drives, cabinets and/or drive combinations that might have > > > been addressed with either drive firmware, or controller firmware updates. > > > Currently the customer has better access to Technical Support than I do at > > > this moment :-( even though I virtually end up driving over top them each > > > morning as I head to the parking lot ... > > > > > > In any case, I will report this to the Firmware engineers to see if they > > > have any additional comments to add about this issue. > > > > > > Keep in mind that at initial negotiation, the speed is lower, the transfers > > > less stressful, than at operating system time. Edge issues may surface as a > > > result, sometimes appearing different from OS to OS. For instance, I > > believe > > > the ASR driver can request up to 58 (~4KB) scatter/gather elements in one > > > request, allowing up to 256 requests/device. NT's scsiport driver, on the > > > other hand, limits request to 64KB/each and only 16 requests/controller. > > > Stresses vary. > > > > > > However, OS issues do not typically affect drive failures, which is > > curious. > > > I have an issue that comes up in FreeBSD, for instance, with the array > > > performance in an impacted (read failures do not fail an array since data > > > can be reconstructed) state since the requests take much longer to fulfill > > > than in the genuine failed state. Impacted means every request still tries > > > to be fulfilled by first trying to talk to the not-yet failed component. > > > This has the catch-22 effect of not being able to mount the array head due > > > to the protracted responses on some failed drive scenarios before the > > > adapter has considered the component to be marked as failed. Pulling the > > > errant drive might be the only way. Later adapter Firmware may deal with > > > this through careful consideration of request response time. Tech support > > > may supply a select fail-on-read firmware/NVRAM, or one can chose to > > bump up > > > the timeout in the SCSI layer. This issue, for instance, does not occur > > > under Solaris because their SCSI layer is set to 2 minute timeouts. > > > > > > Sincerely -- Mark Salyzyn > > > > > > -----Original Message----- > > > From: Mike Smith [mailto:msmith@freebsd.org] > > > Sent: Monday, December 18, 2000 5:37 AM > > > To: Micah Anderson > > > Cc: noah; freebsd-scsi@freebsd.org; mark_salyzyn@adaptec.com > > > Subject: Re: update > > > > > > > > > > > > Mark; I miscopied you on my previous reply to this message, sorry about > > > that. Do you have any ideas? > > > > > > > On Sat, 16 Dec 2000, Mike Smith wrote: > > > > > > > > > > At "asr0: major=154" the raid card begins a high pitched beep > > > indicating > > > > > > that two of the drives have failed and that a rebuild of the raid is > > > > > > required, but we've tested all of the drives and replaced the raid > > > card > > > > > > with a new one, and still get the same problem. The reason I'm asking > > > > > > about possible software issues is that other OS's have worked on this > > > raid > > > > > > setup. > > > > > > > > > > I've copied Mark at Adaptec, who is the author and principle > > maintainer > > > > > of the 'asr' driver, since he's going to have the best idea of what's > > > > > actually going on here. Without saying which OS' you've used, it's > > > tough > > > > > to know whether they simply aren't enabling the card alarm though. > > > > > > > > We have gone through exhaustive troubleshooting lengths to try to > > > determine > > > > what the problem is. I have swapped RAID cards, swapped cables, tried a > > > > different motherboard, different powersupply in every possible > > combination > > > > of configuration. Each time I have to start from the beginning, > > destroying > > > > the RAID configuration and then creating a new one, which takes over an > > > > hour, so this process has taken literally three weeks to try all the > > > > potential configurations. > > > > > > > > The RAID alarm goes off on the card during the FreeBSD boot process, the > > > OS > > > > continues to boot, but the alarm continues. Rebooting and going into the > > > > Adaptec setup tells us that a drive has failed, it is not the same drive > > > > every time. During bootup after the RAID POST when the SMOR utility is > > > > loading it will usually show the RAID-5 drive as well as the single > > drive. > > > > It is almost as if one of the drives of the RAID is pushed out of the > > > RAID. > > > > Individually, each drive works fine. If I install FreeBSD on a single > > > drive, > > > > without a RAID constructed things act as normal. These are IBM 10k RPM > > > LVD > > > > drives and I ran IBM's drive test utility on each one of them and it came > > > > back with no errors. > > > > > > > > I have been able to install Debian Linux and use the card/drives without > > > > this problem. I have called Adaptec to ask them about this and was > > told to > > > > try changing the drive speed from Ultra 3 to Ultra as well as change the > > > > delay from the default to 30 seconds, all of these do not change the > > > > behavior whatsoever. > > > > > > > > I have spoken with one other person who had a similar type of problem, > > > > except what was happening to him was he was loading some DOS drivers, one > > > of > > > > which would wipe the RAID card configuration when it was loaded (ASAPI? I > > > > can't recall right now)... I am wondering if there are some other drivers > > > > that are being probed in the generic FreeBSD kernel that are doing a > > > similar > > > > thing to the config. > > > > > > > > > > > > > > Have you tried running the Adaptec management software to check the > > > > > status of the card? > > > > > > > > In FreeBSD? If there is such a thing it would be interesting to know > > where > > > > one could get it. The CD that was included with the card has no FreeBSD > > > > anything on it - the website has no FreeBSD information or downloads > > on it > > > > (except for the breif mention that it is supported, but if you call for > > > > support you can't get it). Or are you talking about the SMOR utility that > > > > you can access from the BIOS? > > > > > > > > Thanks for any help that you can offer. > > > > > > > > Micah > > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > On 12/15, Mike Smith wrote: > > > > > > > > > > > > > > > Hi, I'm working on trying to install FreeBSD 4.2 on a dual p3 700 > > > with > > > > > > > > an Adaptec 3200S raid card. From what I can tell everyone > > that has > > > tried > > > > > > > > this card has had good luck. When we install FreeBSD (booting off > > > cd) it > > > > > > > > recognizes the card and installs on it perfectly, but when it > > > loads the OS > > > > > > > > off the raid it does something to damage the hardware raid, > > > requiring us > > > > > > > > to rebuild the RAID in the 3200S' bios. We're pretty sure that > > > this isn't > > > > > > > > a hardware problem. > > > > > > > > > > > > > > You haven't actually included anything that suggests that > > there's a > > > > > > > problem occurring, so it's somewhat difficult to guess what's going > > > on. > > > > > > > > > > > > > > However, I don't lend much credibility to the suggestion that > > > "FreeBSD > > > > > > > does something to damage the hadware raid" - things just don't > > > happen > > > > > > > like that. > > > > > > > > > > > > > > I would be inclined to suspect that you probably have a suspect > > > disk, or > > > > > > > cabling/enclosure problems, but without more details it's hard > > to be > > > sure. > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > ... every activity meets with opposition, everyone who acts has his > > > > > > > rivals and unfortunately opponents also. But not because people > > > want > > > > > > > to be opponents, rather because the tasks and relationships force > > > > > > > people to take different points of view. [Dr. Fritz Todt] > > > > > > > V I C T O R Y N O T V E N G E A N C E > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > noah .. email for pgp/gpg key > > > > > > > > > > > > > > > > -- > > > > > ... every activity meets with opposition, everyone who acts has his > > > > > rivals and unfortunately opponents also. But not because people want > > > > > to be opponents, rather because the tasks and relationships force > > > > > people to take different points of view. [Dr. Fritz Todt] > > > > > V I C T O R Y N O T V E N G E A N C E > > > > > > > > > > > > > > > > > > > > -- > > > ... every activity meets with opposition, everyone who acts has his > > > rivals and unfortunately opponents also. But not because people want > > > to be opponents, rather because the tasks and relationships force > > > people to take different points of view. [Dr. Fritz Todt] > > > V I C T O R Y N O T V E N G E A N C E > > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 6 10:46:22 2001 From owner-freebsd-scsi@FreeBSD.ORG Sat Jan 6 10:46:20 2001 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (SHW2-220.accesscable.net [24.71.145.220]) by hub.freebsd.org (Postfix) with ESMTP id 6006337B402 for ; Sat, 6 Jan 2001 10:46:19 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id f06Iisf16143 for ; Sat, 6 Jan 2001 14:44:54 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Sat, 6 Jan 2001 14:44:54 -0400 (AST) From: The Hermit Hacker To: Subject: parity error detected in ... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org newest 4.2-STABLE kernel, two scsi bus, 3 drives each ... and i'm getting the following: Jan 6 14:27:54 poseidon /kernel: ahc0:A:0: parity error detected in Message-in phase. SEQADDR(0x121) SCSIRATE(0x0) Jan 6 14:27:54 poseidon /kernel: ahc0:A:0: parity error detected in Message-in phase. SEQADDR(0x121) SCSIRATE(0x0) Jan 6 14:28:09 poseidon /kernel: (ahc0:A:0:0): refuses tagged commands. Performing non-tagged I/O Jan 6 14:28:09 poseidon /kernel: (ahc0:A:0:0): refuses tagged commands. Performing non-tagged I/O Jan 6 14:28:09 poseidon /kernel: ahc0:A:0: Target did not send an IDENTIFY message. LASTPHASE = 0x0, SAVED_SCSIID == 0x7 Jan 6 14:28:09 poseidon /kernel: ahc0:A:0: Target did not send an IDENTIFY message. LASTPHASE = 0x0, SAVED_SCSIID == 0x7 Jan 6 14:28:09 poseidon /kernel: ahc0: Issued Channel A Bus Reset. 64 SCBs aborted Jan 6 14:28:09 poseidon /kernel: ahc0: Issued Channel A Bus Reset. 64 SCBs aborted up until the other day, that machine was running 2 scsi buses, with 1 9gig drive per bus, and 4 4gig ... we removed the 4 4gig per bus and swapped in 2x9gig, and now I'm starting to get the above ... I have the Adaptec's throttled down to 20Mb/s vs the max at 40 on these ... the adaptec controllers are: ahc0: port 0x7000-0x70ff mem 0x80300000-0x80300fff irq 12 at device 17.0 on pci0 aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: port 0x7400-0x74ff mem 0x80301000-0x80301fff irq 11 at device 18.0 on pci0 aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs and the drives are all Quantum Atlas V's: da0: Fixed Direct Access SCSI-3 device da1: Fixed Direct Access SCSI-3 device da2: Fixed Direct Access SCSI-3 device da3: Fixed Direct Access SCSI-3 device da4: Fixed Direct Access SCSI-3 device da5: Fixed Direct Access SCSI-3 device da[1234] were installed this week ... da[05] Q3 of last year ... thanks ... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 6 11:57:27 2001 From owner-freebsd-scsi@FreeBSD.ORG Sat Jan 6 11:57:24 2001 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from boat.mail.pipex.net (our.mail.pipex.net [158.43.128.75]) by hub.freebsd.org (Postfix) with SMTP id 1290737B400 for ; Sat, 6 Jan 2001 11:57:24 -0800 (PST) Received: (qmail 27884 invoked from network); 6 Jan 2001 19:57:23 -0000 Received: from mailhost.puck.pipex.net (HELO mailhost.uk.internal) (194.130.147.54) by our.mail.pipex.net with SMTP; 6 Jan 2001 19:57:23 -0000 Received: (qmail 7329 invoked from network); 6 Jan 2001 19:57:22 -0000 Received: from yukon.cam.uk.internal (172.31.3.155) by mailhost.uk.internal with SMTP; 6 Jan 2001 19:57:22 -0000 Date: Sat, 6 Jan 2001 19:57:23 +0000 (GMT) From: Darren Joy X-Sender: darrenj@yukon.cam.uk.internal To: freebsd-scsi@freebsd.org Subject: Continuing Problems with DC390W and 4.2 Release Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I wrote to this list at the end of November with a problem I was having with 4.2 Release and my Tekram DC390W. I had the machine running 3.2 Release happily, without any problems. Then as I reinstalled with 4.2, I found that the machine would lock up with errors reported from the SYM driver. I have revisited this hardware now with the intention of getting it running rather than sitting there switched off. I want my machine back! In response to my last post, Gerard suggested a using the "ncr" driver instead of "sym", as this was the one used in 3.2. By doing a 4.2 install, and omitting the ports and src, I managed to get FreeBSD installed on this machine before it locked up. Then post installation, added the sources distribution and made my custom kernel using the "ncr" driver. Alas, I am still seeing problems, the symptoms being the same as those experienced with the "sym" driver. If I try to install the ports distibution, I get the following errors : ncr0: queue empty ncr0: queue empty ncr0: queue empty ncr0: queue empty A colleague once suggested to me that disabling Tagged Command Queueing could help. This I did in the controller BIOS, however upon bootup I see : /kernel: ncr0: port 0xe400-0xe4ff mem 0xeb001000-0xeb001fff,0xeb000000-0xeb0000f f irq 15 at device 15.0 on pci0 /kernel: da0 at ncr0 bus 0 target 0 lun 0 /kernel: da0: Fixed Direct Access SCSI-2 device /kernel: da0: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled /kernel: da0: 2048MB (4194304 512 byte sectors: 255H 63S/T 261C) My thinking here is that disabling Tagged Command Queueing may cure my woes, but FreeBSD seems to be enabling it regardless! I have double-checked the controller BIOS, and Tagged Command Queueing is definitely disabled for this device ( there's no option to disable it globally ), indeed, disabled for every individual device. I even tried reducing the queue length to the minimum setting allowed in the BIOS, but to no avail. And of course, I have tried it with Tagged Queueing enabled. Can anyone offer any help as to how I might get the NCR ( or SYM ) to disable Tagged Command Queueing? Any ideas appreciated. Regards -- Darren Joy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 6 15:43:48 2001 From owner-freebsd-scsi@FreeBSD.ORG Sat Jan 6 15:43:46 2001 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 5F02F37B400 for ; Sat, 6 Jan 2001 15:43:45 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA26504; Sat, 6 Jan 2001 16:43:30 -0700 (MST) (envelope-from ken) Date: Sat, 6 Jan 2001 16:43:30 -0700 From: "Kenneth D. Merry" To: Darren Joy Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Continuing Problems with DC390W and 4.2 Release Message-ID: <20010106164330.A26365@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from darrenj@uk.uu.net on Sat, Jan 06, 2001 at 07:57:23PM +0000 Sender: ken@panzer.kdm.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jan 06, 2001 at 19:57:23 +0000, Darren Joy wrote: [ ... ] > A colleague once suggested to me that disabling Tagged Command Queueing > could help. This I did in the controller BIOS, however upon bootup I see : > > /kernel: ncr0: port 0xe400-0xe4ff mem > 0xeb001000-0xeb001fff,0xeb000000-0xeb0000f > f irq 15 at device 15.0 on pci0 > > /kernel: da0 at ncr0 bus 0 target 0 lun 0 > /kernel: da0: Fixed Direct Access SCSI-2 device > /kernel: da0: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled > /kernel: da0: 2048MB (4194304 512 byte sectors: 255H 63S/T 261C) > > My thinking here is that disabling Tagged Command Queueing may cure my > woes, but FreeBSD seems to be enabling it regardless! > > I have double-checked the controller BIOS, and Tagged Command Queueing is > definitely disabled for this device ( there's no option to disable it > globally ), indeed, disabled for every individual device. I even tried > reducing the queue length to the minimum setting allowed in the BIOS, but > to no avail. And of course, I have tried it with Tagged Queueing enabled. > > Can anyone offer any help as to how I might get the NCR ( or SYM ) to > disable Tagged Command Queueing? If you want to disable tagged queueing temporarily: camcontrol negotiate da0 -v -T disable -a If you want to do it permanantly: echo "DQue: 1" | camcontrol modepage da0 -m 10 -P 3 -e You may have to reboot the machine after changing the mode page in order for the kernel to recognize the change. (Tagged queueing will be disabled for any given boot with the first command.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 6 15:46:22 2001 From owner-freebsd-scsi@FreeBSD.ORG Sat Jan 6 15:46:20 2001 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mail1.rdc1.az.home.com (mail1.rdc1.az.home.com [24.1.240.75]) by hub.freebsd.org (Postfix) with ESMTP id C73D637B400 for ; Sat, 6 Jan 2001 15:46:20 -0800 (PST) Received: from nordec ([24.177.148.196]) by mail1.rdc1.az.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010106234620.RQCF1817.mail1.rdc1.az.home.com@nordec> for ; Sat, 6 Jan 2001 15:46:20 -0800 Message-ID: <001e01c0783a$f0b8c0d0$0301a8c0@nordec> From: "Kelsey Womack" To: References: Subject: SCSI Controller Recommendation Date: Sat, 6 Jan 2001 16:46:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have 3 IBM Ultrastar ES SCSI LVD/SE drives I'm putting into a new server, however, I cannot find anyone that knows a thing about controllers. The model number for these drives is DNES-318350 E182115, they are 18 gig, 7200 rpm U2L drives according to yet another sticker on these drives. I am looking for some Adaptec card, but cannot find one that I am 100% will work, could someone point me towards a card, and perhaps an online vendor that isn't too expensive? Thank you. -Kelsey Kelsey Womack Network and Systems Administrator the mc6 project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 6 21:24:46 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 15D7137B400 for ; Sat, 6 Jan 2001 21:24:29 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA36834; Sat, 6 Jan 2001 22:24:22 -0700 (MST) (envelope-from ken) Date: Sat, 6 Jan 2001 22:24:22 -0700 From: "Kenneth D. Merry" To: The Hermit Hacker Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: parity error detected in ... Message-ID: <20010106222421.A36036@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from scrappy@hub.org on Sat, Jan 06, 2001 at 02:44:54PM -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jan 06, 2001 at 14:44:54 -0400, The Hermit Hacker wrote: > > newest 4.2-STABLE kernel, two scsi bus, 3 drives each ... and i'm getting > the following: > > Jan 6 14:27:54 poseidon /kernel: ahc0:A:0: parity error detected in Message-in phase. SEQADDR(0x121) SCSIRATE(0x0) > Jan 6 14:27:54 poseidon /kernel: ahc0:A:0: parity error detected in Message-in phase. SEQADDR(0x121) SCSIRATE(0x0) That looks like a cabling/connector problem of some sort. I would suggest checking your cabling and termination. > Jan 6 14:28:09 poseidon /kernel: (ahc0:A:0:0): refuses tagged commands. Performing non-tagged I/O > Jan 6 14:28:09 poseidon /kernel: (ahc0:A:0:0): refuses tagged commands. Performing non-tagged I/O > Jan 6 14:28:09 poseidon /kernel: ahc0:A:0: Target did not send an IDENTIFY message. LASTPHASE = 0x0, SAVED_SCSIID == 0x7 > Jan 6 14:28:09 poseidon /kernel: ahc0:A:0: Target did not send an IDENTIFY message. LASTPHASE = 0x0, SAVED_SCSIID == 0x7 > Jan 6 14:28:09 poseidon /kernel: ahc0: Issued Channel A Bus Reset. 64 SCBs aborted > Jan 6 14:28:09 poseidon /kernel: ahc0: Issued Channel A Bus Reset. 64 SCBs aborted From the timestamps, those may just be generic problems caused by the parity errors. So try looking at cabling and termination and see if that helps things. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 6 21:35:32 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (SHW2-220.accesscable.net [24.71.145.220]) by hub.freebsd.org (Postfix) with ESMTP id 6176737B400 for ; Sat, 6 Jan 2001 21:35:13 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id f075Xgg74385; Sun, 7 Jan 2001 01:33:42 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Sun, 7 Jan 2001 01:33:42 -0400 (AST) From: The Hermit Hacker To: "Kenneth D. Merry" Cc: Subject: Re: parity error detected in ... In-Reply-To: <20010106222421.A36036@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org will do, thanks ... On Sat, 6 Jan 2001, Kenneth D. Merry wrote: > On Sat, Jan 06, 2001 at 14:44:54 -0400, The Hermit Hacker wrote: > > > > newest 4.2-STABLE kernel, two scsi bus, 3 drives each ... and i'm getting > > the following: > > > > Jan 6 14:27:54 poseidon /kernel: ahc0:A:0: parity error detected in Message-in phase. SEQADDR(0x121) SCSIRATE(0x0) > > Jan 6 14:27:54 poseidon /kernel: ahc0:A:0: parity error detected in Message-in phase. SEQADDR(0x121) SCSIRATE(0x0) > > That looks like a cabling/connector problem of some sort. > > I would suggest checking your cabling and termination. > > > Jan 6 14:28:09 poseidon /kernel: (ahc0:A:0:0): refuses tagged commands. Performing non-tagged I/O > > Jan 6 14:28:09 poseidon /kernel: (ahc0:A:0:0): refuses tagged commands. Performing non-tagged I/O > > Jan 6 14:28:09 poseidon /kernel: ahc0:A:0: Target did not send an IDENTIFY message. LASTPHASE = 0x0, SAVED_SCSIID == 0x7 > > Jan 6 14:28:09 poseidon /kernel: ahc0:A:0: Target did not send an IDENTIFY message. LASTPHASE = 0x0, SAVED_SCSIID == 0x7 > > Jan 6 14:28:09 poseidon /kernel: ahc0: Issued Channel A Bus Reset. 64 SCBs aborted > > Jan 6 14:28:09 poseidon /kernel: ahc0: Issued Channel A Bus Reset. 64 SCBs aborted > > From the timestamps, those may just be generic problems caused by the parity > errors. > > So try looking at cabling and termination and see if that helps things. > > Ken > -- > Kenneth Merry > ken@kdm.org > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message