2022년 9월, ThinkPad E14 Gen3를 구입한 뒤 이해하기 어려운 문제 하나를 만났다. 오래 사용하던 USB MIDI 키보드 컨트롤러인 iCON iKeyboard 5 NANO가 도무지 제대로 인식되지 않는 것이었다.
당시의 '삽질'은 다음 글에 기록해 두었다.
OneDrive 생태계의 일원이 되어 보기로 하다 - 조직 이름 바꾸기에는 성공하였지만... 그리고 iCON MIDI 키보드 인식 문제!
장치 관리자에 나타난 메시지는 다음과 같았다.
This device cannot start. (Code 10) Insufficient system resources exist to complete the API.
처음에는 Windows 11의 문제라고 생각했다. Windows를 다시 설치해 보기도 하고 나중에는 Windows 10으로 내려서 시험하기도 했지만 문제는 해결되지 않았다. 더 이상했던 것은 같은 iKeyboard 5 NANO가 다른 환경에서는 작동한다는 점이었다. Linux에서는 정상적으로 인식되었고 FluidSynth를 이용한 연주도 가능했다. 예전 Windows 컴퓨터에서도 작동한 적이 있었다.
그러니 장치가 완전히 고장 난 것도 아니었다. 그렇다고 ThinkPad의 USB 자체가 망가진 것도 아니었다. 몇 년 뒤 구입한 iCON iKeyboard 8 Nano는 바로 그 ThinkPad에 연결해도 정상적으로 작동했다.
대체 무엇이 문제였을까?
2026년, 다시 시작한 삽질
2026년 8월 마지막 날, 이 문제를 다시 파보기로 했다. 이번에는 장치 관리자에서 노란 느낌표를 바라보는 수준에서 그치지 않고, Windows의 USB ETW(Event Tracing for Windows)를 이용하여 USB stack의 어느 단계에서 장치 초기화가 실패하는지를 추적했다.
문제가 발생하던 iKeyboard 5 NANO의 firmware는 V1.05였다. V1.05 장치를 ThinkPad에 연결하면 USB device descriptor와 configuration descriptor는 정상적으로 읽혔다. Windows UCX(USB Host Controller Extension)도 MIDI endpoint를 생성하려 했다.
문제는 그 다음 단계였다.
USB descriptor read
↓
UCX endpoint creation
↓
xHCI Configure Endpoint Command
↓
Completion Code 17: Parameter Error
↓
endpoint deletion and retry
↓
USB Composite Device start failure
↓
Code 10
즉 드라이버 파일이 없거나 잘못 설치된 문제가 아니었다. iKeyboard 5 NANO는 USB class-compliant 장치이고, Windows에서는 Microsoft의 표준 USB composite driver가 정상적으로 선택되고 있었다. 문제는 훨씬 아래쪽, USB host controller가 endpoint를 실제로 구성하는 단계에서 발생하고 있었다.
수상한 숫자 하나: 4
USB descriptor를 자세히 비교하다가 흥미로운 차이를 발견했다. iKeyboard 5 NANO V1.05의 MIDI OUT bulk endpoint descriptor는 다음과 같았다.
09 05 02 02 04 00 00
^^
wMaxPacketSize = 4
반면 같은 ThinkPad에서 정상 작동하는 iKeyboard 8 Nano V1.06의
MIDI OUT endpoint는 wMaxPacketSize = 8이었다.
USB-MIDI 1.0의 MIDI Event Packet 자체는 4 byte이므로
wMaxPacketSize=4라는 값이 얼핏 보아 터무니없는 것은 아니다.
실제로 Linux와 일부 Windows 컴퓨터는 이 설정을 받아들였고 장치도 정상 작동했다. 그러나 문제의 ThinkPad에서는 이 endpoint를 xHCI controller에 설정하는 과정에서
Parameter Error가 발생했다.
펌웨어를 직접 고쳐야 하나?
공식 iKeyboard 5 NANO V1.05 firmware binary도 열어 보았다. 그 안에서 실제 USB endpoint descriptor를 그대로 찾을 수 있었다.
V1.05 @ 0x4044
09 05 02 02 04 00 00
^^
04를 08로 바꾼 실험용 firmware까지 만들어 두었다. 하지만 firmware를 직접 수정해서 장치에 쓰는 것은 이야기가 다르다.
잘못하면 멀쩡한 MIDI keyboard를 '벽돌'로 만들 수도 있다.
그래서 실제 flashing은 하지 않고 조금 더 조사하기로 했다.
그 판단은 옳았다.
그런데 V1.06 Beta가 있었다
iCON의 현재 firmware update 프로그램을 다시 살펴보다가 뜻밖의 항목을 발견했다.
iKeyboard 5Nano v1.05 iKeyboard 5Nano v1.06 (Beta)
내가 오랫동안 마지막 firmware라고 알고 있던 것은 V1.05였다.
제품 지원 페이지에서도 V1.05가 눈에 띄었기 때문에
그 이후 버전이 존재한다는 사실을 알지 못했다. 그러나 firmware updater가 읽어 오는 서버의 firmware.xml에는
V1.05와 함께 V1.06 (Beta)가 등록되어 있었다.
사무실의 정상 작동하는 PC에서 5 NANO를 V1.06 Beta로 업데이트했다. 그 뒤 문제의 ThinkPad에 다시 연결했다.
정상 작동했다.
USB Composite Device Status : OK Problem : CM_PROB_NONE iCON iKeyboard 5 Nano V1.06 Status : OK Problem : CM_PROB_NONE
같은 iKeyboard 5 NANO, 같은 ThinkPad E14 Gen3, 같은 Windows, 같은 USB hub였다.
바뀐 것은 firmware뿐이었다.
V1.05 → Code 10 V1.06 → 정상 작동
2022년에 처음 기록했던 문제가 4년 만에 해결되었다. 어이가 없네!
그리고 정말 4가 8로 바뀌어 있었다
V1.06을 설치한 뒤 Microsoft USBView를 이용하여 5 NANO의 USB descriptor를 다시 확인했다.
V1.05 V1.06 Beta ------------------------------------------------ MIDI IN wMaxPacketSize 8 8 MIDI OUT wMaxPacketSize 4 8
공식 V1.06 Beta firmware binary도 직접 내려받아 조사했다.
V1.06에서는 firmware 내부 구조가 달라져 descriptor의 위치가 이동해 있었지만, 동일한 MIDI OUT endpoint descriptor를 찾아 비교해 보니 다음과 같았다.
V1.05 @ 0x4044 09 05 02 02 04 00 00 V1.06 @ 0x420C 09 05 02 02 08 00 00
더 흥미로운 점은 이 부분 앞뒤의 USB MIDI descriptor가 거의 동일하다는 것이다.
즉 내가 V1.05 실험용 firmware에서 바꾸려고 했던 바로 그 값, MIDI OUT endpoint의 wMaxPacketSize 4 → 8 변경이 공식 V1.06에도 실제로 들어 있었다.
물론 V1.05와 V1.06 사이에는 다른 firmware 변경도 존재할 수 있다. 따라서 이 한 바이트 변경만이 유일한 해결 원인이었다고 단정할 수는 없다. 그러나 다음 세 가지 사실은 서로 매우 잘 맞아떨어진다.
- V1.05에서는 xHCI Configure Endpoint 명령이 Parameter Error로 실패한다.
- V1.06에서는 같은 ThinkPad에서 장치가 정상적으로 시작된다.
- V1.06에서는 MIDI OUT endpoint의 wMaxPacketSize가 4에서 8로 변경되었다.
따라서 이 값의 변경이 USB host controller 호환성 문제 해결과 직접 관련되어 있을 가능성은 매우 높다고 생각한다.
그런데 왜 V1.05도 어떤 컴퓨터에서는 잘 작동했을까?
이것이 이 문제에서 가장 흥미로운 부분이다.
wMaxPacketSize=4가 USB 규격상 완전히 잘못된 값이었다면
모든 컴퓨터에서 실패했어야 한다.
실제로는 그렇지 않았다. V1.05는 Linux에서 작동했고,
다른 Windows PC에서도 작동했다.
이번 조사에서도 Intel USB controller를 사용하는 사무실 PC에서는
같은 V1.05 장치가 아무 문제 없이 인식되었다.
따라서 V1.05를 단순히 '고장 난 firmware'라고 부르는 것보다는 특정 USB host controller와의 compatibility problem을 가진 firmware라고 표현하는 것이 더 적절할 것 같다.
어떤 USB host/controller stack에서는 OUT endpoint의
wMaxPacketSize=4를 받아들였지만,
내 ThinkPad의 AMD xHCI 환경에서는 endpoint configuration 단계에서
이를 받아들이지 않고 Parameter Error를 반환했다. V1.06에서 이 값이 8로 변경되자 같은 ThinkPad에서도 정상 작동했다.
결국 이것은 단순한 Windows 11 문제도, MIDI driver 문제도, 하드웨어 고장도 아니었다.
오래된 device firmware와 특정 USB host controller 구현 사이의 호환성 문제였던 것으로 보인다.
그런데 답은 2020년부터 서버에 있었다
마지막으로 V1.06 Beta firmware가 언제부터 존재했는지도 궁금해졌다.
iCON firmware distribution server에서 현재 제공되는
iKeyboard_5Nano_V1.06.bin의 HTTP header를 확인해 보았다.
HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 19376 Last-Modified: Mon, 27 Apr 2020 08:18:30 GMT ETag: "b61ed912b107fc7af1a8de0873a6c2d2"
현재 제공되는 V1.06 Beta 객체의
Last-Modified timestamp는
2020년 4월 27일이었다. 물론 이것을 V1.06의 공식 발표일이라고 단정할 수는 없다.
해당 객체가 그날 재업로드된 것일 가능성도 있기 때문이다. 정확하게 표현하면,
현재 서버에서 배포되는 V1.06 Beta binary의 S3 객체 수정 시각이
2020년 4월 27일이다.
어쨌든 내가 이 문제를 처음 블로그에 기록한 것은 2022년이었다. 내가 문제를 기록하기 전부터 해결 firmware가 서버에 있었을 가능성이 매우 높은 셈이다. 그런데 일반적인 제품 지원 페이지에서는 V1.05만 눈에 띄었고, V1.06 Beta는 firmware updater가 읽어 오는 목록 속에 조용히 들어 있었다.
이걸 지금까지 몰랐다니.
기록을 위한 V1.06 Beta 정보
다운로드 URL은 언젠가 바뀌거나 사라질 수 있다. 따라서 URL뿐 아니라 파일의 식별 정보를 함께 남겨 둔다.
Product: iCON iKeyboard 5 NANO Firmware: V1.06 (Beta) Filename: iKeyboard_5Nano_V1.06.bin File size: 19,376 bytes SHA-256: 7F4423D2EB2FBCF47584DAB4AF07B97968EA3A5AF7C74D56ADB89C510F2E96A9 Current firmware feed: https://d2ff5pmy2hzqo1.cloudfront.net/firmware.xml Current binary URL: https://d2ff5pmy2hzqo1.cloudfront.net/iKeyboard_5Nano_V1.06.bin S3/CloudFront Last-Modified: 2020-04-27 08:18:30 GMT
BIN 파일 자체도 별도로 보관해 두었다. URL은 언제든 바뀔 수 있지만 SHA-256 값은 나중에 파일의 동일성을 확인할 수 있는 좋은 기록이 된다.
또 한 가지 주의할 점이 있다.
예전에 배포된 firmware update 설명서에서는 사용자가 로컬의
.bin 파일을 직접 지정하는 방식이 소개되어 있었지만,
현재 사용한 iMap의 firmware update 인터페이스는 그 설명서와 달랐다.
현재 프로그램은 서버의 firmware.xml을 읽어
해당 장치에 사용 가능한 firmware version을 목록으로 제시하고,
사용자가 그중 하나를 선택하는 방식으로 보인다.
따라서 미래에 iCON의 firmware server가 없어졌을 때 보관해 둔 BIN 파일만으로 쉽게 복구할 수 있는지는 아직 확인하지 못했다.
결론
돌고 돌아 결론은 놀라울 정도로 간단했다.
고장 난 MIDI keyboard가 아니었다.
Windows 11만의 문제도 아니었다.
해결책은 공식 V1.06 Beta firmware였다.
그리고 현재 서버에서 배포되는 그 firmware의 timestamp는 내가 이 문제를 처음 기록하기도 전인 2020년이었다. 2022년에 시작한 문제를 2026년에야 해결했다. 그 과정에서 Windows USB stack의 ETW trace를 뜨고, xHCI Configure Endpoint command의 실패까지 추적하고, firmware binary에서 USB endpoint descriptor를 직접 찾아 비교하게 될 줄은 몰랐다.
처음에는 단순히 낡은 MIDI keyboard 하나가 작동하지 않는 문제였다.
그런데 끝까지 파고 들어가니 USB descriptor, host controller compatibility, firmware binary와 CloudFront의 오래된 파일까지 이어지는 작은 디지털 고고학이 되어 버렸다.
이래서 오래된 디지털 기기를 쉽게 버리면 안 된다. 가끔은 기계보다 해결책을 찾아내는 사람이 더 늦게 업데이트된다.
아직 남은 약간의 찜찜함
문제는 해결되었지만 한 가지는 아직 깔끔하게 설명되지 않는다.
사무실 PC에서 iMap V1.18을 이용하여 firmware update mode로 들어가면
iCON firmware upgrade v1.00이라는 장치가 정상적으로 나타나고,
그 다음 단계에서 firmware version을 선택하여 업데이트를 진행할 수 있었다.
그런데 같은 5 NANO를 ThinkPad에서 firmware update mode로 전환해 보니 해당 단계의 장치 목록이 비어 있었다. 현재 설치된 V1.06 Beta에서는 5 NANO 자체가 ThinkPad에서 정상적으로 작동하는데도 firmware update 과정에서는 다시 PC에 따른 차이가 나타난 셈이다.
이 현상의 원인은 더 이상 추적하지 않았다. Firmware update mode에서는 일반 동작 때와 다른 bootloader 또는 USB/MIDI configuration을 사용할 가능성이 있고, 그것이 ThinkPad의 USB 환경과 또 다른 호환성 문제를 일으키는 것일 수도 있다. 그러나 이것은 확인된 사실이 아니라 추측이다.
따라서 이번 조사에서 확실하게 말할 수 있는 것은 여기까지다. V1.05에서는 특정 host controller 환경에서 USB endpoint configuration이 실패했고, 공식 V1.06 Beta로 업데이트한 뒤에는 같은 ThinkPad에서 정상적으로 사용할 수 있게 되었다.
다만 이 오래된 장치의 USB 구현에는 host controller에 따라 행동이 달라지는 부분이 적어도 하나 더 남아 있는 듯하다.
어차피 이 모델에 새로운 firmware가 다시 나올 가능성은 매우 낮다. V1.06 Beta로 정상 작동하는 지금, 여기서 더 파고들 이유도 별로 없다. 해결은 되었지만 모든 의문이 해결된 것은 아니다. 그 정도의 찜찜함은 기록으로 남겨 두기로 한다.
댓글 없음:
댓글 쓰기