Date: Tue, 13 Apr 1999 16:09:43 -0400 (EDT) From: spork <spork@super-g.com> To: "Kenneth D. Merry" <ken@plutotech.com> Cc: "Jason K. Fritcher" <jkf@wolfnet.org>, freebsd-scsi@FreeBSD.ORG Subject: Re: Boot-time scsi probe problem Message-ID: <Pine.BSF.4.00.9904131559590.28516-100000@super-g.inch.com> In-Reply-To: <199903160625.XAA23822@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I haven't read the list in a while, but I just started putting 3.1-REL on
a new news machine with an ASUS-P2B-LS mobo. It has the internal 7890 and
a 2940-U2W card as well. I get the exact same results with about one in
five warm boots.
Is there any more news on this problem? Some info I haven't seen posted
before follows:
7890 bios version: 2.01
2940-U2W bios version: 2.01.0
'boot -v' shows the hang right after trying to talk to the first target
after the "waiting for scsi devices to settle" message. Since I wrote it
all down, I'll share...
(noperiph:ahc0:0:-1:-1): scsi bus reset delivered 0 SCBs aborted
(noperiph:ahc1:0:-1:-1): scsi bus reset delivered 0 SCBs aborted
ahc1: Selection Timeout on A:3. 1 SCB aborted
ahc0: Selection Timeout on A:5. 1 SCB aborted
*(this repeats, alternating from one controller to another with a random
number appearing each time after the "A:")
ahc0: target 0 using 16 bit transfers
ahc0: target 0 synchronous at 20.0 MHz, offset=0xf
That's it. Each time the target may be different, but it always hangs
right after the first "target" message and always on ahc0, which is the
built-in 7890.
I also didn't see the problem until I compiled my own kernel. After many
reboots on the generic kernel I never saw this.
thanks,
Charles
---
Charles Sprickman
spork@super-g.com
---
"...there's no idea that's so good you can't
ruin it with a few well-placed idiots."
On Mon, 15 Mar 1999, Kenneth D. Merry wrote:
> Jason K. Fritcher wrote...
> >
> > Hello. I am trying to get FreeBSD 3.1-Stable to boot reliably on a machine I
> > have. It was cvsup'ed from Sunday night about 11pm or so. The system was
> > originally installed with the 3.1-19990227 snapshot. I can somewhat reliably
> > boot from the generic kernel included with the snapshot, but I can not boot
> > at all with a kernel compiled from the cvsup. The problems I am having are
> > this. When booting with the generic kernel, the system will boot all the way
> > through if I power-cycle the machine, or reboot it with the reset boot,
> > basically a cold-boot. If I reboot the machine with a warm boot, ie
> > Ctrl-Alt-Del, the system will lockup when it tries to probe the scsi bus for
> > devices. It will wait the 15 seconds for things to settle, and then it locks
> > one the probe starts. I am forced to use the reset button to restart it.
> >
> > With the new kernel, when the machine gets to the probe, it does not lock
> > up, but the probe doesn't work either. It sits there for a few, and then
> > starts giving error messages about timeouts. At the end of the message I
> > have included the entire boot sequence for reference.
> >
> > The hardware I have ia an Asus P2B-LS motherboard with onboard AIC-7890 SCSI
> > controller + 3860 bridge. For those not familiar with the P2B-LS, the SCSI
> > bus is divided into three segments, a U2W, UW, and UN buses. On the U2W bus
> > I have a Quantum Viking II 9.1 GB hard drive in LVD mode, on the UW bus is
> > nothing but a terminator, and on the UN bus is a Plextor 40x cdrom drive.
> > The hard drive is scsi id 0, and the cdrom is scsi id 6.
> >
> > After looking through the archives for anything similar, I came across
> > similar problems which were caused by termination problems. I have checked
> > the termination and all seems well.
> >
> > Any suggestions about what the cause could and possible solutions would be
> > much appriciated. I have spent a good 4-5 hours compiling kernels with
> > different options, and reading through list archives to try and solve this
> > problem. If there is any more information that anyone needs, or have
> > questions, please, write me and I will do what I can.
>
> This sounds and looks like a known problem with the Adaptec 7890 chips. A
> number of people have reported this.
>
> Justin has reproduced the problem (with a lot of help from Tor Egge) and
> has a PCI bus trace showing the problem.
>
> He said that there may be a bug in the 7890 that causes it to hang in
> certain circumstances; he has mailed Adaptec asking for information.
>
> Since he's not in town at the moment, I wouldn't expect any response from
> him on this for a few days.
>
> I suggest that you stick with the kernel that boots for now, if you can.
> The hang seems to be timing related in some way, so you might get different
> results if you stick your hard disk on the Ultra-Wide bus instead of the
> Ultra-2 bus. Hopefully Justin will be able to come up with a fix for it
> before too long.
>
> You also may want to subscribe to the -scsi list, there's a lot less noise
> on this list than on many of the other FreeBSD lists. (for now, at least)
>
> Ken
> --
> Kenneth Merry
> ken@plutotech.com
>
>
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.00.9904131559590.28516-100000>