lkml.org 
[lkml]   [1999]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: IDE + SMP Lockup (no OOPS) in 2.2.12, 2.2.10
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.076 / U:0.944 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site