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

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

 



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 :)

> 
> Cheers,
> 
> Hannes


-- 
Damien Le Moal
Western Digital Research




[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