Date: Fri, 21 Jun 2002 10:34:25 +0100 From: Pete French <pfrench@firstcallgroup.co.uk> To: frank@exit.com, holger.kipp@alogis.com Cc: pjklist@ekahuna.com, stable@FreeBSD.ORG Subject: Re: Status of fxp / smp problem? Message-ID: <E17LKoD-0001RG-00@mailhost.firstcallgroup.co.uk> In-Reply-To: <3D12EB49.3E3CC0D5@alogis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Not only sym/fxp, but also sym/ata, only sym, or only fxp or even others.
Did we ever track down a time window as to *when* the changes were made
thats caused this to start happening ? For me it was the update on May 22
that started it all going wrong, but I cant (unfortunately) remember what
date of -STABLE the machine was running up until that point.
> Problem seems to manifest itself especially on systems with:
> - shared IRQs AND
> - SMP enabled
One added thing here - I had shared IRQ's between ata and sym, and the
problem went away when I took the ata driver out of the kerenl. *but* I
do not have any devices attached to the atat controller, so (preseumably)
it could not have actually been interrupting ?
Speculation: preseumably wth a shared IRQ the system scans devices it
knows are attached to that IRQ until it finds one which needs service ? Any
ideas what order it will do this in - i.e. would it be possible for it
to scan ata, followed by sym, and for there to be some oddity in the IRQ
code that stops it continuing on to scan sym under certain circumstances ?
Unsure as to how this might happen, and I havent looked at the IRQ code,
but I do have a machine on which I can reproduce the problem 100% reliably
if that helps.
-pcf.
PS: committing that sym workaround would be really nice as I could at least
then use our Compaq multiprocessor machines reliably.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E17LKoD-0001RG-00>