XPost: linux.debian.user

Hi all,

I tried to install Bullseye on my MacBookAir6,1 but the SSD is not detected:

ACPI: SSDT 0x000000008CD7E000 00010B (v01 APPLE SataAhci 00001000
INTL 20100915)
libata version 3.00 loaded.
ahci 0000:04:00.0: version 3.0
ahci 0000:04:00.0: AHCI 0001.0000 32 slots 1 ports 6 Gbps 0x1 impl SATA mode ahci 0000:04:00.0: flags: 64bit ncq sntf led pio slum part
scsi host0: ahci
ata1: SATA max UDMA/133 abar m512@0xb0700000 port 0xb0700100 irq 54
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Write] Request device [04:00.1] PASID ffffffff fault addr
fffe0000 [fault reason 02] Present bit in context entry is clear
ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
DMAR: DRHD: handling fault status reg 3
DMAR: [DMA Write] Request device [04:00.1] PASID ffffffff fault addr
fffe0000 [fault reason 02] Present bit in context entry is clear
ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Write] Request device [04:00.1] PASID ffffffff fault addr
fffe0000 [fault reason 02] Present bit in context entry is clear
ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
DMAR: DRHD: handling fault status reg 3
DMAR: [DMA Write] Request device [04:00.1] PASID ffffffff fault addr
fffe0000 [fault reason 02] Present bit in context entry is clear
ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
ata1: limiting SATA link speed to 3.0 Gbps
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Write] Request device [04:00.1] PASID ffffffff fault addr
fffe0000 [fault reason 02] Present bit in context entry is clear
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
DMAR: DRHD: handling fault status reg 3
DMAR: [DMA Write] Request device [04:00.1] PASID ffffffff fault addr
fffe0000 [fault reason 02] Present bit in context entry is clear
ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Write] Request device [04:00.1] PASID ffffffff fault addr
fffe0000 [fault reason 02] Present bit in context entry is clear
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 320)

Buster and earlier releases work just well:

ACPI: SSDT 0x000000008CD7E000 00010B (v01 APPLE SataAhci 00001000
INTL 20100915)
libata version 3.00 loaded.
ahci 0000:04:00.0: version 3.0
ahci 0000:04:00.0: AHCI 0001.0000 32 slots 1 ports 6 Gbps 0x1 impl SATA mode ahci 0000:04:00.0: flags: 64bit ncq sntf led pio slum part
scsi host0: ahci
ata1: SATA max UDMA/133 abar m512@0xb0700000 port 0xb0700100 irq 49
ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata1.00: unexpected _GTF length (8)
ata1.00: ATA-8: APPLE SSD TS0128F, 109R0219, max UDMA/100
ata1.00: 236978176 sectors, multi 0: LBA48 NCQ (depth 32)
ata1.00: unexpected _GTF length (8)
ata1.00: configured for UDMA/100
scsi 0:0:0:0: Direct-Access ATA APPLE SSD TS0128 0219 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 236978176 512-byte logical blocks: (121 GB/113 GiB)
sd 0:0:0:0: [sda] 4096-byte physical blocks
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7
sd 0:0:0:0: [sda] Attached SCSI disk

Can anyone help me please?

Regards,
Nikolay

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

XPost: linux.debian.user

Nikolay Velyurov <nvelyurov@gmail.com> writes:

I tried to install Bullseye on my MacBookAir6,1 but the SSD is not detected:

ACPI: SSDT 0x000000008CD7E000 00010B (v01 APPLE SataAhci 00001000
INTL 20100915)
libata version 3.00 loaded.
ahci 0000:04:00.0: version 3.0
ahci 0000:04:00.0: AHCI 0001.0000 32 slots 1 ports 6 Gbps 0x1 impl SATA mode ahci 0000:04:00.0: flags: 64bit ncq sntf led pio slum part
scsi host0: ahci
ata1: SATA max UDMA/133 abar m512@0xb0700000 port 0xb0700100 irq 54
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Write] Request device [04:00.1] PASID ffffffff fault addr
fffe0000 [fault reason 02] Present bit in context entry is clear

try booting with intel_iommu=off on the kernel command line



Bjørn

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

XPost: linux.debian.user

Hi Bjørn,

On Sat, Aug 21, 2021 at 7:42 AM Bjørn Mork <bjorn@mork.no> wrote:

try booting with intel_iommu=off on the kernel command line

It works now, thanks for your help. Is there a known bug or something?

Nikolay

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

XPost: linux.debian.user

On Sat, Aug 21, 2021 at 7:42 AM Bjørn Mork <bjorn@mork.no> wrote:

try booting with intel_iommu=off on the kernel command line

It works now, thanks for your help.

Great! Glad it could be resolved as easily as that.

Is there a known bug or something?

Probably a firmware bug. I don't know. Such issues are pretty common,
and disabling the IOMMU is the first thing you should try. Sometimes
it just doesn't play well with some other feature. If you don't need
it then you might as well just disable it.

My Thinkpad fails to suspend if I enable both IOMMU and TPM 2.0. One of
them is OK, but not both. Go figure. This is https://bugs.debian.org/949020

For some background: https://www.kernel.org/doc/html/latest/x86/intel-iommu.html

There are also a number of other options than "off" you could try if you
want to play with it: https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html

Note that the bug has probably always been there in your PC firmware.
It showed up now because Debian changed the default from "off" to "on".



Bjørn

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

XPost: linux.debian.user

Hi Bjørn,

On Sat, Aug 21, 2021 at 4:38 PM Bjørn Mork <bjorn@mork.no> wrote:

Great! Glad it could be resolved as easily as that.

Probably a firmware bug. I don't know. Such issues are pretty common,
and disabling the IOMMU is the first thing you should try. Sometimes
it just doesn't play well with some other feature. If you don't need
it then you might as well just disable it.

My Thinkpad fails to suspend if I enable both IOMMU and TPM 2.0. One of
them is OK, but not both. Go figure. This is https://bugs.debian.org/949020

For some background: https://www.kernel.org/doc/html/latest/x86/intel-iommu.html

There are also a number of other options than "off" you could try if you
want to play with it: https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html

Note that the bug has probably always been there in your PC firmware.
It showed up now because Debian changed the default from "off" to "on".

Bjørn

Thanks for the explanation, very helpful!

Nikolay

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