Hi,
Support for some 53c400 cards is still bad (the non-PnP), so I'll start
fixing this.
I'll be my fist kernel job, so please spare me :))
Issues :
53c400a non-PNP still lock this system hard. It starts barking about a
busy SCSI bus, and then I can fsck again.
To Alan : How hard is it to get thing beast (53c400 and family) to be SMP
safe ?? Or is it better to start over again ?
Regards,
Igmar
> 53c400a non-PNP still lock this system hard. It starts barking about a
> busy SCSI bus, and then I can fsck again.
>
> To Alan : How hard is it to get thing beast (53c400 and family) to be SMP
> safe ?? Or is it better to start over again ?
The problem is that the code takes spinlocks recursively. The original
code (see 2.0's 5380 generic C code) uses cli/sti. It was converted to
use spin_lock() but not allowing for the recursive locking cases. I tried
to untangle the code paths but they are so ugly and some of the code is
sufficiently messy and unmaintained (for about 6 years) that I gave up
trying to decode it.
Alan
JE's UHCI driver (drivers/usb/uhci.[hc]) uses
nested_lock() and nested_unlock() for this.
Maybe it could help.
~Randy
_______________________________________________
|randy.dunlap_at_intel.com 503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
-----------------------------------------------
> -----Original Message-----
> From: Alan Cox [mailto:[email protected]]
> Sent: Tuesday, November 21, 2000 3:48 PM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: 53c400 driver
>
>
> > 53c400a non-PNP still lock this system hard. It starts
> barking about a
> > busy SCSI bus, and then I can fsck again.
> >
> > To Alan : How hard is it to get thing beast (53c400 and
> family) to be SMP
> > safe ?? Or is it better to start over again ?
>
> The problem is that the code takes spinlocks recursively. The original
> code (see 2.0's 5380 generic C code) uses cli/sti. It was converted to
> use spin_lock() but not allowing for the recursive locking
> cases. I tried
> to untangle the code paths but they are so ugly and some of
> the code is
> sufficiently messy and unmaintained (for about 6 years) that I gave up
> trying to decode it.
>
> Alan
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, 21 Nov 2000, Dunlap, Randy wrote:
> JE's UHCI driver (drivers/usb/uhci.[hc]) uses
> nested_lock() and nested_unlock() for this.
> Maybe it could help.
I may should solve the nested spinlock issue.. It however doesn't solve
the 100Kb+ pile of spaghetti the code is.
I think I'll just start over. I have to do something in my spare time :)
> ~Randy
Regards,
Igmar