Opened 8 years ago

Last modified 2 years ago

#8830 new bug

Sometimes cdrecord, mistakenly lists my cd burn device

Reported by: Giova84 Owned by: nobody
Priority: normal Milestone: R1
Component: Applications/Command Line Tools Version: R1/Development
Keywords: cdrecord mistakenly lists my cd burn device Cc:
Blocked By: Blocking:
Platform: x86


With the newer version of cdrecord ( ) finally i can see and use my cd burner. Is listed as "ATAPI ' 'DVD A DH16A6S ' 'YA17' Removable CD-ROM" but sometimes - this happens randomly - cdrecord lists my device as a "FAKE DEVICE" or something similar (now, for example is correctly listed), and in this case, due to the fact that i cannot write nothing on cd/dvd, i have to reboot Haiku to solve this issue.

Attachments (2)

syslog (357.5 KB ) - added by Giova84 8 years ago.
cdrecord_adaptec_fake (2.2 KB ) - added by vidrep 3 years ago.

Download all attachments as: .zip

Change History (18)

comment:1 by diver, 8 years ago

Please attach your syslog with both correctly and incorrectly cd burner listed.

in reply to:  1 comment:2 by Giova84, 8 years ago

Correct: ATAPI ' 'DVD A DH16A6S ' 'YA17' Incorrect: 'ADAPTEC ' 'ACB-5500 ' 'FAKE' NON CCS Disk And i have just on cd/dvd burner device on my system.

Syslog attached.

Version 0, edited 8 years ago by Giova84 (next)

by Giova84, 8 years ago

Attachment: syslog added

comment:3 by Giova84, 8 years ago

This happens since two weeks, when was released.

comment:4 by phoudoin, 8 years ago

Seems like the SCSI inquiry command can failed on your device, and in such case the AHCI or cdrecord don't detect it's a failure and instead fall into fake/incomplete inquiry replies, which leads to cdrecord to think it's a FAKE device.

The root issue, as shown in syslog, is why the AHCI inquiry command fails and why this information is not detected by cdrecord scg lib...

comment:5 by Giova84, 8 years ago

Hi Phoudoin,

do you think that there is a way to solve this issue?

comment:6 by Giova84, 8 years ago

Haiku R1 Alpha 4: this bug is still present.

comment:7 by Giova84, 8 years ago

I forget to say that cdrecord has another issue, so i have opened another ticket:

comment:8 by Giova84, 6 years ago

Still present for me in hrev46464 This issue was also reported by Kallisti in

comment:9 by vidrep, 5 years ago

This ticket appears to have been resolved with the update to cdrtools 3.01a30. Giova84 could you please verify this before they close the ticket?

comment:10 by vidrep, 4 years ago

Are you still experiencing this issue with the latest cdrtools (3.02a06)?

comment:11 by Giova84, 4 years ago

Hi, sorry for the very long report.

As I've said in my first message, this issue occurs randomly: I've tried few minutes ago and for now my device is correctly reported; however when I launch

cdrecord -checkdrive

I get some warning message (at the end of the following output):

Cdrecord-ProDVD-ProBD-Clone 3.02a06 (i586-pc-haiku) Copyright (C) 1995-2016 Joerg Schilling
Using libscg version 'schily-0.9'.
No target specified, trying to find one...
Using dev=0,3,0.
Device type    : Removable CD-ROM
Version        : 2
Response Format: 2
Capabilities   : 
Vendor_info    : 'ATAPI   '
Identifikation : 'DVD A  DH16A6S  '
Revision       : 'YA17'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
cdrecord: Warning: Cannot read drive buffer.
cdrecord: Warning: The DMA speed test has been skipped.

comment:12 by Giova84, 4 years ago


I hit again this bug:

When I launch

cdrecord -checkdrive

I got:

Cdrecord-ProDVD-ProBD-Clone 3.02a06 (i586-pc-haiku) Copyright (C) 1995-2016 Joerg Schilling
Using libscg version 'schily-0.9'.
No target specified, trying to find one...
cdrecord: No such file or directory. Cannot open or use SCSI driver.
cdrecord: For possible targets try 'cdrecord -scanbus'.
cdrecord: For possible transport specifiers try 'cdrecord dev=help'.

And with

cdrecord -scanbus

I got

Cdrecord-ProDVD-ProBD-Clone 3.02a06 (i586-pc-haiku) Copyright (C) 1995-2016 Joerg Schilling
Using libscg version 'schily-0.9'.
        0,0,0     0) '' '' '' NON CCS Disk
        0,1,0     1) *
        0,2,0     2) *
        0,3,0     3) 'ADAPTEC ' 'ACB-5500        ' 'FAKE' NON CCS Disk
        0,4,0     4) *
        0,5,0     5) *
        0,6,0     6) *
        0,7,0     7) *

This morning was fine...

comment:13 by vidrep, 3 years ago

After doing a little research on this issue I found that virtually every distribution which uses cdrtools has reports for the same bug. This is not likely a Haiku bug at all, but a CDRTools bug.

Last edited 3 years ago by vidrep (previous) (diff)

comment:14 by vidrep, 3 years ago

Tested with hrev51206 x86_gcc2h Attached output of last session "cdrecord_adaptec_fake"

by vidrep, 3 years ago

Attachment: cdrecord_adaptec_fake added

comment:15 by vidrep, 3 years ago

Jörg Schilling, the author of CDRTools responded on IRC: [10:14] <schily> Looks like this is a set of fake INQUIRY from the kernel for an ATA drive [10:14] <schily> as it claims SCSI-2 compatibility in the Inquiry data [10:14] <schily> So you need to ask the person who sythesized this set of data [10:21] <schily> For SCSI via USB, the INQUIRY command is handled by the USB device [10:21] <schily> for ATA drives, the kernel converts other information from the drive and synthesizes an INQUIRY

comment:16 by vidrep, 2 years ago

This is still a problem with current hrev51639.

Many of the issues are documented in the following related ticket:

Note: See TracTickets for help on using tickets.