On Fri, 6 Apr 2001, Gérard Roudier wrote:
> Here is a patch that removes the offending PPC PCI hacky area from the
> driver (sym53c8xx_defs.h):
>
> --- sym53c8xx_defs.h Fri Apr 6 16:23:48 2001
> +++ sym53c8xx_defs.h.orig Sun Mar 4 13:54:11 2001
> @@ -175,6 +175,9 @@
> #define SCSI
On Thu, 5 Apr 2001, Geert Uytterhoeven wrote:
>
> BTW, my 2.4.3-pre8 kernel just said
>
> | sym53c875-0:0: ERROR (81:0) (3-21-0) (10/9d) @ (script 8a8:0b00).
Illegal instruction detected.
> | sym53c875-0: script cmd = 1100
> | sym53c875-0: regdump: da 10 80 9d 47 10 00 0d 00 03 80 2
On Fri, 6 Apr 2001, Stefano Coluccini wrote:
> > I'm still waiting for other reports of st/sym53c8xx on PPC under
> > 2.4.x. BTW,
> > does it work on other big-endian platforms, like sparc?
>
> I don't know if it is the same problem, but ...
> I have a Motorola MVME5100 (PowerPC 750 based CPU)
On Fri, 6 Apr 2001, Stefano Coluccini wrote:
> > I'm still waiting for other reports of st/sym53c8xx on PPC under
> > 2.4.x. BTW,
> > does it work on other big-endian platforms, like sparc?
>
> I don't know if it is the same problem, but ...
> I have a Motorola MVME5100 (PowerPC 750 based CPU) wi
> I'm still waiting for other reports of st/sym53c8xx on PPC under
> 2.4.x. BTW,
> does it work on other big-endian platforms, like sparc?
I don't know if it is the same problem, but ...
I have a Motorola MVME5100 (PowerPC 750 based CPU) with a mezzanine PCI
based on the sym53c875 chip. I'm using
BTW, my 2.4.3-pre8 kernel just said
| sym53c875-0:0: ERROR (81:0) (3-21-0) (10/9d) @ (script 8a8:0b00).
| sym53c875-0: script cmd = 1100
| sym53c875-0: regdump: da 10 80 9d 47 10 00 0d 00 03 80 21 80 01 09 09 00 30 4e 00 08
|ff ff ff.
| sym53c875-0-<0,*>: FAST-20 WIDE SCSI 40.0 MB/s (50
On Thu, 22 Mar 2001, Geert Uytterhoeven wrote:
> On Tue, 20 Mar 2001, Gérard Roudier wrote:
> > On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> > > On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> > > > On Mon, 19 Mar 2001, Jeff Garzik wrote:
> > > I did some more tests:
> > > - The problem als
On Tue, 20 Mar 2001, Gérard Roudier wrote:
> On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> > On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> > > On Mon, 19 Mar 2001, Jeff Garzik wrote:
> > I did some more tests:
> > - The problem also occurs when tarring up files from a disk on the Sym53c875
On Tue, 20 Mar 2001, Gérard Roudier wrote:
> On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> > On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> > > On Mon, 19 Mar 2001, Jeff Garzik wrote:
> > > > Is the corruption reproducible? If so, does the corruption go away if
> > >
> > > Yes, it is reprod
On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> > On Mon, 19 Mar 2001, Jeff Garzik wrote:
> > > Is the corruption reproducible? If so, does the corruption go away if
> >
> > Yes, it is reproducible. In all my tests, I tarred 16 files of 16 MB
On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> On Mon, 19 Mar 2001, Jeff Garzik wrote:
> > Is the corruption reproducible? If so, does the corruption go away if
>
> Yes, it is reproducible. In all my tests, I tarred 16 files of 16 MB each to
> tape (I used a new one).
> - test 1: 4 files wit
On Mon, 19 Mar 2001, Jeff Garzik wrote:
> Is the corruption reproducible? If so, does the corruption go away if
Yes, it is reproducible. In all my tests, I tarred 16 files of 16 MB each to
tape (I used a new one).
- test 1: 4 files with failed md5sum (no further investigation on type of
While doing some tests with my DDS drive, I noticed some file corruption. The
data was written to the tape incorrectly, since reading always gives the same
result. The drive didn't notice any write error.
My test consisted of tarring up some kernel sources and splitting them in
files of 16 MB. T
13 matches
Mail list logo