Date: Thu, 24 Sep 1998 01:31:57 -0400 From: Adam McDougall <mcdougall@ameritech.net> To: current@FreeBSD.ORG Subject: Re: options DPT_LOST_IRQ Message-ID: <3609D94D.8397CF49@ameritech.net> References: <199809240354.VAA03623@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Justin T. Gibbs wrote: > > In article <3609A685.A9B65B3A@ameritech.net> you wrote: > > Does CAM still perform what is supposed to when using this kernel > > option? Because it doesn't show any evidence of it in Boot: -v and the > > unwanted behavior of not using this option is showing up again, even > > though its still in my kernel. > > The CAM driver does not currently honor this option. It could easily > be added again, but it would be nice to know why it is necessary. Is > the symptom simply a timeout? > The symptom (at least on my system) is that the HD totally freezes up with the light on, and the dpt sits there merrily idle, while freebsd processes start losing sanity because the disk cannot be accessed (eg. any interaction with the system which would trigger a HD access would freeze up that portion of the system..) I know there is a 'irq pending' led on the dpt which may indicate the condition has occurred for some people, but mine didnt happen this way, and adding this kernel option ceased the described lockups. I have a 2144UW, a Atlas II, and a Mtech R534 motherboard. # DPT_LOST_IRQ When enabled, will try, once per second, to catch # any interrupt that got lost. Seems to help in some # DPT-firmware/Motherboard combinations. Minimal # cost, great benefit. ^^ from LINT would hate to lose that great benefit :P > One thing I noticed that the Linux driver does in it's interrupt > handler that FreeBSD doesn't, is to watch for the busy bit in the > aux status register. Is this important? (I don't have any docs...) > Could it be that we inadvertantly clear an interrupt before the > status packet write is complete? > > If the problem is in the FreeBSD interrupt code, we should find out > for sure. I may not have a fast enough adapter (PM3224A) to make > the failure occur here, under a PCI bus analyzer, to determine one > way or the other. > > > Thanks in advance.. > > -- > Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3609D94D.8397CF49>