dmesg 출력 - 모드 인식 - 바이트 해석

dmesg 출력 - 모드 인식 - 바이트 해석

실행 dmesg및 grep은 [sda] Mode Sense:다음과 같은 줄을 반환합니다.

[sda] Mode Sense: 00 3a 00 00

이 4바이트의 데이터는 무엇을 나타냅니까 00 3a 00 00?

대답은 다음과 같은 후속 출력 줄에 포함될 수 있습니다.

[sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

...하지만 데이터를 설명에 매핑하는 방법을 알고 싶습니다.

답변1

이는 모드 감지 명령(drivers/scsi/sd.c, sd_mode_sense() 참조)에서 반환된 버퍼의 처음 4바이트입니다. drivers/scsi/scsi_lib.c, scsi_mode_sense())를 보면 이것이 무엇을 의미하는지 알 수 있습니다. 이 루틴은 설명에 따르면 버퍼의 처음 두 개 모드 헤더 데이터를 추상화하는 "data"라는 구조를 반환합니다. 첫 번째 바이트(00 및 3a)는 "데이터" 길이에서 2를 뺀 상위/하위 바이트이고, 세 번째 바이트(00)는 media_type이고, 네 번째 바이트는 장치별 바이트입니다.

        data->length = buffer[0]*256 + buffer[1] + 2;
        data->medium_type = buffer[2];
        data->device_specific = buffer[3];

따라서 data->length는 0*256 + 0x3a + 2 = 60, media_type은 0입니다. 네 번째 바이트가 무엇을 의미하는지 아는 사람은... (BTW, printkMode Sense: 를 인쇄하는 줄이 표시되어 있으므로 KERN_DEBUG일반용에는 적합하지 않습니다. 소비).

번역에 많은 노력을 들이지 않고도 패키지 sg_modes에 포함된 내용을 사용하여 이와 같은 내용을 확인할 수 있습니다 .sg3_utils

 # sg_modes -a /dev/sg0
    ATA       SAMSUNG MZ7LN512  4L0Q   peripheral_type: disk [0x0]
Mode parameter header from MODE SENSE(10):
  Mode data length=60, medium type=0x00, WP=0, DpoFua=0, longlba=0
  Block descriptor length=8
> Direct access device block descriptors:
   Density code=0x0
 00     00 00 00 00 00 00 02 00

>> Read-Write error recovery, page_control: current
 00     01 0a 80 00 00 00 00 00  00 00 00 00
>> Caching, page_control: current
 00     08 12 04 00 00 00 00 00  00 00 00 00 00 00 00 00
 10     00 00 00 00
>> Control, page_control: current
 00     0a 0a 02 00 00 00 00 00  ff ff 00 1e

당신이 언급한 다른 줄은 다음과 같습니다.

Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

sd_read_cache_type의 루틴에서 생성됩니다 drivers/scsi/sd.c. 이 정보를 얻기 위해 몇 가지 다른 소스를 사용합니다. 쓰기 및 읽기 캐시 정보는 modepage==8 버퍼의 특정 바이트를 확인하여 얻습니다. DPO/FUA 정보는 위의 "데이터" 구조에서 얻습니다. 반드시 동일한 데이터를 포함할 필요는 없습니다. 두 호출에 사용된 스키마 페이지는 다를 수 있습니다.

AFAICT, 이 줄의 정보와 위 디버깅 줄의 정보는 다음과 같습니다.아니요디.

관련 정보