Summary: | GENERIC-MMCCAM: unable to cope with Hetzner VPS (ARM Ampere) SCSI CD-ROM drive | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Mina Galić <freebsd> | ||||
Component: | kern | Assignee: | freebsd-arm (Nobody) <freebsd-arm> | ||||
Status: | New --- | ||||||
Severity: | Affects Only Me | CC: | emaste, imp | ||||
Priority: | --- | ||||||
Version: | 14.0-RELEASE | ||||||
Hardware: | arm64 | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Mina Galić
2023-11-08 00:18:29 UTC
so we get selection timeouts when we send the INQUIRY command. There's no device at those addresses. Why we do this for targets 1 through (or maybe 255), I know not. It's likely not relevant though. cdopen is called when we start to read from the CD device. We send a READ CAPACITY command to fine out how big the media is... only to be told there's no MEDIA... So maybe a config error on the other side of vtscsi? just for completeness, the full dmesg: https://gist.github.com/7b4343df3c646d45f978b99e7cd7b19e (at least that part that wasn't overrun from the buffer already) Can you up the msgbuf size to capture the start? But honestly, I'm not seeing any misbehavior so far. (In reply to Warner Losh from comment #3) > Can you up the msgbuf size to capture the start? full dmesg: https://gist.github.com/c4772229c128d4c45ac18ac19a75475f > But honestly, I'm not seeing any misbehavior so far. I think the only real misbehaviour is: This trace on a RELEASE kernel. (and my misunderstanding of when to stop… like when something says that's an Error 6, Unretryable error) Created attachment 246198 [details] Full dmesg attach https://gist.github.com/c4772229c128d4c45ac18ac19a75475f here, so we're not dependent on GitHub note that setting kern.cam.dflags=1 (in loader.conf), which according to sys/cam/cam_debug.h is: CAM_DEBUG_INFO = 0x01, /* scsi commands, errors, data */ does not change anything about the output. Hmmm.. OK. I see we have options CAMDEBUG and CAM_DEBUG_FLAGS in the MMCCAM kernel for reasons that I'm unsure of. But that explains the verbosity. we might wanna reverse those in std.nodebug (In reply to Warner Losh from comment #7) > we have options CAMDEBUG and CAM_DEBUG_FLAGS in the MMCCAM kernel I assume those were added as MMCCAM is experimental and debugging information is desired when something goes wrong. What we should do depends on how close we are to enabling `options MMCCAM` by default, I'd think. (In reply to Ed Maste from comment #9) Yea... this bug is unrelated to mmc. We're ready for sure on arm64. Intel platforms have faster speeds / modes not yet implemented by cam mmc. |