Re: How to match disk to controller in Linux log?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/21/22 13:55, Damien Le Moal wrote:
On 2022/03/21 18:52, Hannes Reinecke wrote:
On 3/21/22 09:44, Paul Menzel wrote:
Dear Linux folks,


AMD Ryzen devices come with two SATA controllers:

      $ lspci -nn | grep SATA
      01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD]
300 Series Chipset SATA Controller [1022:43b7] (rev 02)
      07:00.2 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD]
FCH SATA Controller [AHCI mode] [1022:7901] (rev 51)

lsscsi [1] in verbose mode shows the controller a disk is actually
attached to.

      $ lsscsi -v
      [0:0:0:0]    disk    ATA      ST500LM021-1KJ15 SDM1  /dev/sda
        dir: /sys/bus/scsi/devices/0:0:0:0
[/sys/devices/pci0000:00/0000:00:01.3/0000:01:00.1/ata1/host0/target0:0:0/0:0:0:0]


For analysis and bug reports, it’d be great if the Linux kernel log
would contain that information too. But I am unable to find it. Is it
present?

      [    0.426850] calling  ahci_pci_driver_init+0x0/0x1a @ 1
      [    0.426869] ahci 0000:01:00.1: version 3.0
      [    0.426970] ahci 0000:01:00.1: SSS flag set, parallel bus scan
disabled
      [    0.427004] ahci 0000:01:00.1: AHCI 0001.0301 32 slots 8 ports 6
Gbps 0x33 impl SATA mode
      [    0.427008] ahci 0000:01:00.1: flags: 64bit ncq sntf stag pm led
clo only pmp pio slum part sxs deso sadm sds apst
      [    0.427412] scsi host0: ahci
      [    0.427493] scsi host1: ahci
      [    0.427569] scsi host2: ahci
      [    0.427653] scsi host3: ahci
      [    0.427728] scsi host4: ahci
      [    0.427801] scsi host5: ahci
      [    0.427876] scsi host6: ahci
      [    0.427950] scsi host7: ahci
      [    0.427978] ata1: SATA max UDMA/133 abar m131072@0xf0600000 port
0xf0600100 irq 36
      [    0.427982] ata2: SATA max UDMA/133 abar m131072@0xf0600000 port
0xf0600180 irq 36
      [    0.427985] ata3: DUMMY
      [    0.427986] ata4: DUMMY
      [    0.427988] ata5: SATA max UDMA/133 abar m131072@0xf0600000 port
0xf0600300 irq 36
      [    0.427991] ata6: SATA max UDMA/133 abar m131072@0xf0600000 port
0xf0600380 irq 36
      [    0.427994] ata7: DUMMY
      [    0.427995] ata8: DUMMY
      [    0.428015] ata1: hard resetting link
      [    0.428116] ahci 0000:07:00.2: AHCI 0001.0301 32 slots 1 ports 6
Gbps 0x1 impl SATA mode
      [    0.428124] ahci 0000:07:00.2: flags: 64bit ncq sntf ilck pm led
clo only pmp fbs pio slum part
      [    0.428250] scsi host8: ahci
      [    0.428278] ata9: SATA max UDMA/133 abar m4096@0xf0108000 port
0xf0108100 irq 38
      [    0.428295] initcall ahci_pci_driver_init+0x0/0x1a returned 0
after 1409 usecs
      […]
      [    0.428316] ata9: hard resetting link
      [    0.532308] ata9: SATA link down (SStatus 0 SControl 300)
      [    0.696316] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
      [    0.725963] ata1.00: ATA-8: ST500LM021-1KJ152, 0005SDM1, max
UDMA/133
      [    0.725982] ata1.00: 976773168 sectors, multi 16: LBA48 NCQ
(depth 32)
      [    0.764845] ata1.00: configured for UDMA/133

Can you think of a way and log format, what controller the disk is
actually attached to?

      [    0.765133] ata2: hard resetting link
      [    0.868330] ata2: SATA link down (SStatus 0 SControl 300)
      [    0.868965] ata5: hard resetting link
      [    0.973337] ata5: SATA link down (SStatus 0 SControl 300)
      [    0.973910] ata6: hard resetting link
      [    1.077832] ata6: SATA link down (SStatus 0 SControl 300)


It's 'magic' ... (/me waves magic wand)
One does know where the ports are ... no?

I did do a patch once (grep for 'libata: sysfs naming option'), but that
got shelved as I didn't had a good idea how to handle PMP devices.

Seems that I have to look at it again ...

Yes, that would be great. I have a PMP box hooked up to my test rig now, and for
good measure, it is filled with the oldest drives I could find (10+ years old
drives that still work fine).
I am waiting to test your patch :)

Patches sent.
Happy testing.

Cheers,

Hannes
--
Dr. Hannes Reinecke                Kernel Storage Architect
hare@xxxxxxx                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer



[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux