Date: Fri, 20 Apr 2001 10:25:52 -0500 (CDT) From: Chris Dillon <cdillon@wolves.k12.mo.us> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Tom Samplonius <tom@sdf.com>, =?iso-8859-1?Q?Jo=E3o_Pagaime?= <jpsp@fccn.pt>, <freebsd-scsi@FreeBSD.ORG> Subject: Re: Mylex 170 - boot takes several minutes Message-ID: <Pine.BSF.4.32.0104200946550.80885-100000@mail.wolves.k12.mo.us> In-Reply-To: <200104200147.f3K1llu17658@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 19 Apr 2001, Mike Smith wrote: > > > The mly driver in 4.3-RC is much better. It might fix this problem. > > > Besides that, It is definitely much faster. > > > > It doesn't fix that particular problem, at least not for me. The > > controller/driver was also causing a system panic for me shortly > > before root was mounted. I had some earlier kernels where everything > > worked just fine except for the long delay, and then a few days ago I > > attempted to update to the latest 4.3-RC and it still paniced on me. > > I've had another report of this, involving a smart/managed > backplane. Does this feature in your configuration as well? Yes, the system is a SuperMicro SuperServer 6040, which I believe includes the CSE-031 SCA backplane that you can buy separately from them. It uses a "<SUPER GEM354 REV001 1.04>" on made by QLogic on ID 6. This is what I would get, wether the system booted successfully or paniced (obviously successful on this run, since it made it into the log): Mar 27 17:43:41 duey /kernel: mly0: <Mylex AcceleRAID 170> mem 0xfc5fe000-0xfc5fffff irq 10 at device 1.1 on pci2 Mar 27 17:43:41 duey /kernel: mly0: AcceleRAID 170 , 1 channel, firmware 6.00-3-00 (20000919), 32MB RAM Mar 27 17:43:41 duey /kernel: Waiting 15 seconds for SCSI devices to settle [...here is where the long wait begins... the bus seems to be reset and devices probed between each message, judging just by the activity lights on the drives during the whole process] Mar 27 17:43:41 duey /kernel: mly0: physical device 0:6 sense data received Mar 27 17:43:41 duey /kernel: mly0: sense key 5 asc 00 ascq 00 Mar 27 17:43:41 duey /kernel: mly0: info 00000000 csi 00000000 Mar 27 17:43:41 duey /kernel: mly0: physical device 0:6 sense data received Mar 27 17:43:41 duey /kernel: mly0: sense key 5 asc 00 ascq 00 Mar 27 17:43:41 duey /kernel: mly0: info 00000000 csi 00000000 Mar 27 17:43:41 duey /kernel: mly0: physical device 0:6 sense data received Mar 27 17:43:41 duey /kernel: mly0: sense key 5 asc 00 ascq 00 Mar 27 17:43:41 duey /kernel: mly0: info 00000000 csi 00000000 Mar 27 17:43:41 duey /kernel: mly0: physical device 0:6 sense data received Mar 27 17:43:41 duey /kernel: mly0: sense key 5 asc 00 ascq 00 Mar 27 17:43:41 duey /kernel: mly0: info 00000000 csi 00000000 Mar 27 17:43:41 duey /kernel: mly0: physical device 0:6 sense data received Mar 27 17:43:41 duey /kernel: mly0: sense key 5 asc 00 ascq 00 Mar 27 17:43:41 duey /kernel: mly0: info 00000000 csi 00000000 Mar 27 17:43:41 duey /kernel: mly0: physical device 0:6 sense data received Mar 27 17:43:41 duey /kernel: mly0: sense key 5 asc 00 ascq 00 Mar 27 17:43:41 duey /kernel: mly0: info 00000000 csi 00000000 Mar 27 17:43:41 duey /kernel: mly0: physical device 0:6 sense data received Mar 27 17:43:41 duey /kernel: mly0: sense key 5 asc 00 ascq 00 Mar 27 17:43:41 duey /kernel: mly0: info 00000000 csi 00000000 [...and where the long wait ends...] Mar 27 17:43:41 duey /kernel: da0 at mly0 bus 1 target 0 lun 0 Mar 27 17:43:41 duey /kernel: da0: <RAID 1 online > Fixed Direct Access SCSI-3 device I know a crashdump and backtrace would be best... I'll get that (the crashdump, at least, since I don't think I'll know how to backtrace it) at the next available opportunity. :-) One intersting thing is that one time I saw an error pop up during probing for the spare drive I had sitting in the chassis, which was not configured in the controller as anything. It was there just to be a warm spare that I would pull out and move over to the slot of a dead drive when the time came. The system suddenly started panicing every time on boot until I pulled that spare unconfigured drive out. Now it panics every time regardless, even with the same kernels. Does this sound like there is something weird going on with the on-controller configuration that could be causing the panic? Thats the only thing I can think of that would cause inconsistent boot failures and failures with previously known-good kernels. Is there any configuration information stored on the disk by the controller? -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.32.0104200946550.80885-100000>