linux-next: Signed-off-by missing for commit in the parisc-hd tree

linux-next: Signed-off-by missing for commit in the parisc-hd tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

Hi all,

Commit

  2b731a920986 ("parisc: Update huge TLB page support to use per-pagetable spinlock")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: Signed-off-by missing for commit in the parisc-hd tree

[Helge Deller]

[-- Attachment #1.1: Type: text/plain, Size: 224 bytes --]

On 01.05.19 23:45, Stephen Rothwell wrote:
> Commit
>   2b731a920986 ("parisc: Update huge TLB page support to use per-pagetable spinlock")
> is missing a Signed-off-by from its committer.

Thanks. Fixed now.
Helge


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

C3600, sata controller

[Carlo Pisani]

guys,
I asked a friend to lend us his card, which is the card2 listed below
and not things are becoming really weird

card1, Silicon Image, Inc. Adaptec AAR-1210SA
card2, Silicon Image, Inc. SiI 3124 PCI-X Serial ATA

the card1 is a PCI32 bit card, and uses the "sata_sil" driver
the card2 is a PCI64 bit card, and uses the "sata_sil24" driver

card1 is installed in a PCI32 slot, and it's moving 32Gbyte in a loop
without any issue

I have just tested card2 in each of the PCI-X slot (including the 3.3V
one) and ... it has always triggered the HPMC unit, crashing the
machine

the hardware is different, and drivers are also different, but  ....
maybe the problem is related to 32 vs 64bit?

I am going to repeat the test with card2 installed in a PCI32 slot.
This should force it to 32bit: will it work correctly?
(hope this makes sense)

---

we have also checked if the kernel is correctly handling the ram
we have a C3600 with 8Gbyte of ram

mount -t tmpfs -o size=7G tmpfs /mnt/ramdrive/
dd if=/dev/zero of=/mnt/ramdrive/test.bin
badblocks -swv /mnt/ramdrive/test.bin

checking for bad blocks in read-write mode
From block 0 to 7340031
Testing with pattern 0xaa: done
Reading and comparing: done
Testing with pattern 0x55: done
Reading and comparing: done
Testing with pattern 0xff: done
Reading and comparing: done
Testing with pattern 0x00: done
Reading and comparing: done
Pass completed, 0 bad blocks found.

no problems found

Re: C3600, sata controller

[Carlo Pisani]

kernel's config and dmesg are here

http://www.downthebunker.com/chunk_of/stuff/public/projects/workstations/hppa/c3600/kernel/5.1-git-v5.2-64bit/

http://www.downthebunker.com/chunk_of/stuff/public/projects/workstations/hppa/c3600/kernel/4.16.2-64bit/

Il giorno dom 12 mag 2019 alle ore 22:44 Carlo Pisani
<carlojpisani@gmail.com> ha scritto:
>
> guys,
> I asked a friend to lend us his card, which is the card2 listed below
> and not things are becoming really weird
>
> card1, Silicon Image, Inc. Adaptec AAR-1210SA
> card2, Silicon Image, Inc. SiI 3124 PCI-X Serial ATA
>
> the card1 is a PCI32 bit card, and uses the "sata_sil" driver
> the card2 is a PCI64 bit card, and uses the "sata_sil24" driver
>
> card1 is installed in a PCI32 slot, and it's moving 32Gbyte in a loop
> without any issue
>
> I have just tested card2 in each of the PCI-X slot (including the 3.3V
> one) and ... it has always triggered the HPMC unit, crashing the
> machine
>
> the hardware is different, and drivers are also different, but  ....
> maybe the problem is related to 32 vs 64bit?
>
> I am going to repeat the test with card2 installed in a PCI32 slot.
> This should force it to 32bit: will it work correctly?
> (hope this makes sense)
>
> ---
>
> we have also checked if the kernel is correctly handling the ram
> we have a C3600 with 8Gbyte of ram
>
> mount -t tmpfs -o size=7G tmpfs /mnt/ramdrive/
> dd if=/dev/zero of=/mnt/ramdrive/test.bin
> badblocks -swv /mnt/ramdrive/test.bin
>
> checking for bad blocks in read-write mode
> From block 0 to 7340031
> Testing with pattern 0xaa: done
> Reading and comparing: done
> Testing with pattern 0x55: done
> Reading and comparing: done
> Testing with pattern 0xff: done
> Reading and comparing: done
> Testing with pattern 0x00: done
> Reading and comparing: done
> Pass completed, 0 bad blocks found.
>
> no problems found

Re: C3600, sata controller

[John David Anglin]

The c3600 doesn't have any PCI-X slots (only PCI) as far as I can tell from user manuals.

The SY-PCX40009 PCI-X card that I have says it supports two models: 32-bit at 66 MHz and 64-bit
at 133 MHz.  The 32-bit slots in c3600 are 33 MHz.  Whether the card will work at 33 MHz is not
clear.  The card says it's backward compatible to PCI 2.3.

On 2019-05-12 4:44 p.m., Carlo Pisani wrote:
> guys,
> I asked a friend to lend us his card, which is the card2 listed below
> and not things are becoming really weird
>
> card1, Silicon Image, Inc. Adaptec AAR-1210SA
> card2, Silicon Image, Inc. SiI 3124 PCI-X Serial ATA
>
> the card1 is a PCI32 bit card, and uses the "sata_sil" driver
> the card2 is a PCI64 bit card, and uses the "sata_sil24" driver
>
> card1 is installed in a PCI32 slot, and it's moving 32Gbyte in a loop
> without any issue
>
> I have just tested card2 in each of the PCI-X slot (including the 3.3V
> one) and ... it has always triggered the HPMC unit, crashing the
> machine
>
> the hardware is different, and drivers are also different, but  ....
> maybe the problem is related to 32 vs 64bit?
>
> I am going to repeat the test with card2 installed in a PCI32 slot.
> This should force it to 32bit: will it work correctly?
> (hope this makes sense)
>
> ---
>
> we have also checked if the kernel is correctly handling the ram
> we have a C3600 with 8Gbyte of ram
>
> mount -t tmpfs -o size=7G tmpfs /mnt/ramdrive/
> dd if=/dev/zero of=/mnt/ramdrive/test.bin
> badblocks -swv /mnt/ramdrive/test.bin
>
> checking for bad blocks in read-write mode
> >From block 0 to 7340031
> Testing with pattern 0xaa: done
> Reading and comparing: done
> Testing with pattern 0x55: done
> Reading and comparing: done
> Testing with pattern 0xff: done
> Reading and comparing: done
> Testing with pattern 0x00: done
> Reading and comparing: done
> Pass completed, 0 bad blocks found.
>
> no problems found
>


-- 
John David Anglin  dave.anglin@bell.net

Re: C3600, sata controller

[Carlo Pisani]

> The c3600 doesn't have any PCI-X slots (only PCI) as far as I can tell from user manuals.

PCI-32/33 device I/O bus
PCI-64/33 high-performance device I/O bus <----------------- this is
PCI-X, 64bit 5V
PCI-64/66 high-performance graphics I/O bus <----------------- this is
PCI-X, 64bit 3.3V

https://www.openpa.net/systems/hp-visualize_b1000_c3000_c3600.html

Re: C3600, sata controller

[John David Anglin]

On 2019-05-12 5:15 p.m., Carlo Pisani wrote:
>> The c3600 doesn't have any PCI-X slots (only PCI) as far as I can tell from user manuals.
> PCI-32/33 device I/O bus
> PCI-64/33 high-performance device I/O bus <----------------- this is
> PCI-X, 64bit 5V
> PCI-64/66 high-performance graphics I/O bus <----------------- this is
> PCI-X, 64bit 3.3V
>
> https://www.openpa.net/systems/hp-visualize_b1000_c3000_c3600.html
I think that you are wrong.  HP would have said the slots were PCI-X compatible if they were.
They did in c8000.

The issue is probably the signalling voltage and clock rate capability.  33 MHz always uses 5V
signalling whereas PCX-X cards typically support 66 and 133 MHz.  Thus, I think PCI-X cards use
CMOS 3.3V signalling although they may accept 5V on their inputs.  If the c3600 uses older
TTL logic, it is likely that 3.3V CMOS logic can't provide the high level for 5V TTL logic.

I suspect the only slot that might work with a PCI-X card is the 3.3V SL2.  However, if you see I/O errors
in the PIM dump following a HPMC, then it's not compatible.

So, probably you would have better luck with the PCI Syba SD-SATA150R in c3600.  However, it is similar
to the Adaptec 1210SA which works.  Maybe they differ in RAID capability.

Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: C3600, sata controller

[Carlo Pisani]

> The issue is probably the signalling voltage and clock rate capability.

PCI_X means 64bit, no matter voltage of anything.
You can have PCI_X at 33Mhz, 66Mhz, 100Mhz
You can have PCI_X at 5V, or PCI_X at 3.3V

> TTL logic, it is likely that 3.3V CMOS logic can't provide the high level for 5V TTL logic.

inputs are 5V tolerant, outputs are already ok about their levels

> I suspect the only slot that might work with a PCI-X card is the 3.3V SL2.

the SIL24 PCI_X card has been already checked in that slot, and it
fails in the same way as it fails when it's plugged in one of the 5V
slots

> However, if you see I/O errors in the PIM dump following an HPMC, then it's not compatible.

if things were that way, it wouldn't be a random failure, but rather
an immediate failure

to me, it looks more like a timing error, or something bad with DMA 64bit

it's like to force the card to be "DMA32bit" only, just to check it

Re: C3600, sata controller

[Carlo Pisani]

> > The issue is probably the signaling voltage and clock rate capability.

well, I have just checked again, the Italian Wikipedia and the English
Wikipedia do not report the same things about the PCI_X

X___X

in short, the Italian Wikipedia says PCI64 = PCI_X, just PCI64 is clocked slower
while the English Wikipedia says PCI64 != PCI_X, but it doesn't explain why

And the https://www.openpa.net/bus.html#pci doc is even more confusing
in the table about the PCI buses used in PA-RISC computers overview:
why things are named differently?!?

What makes me perplex is: the PCI-X is physically a 3.3 V PCI slot
with/out a voltage level shifter.
So levels should be compatible, but so what is the difference between
64-bit PCI slot and PCI-X slot?

In my head, there shouldn't be any significant physical differences
between the slots. The newer PCI cards - 3.3V will fit and work in a
PCI-X slot, and PCI-X cards will fit in an older PCI slot as long as
the voltage - 3.3V - matches, and they should do!

Now, I am even more perplex: need to check the PCI-64 and PCI-X specs,
and compare them.

Re: C3600, sata controller

[John David Anglin]

On 2019-05-13 7:47 p.m., Carlo Pisani wrote:
> So levels should be compatible, but so what is the difference between
> 64-bit PCI slot and PCI-X slot?
There is no difference in the slots except PCI-X slots are always 3.3V and a 5V card won't work in them.
The difference is in the bus protocol and timing.

This is what I see in wikipedia:

"In PCI, a transaction that cannot be completed immediately is postponed by either the target or the initiator issuing retry-cycles, during
which no other agents can use the PCI bus. Since PCI lacks a split-response mechanism to permit the target to return data at a later time, the
bus remains occupied by the target issuing retry-cycles until the read data is ready. In PCI-X, after the master issues the request, it
disconnects from the PCI bus, allowing other agents to use the bus. The split-response containing the requested data is generated only when the
target is ready to return all of the requested data. Split-responses increase bus efficiency by eliminating retry-cycles, during which no data
can be transferred across the bus.

PCI also suffered from the relative scarcity of unique interrupt lines. With only 4 interrupt lines (INTA/B/C/D), systems with many PCI devices
require multiple functions to share an interrupt line, complicating host-side interrupt-handling. PCI-X added Message Signaled Interrupts
<https://en.wikipedia.org/wiki/Message_Signaled_Interrupts>, an interrupt system using writes to host-memory. In MSI-mode, the function's
interrupt is not signaled by asserting an INTx line. Instead, the function performs a memory-write to a system-configured region in host-memory.
Since the content and address are configured on a per-function basis, MSI-mode interrupts are dedicated instead of shared. A PCI-X system allows
both MSI-mode interrupts and legacy INTx interrupts to be used simultaneously (though not by the same function.)

The lack of registered I/Os limited PCI to a maximum frequency of 66 MHz. PCI-X I/Os are registered to the PCI clock, usually through means of a
PLL to actively control I/O delay the bus pins. The improvement in setup time allows an increase in frequency to 133 MHz."

Nominally, one would think a PCI-X card would fall back to PCI mode but maybe this needs firmware
support.

I still think the 3.3V signalling of a PCI-X card likely is incompatible with 5V signalling in c3600.  A 5V
card won't work in a PCI-X slot.  Only slot SL2 is 3.3V.

Wiki also says:

"Many 64-bit PCI-X cards are designed to work in 32-bit mode if inserted in shorter 32-bit connectors, with some loss of speed.[19][20] An
example of this is the Adaptec 29160 64-bit SCSI interface card.[21] However some 64-bit PCI-X cards do not work in standard 32-bit PCI slots.[22]"

So, I think you can only use 5V or universal conventional PCI cards in c3600 (except for slot SL2).

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/

Dave
-- 

John David Anglin  dave.anglin@bell.net

Re: C3600, sata controller

[Carlo Pisani]

> "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.

Re: C3600, sata controller

[John David Anglin]

On 2019-05-14 4:15 a.m., Carlo Pisani wrote:
> 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.
I agree but it appears fallback requires BIOS or a QUIRK to configure card.  One would have to
look at driver and/or BIOS to see what is/can done. Maybe OpenBIOS has something.

There is ENABLE_HARDFAIL config option in lba_pci.c which determines whether HPMC occurs.
Soft fail might be useful to debug.  However, I doubt there's enough public information to configure
card given what Alan said.
>
>
>> 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 listed these cards because they are PCI64 and the Adaptec site didn't say Intel
architecture was required.  There was one card that claimed to be PCI-X and PCI64
(both 3.3 and 5V signalling) but it required Intel or AMD architecture.

Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: C3600, sata controller

[Carlo Pisani]

> I had listed these cards because they are PCI64 and the Adaptec site didn't say Intel
> architecture was required.

Adaptec AAR-2410SA was tested on x86, C3600, and Apple PowerMac G4
MDD. It worked only on x86.

01:10:15.0 RAID bus controller: Adaptec AAC-RAID (rev 01)
        Subsystem: Adaptec AAR-2410SA PCI SATA 4ch (Jaguar II)
        Flags: 66MHz, slow devsel, IRQ 58
        Memory at 84000000 (32-bit, prefetchable) [size=64M]
        Expansion ROM at 80088000 [disabled] [size=32K]
        Capabilities: [80] Power Management version 2

Alan Cox explained some reasons for this. His email is long, and not
public, so I summarize what I have understood.

as soon as the computer bootstraps, the firmware in its BIOS scans
every PCI-peripherical for any BIOS-extension, it finds then there is
a BIOS-extension ROM on the SATA-card, and it loads and executes it:
the flash-chip on the card contains x86 opcode! The ROM initializes
some features on the SATA-card and loads and bootstraps a firmware
there (the firmware is contained in the flash, but it somehow requires
to be launched by the PC, dunno how/what), the PC goes ahead and
bootstrap the OS-loader (Grub? Lilo? ... this stuff), the Linux kernel
is loaded and bootstrapped too, the kernel is now running, and it
probes for the SATA-controller device and it finds it, so the
kernel-driver finds the SATA-controller already configured and - it's
running its own firmware - so, when the kernel issues commands, it
responds properly!

So, if you put the Adaptec AAR-2410SA SATA-card into a non-x86
computer ... the BIOS extension is not expected, and the Linux kernel
does not find the SATA correctly configured-card, in fact, the kernel
complains the card is not even found running its own firmware running,
and this can't be fixed unless you do a full reverse-engineering of
flash-code, in order to create a new kernel-driver able to directly
initialize the card instead of waiting for the job done by the
PC-BIOS.

hardware RAID cards are usually problematic for the same reason.

C3600, optical Fibre Channel, any card?

[Carlo Pisani]

hi guys
anyone has ever tried an optical Fibre Channel adapter with C36xx or C37xx?
e.g. QLA2302F is PCI-X, so ... I have some doubt.

let me know

Re: C3600, sata controller

[Sven Schnelle]

On Tue, May 14, 2019 at 02:29:07PM +0200, Carlo Pisani wrote:
> > I had listed these cards because they are PCI64 and the Adaptec site didn't say Intel
> > architecture was required.
> 
> So, if you put the Adaptec AAR-2410SA SATA-card into a non-x86
> computer ... the BIOS extension is not expected, [..]

I think the ATI FireGL card in the C8000 Workstation is a normal x86 graphics
card and PDC just emulates the stuff required to execute the VGA BIOS. Would
be interesting whether it would also execute a BIOS on a PCI-X card, but i would
guess not. So a x86 BIOS in the C8000 is not always unexpected.

Sven

Re: C3600, sata controller

[John David Anglin]

On 2019-05-14 9:01 a.m., Sven Schnelle wrote:
> On Tue, May 14, 2019 at 02:29:07PM +0200, Carlo Pisani wrote:
>>> I had listed these cards because they are PCI64 and the Adaptec site didn't say Intel
>>> architecture was required.
>> So, if you put the Adaptec AAR-2410SA SATA-card into a non-x86
>> computer ... the BIOS extension is not expected, [..]
> I think the ATI FireGL card in the C8000 Workstation is a normal x86 graphics
> card and PDC just emulates the stuff required to execute the VGA BIOS. Would
> be interesting whether it would also execute a BIOS on a PCI-X card, but i would
> guess not. So a x86 BIOS in the C8000 is not always unexpected.
Maybe this is why SY-PCX40009 works in c8000 and not in c3600.  It would be interesting to try
AAR-2410SA in c8000.

Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: C3600, sata controller

[Carlo Pisani]

guys, new tests(1) with SYBA-SY-PCX40009 on C3600
tested on different slots: it always fails with the same behavior

I really do not understand the random failure, because it seems
working for a while, and then, it suddenly fails I don't know how to
investigate.

(1)
http://www.downthebunker.com/reloaded/space/viewtopic.php?f=50&t=337&p=1663

Re: C3600, sata controller

[Helge Deller]

Hi Carlo,

On 17.05.19 17:43, Carlo Pisani wrote:
> guys, new tests(1) with SYBA-SY-PCX40009 on C3600
> tested on different slots: it always fails with the same behavior
> (1) http://www.downthebunker.com/reloaded/space/viewtopic.php?f=50&t=337&p=1663
>
> I really do not understand the random failure, because it seems
> working for a while, and then, it suddenly fails I don't know how to
> investigate.

Random failure could happen because of missing calls to DMA syncs in the driver.
PCI device drivers on PA-RISC require that you strictly follow the rules as mentioned in:
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/DMA-API-HOWTO.txt
and
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/DMA-API.txt

Not following those rules may lead to the same device driver working on x86
but failing on parisc, simply because x86 is much more relaxed regarding DMA
and CPU caches.

That said, I would not expect every device driver to work out of the box
on parisc...

Helge

Re: C3600, sata controller

[John David Anglin]

On 2019-05-17 1:21 p.m., Helge Deller wrote:
> Hi Carlo,
>
> On 17.05.19 17:43, Carlo Pisani wrote:
>> guys, new tests(1) with SYBA-SY-PCX40009 on C3600
>> tested on different slots: it always fails with the same behavior
>> (1) http://www.downthebunker.com/reloaded/space/viewtopic.php?f=50&t=337&p=1663
>>
>> I really do not understand the random failure, because it seems
>> working for a while, and then, it suddenly fails I don't know how to
>> investigate.
> Random failure could happen because of missing calls to DMA syncs in the driver.
> PCI device drivers on PA-RISC require that you strictly follow the rules as mentioned in:
> * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/DMA-API-HOWTO.txt
> and
> * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/DMA-API.txt
>
> Not following those rules may lead to the same device driver working on x86
> but failing on parisc, simply because x86 is much more relaxed regarding DMA
> and CPU caches.
>
> That said, I would not expect every device driver to work out of the box
> on parisc...
It seems likely to me that the sil24 driver depends on the card operating in PCI-X mode.  As noted
previously, PCI-X differs from PCI in interrupt handling.  The driver has this flag SIL24_FLAG_PCIX_IRQ_WOC.

There's this comment:
        /* If PCIX_IRQ_WOC, there's an inherent race window between
         * clearing IRQ pending status and reading PORT_SLOT_STAT
         * which may cause spurious interrupts afterwards.  This is
         * unavoidable and much better than losing interrupts which
         * happens if IRQ pending is cleared after reading
         * PORT_SLOT_STAT.
         */
Maybe the workaround shouldn't be applied when card is in PCI 66 MHz slot?  See drivers/ata/sata_sil24.c.
https://www.mail-archive.com/linux-ide@vger.kernel.org/msg11502.html
https://www.mail-archive.com/linux-ide@vger.kernel.org/msg11516.html

The card works in my c8000 PCI-X slot.

Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: C3600, sata controller

[Carlo Pisani]

> > Random failure could happen because of missing calls to DMA syncs in the driver.

we have tested several drivers and cards, these show the same behavior
-a- Highpoint RocketRAID 1640 HTP374 (PCI)
-b- HighPoint RocketRAID 2224Marvell MV88SX6081 (PCI-X)
-c- SYBA-SY-PCX40009Silicon Image Sil3124 (PCI-X)

I don't know about the HTP374 because it hasn't yet been tested on our
PowerMac-G4, but about other cards:
- they perfectly work on the PowerMacG4 MDD
- they perfectly work on our x86-box (intel core duo)
- they randomly fail in the same way on the C3600

this might mean something. I Don't know.

Anyway, even the I/O performance is not good on our C3600: none of the
above move more than 20Mbyte/sec, while the internal SCSI moves
60Mbyte/sec.

So I wonder if there is something really really wrong with the DMA:
it's too slow!

Re: C3600, sata controller

[Carlo Pisani]

hi, good news!
after a burn-in test of 8hours, we can affirm that Adaptec 1210SA does work
The chip is "Silicon Image Sil31122", so the kernel module is
"sata_sil" (not sata_sil24)

while [ 1 ]
do
for item in `ls *.bin`
    do
        rm -f $copy.out
        echo -n "$item ... "
        mycp $item $copy.out
        echo "done"
    done
done

*.bin are giant files, 1GB, 2GB, 4GB, 8GB, 16GB, 32GB

it has been tested on a PCI 32bit lost of a C3600
with kernel /v4.16!!!

"mycp" does a copy and then checks the md5 checksum

I think this card can be added to the list!

Our list has been already updated
http://www.downthebunker.com/reloaded/space/viewtopic.php?f=50&p=1632

Re: C3600, sata controller

[Carlo Pisani]

about C3600 and C3750, is there any known working PCI-X card?

anyone has ever tried:
- optical fiber channel cards?
- Infiniband cards?

I ask this because none of our  PCI-X SATA cards seems to be working
we will try with a PCI-X SCSI card, but first, we have to buy a couple

Re: C3600, sata controller

[Carlo Pisani]

> I asked a friend to lend us his card, which is the card2 listed below
> and not things are becoming really weird

> card1, Silicon Image, Inc. Adaptec AAR-1210SA
> card2, Silicon Image, Inc. SiI 3124 PCI-X Serial ATA

card1 is not PCI-X, the chip is PCI. So it's not problematic.
card2 is PCI-X, the chip is PCI-X

on which machine have you tested card2? C36xx? C37xx? C8000?
and with which test(1)? how long, and with which result?

(1) ours are published on the website

Re: C3600, sata controller

[Carlo Pisani]

guys?
yahoooooooooooooooo, SYBA-SY-PCX40009 does woooork :D :D

02:03.0 RAID bus controller: Silicon Image, Inc. SiI 3124 PCI-X Serial
ATA Controller (rev 01)

10 hours burn-in test passed!!!!

while [ 1 ]
do
for item in `ls *.bin`
    do
        rm -f $copy.out
        echo -n "$item ... "
        time cp_and_check_md5sum $item $copy.out
        echo "done"
    done
done

kernel 5.1, from the git repository, compiled with SMP

dmesg | grep altern
[    2.551002] alternatives: applied 156 out of 175 patches

only applied this patch:

--- a/arch/parisc/include/asm/cache.h
+++ b/arch/parisc/include/asm/cache.h
@@ -52,7 +52,6 @@ void parisc_setup_cache_timing(void);

 #define asm_io_fdc(addr) asm volatile("fdc %%r0(%0)" \
                        ALTERNATIVE(ALT_COND_NO_DCACHE, INSN_NOP) \
-                       ALTERNATIVE(ALT_COND_NO_IOC_FDC, INSN_NOP) \
                        : : "r" (addr) : "memory")
 #define asm_io_sync()  asm volatile("sync" \
                        ALTERNATIVE(ALT_COND_NO_DCACHE, INSN_NOP) \

linux-next: Signed-off-by missing for commit in the parisc-hd tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 172 bytes --]

Hi all,

Commit

  9baece83a913 ("parisc: Add nop instructions after TLB inserts")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: Signed-off-by missing for commit in the parisc-hd tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

Hi all,

Commits

  71174cc59436 ("parisc: Add lws_atomic_xchg and lws_atomic_store syscalls")
  8e38228709b0 ("parisc: Rewrite light-weight syscall and futex code")
  3a747b528b6d ("parisc: Enhance page fault termination message")
  e62aecc32fac ("parisc: Don't call faulthandler_disabled() in do_page_fault()")

are missing a Signed-off-by from their committer.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: Signed-off-by missing for commit in the parisc-hd tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 178 bytes --]

Hi all,

Commit

  cad7eadf2afb ("parisc: Use swap() to swap values in setup_bootmem()")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: Signed-off-by missing for commit in the parisc-hd tree

[Helge Deller]

On 11/1/21 11:44, Stephen Rothwell wrote:
> Commit
>   cad7eadf2afb ("parisc: Use swap() to swap values in setup_bootmem()")
> is missing a Signed-off-by from its committer.

Thanks, fixed now.

Helge

linux-next: Signed-off-by missing for commit in the parisc-hd tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 169 bytes --]

Hi all,

Commit

  ca7222dcfff4 ("parisc: Bump 64-bit IRQ stack size to 64 KB")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: Signed-off-by missing for commit in the parisc-hd tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 165 bytes --]

Hi all,

Commit

  41fbb820b797 ("PARISC: elf.h: delete a duplicated word")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: Signed-off-by missing for commit in the parisc-hd tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 166 bytes --]

Hi all,

Commit

  7148d434d451 ("parisc: asm: psw.h: missing header guard")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: Signed-off-by missing for commit in the parisc-hd tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 184 bytes --]

Hi all,

Commit

  f17bbdb5eea2 ("parisc: Remove PTE load and fault check from L2_ptep macro")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: Signed-off-by missing for commit in the parisc-hd tree

[Helge Deller]

[-- Attachment #1.1: Type: text/plain, Size: 221 bytes --]

On 01.10.2018 03:04, Stephen Rothwell wrote:
> Commit
>   f17bbdb5eea2 ("parisc: Remove PTE load and fault check from L2_ptep macro")
> is missing a Signed-off-by from its committer.

Fixed now.

Thanks!
Helge


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]