Messages in this thread | | | From | "Tom Livingston" <> | Subject | RE: IDE + SMP Lockup (no OOPS) in 2.2.12, 2.2.10 | Date | Wed, 29 Sep 1999 14:33:48 -0700 |
| |
Alan Cox wrote: > That proves the diagnosis which is good. I was trying to work out > if it was > safe or not but the code needs a bit of cleaning up before I > could be sure.
Thank you very much for looking at this stuff... I can almost feel my processor being used again someday ;)
While we are roughly on the subject, a couple of the recipients on this list may remember my report of infrequent corruptions on reads while using a hpt-366 onboard the bp-6. It turned out that this infrequent corruption was due to one of my other controllers in my raid set being forced to share the same irq as the hpt-366. This is a limitation of the bp-6.
My question is: what is the right behavior for sharing an irq in a situation like this? Is it considered not something you can do, or something that should be working? Though I understand that the sharing of irqs is significantly frowned upon, it would seem that the ide driver has the basic ability to do so, as i was seeing corruption only in < 0.1 % of my blocks, with heavy access on all channels on the irq. My casual reading of the ide source leads me to believe that this is technically possible.
If it is possible, is there any kind of typical problem suggested by this behavior? Since I just learned about spinlocks it seems to me that this might be a case of a hwgroup->spinlock that just controls irq access for one controller (two ide channels) when in the case of the multi controller shared irq, possibly it should be holding a hwgroup->spinlock for every channel that uses the irq (4 total?) I see code that seems to do this, would this be a general area for investigation?
Tom
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |