에 따라 어떻게 USB3.0 UASP 모드가 리눅스에서 사용할 수 있는지 여부를 확인할 수 있습니까? , UASP는 UASP를 지원 한다고 말하는 새로운 HDD 인클로저에서 사용되지 않습니다 .
또한 내 마더 보드의 (ASUS M5A99FX PRO R2.0) 매뉴얼은 다음과 같이 말합니다.
USB 3.0 부스트 ASUS USB 3.0 부스트 기술은 최신 USB 3.0 표준 인 UASP (USB Attached SCSI Protocol)를 지원합니다. USB 3.0 부스트 기술을 사용하면 USB 장치의 전송 속도가 최대 170 %까지 크게 향상되어 이미 인상적인 빠른 USB 3.0 전송 속도가 추가됩니다. ASUS 소프트웨어는 사용자 상호 작용없이 호환되는 USB 3.0 주변 장치의 데이터 속도를 자동으로 가속화합니다.
따라서 마더 보드 지원 및 장치 지원 (및 Linux 지원 )에서 UASP를 사용하지 않는 이유는 무엇이며 어떻게 사용합니까?
또는 아마도 사용 중이며 확인 방법을 모르겠습니다. 관련 출력 lsusb -t:
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
|__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
편집
Fedora 21 (64 비트)에서 Linux 4.0.8을 실행하고 있습니다.
2 편집
결과는 다음과 같습니다 lsmod | grep uas.
uas 24576 0
usb_storage 65536 1 uas
dmesg도킹 스테이션을 켜면 생성 된 모든 출력 은 다음과 같습니다 (HDD 포함).
[173791.566332] usb 2-2: new SuperSpeed USB device number 4 using xhci_hcd
[173791.581802] usb 2-2: New USB device found, idVendor=174c, idProduct=55aa
[173791.581809] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[173791.581814] usb 2-2: Product: ASMT1053
[173791.581818] usb 2-2: Manufacturer: asmedia
[173791.581822] usb 2-2: SerialNumber: 123456789012
[173791.583705] usb-storage 2-2:1.0: USB Mass Storage device detected
[173791.583933] usb-storage 2-2:1.0: Quirks match for vid 174c pid 55aa: 400000
[173791.583981] scsi host11: usb-storage 2-2:1.0
[173792.587494] scsi 11:0:0:0: Direct-Access ASMT 2105 0 PQ: 0 ANSI: 6
[173792.588048] sd 11:0:0:0: Attached scsi generic sg3 type 0
[173792.589870] sd 11:0:0:0: [sdc] Spinning up disk...
[173793.589663] .......ready
[173799.606012] sd 11:0:0:0: [sdc] 625142448 512-byte logical blocks: (320 GB/298 GiB)
[173799.606599] sd 11:0:0:0: [sdc] Write Protect is off
[173799.606606] sd 11:0:0:0: [sdc] Mode Sense: 43 00 00 00
[173799.607092] sd 11:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[173799.624914] sdc: sdc2
[173799.626624] sd 11:0:0:0: [sdc] Attached SCSI disk
답변
보고에서 UAS-detect.h 나는 인클로저의 ASM1053 칩이 실제로 UAS 드라이버 (이 큰 전송에 버그가있는 경우에도)에 의해 지원되는 것을 확인할 수 있습니다.
devices.alias 파일을 수정하여 장치 ID에 대한 지원을 추가 할 수 있습니다. 불행히도 depmod시스템의 어떤 항목으로 다시 실행 되면 해당 변경 사항을 modules.alias 파일에 다시 실행해야합니다.
두 번째 옵션은 장치 ID 지원을 알리고 모듈을 다시 빌드하기 위해 UAS 커널 모듈을 패치하는 것입니다. 이 작업을 수행하고 좋은 패치를 다시 업스트림으로 푸시하면 HD 인클로저 Linux UAS 지원을 가진 모든 사람을 얻을 수도 있습니다.
답변
비슷한 문제가있는 사람 이이 스레드에서 우연히 발견되는 경우 …
대부분의 장치 드라이버 커널 모듈과 달리 usb-storage 및 uas 드라이버는 알려진 장치 ID 목록을 기반으로 작동하지 않지만 대신 uas-detect.h 파일의 uas_use_uas_driver () 함수에있는 감지 논리 를 사용합니다. 장치가 UAS 프로토콜을 지원한다고 주장하는지에 대한 결정. ( 디바이스 별명에 관한 이 linuxquestions.org 스레드 도 참조하십시오 .)
이 경우 하나 또는 다른 모듈을 블랙리스트에 올리면 아무런 차이가 없습니다. uas_use_uas_driver ()가 true를 리턴하면 uas.c가이를 청구하고 usb.c가이를 거부하고 함수가 false를 리턴하면 그 반대가 발생합니다.
(대신 커널 명령 행 매개 변수 문서에 설명 된대로 uas 드라이버 가 장치를 요구하지 않도록 구성 설정 “usb-storage.quirks = VID : PID : u”가 있습니다 . [다른 방향으로 강제하는 플래그는 없습니다.])
OP의 문제 : 문제는 일반적으로 커널이 USB ID를 직접 사용하여 장치에 특별한 처리가 필요한지 여부를 결정할 수 있지만 ID 0x174c : 0x55aa의 경우 ASMedia는 다른 칩셋에 대해 동일한 ID를 재사용했습니다. UAS 지원 수준. 따라서 uas_use_uas_driver () 함수는 실제로 사용중인 칩셋을 확인하기 위해 장치의 특정 속성을 확인한 다음이를 기반으로 해당 장치에 uas 드라이버를 사용할지 여부를 결정해야합니다. 불행히도 이런 일이 발생하면 결정한 내용을 명시 적으로 나타 내기 위해 생성 된 커널 메시지가 없습니다.
(아마도 "lsusb -v -d174c:55aa"uas_use_uas_driver () 함수의 주석과 함께 출력을 사용하여 특정 장치에서 발생한 상황과 이유를 확인할 수 있습니다. 그러나 어쨌든 감지 논리는 장치가 연결될 때 dmesg 라인의 일부로 인쇄되는 제품 문자열 (예 : “ASMT1053”]-해당 이름은 실제로 uas-detection logic이 특정 장치에 대해 결정하는 내용에 대해 아무 것도 알려주지 않습니다.)