James Bottomley wrote:
On Sun, 2007-07-29 at 21:04 -0400, Jeff Garzik wrote:
James Bottomley wrote:
msleep_interruptible -> ssleep is a
change with zero practical impact for this driver,
eh, how do you figure?
A signal can clearly cause the abort-related functions to delay far
shorter than t
On Sun, 2007-07-29 at 21:04 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > msleep_interruptible -> ssleep is a
> > change with zero practical impact for this driver,
>
> eh, how do you figure?
>
> A signal can clearly cause the abort-related functions to delay far
> shorter than the driv
James Bottomley wrote:
msleep_interruptible -> ssleep is a
change with zero practical impact for this driver,
eh, how do you figure?
A signal can clearly cause the abort-related functions to delay far
shorter than the driver wishes.
The msleep_interruptible() in arcmsr_wait_msgint_ready() p
On Sun, 2007-07-29 at 18:51 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > This is basically a set of bug fixes with a few minor cleanups thrown
> > in. There are also a few bsg fixes we're taking through this tree
> > because SCSI is the current sole consumer. The reason for the huge size
James Bottomley wrote:
This is basically a set of bug fixes with a few minor cleanups thrown
in. There are also a few bsg fixes we're taking through this tree
because SCSI is the current sole consumer. The reason for the huge size
is the lindent of the advansys driver along with a few cleanups.
This is basically a set of bug fixes with a few minor cleanups thrown
in. There are also a few bsg fixes we're taking through this tree
because SCSI is the current sole consumer. The reason for the huge size
is the lindent of the advansys driver along with a few cleanups.
The patch is available h
6 matches
Mail list logo
