Hi,

I guess this is related also to the Atari platform: https://lore.kernel.org/lkml/20210318045706.200458-1-hch@lst.de/ ? Or has Falcon/Milan/Hades been using libata already?

Cheers,
Miro

<div dir="ltr">Hi,<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"></div></div><div><br></div><div>I guess this is related also to the Atari platform: <a href="https://lore.kernel.org/lkml/20210318045706.200458-1-
hch@lst.de/">https://lore.kernel.org/lkml/20210318045706.200458-1-hch@lst.de/</a> ? Or has Falcon/Milan/Hades been using libata already?</div><div><br></div><div>Cheers,</div><div>Miro</div><div><br></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/21/21 9:49 AM, Miro Kropáček wrote:

I guess this is related also to the Atari platform: https://lore.kernel.org/lkml/20210318045706.200458-1-hch@lst.de/ ?

No, it's not.

Or has Falcon/Milan/Hades been using libata already?

Yes, I have pushed for the most important drivers to be converted. Amiga
and Atari are safe. There are two m68k-related drivers which have not
been converted to libata yet but that's because we don't have access to
the hardware in question.

I think one was the Q60 platform and the other m68k Macs with IDE, if I remember correctly.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Miro,

note that the libata driver for Falcon does not utilize interrupts due
to the interaction between IDE, SCSI and floppy hardware, the latter two
also making use of the ST-DMA chip which cannot be transparently checked
for DMA completion.

Instead, the libata driver polls for IDE command completion. This may
add a little latency, but that's probably offset by the lack of
contention between IDE and SCSI drivers in mixed IDE / SCSI operation.
In my tests, I haven't found any substantial impact from the driver
change (and I was quite sceptical of the libata driver performance).

Cheers,

Michael


Am 21.03.2021 um 22:16 schrieb John Paul Adrian Glaubitz:

On 3/21/21 9:49 AM, Miro Kropáček wrote:

I guess this is related also to the Atari platform:
https://lore.kernel.org/lkml/20210318045706.200458-1-hch@lst.de/ ?

No, it's not.

Or has Falcon/Milan/Hades been using libata already?

Yes, I have pushed for the most important drivers to be converted. Amiga
and Atari are safe. There are two m68k-related drivers which have not
been converted to libata yet but that's because we don't have access to
the hardware in question.

I think one was the Q60 platform and the other m68k Macs with IDE, if I remember correctly.

Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Michael!

On 3/22/21 3:31 AM, Michael Schmitz wrote:

note that the libata driver for Falcon does not utilize interrupts due to the interaction between IDE, SCSI and floppy hardware, the latter two also making use of the ST-DMA chip which cannot be transparently checked for DMA completion.

Instead, the libata driver polls for IDE command completion. This may add a little
latency, but that's probably offset by the lack of contention between IDE and SCSI
drivers in mixed IDE / SCSI operation. In my tests, I haven't found any substantial
impact from the driver change (and I was quite sceptical of the libata driver performance).

Is this a fundamental limitation of libata that interrupts are not supported or just
a limitation of pata_falcon?

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mär 22 2021, Stan Johnson wrote:

My issue with the retirement of legacy IDE isn't technical. Two of the systems that I use are a PowerBook Wallstreet and a PowerBook 3400c.
Both of these laptops have internal IDE drives, an external SCSI port,
and require BootX to boot into Linux. BootX wants explicit specification
of the root device (e.g. /dev/sda4, /dev/hda4, etc.). With libata, the
disk drive names change depending on what is connected to the SCSI port.
I'm aware that I can use "UUID=" or "LABEL=" in /etc/fstab, but that
naming convention doesn't work with BootX. So using BootX will become
more complicated depending on connected SCSI devices, if any.

Does it work to use /dev/disk/by-{uuid,label}/...?

Andreas.

--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Adrian,

On 22/03/21 8:27 pm, John Paul Adrian Glaubitz wrote:

Hi Michael!

On 3/22/21 3:31 AM, Michael Schmitz wrote:

note that the libata driver for Falcon does not utilize interrupts due to the
interaction between IDE, SCSI and floppy hardware, the latter two also making
use of the ST-DMA chip which cannot be transparently checked for DMA completion.

Instead, the libata driver polls for IDE command completion. This may add a little
latency, but that's probably offset by the lack of contention between IDE and SCSI
drivers in mixed IDE / SCSI operation. In my tests, I haven't found any substantial
impact from the driver change (and I was quite sceptical of the libata driver performance).

Is this a fundamental limitation of libata that interrupts are not supported or just
a limitation of pata_falcon?

Only affects pata_falcon, and this was a design decision of the libata
authors to not copy the clunky code that guards against simultaneous use
of IDE and SCSI/floppy on Falcon.

No other IDE hardware supported by libata appears to require such
locking. I'm sure it could be added back, but I won't open that
particular can of worms.

Cheers,

    Michael

Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 22 Mar 2021, Stan Johnson wrote:

My issue with the retirement of legacy IDE isn't technical. Two of the systems that I use are a PowerBook Wallstreet and a PowerBook 3400c.
Both of these laptops have internal IDE drives, an external SCSI port,
and require BootX to boot into Linux. BootX wants explicit specification
of the root device (e.g. /dev/sda4, /dev/hda4, etc.). With libata, the
disk drive names change depending on what is connected to the SCSI port.
I'm aware that I can use "UUID=" or "LABEL=" in /etc/fstab, but that
naming convention doesn't work with BootX. So using BootX will become
more complicated depending on connected SCSI devices, if any.

The /dev/hda, hdb etc. names are transient and don't refer to any
particular drive. That is, they have the same problem that /dev/sda, sdb
etc. have.

That is, if you plug or unplug ATA devices from the powerbook expansion
bay, you can alter the internal ATA (boot) device naming.

Changing the kernel .config can also affect internal ATA device naming:

config BLK_DEV_IDE_PMAC_ATA100FIRST
bool "Probe on-board ATA/100 (Kauai) first"
depends on BLK_DEV_IDE_PMAC
help
This option will cause the ATA/100 controller found in UniNorth2
based machines (Windtunnel PowerMac, Aluminium PowerBooks, ...)
to be probed before the ATA/66 and ATA/33 controllers. Without
these, those machine used to have the hard disk on hdc and the
CD-ROM on hda. This option changes this to more natural hda for
hard disk and hdc for CD-ROM.

Also, the legacy ide subsystem names devices according to the sequence in
which drivers are loaded, which is fragile.

Anyway, I admit that adopting libata makes a very old problem slightly
worse.

Even in Linux, it can be convenient (at least for me) to have /dev/hda
and /dev/hdb internal disks and, if connected, /dev/sdX external
disk(s).

We did find a solution for this. You can ensure that /dev/sda always
refers to an internal ATA drive by inhibiting the SCSI bus scan until
after the internal ATA devices are probed.

To do that, you have to set the "scsi_mod.scan=manual" kernel parameter.
Then, after the internal devices have been probed, you can scan the SCSI
bus manually after logging in, or automatically with the /etc/rc.local
script (or equivalent):

# echo "- - -" > /sys/class/scsi_host/hostX/scan

The main drawback of this is that SCSI partitions listed in /etc/fstab (if
any) won't get mounted early by the init scripts. They would get mounted
by udisks (or similar) after the explicit bus scan runs. (But you could
improve on that if you needed to.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/23/21 1:10 AM, Stan Johnson wrote:

On 3/22/21 5:37 PM, Andreas Schwab wrote:

On Mär 22 2021, Stan Johnson wrote:

My issue with the retirement of legacy IDE isn't technical. Two of the
systems that I use are a PowerBook Wallstreet and a PowerBook 3400c.
Both of these laptops have internal IDE drives, an external SCSI port,
and require BootX to boot into Linux. BootX wants explicit specification >>> of the root device (e.g. /dev/sda4, /dev/hda4, etc.). With libata, the
disk drive names change depending on what is connected to the SCSI port. >>> I'm aware that I can use "UUID=" or "LABEL=" in /etc/fstab, but that
naming convention doesn't work with BootX. So using BootX will become
more complicated depending on connected SCSI devices, if any.

Does it work to use /dev/disk/by-{uuid,label}/...?

Those don't work with BootX in Mac OS. I need to know what the real
name of the disk will be after booting (/dev/hda, /dev/hdb, /dev/sda, etc.).

Isn't the sourcecode for BootX available so that we could add support for accessing disks/partitions by label or UUID?

I haven't used block device names on my Amiga for a long time now.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)