Cannot burn ISO onto DVD on Jetson Xavier NX

Hi, I am beginning to use Jetson Xavier NX. I have faced an Input/Output error issue with burning an ISO image onto a DVD+R through a USB DVD writer. I have confirmed that it is not the issue of the USB DVD Writer, as I have tested on multiple other computers running Windows and Ubuntu, and was able to burn the image.

I have tried two methods, 1) through brasero, 2) through growisofs; which both worked on my other PC running Ubuntu. Here are the error logs and system information I have gathered.

Brasero logs:
brasero-session-03122022.log (7.6 KB)
brasero-session-05122022.log (5.1 KB)

growisofs logs:


Mediainfo Details:



dev_dvdrw_mediainfo.txt (1.6 KB)
dev_dvdrw_mediainfo.txt (1.6 KB)

dmesg details:

As I’m just beginning testing, I am not sure if the issue directly relates to Jetson NX or not. If this is not the correct forum to raise this issue, please help redirect me to the appropriate places/sources. Thank you for reading!

Hi,
We don’t have experience about this use-case. Would need other users to share suggestion.

Can you verify if this a USB DVD writer? Looks like it is. The image is useful, but if you monitor “dmesg --followprior to plugging in the DVD writer, and copy and paste only what occurs from plugin, what shows up (copy and paste or redirect to a file is better than an image)? What extra log shows up during an attempt to write (it is important to know which log lines are from plugin, versus from write attempts; also, if it reads without issue would be useful information).

Also, what do you see, with the unit plugged in, but prior to any error, versus what shows up upon error?

What do you see for “lsusb” and “lsusb -t”?

Note that the DVD will be listed in “lsusb”, and that it will show an “ID”. The ID will be something similar to “0955:7e19” (though it won’t be that particular number). One can list just that device, with verbose output, like this (adjust the ID though):
sudo lsusb -vvv -d 0955:7e19

You could redirect that to a file for logging:
sudo lsusb -vvv -d 0955:7e19 | tee log_verbose_lsusb.txt

Thanks for the reply, attached are the dmesg log, verbose lsusb log, and other supplementary logs I have got from the device. I have run both growisofs and brasero in this test.

When it came out of the box the DVD read/writer could not mount onto the device, so I made changes to the kernel configurations to enable ISO9660_FS. I have then made changes to /etc/fstab to automount, and DVD contents are readable (I burnt the ISO image onto one of my DVD+R using my Ubuntu laptop and the same DVD writer)

the line I included in /etc/fstab is as follows:

/dev/sr0 /media/cdrom iso9660 user,noauto,exec,utf8 0 0

The problem arises when I load in a new blank DVD and intend to burn a new ISO image into the DVD on the NX. This is the pop-up error I get when I insert a blank DVD. This does not show up when I insert a DVD that has data in it.

log_growisofs.txt (790 Bytes)
log_verbose_lsusb.txt (2.3 KB)
brasero-session.log (5.1 KB)
log_dmesg.txt (69.1 KB)

Sorry for the response delay. My computer had died and the motherboard needed to be replaced (and the first replacement motherboard was also bad). I’m just now starting to catch up.

One cannot mount a blank DVD or CD. I’m thinking perhaps that pop-up item might be a more indirect clue than taking it at face value. For example, if the DVD drive wants to mount at a particular location, and something is already there, then this would be an issue regardless of whether it is a DVD (blank or otherwise) or anything else which could be mounted. However, there is still the question of whether it is just a bad message since a blank DVD cannot be mounted…I’m thinking that your mount rule needs to be examined. This part of the problem may not actually be a problem (so far as burning DVDs goes).

When you see this message, what do you see from:
lsblk -f

It’s useful to note that ISO9660 filesystems on a drive must have special schemes set up if they are to be grown on the DVD itself. Working with this demands that the original burn to DVD has special options with software capable of working with those options. There is less of a restriction on this to use growisofs on a file intended to burn which is originally purely ISO9660 (possibly with Rock Ridge or Joliet extensions which are just for long name formats and are not actually part of the ISO9660 itself…Joliet would be involved with the Unicode option “utf”, but can be ignored).

In the log_growisofs.txt I see an I/O error. I don’t have enough experience with this to say if it is a hardware issue or a configuration issue. If you use an ordinary data DVD or CD, can you read from this drive? If so, then likely the I/O error is software (perhaps as simple as a configuration).

The log_verbose_lsusb.txt seems normal and without error. This tends to indicate the hardware and basics of the driver are functioning correctly. I think this drive is capable of functioning correctly, at least so far as basics go.

I’ve not used Brasero, but the logs seem useful. Incidentally, almost every CD/DVD program is just a front end to combinations of other software. In the logs I see all is valid up to and including reading of an ISO file, “/home/nvidia/Desktop/waku.iso”. Then there is the beginning of write. Not all burners and drivers support exactly the same set of commands (e.g., some might understand DVDs and CDs, others might understand only CDs), and although I am not certain, it may not be a problem that at the start of write there is one feature failure (not sure):

BraseroLibburn called brasero_job_get_action
BraseroLibburn unsupported operation
BraseroLibburn deactivating

(I wouldn’t look too hard at this “generic” and undetailed error, at least not yet, since it has no useful details of what operation is not supported)

It tries to “init” the device, gets a return value of “1”, and this might be good. I don’t know what is inside the code there to say if “1” is success or not, but probably it is success (if it were “-1”, then I’d say it is almost certainly an error). The program continues on, so it seems highly likely the burner is working up to this point.

Here is the point which really matters (the problem is a SCSI command, which is basically part of the SATA I/O):

BraseroLibburn SCSI command 2Ah yielded host problem: 0x7 SG_ERR_DID_ERROR (Internal error detected in the host adapter)

At this point it becomes even more important to find out if the drive can read a data type CD or DVD. Does the drive work for reading?

I don’t know enough about these dmesg errors to say exactly what is going on, but it is possible that write itself fails for any number of reasons. Examples might be an ISO image too large, or software trying to use commands the driver does not understand, or actual hardware write issues:

[  121.689529] capability: warning: `growisofs' uses 32-bit capabilities (legacy support in use)
[  127.000033] usb 1-2.4.2: reset full-speed USB device number 4 using tegra-xusb
[  146.967577] usb 1-2.4.2: reset full-speed USB device number 4 using tegra-xusb
[  208.405848] usb 1-2.4.2: reset full-speed USB device number 4 using tegra-xusb
[  208.440591] sr 0:0:0:0: [sr0] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
[  208.440605] sr 0:0:0:0: [sr0] tag#0 CDB: opcode=0x1b 1b 01 00 00 01 00 00 00 00 00 00 00
[  215.061633] usb 1-2.4.2: reset full-speed USB device number 4 using tegra-xusb
[  215.096359] sr 0:0:0:0: [sr0] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
[  215.096400] sr 0:0:0:0: [sr0] tag#0 CDB: opcode=0x1b 1b 01 00 00 01 00 00 00 00 00 00 00
[  224.021288] usb 1-2.4.2: reset full-speed USB device number 4 using tegra-xusb
[  229.397338] usb 1-2.4.2: reset full-speed USB device number 4 using tegra-xusb
[  229.431774] sr 0:0:0:0: [sr0] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
[  229.431787] sr 0:0:0:0: [sr0] tag#0 CDB: opcode=0x1b 1b 00 00 00 02 00 00 00 00 00 00 00
[  344.312541] isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16
[  352.326211] isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16
[  388.534566] isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16
[  452.382546] isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16
[  478.226270] usb 1-2.4.2: reset full-speed USB device number 4 using tegra-xusb
[  528.145436] usb 1-2.4.2: reset full-speed USB device number 4 using tegra-xusb
[  533.777504] usb 1-2.4.2: reset full-speed USB device number 4 using tegra-xusb
[  533.812135] sr 0:0:0:0: [sr0] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
[  533.812150] sr 0:0:0:0: [sr0] tag#0 CDB: opcode=0x1b 1b 00 00 00 02 00 00 00 00 00 00 00
[  618.513535] usb 1-2.4.2: reset full-speed USB device number 4 using tegra-xusb
[  624.145518] usb 1-2.4.2: reset full-speed USB device number 4 using tegra-xusb
[  624.180062] sr 0:0:0:0: [sr0] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
[  624.180078] sr 0:0:0:0: [sr0] tag#0 CDB: opcode=0x1b 1b 00 00 00 02 00 00 00 00 00 00 00

Also, how well does this drive write on another Ubuntu system?

Much thanks for the reply! Here is the lsblk result

NAME         FSTYPE  LABEL                 UUID                                 MOUNTPOINT
loop0        vfat    L4T-README            1234-ABCD                            
sda                                                                             
└─sda1       vfat                          9EA8-A348                            /media/nvidia/9EA8-A348
sr0          iso9660 Data disc (20 Dec 22) 2022-12-20-04-36-10-00               /media/cdrom
mtdblock0                                                                       
mmcblk0                                                                         
├─mmcblk0p1  ext4                          d5613c93-0165-4021-a813-2a4ce8c24a64 /
├─mmcblk0p2                                                                     
├─mmcblk0p3                                                                     
├─mmcblk0p4                                                                     
├─mmcblk0p5                                                                     
├─mmcblk0p6                                                                     
├─mmcblk0p7                                                                     
├─mmcblk0p8                                                                     
├─mmcblk0p9                                                                     
├─mmcblk0p10                                                                    
└─mmcblk0p11                                                                    
mmcblk0boot0                                                                    
mmcblk0boot1                                                                    
mmcblk0rpmb                                                                     
zram0                                                                           [SWAP]
zram1                                                                           [SWAP]
zram2                                                                           [SWAP]
zram3                                                                           [SWAP]

log_lsblk_f.txt (2.1 KB)

I mounted a data DVD with some contents in it already and I can then read the DVDs contents. Here is a pic of the contents in the DVD on my Jetson Xavier NX. I used this same data ISO file (waku.iso) here, the file is just around 15kB so it’s not a large file that I’m using for testing.

I have tested the same procedure on another PC running Ubuntu. I have tried burning an ISO file using the same drive on another Ubuntu device, it worked without any abnormalities.

The drive is a SATA drive, and we connected it to our carrier board using a SATA-to-USB cable. So if its ends up being a possible hardware problem, I think that cable may be the root of the issue. Though supposedly that cable should support Linux so I’m not sure. Would like to get your opinion again. Appreciate the help!

This verifies the read part of the CD/DVD works and does not fail:

Since read works, most I/O failure will not be from hardware (though it could still be for parts of wiring different than read). This tends to point at software if write fails (I say “tends” because it is not guaranteed). Overall, this is good news. SATA works.

The fact that you could burn from the same drive on another Ubuntu system also indicates a software issue, but likely not the base driver (there could be a different driver involved in write, but there are many steps to write before the drive is actually written to, e.g., creating a correct image involves much more, and then writing involves another driver and software beyond SATA and read).

Are you using the same SATA-to-USB cable on both host PC and Jetson? Either way, if the USB is not plugged in to the Jetson, and you run the command “dmesg --follow”, what new log lines appear upon plugin of the USB cable when a blank CD or DVD is in the drive (I’m trying to avoid the mount step)?

Note: SATA goes through USB in this case, but the driver is the same to some extent; it is just a USB PHY SATA tunnels through.

Yes I’ve been using the same SATA-to-USB cable on both host PC and Jetson.
Here is the dmesg --follow trace for when I plug-in the USB cable with a blank DVD and a burnt DVD with data.

dmesg trace with blank DVD:
log_dmesgfollow_blank_dvd.txt (66.3 KB)

dmesg trace with DVD that contains data:
log_dmesgfollow_data_dvd.txt (66.3 KB)

Also happy new year!

For reference, the device ID (0x13fd) is for brand Initio, and the product ID (0x0840) within that brand is “INIC-1618L SATA”. So this would probably use standard drivers. Upon plugin it produces “/dev/sr0”. The data DVD log indicates it correctly detects an ISO 9660 filesystem. So all basics are ok in the logs you provided. Can I verify this is from the PC and not the Jetson (I’m pretty sure it is, but don’t want to assume).

On the Jetson (you don’t need the drive plugged in for this), what do you see from:
cat /proc/cmdline | grep 9660

Mostly I’m trying to find out if driver and kernel support are present; the software for burning DVDs would be a separate topic). If they are, then most of USB could be considered working. Along that line, I also want to find out, is this a USB3 drive? Are you plugging it in to a USB3 socket? After the drive is plugged in, what do you see from “lsusb -t”?

I ran the dmesg traces on Jetson, not on my host PC. I’ve previously changed some of the kernel configurations to allow ISO9660 FS support, following another post on the forum here. Unable to mount sub connected DVD drive on Jetson TX2 - #9 by richardsearle

I didn’t get anything from cat /proc/cmdline | grep 9660, running just cat /proc/cmdline alone returns this:

console=ttyTCU0,115200 video=tegrafb earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt rootfs.slot_suffix= tegra_fbmem2=0x800000@0xa06b2000 lut_mem2=0x2008@0xa06af000 usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.4.2 vpr_resize sdhci_tegra.en_boot_part_access=1    quiet pci=noaer root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0

log_cat_proc_cmdline.txt (440 Bytes)

The SATA-USB cable I’m using is not on USB3, but I plugged it into a USB3 port. Here is the lsusb -t log:

nvidia@tegra-ubuntu:~$ lsusb
Bus 002 Device 004: ID 05e3:0626 Genesys Logic, Inc. 
Bus 002 Device 003: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. 
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0403:c630 Future Technology Devices International, Ltd lcd2usb interface
Bus 001 Device 008: ID 13fd:0840 Initio Corporation INIC-1618L SATA
Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 007: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 006: ID 046d:c52e Logitech, Inc. MK260 Wireless Combo Receiver
Bus 001 Device 003: ID 0a05:7211 Unknown Manufacturer hub
Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
nvidia@tegra-ubuntu:~$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 10000M
    |__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M
        |__ Port 4: Dev 4, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 480M
    |__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 12M
            |__ Port 2: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 2: Dev 6, If 1, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 4: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 4: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 4: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 8, If 0, Class=Mass Storage, Driver=usb-storage, 480M
            |__ Port 4: Dev 5, If 0, Class=(Defined at Interface level), Driver=usbfs, 12M

The above implies Jetson USB is working during the creation of those logs. Previously it sounded like there might be a failure from the Jetson side, and so this is why I wondered if it was from the PC. Good to know though that USB itself is succeeding, and producing the read-only /dev/sr0. The addition of ISO 9660 support seems to have succeeded.

What I should have asked for is:
lsmod | grep 9660
(but no need to check this now since ISO 9660 is working for read)

One thing I will suggest while debugging is to remove “quiet” from “/boot/extlinux/extlinux.conf” (you could put this back in later if you don’t want so many boot log lines). I don’t think this will make much of a difference though in this case, but serial boot logs are much more useful when needed if quiet is removed.

For reference, this is the particular device:
Bus 001 Device 008: ID 13fd:0840 Initio Corporation INIC-1618L SATA

Having a USB2 device on a USB3 bus works well, but I needed to know if it was reverting to USB2 when it is actually USB3 (this would have been an indication of lower signal quality, but since it is USB2 and is operating at USB2 speeds, signal seems good).

At this point it looks like a requirements for reading a CD/DVD is working. Only write remains. Now that you’ve added ISO 9660, does write succeed? If not, can you run “dmesg --follow”, and post only the messages which occur as a result of trying to burn a CD/DVD?

Sorry for the late response.

I already made the change to the kernel to include ISO9660 from the beginning, so write still doesn’t work.
But I don’t see anything returned from lsmod | grep 9600.

I looked into the dmesg logs and found one of the issues was that the USB connection seems to be unstable, and disconnects from time to time. wodim would return Errno: 5 (Input/output error), prevent/allow medium removal scsi sendcmd: cmd timeout after 5.376 (40) swhen that happens. It seemed that the problem was it wasn’t able to draw enough current. My solution to this is to just give it an external power supply, and I haven’t gotten those usb disconnect messages in my dmesg log since. Even so, I am still unable to flash the drive. Here is the latest log.

wodim: No write mode specified.
wodim: Assuming -tao mode.
wodim: Future versions of wodim may have different drive dependent defaults.
TOC Type: 1 = CD-ROM
scsidev: '/dev/dvdrw'
devname: '/dev/dvdrw'
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Wodim version: 1.1.11
SCSI buffer size: 64512
Device type    : Removable CD-ROM
Version        : 0
Response Format: 2
Capabilities   : 
Vendor_info    : 'TSSTcorp'
Identification : 'DVD+-RW SU-208GB'
Revision       : 'H100'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Current: 0x001B (DVD+R)
Profile: 0x0015 (DVD-R/DL sequential recording) 
Profile: 0x0016 (DVD-R/DL layer jump recording) 
Profile: 0x002B (DVD+R/DL) 
Profile: 0x001B (DVD+R) (current)
Profile: 0x001A (DVD+RW) 
Profile: 0x0014 (DVD-RW sequential recording) 
Profile: 0x0013 (DVD-RW restricted overwrite) 
Profile: 0x0012 (DVD-RAM) 
Profile: 0x0011 (DVD-R sequential recording) 
Profile: 0x0010 (DVD-ROM) 
Profile: 0x000A (CD-RW) 
Profile: 0x0009 (CD-R) 
Profile: 0x0008 (CD-ROM) 
Profile: 0x0002 (Removable disk) 
Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd).
Driver flags   : SWABAUDIO BURNFREE 
Supported modes: PACKET SAO
Drive buf size : 262144 = 256 KB
Beginning DMA speed test. Set CDR_NODMATEST environment variable if device
communication breaks or freezes immediately after that.
FIFO size      : 12582912 = 12288 KB
Track 01: data     3 MB        
Total size:        4 MB (00:25.98) = 1949 sectors
Lout start:        4 MB (00:27/74) = 1949 sectors
Current Secsize: 2048
HINT: use dvd+rw-mediainfo from dvd+rw-tools for information extraction.
Blocks total: 2295104 Blocks current: 2295104 Blocks remaining: 2293155
resid: 28
resid: 60
Speed set to 11080 KB/s
Starting to write CD/DVD at speed   8.0 in real unknown mode for single session.
Last chance to quit, starting real write in    0 seconds. Operation starts.
Waiting for reader process to fill input buffer ... input buffer ready.
resid: 24
resid: 60
resid: 60
Performing OPC...
Errno: 5 (Input/output error), send opc scsi sendcmd: cmd timeout after 5.220 (60) s
CDB:  54 01 00 00 00 00 00 00 00 00
cmd finished after 5.220s timeout 60s
wodim: OPC failed.
Writing  time:    5.258s
wodim: fifo had 2 puts and 0 gets.
wodim: fifo was 0 times empty and 0 times full, min fill was 100%.

These are the messages that show up in my dmesg log now every time I attempt to flash, after I have found the power supply issue

[ 1042.635741] usb 1-2.4.1: reset high-speed USB device number 7 using tegra-xusb
[ 1042.656633] sr 0:0:0:0: [sr0] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
[ 1042.656651] sr 0:0:0:0: [sr0] tag#0 CDB: opcode=0x53 53 00 00 00 00 00 00 07 9d 00

It would be:
lsmod | grep 9660
(if the feature is integrated, installed with the “=y” instead of “=m”, then you would not see the grep for 9660 return anything)

What do you see from (though this won’t cause a timeout):
zcat /proc/config.gz | grep 9660

I’m thinking the issue is due to the user space software, possibly needing something more installed. However, when the DVD drive is present, and when there is a blank DVD in it, what do you see from “ls -l /dev/dvd*”? The device special file used for write will differ from the one used in read, and your log indicates this is the device being searched for (/dev/dvdrw). If this is present, then all drivers are present and basically functioning, which implies a user space software issue. However, if no dvdrw device is present, then there is yet another driver required and user space software would possibly be working as expected.

The actual dmesg is a bit confusing since it could be from different software sources, but it tends to indicate the driver not believing the device has write hardware (that’s a wild guess).

But I don’t see anything returned from lsmod | grep 9600 .

Sorry that was a typo, yes lsmod | grep 9600 doesn’t return anything for me.

I get this returned when I run ls -l /dev/dvd*:

lrwxrwxrwx 1 root root 3 Jan 10 06:22 /dev/dvd -> sr0
lrwxrwxrwx 1 root root 3 Jan 10 06:22 /dev/dvdrw -> sr0

zcat /proc/config.gz | grep 9660 gets me this:
CONFIG_ISO9660_FS=y

Which makes sense because I changed the kernel to support ISO9660 FS already.

Update: I got it to flash on the Jetson with an abnormal operation. I ran the same flash command using growisofs thrice in very quick succession (after it returned error) and it worked on the last time. The writer was still spinning the DVD as I typed the next commands in. I also confirmed that the contents were burnt properly. I have tested around 6 times and seems this is a stable method to flash content into the DVD.

 nvidia@tegra-ubuntu:~/Desktop$ growisofs -Z /dev/dvdrw=test.iso
Executing 'builtin_dd if=test.iso of=/dev/dvdrw obs=32k seek=0'
/dev/dvdrw: "Current Write Speed" is 8.2x1352KBps.
:-( unable to WRITE@LBA=0h: Input/output error
:-( write failed: Input/output error
nvidia@tegra-ubuntu:~/Desktop$ growisofs -Z /dev/dvdrw=test.iso
Executing 'builtin_dd if=test.iso of=/dev/dvdrw obs=32k seek=0'
/dev/dvdrw: "Current Write Speed" is 8.2x1352KBps.
:-( unable to WRITE@LBA=0h: Input/output error
:-( write failed: Input/output error
nvidia@tegra-ubuntu:~/Desktop$ growisofs -Z /dev/dvdrw=test.iso
Executing 'builtin_dd if=test.iso of=/dev/dvdrw obs=32k seek=0'
/dev/dvdrw: "Current Write Speed" is 8.2x1352KBps.
builtin_dd: 48*2KB out @ average 0.0x1352KBps
/dev/dvdrw: flushing cache
/dev/dvdrw: closing track
/dev/dvdrw: closing session
/dev/dvdrw: reloading tray

The only dmesg I got from this operation was:

[1056.192769] usb 1-2.4.4: reset high-speed USB device number 24 using tegra-xusb
[1062.336667] usb 1-2.4.4: reset high-speed USB device number 24 using tegra-xusb
[1067.712531] usb 1-2.4.4: reset high-speed USB device number 24 using tegra-xusb

The growisofs command waits until the reset happens, returning nothing.
After this reset is shown in dmesg, the growisofs will begin Executing 'builtin_dd if=test.iso of=/dev/dvdrw obs=32k seek=0'

So this confirms what you said, that the Jetson should already have the appropriate software support to do the actual burning (drivers, etc), but some problem is stopping it from recognizing it can begin the burn process.

The above verifies the feature is there and available 100% of the time, and that no module would be used.

At this point I don’t know how to trace it any further. I can give a guess, but it is purely conjecture: Possibly, when you first run the command, the device may not respond as fast as required in the software. However, if some part of it is already spinning and running, then it might mean you get lucky and it does as you mention, it waits longer because it sees a need to wait (versus timing out for not knowing it needs to wait a bit longer).

You might try running “sudo jetson_clocks” prior to burning a DVD and see if it is easier to get it to actually start. What that would do is to max out clocks within the current power mode profile. If clocks are maxed out, then there would be lower latency, and perhaps lower latency would mean not timing out. If there is any other CD/DVD burn software available to test with (one not using growisofs, but many are just frontends to this), then you might check if other software works without jetson_clocks.

So that is my guess: The Jetson is responding too slowly and the software using the DVD writer is timing out faster than it should.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.