aic94xx: fix SSP IU status print-out
PATCH 1/1 aic94xx: fix SSP IU status print-out
The SSP response DPRINTK in asd_get_response_tasklet() was printing a hardcoded status result, rather than the status from the SSP response IU.
Arguably, this should not be a DPRINTK either, since the admin might want to know about this.
--- drivers/scsi/aic94xx/aic94xx_task.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/aic94xx/aic94xx_task.c +1 -1
@@ -207,7 +207,7 @@ static void asd_get_response_tasklet(struct asd_ascb *ascb,"stat(0x%x) is not CHECK_CONDITION" "\n" ,SAS_ADDR (task->dev->sas_addr), - ts->stat); + iu->status); } } }else {
James, what is the upstream status of my two aic94xx bug fixes?
Have they been sent to Linus yet?
Since you seem M.I.A., I'll send them upstream if I do not hear from you today.
Jeff
Quoted 6 lines · Jeff Garzik
James, what is the upstream status of my two aic94xx bug fixes?
Have they been sent to Linus yet?
Since you seem M.I.A., I'll send them upstream if I do not hear from you today.
They're hardly -rc8 critical bug fixes, since no-one has noticed their effects for about 5 kernel releases. I'll stick them into scsi-misc with the rest of the pending stuff.
And going away for the Weekend is hardly MIA.
James
Quoted 10 lines · James Bottomley
Quoted 5 lines · Jeff Garzik
James, what is the upstream status of my two aic94xx bug fixes?
Have they been sent to Linus yet?
Since you seem M.I.A., I'll send them upstream if I do not hear from you today.
They're hardly -rc8 critical bug fixes, since no-one has noticed their effects for about 5 kernel releases. I'll stick them into scsi-misc with the rest of the pending stuff.
Except for those people who want SMP to work, on platforms where TODEVICE actually matters.
I'll send them upstream myself.
Quoted 1 line
And going away for the Weekend is hardly MIA.
A week has gone by since any SCSI commit, and longer than that if you actually look at the send-date of the most recent patch applied.
Jeff
Quoted 9 lines · Jeff Garzik
Quoted 8 lines · James Bottomley
Quoted 6 lines · Jeff Garzik
James, what is the upstream status of my two aic94xx bug fixes?
Have they been sent to Linus yet?
Since you seem M.I.A., I'll send them upstream if I do not hear from you today.
Quoted 6 lines
Quoted 3 lines
They're hardly -rc8 critical bug fixes, since no-one has noticed their effects for about 5 kernel releases. I'll stick them into scsi-misc with the rest of the pending stuff.
Except for those people who want SMP to work, on platforms where TODEVICE actually matters.
And the number of bug reports on this?
Quoted 1 line
I'll send them upstream myself.
No, you won't; because that would be completely irresponsible. You don't turn code for no reason at the last minute unless it's essential because of the danger of introducing inadvertent bugs along with the changes. Since there are no users affected, there's zero benefit and there is a potential non-zero detriment to the code turn.
There's absolutely no reason to rush these into the release at the last minute. The correct path is via scsi-misc and then to be backported into the stable series once we're sure they're OK.
Quoted 4 lines
Quoted 1 line
And going away for the Weekend is hardly MIA.
A week has gone by since any SCSI commit, and longer than that if you actually look at the send-date of the most recent patch applied.
If you follow the linux-scsi mailing list, you'll see fairly active participation after that, I think.
James
Quoted 23 lines · James Bottomley
Quoted 11 lines · Jeff Garzik
Quoted 9 lines · James Bottomley
Quoted 5 lines · Jeff Garzik
James, what is the upstream status of my two aic94xx bug fixes?
Have they been sent to Linus yet?
Since you seem M.I.A., I'll send them upstream if I do not hear from you today.
They're hardly -rc8 critical bug fixes, since no-one has noticed their effects for about 5 kernel releases. I'll stick them into scsi-misc with the rest of the pending stuff.
Except for those people who want SMP to work, on platforms where TODEVICE actually matters.
And the number of bug reports on this?
Quoted 1 line
I'll send them upstream myself.
No, you won't; because that would be completely irresponsible. You don't turn code for no reason at the last minute unless it's essential because of the danger of introducing inadvertent bugs along with the changes. Since there are no users affected, there's zero benefit and there is a potential non-zero detriment to the code turn.
Quoted 3 lines
There's absolutely no reason to rush these into the release at the last minute. The correct path is via scsi-misc and then to be backported into the stable series once we're sure they're OK.
What's irresponsible is holding onto simple, obvious bug fixes that obviously break certain scenarios.
Jeff
Quoted 26 lines · Jeff Garzik
Quoted 25 lines · James Bottomley
Quoted 6 lines · Jeff Garzik
Quoted 5 lines · James Bottomley
Quoted 4 lines · Jeff Garzik
James, what is the upstream status of my two aic94xx bug fixes?
Have they been sent to Linus yet?
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Since you seem M.I.A., I'll send them upstream if I do not hear from you today.
They're hardly -rc8 critical bug fixes, since no-one has noticed their effects for about 5 kernel releases. I'll stick them into scsi-misc with the rest of the pending stuff.
Except for those people who want SMP to work, on platforms where TODEVICE actually matters.
And the number of bug reports on this?
Quoted 1 line
I'll send them upstream myself.
No, you won't; because that would be completely irresponsible. You don't turn code for no reason at the last minute unless it's essential because of the danger of introducing inadvertent bugs along with the changes. Since there are no users affected, there's zero benefit and there is a potential non-zero detriment to the code turn.
Quoted 6 lines
Quoted 3 lines
There's absolutely no reason to rush these into the release at the last minute. The correct path is via scsi-misc and then to be backported into the stable series once we're sure they're OK.
What's irresponsible is holding onto simple, obvious bug fixes that obviously break certain scenarios.
Those scenarios don't exist. I spent quite a while with Adaptec trying to get this card to work on non-x86 platforms. There's a bug which manifests as the driver decides the card hasn't been setup by bios and it tries to write the OCF parameters itself ... on non-x86 platforms this always ends up inducing a master abort on the PCI bus for no explicable reason (and it's not the code you're fixing, it happens way before this). There is actually an ia64 box at Adaptec which exhibits the problem ... and they're trying to trace the PCI bus transactions. The fascinating thing will be to see if this also shows up in the Calgary when we get all of that working.
So I know, beyond a shadow of a doubt, that there are no non-x86 users of this.
James
Quoted 2 lines · James Bottomley
So I know, beyond a shadow of a doubt, that there are no non-x86 users of this.
If you don't get the DMA direction right on x86, swiotlb will corrupt your data.
Jeff
Quoted 6 lines · Jeff Garzik
Quoted 2 lines · James Bottomley
So I know, beyond a shadow of a doubt, that there are no non-x86 users of this.
If you don't get the DMA direction right on x86, swiotlb will corrupt your data.
Er, this is a fully 64 bit device: it shouldn't use swiotlb.
James