[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: cdrecord, no scsi, netbsd 9
Date: Thu, 2 Apr 2020 15:54:26 +0100
From: Chavdar Ivanov <ci4ic4%gmail.com@localhost>
| And ofcourse, it is not strictly needed - one can always check the
| device name in the dmesg and use it in the program.
Yes, on NetBSD, on some other systems (apparently) the bus address
has to be handed off to cdrecord to tell it which device to use (I
guess it uses some kind of raw scsi interface, and does everything
But apparently the real problem is:
| The CD/DVD is not found by NetBSD. It's an USB 2.0 CD/DVD/BD writer
| and it is not even recognised as a CDROM.
And the dmesg output (from 9.0) was:
[ 3.805742] uhub4 at uhub1 port 2: vendor 1a40 (0x1a40) USB 2.0 Hub (0x101), class 9/0, rev 2.00/1.11, addr 2
[ 3.818273] uhub4: single transaction translator
[ 3.818273] uhub4: 4 ports with 4 removable, self powered
[ 368.431581] uhub4: detached
[ 368.431581] uhub4: at uhub1 port 2 (addr 2) disconnected
[ 435.791321] uhub1: autoconfiguration error: device problem, disabling port 2
with nothing else (reported) about uhub4 or anything that might be connected
to it. This is from plugging in the device after boot. I would have
expected some other message before the sudden "detached" though, was there
nothing else at all?
On the other hand, when plugged in at boot time:
[ 3.799579] uhub4 at uhub1 port 2: vendor 1a40 (0x1a40) USB 2.0 Hub (0x101), class 9/0, rev 2.00/1.11, addr 2
[ 3.809613] uhub4: single transaction translator
[ 3.809613] uhub4: 4 ports with 4 removable, self powered
[ 4.820090] umass1 at uhub4 port 2 configuration 1 interface 0
[ 4.820090] umass1: MediaTek Inc (0xe8d) MT1956 (0x1956), rev 2.00/0.00, addr 3
[ 4.835319] umass1: using ATAPI over Bulk-Only
[ 4.835319] atapibus0 at umass1: 2 targets
[ 4.840763] cd0 at atapibus0 drive 0: <TSSTcorp, BDDVDW SE-506CB, TS02> cdrom removable
Someone who knows the USB code, and how the attach stuff is intended
to work, and can suggest what might be going wrong is needed here.
But if it can attach correctly at boot time, it should also attach
correctly later, I would have thought.
About all I can suggest is trying a current kernel (a kernel from HEAD)
just in case something has been fixed, and either not pulled up to
netbsd-9 (or that really was a 9.0 RELEASE kernel) or perhaps pulled up
after Feb 14.
Main Index |
Thread Index |