Date: Sat, 3 Oct 1998 10:56:51 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: dswartz@druber.com (Dan Swartzendruber) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: dumping with CAM kernel? Message-ID: <199810031656.KAA13245@panzer.plutotech.com> In-Reply-To: <3.0.5.32.19981003103509.0094e6f0@mail.kersur.net> from Dan Swartzendruber at "Oct 3, 98 10:35:09 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Swartzendruber wrote... > > I had sent email awhile back to the -stable list about a panic I ran into > on 2.2.7-STABLE, using quotas. I couldn't provide a trace, because the > system didn't seem to be taking a dump. I was managing the system > remotely, so I couldn't see what was happening. Yesterday, I got to run > the repro testcase > while looking at the console. When the system panicked, it did in fact try > to take a dump. However, the ahc driver coughed up a few furballs about > SCB's and aborted. I have done this 3 times and gotten somewhat different > messages each time. I don't have more precise info, since I haven't yet > gotten remote console access working for that machine. This is a 2.2.7-STABLE > system with the most recent CAM patches. The system has onboard 7880 driving > several UW drives, and onboard 7860 driving the CDROM (this is a Dell server). > It's hard to believe it's a configurating/wiring/termination issue, since the > machine works flawlessly under normal conditions. Any ideas? Dumps were broken for a while in CAM because (I think) of the order some of the shutdown hooks were called. Basically, the shutdown hook that Justin uses to reset the Adaptec board to a "known" state was getting called before the dump routine in the da driver gets called. So when we tried to run the dump routine, everything just blew up. (no sequencer running on the card, all the registers are set wrong, etc. etc.) Justin finally figured out and fixed the problem around the time we put CAM into -current. We haven't released another -stable snapshot yet. That'll probably happen after 3.0 goes out. I'm not sure what kind of environment you've got it in, but if you can, you might want to put a serial console on it and enable DDB. Then you can capture a stack trace of the problem at least. If that's not possible, I guess you'll probably have to wait until we get another -stable snapshot out. That problem bugged me for a good while, because I had a bad RAM setup in my home machine (too much capacitance load), and couldn't see the panic messages to figure out whether it was a parity problem or something else. I finally setup a serial console, and I was able to see what the problem was. (Or rather see that it wasn't a parity error...) Ken -- Kenneth Merry ken@plutotech.com 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?199810031656.KAA13245>