Martin Drab <[email protected]> wrote:
>
> > > [ 278.732829] scsi0 (0:0): rejecting I/O to offline device
> > > [ 278.735954] Buffer I/O error on device sda2, logical block 491840
> > > [ 278.739147] lost page write due to I/O error on sda2
> > > [ 278.742389] scsi0 (0:0): rejecting I/O to offline device
> > > [ 278.745618] Buffer I/O error on device sda2, logical block 950284
> > > [ 278.748911] lost page write due to I/O error on sda2
> > > [ 278.752238] Buffer I/O error on device sda2, logical block 950285
> > > [ 278.755614] lost page write due to I/O error on sda2
> > > [ 278.759009] scsi0 (0:0): rejecting I/O to offline device
> > > [ 278.762408] Buffer I/O error on device sda2, logical block 950287
> > > [ 278.765855] lost page write due to I/O error on sda2
> > > [ 278.769318] scsi0 (0:0): rejecting I/O to offline device
> > > ... last message repeats about 45-times ...
> > > [ 347.564676] EXT3-fs error (device sda2): ext3_find_entry: reading directory #544057 offset 0
> > > ... here the log ends, nothing else happens then, since nothing is working when / is inaccessible ... :(
> >
> > Martin, is this problem still present in 2.6.13-rc4?
> >
> > If so, please cc linux-kernel on the reply, thanks.
> >
> > It would also be useful if you could try reverting that aacraid patch, see
> > if that helps.
>
> Hi, Andrew!
>
> The thing is still not fixed in 2.6.13-rc4. I had a long discussion about
> this with Mark Salyczyn and Mark Haverkamp. We came out with a temporary
> workaround, which was to set the AAC_MAX_32BIT_SGBCOUNT in aacraid.h to
> 512 instead of 8192. The patch for this was presented 8.7.2005 on
> linux-scsi list by Mark Haverkamp. However this constant solution may (?)
> have some performance impact on the configurations which are capable of
> delivering a better performance (with respect to this constant at hand).
>
> IMHO the real solution to this problem is the new Adaptec variant of
> aacraid driver which uses the 'new comm' technology to negotiate all these
> essential parameters directly with the hardware instead of relying on some
> preset constants. Mark Salyzyn has the patches prepared in his patch
> queue, and I vote for pushing it into the mainline ASAP.
ah, thanks.
A temporary workaround which might affct performance sounds better than a
dead box though.
Mark, do you think that many systems are likely to be affected this way?
Do you think we should do something temporary for 2.6.13?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |