From: Carlo Pisani <email@example.com> To: John David Anglin <firstname.lastname@example.org> Cc: Parisc List <email@example.com> Subject: Re: C3600, sata controller Date: Tue, 14 May 2019 10:22:43 +0200 Message-ID: <CA+QBN9BfXWN1Wd3jMo_z8e0nbYLuSEH+Zz1MVbAfjF=uzGnusw@mail.gmail.com> (raw) In-Reply-To: <firstname.lastname@example.org> > "In PCI, a transaction that cannot be completed immediately > I think this *is* the only reason for failure, and it's compatible with what I observe. The failure usually happens only when moving big files. one day ago, on a second C3600 (yes, we have two workstations), we spent 10 hours at moving small files (<10Mbyte) on a "SY-PCX40009" "Silicon Image Sil3124" SIL24 card, with a sleep of 2 seconds between each copy, and we registered zero failures. Whereas, when copying a file bigger than 8Gbyte files we had a probability of 0.97 to end with a PCI error on the bus, and repeating the test, this usually happened within 10 minutes. results were the same if the card was plugged in PCI_SLOT2 (3.3V), or PCI_SLOT1 (5V): all the same behavior! what do I conclude? the voltage of signals is OK, the onboard voltage-level-shifter was doing a good job, so I think that it all a timing problem: the less an I/O task takes the PCI bus busy, the best it is. maybe, interrupt problem? some got lost? how to investigate the exact reason for the failure? did a PCI transaction fail when recycled? or did it fail due to interrupt lost? The MSI stuff is too complex and I haven't understood it, the wiki seems confusing to me, and we do not have it enabled in the kernel config. anyway, if it's a firmware problem, all related to the firmware running the SATA card, it may be fixed by a kernel driver forcing the chip into PCI64 mode. I am surprised that a PCI-X chip isn't able to switch into PCI64 mode. Cards are usually declared "backward compatible", and it would be just a matter of "how" to handle the finite state machine that drives the PCI, plus the onboard PLL and synchronization. > Here are some Adaptec 64-bit cards that I found. > https://storage.microsemi.com/en-us/support/raid/sata/aar-2410sa/ > https://storage.microsemi.com/en-us/support/raid/sata/aar-21610sa/ as written here (1), we have already tested Adaptec 2410SA, and I have also recently received an email by AlanCox confirming that the card is x86-only! Subsystem: Adaptec AAR-2410SA PCI SATA 4ch (Jaguar II) It fails on every non-x86 machine because it relies on PC-BIOS extension for the initialization of the onboard Intel i960 chip, and we do not have any Linux kernel driver able to do what the PC-BIOS does. I had opened a BUG report to a Linux mailing list, and Alan Cox replied to me privately.
next prev parent reply index Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-01 21:45 linux-next: Signed-off-by missing for commit in the parisc-hd tree Stephen Rothwell 2019-05-02 5:48 ` Helge Deller 2019-05-12 20:44 ` C3600, sata controller Carlo Pisani 2019-05-12 20:49 ` Carlo Pisani 2019-05-12 21:10 ` John David Anglin 2019-05-12 21:15 ` Carlo Pisani 2019-05-13 23:14 ` John David Anglin 2019-05-13 23:24 ` Carlo Pisani 2019-05-13 23:47 ` Carlo Pisani 2019-05-14 1:50 ` John David Anglin 2019-05-14 8:22 ` Carlo Pisani [this message] [not found] ` <CA+QBN9CgMRFmv+isvH-Y=FCCFwKhmD5_5s5u32xg+wk-gTLK5A@mail.gmail.com> 2019-05-14 12:10 ` John David Anglin 2019-05-14 12:29 ` Carlo Pisani 2019-05-14 12:57 ` C3600, optical Fibre Channel, any card? Carlo Pisani 2019-05-14 13:01 ` C3600, sata controller Sven Schnelle 2019-05-14 14:23 ` John David Anglin 2019-05-17 15:43 ` Carlo Pisani 2019-05-17 17:21 ` Helge Deller 2019-05-17 18:05 ` John David Anglin 2019-05-17 18:25 ` Carlo Pisani 2019-05-13 15:10 ` Carlo Pisani 2019-05-13 21:58 ` Carlo Pisani 2019-05-17 17:31 ` Carlo Pisani 2019-05-25 8:59 ` Carlo Pisani
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CA+QBN9BfXWN1Wd3jMo_z8e0nbYLuSEH+Zz1MVbAfjF=uzGnusw@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-parisc archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-parisc/0 linux-parisc/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-parisc linux-parisc/ https://lore.kernel.org/linux-parisc \ firstname.lastname@example.org email@example.com public-inbox-index linux-parisc Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-parisc AGPL code for this site: git clone https://public-inbox.org/ public-inbox