[EMAIL PROTECTED] wrote:
> What kernel version are you using? Very important.
Oops. Kernel=2.2.14-5.0 (RH 6.2). Adaptec aic7xxx version 5.1.28.
Recent attempts with aic7xxx 5.1.29 appear to recreate the problem faster.
>> If "!uptodate" is an error worthy of a printk, shouldn't some sort of
error
>> be returned back?
>
> There is an error being returned back, but the mechanism isn't
obvious.
>Essentially we are taking the blocks for the command and marking them to
>indicate that there is no longer I/O pending. The uptodate flag for the
>buffer indicates whether the I/O was completed with success or not - this
is
>the flag that can be used by the process that initiated the I/O to make
sure
>that everything went OK.
>
> If you think about it, the call to end_scsi_request can take place
from
>the context of an interrupt handler (a bottom half handler in this case).
>The return value from the function isn't going to be significant once you
>return from SCSI into the general purpose kernel code.
I was hoping to get the application to see an I/O error instead of hanging.
The real goal is to find out why this occurs at all as the error inject is
ment to be surviveable (and _is_ surviable on the other supported OS
platforms).
The cmd might have to be retried, but it should not be fatal.
Since the only difference between a survivable error and a fatal one is the
printk generated by !updtodate in end_scsi_request, I can only guess that
the
caller isn't handling it right.
Is there a suggested set of steps to follow for untying this knot? The
only
loose thread I saw to pick at was in the form of the "scsidisk I/O error"
msg.
I should add that while the exerciser is hanging outright, the rest of the
box starts to petrify as well. Eventually the box has to be hw reset and
all the filesystems the exerciser had open have to be cleaned up.
> The minor numbers above are reported in hexadecimal :-).
Ah. You assume all readers of the error msgs are properly caffinated to
catch that? :) how about displaying the minor numbers in the same format
as they appear in /dev.
-steve
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
