imx6 sata cdrom driver issue

[Jon_Bagg]

Mounting a SATA CDROM fails aprox 1/20 times with this error....

root@freescale /tmp$ mount /dev/sr0 test/

UDF-fs: No partition found (1)

mount: mounting /dev/sr0 on test/ failed: Invalid argument

I'm using a Sabre imx6q board, freescale kernel 3.0.35 built with imx6_defconfig and the following extra configs

CONFIG_BLK_DEV_SR=y

CONFIG_UDF_FS=y

CONFIG_UDF_NLS=y

CONFIG_ISO9660_FS=y

I've tried several disks and dvd drivers.  They all experience this issue on the Sabra board.  The same disks mount 100% of the time in an x86 machine.

I first noticed the issue on our own imx6d boards running mainline kernel 3.19.  Once in a while the kernel would dump out a backtrace (attached) when mounting.

Original Attachment has been moved to: mount_cdrom_backtrace.txt.zip

[tonyzheng]

mark

[Jon_Bagg]

bitbake / yacto recipe for cdparanoia.  Should build in L3.14.28.  I put it in

fsl-release-bsp/sources/poky/meta/recipes-core/

[fabio_estevam]

Hi Jonathan,

I have just managed to reproduce it on a wandboard running kernel 4.0.4. The reason I use wandboard is because it is the only board I have access to that has a SATA connector instead of eSATA:

Boot 1:

[    3.132017] CDB rbuf: [4a 01 00 00 10 00 00 00 08]

[    3.136819] CDB rbuf: 00000000: ff ff ff ff ff ff ff ff                          ........

​Boot 2:

[    2.034090] CDB rbuf: [4a 01 00 00 10 00 00 00 08]

[    2.034097] CDB rbuf: 00000000: 00 10 a2 ed 00 00 00 00                          ........

Boot 3:

[    3.043279] CDB rbuf: [4a 01 00 00 10 00 00 00 08]

[    3.048082] CDB rbuf: 00000000: 00 00 00 00 00 00 00 00                          ........

Also tested on a mx53-qsb and the response is always correct there as you stated previously.

Also confirmed what your colleague said about atapi_drain_needed(): after forcing atapi_drain_needed() to return 0, then the CDB rbuf response is always correct:

--- a/drivers/ata/libata-scsi.c

+++ b/drivers/ata/libata-scsi.c

@@ -1102,13 +1102,7 @@ static void ata_scsi_sdev_config(struct scsi_device *sdev

  */

static int atapi_drain_needed(struct request *rq)

{

-       if (likely(rq->cmd_type != REQ_TYPE_BLOCK_PC))

-               return 0;

-

-       if (!blk_rq_bytes(rq) || (rq->cmd_flags & REQ_WRITE))

-               return 0;

-

-       return atapi_cmd_type(rq->cmd[0]) == ATAPI_MISC;

+       return 0;

}

Just wanted to update you that I am able to reproduce the same behaviors here.

[torbansondersko]

Hi Fabio, Hongxing-

Though atapi_drain_needed() seems to improve the reliability of mounting CD-ROMs and access to CD Audio discs, is there an explanation for the root cause of this problem in i.MX6DQ?

We would like to know the root cause of this in the SATA controller and/or driver to be sure we don't run into any stability problems with SATA optical drives in the long term.

[fabio_estevam]

Hi Torban,

We are checking about this problem internally. We don't know the root cause at this point.

Will keep you updated.

Regards,

Fabio Estevam

[Jon_Bagg]

Experiments / findings from my co-worker Kevin....

Using the debug patch I wrote that Jon posted earlier I can see that the

response to the ATAPI 0x4A command (Get Event Status Notification)

during initial boot is always random. For example:

[ 2.237783] CDB rbuf: [4a 01 00 00 10 00 00 00 08]

[ 2.237789] CDB rbuf: 00000000: 7e 31 f7 fd ff f5 7d fd

~1....}.

Running the same test on an iMX53 EVK board the response is always:

[ 2.452303] CDB rbuf: [4a 01 00 00 10 00 00 00 08]

[ 2.452308] CDB rbuf: 00000000: 00 06 04 56 02 02 00 00

...V....

We have rented a Lecroy STX-231 SATA protocol analyzer. Using this tool

I have verified that the response from the optical drive is always

correct in this case but for some reason the data is corrupt by the time

the debug code I added to atapi_qc_complete dumps the response.

I have added debug code to dump the AHCI command header and table before

issuing a command. I have not seen anything out of the ordinary here. I

also added debug code to dump the received FIS on an interrupt. I

haven't studied the received FIS extensively but I did not see anything

out of the ordinary here either.

One thing I suspected and confirmed with the Lecroy analyzer is that the

response to the previous command during boot (ATAPI command 0x5A - Mode

Sense) is always 64 bytes even though the kernel is requesting 128

bytes. This exact behaviour is probably drive dependant. On a hunch I

modified the get_capabilities function in drivers/scsi/sr.c to only

request 64 bytes. With that change the response to the Get Event Status

Notification command during boot is always valid. Although running

cdparanoia or trying to keep using the system in other ways still

results in issues.

Using the Lecroy analyzer I found some other commands where cdparanoia

requests lengths longer than the drive responds with. Comparing the

debug dumps in the kernel to the data captured by the analyzer I can see

problems always start after this happens.

To try and characterize this further I started messing around with the

request lengths. I noticed in the AHCI command header dumps I added

that many of the ATAPI commands have a second SG DMA buffer. I found the

second buffer is added when atapi_drain_needed returns true in

libata-scsi.c. I started hacking the DMA buffer sizes by manipulating

the lengths written to the AHCI command table in the ahci_fill_sg

function in libata.c. I also hacked atap_drain_needed to sometimes

return false to force only one DMA buffer for ATAPI commands.

What I found is that if there are two DMA buffers and the response

length is less than the first buffer size then the response to the next

command is always corrupted. Every other scenario I tried worked okay.

Filling the first buffer and under, over or exactly using the second

buffer does not trigger the issue. If there is only one buffer under,

over or exactly using the one buffer does not trigger the issue.

One other thing I noticed is that if the response under runs the first

buffer and the second ATAPI drain buffer is smaller than the next

command response then the response to the next command is missing the

begging of the response equal to the length of the second buffer from

the previous command. I decided to add some debug code to print out the

DMA buffer used for the previous command. What I found is that the

missing part of the response is written to the DMA buffer from the

previous command. This is very bad as that memory could be dynamically

allocated and subsequently freed and now in use by something else!

Since overruns never seem to cause an issue in this setup I decided to

simply change the atap_drain_needed function to always return false.

With this change I can run cdparanoia successfully and rip audio tracks.

I can also add a port multiplier back to the setup and connect both an

HDD and the optical drive and experience no readily apparent issues.

So it seems I have found a workaround for the most severe symptoms we

were experiencing. But this still leaves me with several questions and

concerns:

1. Is the root cause some obscure bug in the kernel I have not found

yet? Or is it a hardware bug in the iMX6 AHCI SATA host? Or maybe

something else silly we have been doing?

2. When cdparanoia is ripping the actual data it uses large reads which

use multiple SG DMA buffers. What happens if the response is short in

this case? My atapi_drain_needed hack won't help in this case.

cdparanoia could probably be modified to only do smaller reads that fit

in one page to avoid the issue.

3. Can the issue happen with non ATAPI commands? If for any reason an

ATA command to a HDD has a short response could all future commands (and

possibly even system memory) be corrupted similar to what I saw with

ATAPI commands? I wonder if the kernel could be easily modified to limit

the size of ATA commands to avoid this scenario.

4. The Lecroy analyzer can also emulate a device. Using this mode I

tried to trigger the issue with ATA commands. I couldn't figure out how

to trigger the exact scenario I wanted. I was able to cause the

response to be too short, just not short enough to underrun anything but

the last DMA buffer which doesn't seem to cause a problem. What I did

notice though was that this didn't seem to trigger an error anywhere in

the kernel or user space, the data would just simply be corrupted. I

would expect the system should flag the response as being invalid and an

IO error propagated all the way to user space.

[JohnBirch]

Update from HongXing:

When audio CD_ROM DISC and the cutomer’s rootfs are used.

It seems that the cdparanoia can detect the CD_ROM device, but failed to open disc.

And I failed to mount the cdrom device by “mount –t iso9660 …”:

Here is the tests logs at my side:

root@****~$ cdparanoia -vsQ

cdparanoia III release 10.2 (September 11, 2008)

Using cdda library version: 10.2

Using paranoia library version: 10.2

Checking /dev/cdrom for cdrom...

        Testing /dev/cdrom for SCSI/MMC interface

SG_IO device: /dev/sr0

CDROM model sensed sensed: HL-DT-ST DVD+-RW GH50N B103

Checking for SCSI emulation...

        Drive is ATAPI (using SG_IO host adaptor emulation)

Checking for MMC style command set...

        Drive is MMC style

Unable to open disc.

root@****~$

root@****~$ cdparanoia -vsQ

cdparanoia III release 10.2 (September 11, 2008)

Using cdda library version: 10.2

Using paranoia library version: 10.2

Checking /dev/cdrom for cdrom...

        Testing /dev/cdrom for SCSI/MMC interface

SG_IO device: /dev/sr0

CDROM model sensed sensed: HL-DT-ST DVD+-RW GH50N B103

Checking for SCSI emulation...

        Drive is ATAPI (using SG_IO host adaptor emulation)

Checking for MMC style command set...

        Drive is MMC style

Unable to open disc.

root@****~$ mount -t iso9660 /dev/sr0 /mnt/cdrom/

sr 0:0:0:0: [sr0] 

Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

sr 0:0:0:0: [sr0] 

Sense Key : Illegal Request [current]

Info fld=0x10, ILI

sr 0:0:0:0: [sr0] 

1. Add. Sense: Illegal mode for this track

  sr 0:0:0:0: [sr0] CDB:  

Read(10): 28 00 00 00 00 10 00 00 01 00

end_request: I/O error, dev sr0, sector 64

isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16

mount: mounting /dev/sr0 on /mnt/cdrom/ failed: Invalid argument

root@****~$

root@****~$

root@****~$

root@****~$

root@****~$ mount -t iso9660 /dev/sr0 /mnt/cdrom/

sr 0:0:0:0: [sr0] 

Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

sr 0:0:0:0: [sr0] 

Sense Key : Illegal Request [current]

Info fld=0x10, ILI

sr 0:0:0:0: [sr0] 

1. Add. Sense: Illegal mode for this track

sr 0:0:0:0: [sr0] CDB:

Read(10): 28 00 00 00 00 10 00 00 01 00

end_request: I/O error, dev sr0, sector 64

isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16

mount: mounting /dev/sr0 on /mnt/cdrom/ failed: Invalid argument

root@****~$

root@****~$

[JohnBirch]

From HongXing:

The audio disc CD_ROM can be mounted by “mount -t iso9660 /dev/sr0 /mnt/cdrom/” when the Freescale RFS is used.

Here are the logs:
root@imx6sxsabresd:~# mount -t iso9660 /dev/sr0 /mnt/cdrom/

root@imx6sxsabresd:~# df

Filesystem 1K-blocks      Used  Available Use% Mounted on

1. 10.192.224.44:/data/rootfs_home/r65037/yacto/rootfs_2014_310_110ga 1922197336 740997840 1083534524  41% /

devtmpfs 217872 4     217868   1% /dev

tmpfs 40 0         40   0% /mnt/.psplash

tmpfs 381904 276     381628   1% /run

tmpfs 381904        96 381808   1% /var/volatile

/dev/mmcblk2p1 117760 48     117712   1% /run/media/mmcblk2p1

/dev/mmcblk3p1 7494760    432628    6658372   7% /run/media/mmcblk3p1

/dev/sr0 7274 7274          0 100% /mnt/cdrom

root@imx6sxsabresd:~# uname -a

Linux imx6sxsabresd 3.14.38-02160-g4be5c9f #251 SMP PREEMPT Fri May 22 10:56:53 CST 2015 armv7l GNU/Linux

root@imx6sxsabresd:~#  

[Jon_Bagg]

I can also get the CDROM to mount on the imx6q-sabre using our filesystem, just not 100% of the time (aprox 1/20 times it fails).  See above post - May 11, 2015 6:13 AM.

I wouldn't spend any more time on this mounting issue.  Spend time trying to figure out why ATAPI commands that come back a different length than requested cause DMA buffer corruption on imx6 and not the 53.

[JohnBirch]

We first need to confirm if the FSL Linux releases running on his i.MX53 QSB and i.MX6 Sabre boards have the same SATA command responses as ours when the boards are connected to a SATA optical drive.

To observe the command responses, we first need to apply the simple ata_debug.patch (attached) to the kernels of FSL’s Linux releases for the i.MX53 QSB & i.MX6 Sabre.

With an optical drive connected to the i.MX53 QSB (or i.MX6 Sabre), the SATA command responses can then be seen in a console during kernel boot.

On the i.MX53 QSB, the command response length indication bytes (shown in green below) are always correct.

On the i.MX6 Sabre, the command response length indication bytes (shown in red below) are always incorrect.

Once we confirm this result on our setup, customer can proceed with other debug info to help us fully reproduce and diagnose the problem. 

Customer often has evening calls with Asia, so we can arrange a call if it would help.

imx53 QSB – 3.14 kernel boot:

[ 2.713046] CDB rbuf: [4a 01 00 00 10 00 00 00 08]

[ 2.717849] CDB rbuf: 00000000: 00 06 04 56 00 02 00 00

imx6 Sabre – 3.14 kernel boot:

[ 3.451017] CDB rbuf: [4a 01 00 00 10 00 00 00 08]

[ 3.451024] CDB rbuf: 00000000: 01 a0 20 48 6f d6 f6 b5

[fabio_estevam]

Jonathan,

Today a patch was posted that fixes the SATA parent clock:

[PATCH 1/1] ARM: clk-imx6q: refine sata's parent — ARM, OMAP, Xscale Linux Kernel

Does it help?

Regards,

Fabio Estevam

[Jon_Bagg]

Unfortunately it does not.  The response to cmd 4a is still corrupt and cdparanoia still fails.

[Jon_Bagg]

My co-worker discovered something interesting....Using a kernel with ata_debug.patch applied he noticed that before there is any file system access or cdparanoia usage, on the imx6 the cdrom's response to command "4a" (GET_EVENT_STATUS_NOTIFICATION) is always corrupted / random on the imx6 and not the imx53.  The first two bytes of the response are the length and should always be 00 06.

imx53

[     2.713046] CDB rbuf: [4a 01 00 00 10 00 00 00 08]

[     2.717849] CDB rbuf: 00000000: 00 06 04 56 00 02 00 00

imx6

[     3.451017] CDB rbuf: [4a 01 00 00 10 00 00 00 08]

[     3.451024] CDB rbuf: 00000000: 01 a0 20 48 6f d6 f6 b5

He also discovered that changing the length of the previous command [     3.422134] CDB rbuf: [5a 00 2a 00 00 00 00 00 80] from 80 to 40, the "4a" will then succeed on the imx6.

[richard_zhu]

Hi Joanthan:
Thanks for your debug efforts firstly.

I received your rootfs today, but I failed to login although I replace the passwd and masked the rc.sovi line in rcS.

Do you know the passwd of user(18DF)?

Here is the log:

Known <ldisc> names:
  TTY         SLIP        MOUSE       PPP         STRIP       AX25     
  X25         6PACK       R3964       IRDA        HDLC        SYNC_PPP 
  SYNCPPP     HCI         PPS         M101        GIGASET     GIGASET_M101

Known <iflag> names:
  IGNBRK      BRKINT      IGNPAR      PARMRK      INPCK       ISTRIP   
  INLCR       IGNCR       ICRNL       IUCLC       IXON        IXANY    
  IXOFF       IMAXBEL     IUTF8    

For more details see ldattach(8).
I/O warning : failed to load external entity "/etc/sovi_info.xml"
Failed to create client object: Daemon not running
I/O warning : failed to load external entity "/etc/sovi_info.xml"
sed: /etc/sovi_info.xml: No such file or directory
sed: /var/avahi/services/*: No such file or directory
Error connecting: Error connecting: No such file or directory
I/O warning : failed to load external entity "/etc/sovi_info.xml"
/etc/rc.d/rcS: line 84:  1310 Segmentation fault      sovi_hal
modprobe: chdir(3.14.38-02099-g22acdbb): No such file or directory
File does not exist: /etc/sovi_info.xml at /etc/rc.d/rc.alsa line 7
Generating keys for the dropbear ssh server:
Will output 1024 bit rsa secret key to '/var/data/etc/dropbear_rsa_host_key'
Generating key, this may take a while...
Public key portion is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgwDjcQUsMQMlmQhVD9bYmLQno77/iJXp9N1Zz3fEkgC588Jy/4+mML7xubqN+zucmtLDh9ND0LPFc0vy4+AwZ4QRB6kmeeZuGhqevUE+poElsvzOZz7daAwMfy8hY6DZ2O7JP7V9sj5lfj/ar993bkyEvob8Bj4V7NZlZ47V0+ee81nL root@18DF
Fingerprint: md5 93:f8:d5:5a:9a:7c:e0:30:1d:37:24:01:8c:2e:97:2c
Start dropbear ssh server
sed: /etc/sovi_info.xml: No such file or directory
Unknown group "netdev" in message bus configuration file
~~~~mask rc.sovi~~~~
All done
starting pid 1341, tty '': '/sbin/getty -L ttymxc0 115200 vt100'
sed: /etc/sovi_info.xml: No such file or directory
sed: /etc/sovi_info.xml: No such file or directory
avahi-browser-sovi 0.5

18DF login: Could not open sovi_info.xml

18DF login:

BTW, it seems that the dvd_rom works refer to the boot log of kernel:

......

ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

ata1.00: ATAPI: HL-DT-ST DVD+/-RW GH50N, B103, max UDMA/100

ata1.00: configured for UDMA/100

mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA

mmc2: no vqmmc regulator found

mmc2: no vmmc regulator found

scsi 0:0:0:0: CD-ROM            HL-DT-ST DVD+-RW GH50N    B103 PQ: 0 ANSI: 5

sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray

cdrom: Uniform CD-ROM driver Revision: 3.20

......

[Jon_Bagg]

Here is a rootfs with sovi_info.xml (sorry about that). root password is 123456

https://lenbrook.sharefile.com/d-scfae212d60c4115a

The CD-ROM also registers for me...

scsi 0:0:0:0: CD-ROM     TEAC     DV-W28SS-B     1.2A PQ: 0 ANSI: 5

cdrom: Uniform CD-ROM driver Revision:     3.20

sr 0:0:0:0: Attached scsi CD-ROM sr0

[richard_zhu]

When audio CD_ROM DISC and the cutomer’s rootfs are used.

It seems that the cdparanoia can detect the CD_ROM device, but
failed to open disc.

And I failed to mount the cdrom device by “mount –t iso9660 …”:

Is it aligned to your phenomena?

Here is the tests logs at my side:

~~~~~~~~~~~~~~~~~~~~~~~logs~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

root@VAULT2-18DF ~$ cdparanoia -vsQ

cdparanoia III release 10.2 (September 11, 2008)

Using cdda library version: 10.2

Using paranoia library version: 10.2

Checking /dev/cdrom for cdrom...

        Testing /dev/cdrom
for SCSI/MMC interface

              
SG_IO device: /dev/sr0

CDROM model sensed sensed: HL-DT-ST DVD+-RW GH50N B103

Checking for SCSI emulation...

        Drive is ATAPI (using
SG_IO host adaptor emulation)

Checking for MMC style command set...

        Drive is MMC style

Unable to open disc.

root@VAULT2-18DF ~$

root@VAULT2-18DF ~$ cdparanoia -vsQ

cdparanoia III release 10.2 (September 11, 2008)

Using cdda library version: 10.2

Using paranoia library version: 10.2

Checking /dev/cdrom for cdrom...

        Testing /dev/cdrom
for SCSI/MMC interface

              
SG_IO device: /dev/sr0

CDROM model sensed sensed: HL-DT-ST DVD+-RW GH50N B103

Checking for SCSI emulation...

        Drive is ATAPI (using
SG_IO host adaptor emulation)

Checking for MMC style command set...

        Drive is MMC style

Unable to open disc.

root@VAULT2-18DF ~$ mount -t iso9660 /dev/sr0 /mnt/cdrom/

sr 0:0:0:0: [sr0] 

Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

sr 0:0:0:0: [sr0] 

Sense Key : Illegal Request [current]

Info fld=0x10, ILI

sr 0:0:0:0: [sr0] 

Add. Sense: Illegal mode for this track

sr 0:0:0:0: [sr0] CDB:

Read(10): 28 00 00 00 00 10 00 00 01 00

end_request: I/O error, dev sr0, sector 64

isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16

mount: mounting /dev/sr0 on /mnt/cdrom/ failed: Invalid argument

root@VAULT2-18DF ~$

root@VAULT2-18DF ~$

root@VAULT2-18DF ~$

root@VAULT2-18DF ~$

root@VAULT2-18DF ~$ mount -t iso9660 /dev/sr0 /mnt/cdrom/

sr 0:0:0:0: [sr0] 

Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

sr 0:0:0:0: [sr0] 

Sense Key : Illegal Request [current]

Info fld=0x10, ILI

sr 0:0:0:0: [sr0] 

Add. Sense: Illegal mode for this track

sr 0:0:0:0: [sr0] CDB:

Read(10): 28 00 00 00 00 10 00 00 01 00

end_request: I/O error, dev sr0, sector 64

isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16

mount: mounting /dev/sr0 on /mnt/cdrom/ failed: Invalid argument

root@VAULT2-18DF ~$

root@VAULT2-18DF ~$

[richard_zhu]

I tried at my side on imx6q sd board, with the fsl's 3.14 kernel and v4.0-rc1 kernel, the cd-rom works.

NOTE: The power supply of the DVD_ROM and so on, should be provide by the  external PC power supply.

I'm afraid that the power consumption of the DVD_ROM device is too huge to supplied by imx6q sd board itself.

Can you retry it when the external power supply is used?

V4.0 -rc1

---------------logs----------------------

root@imx6sxsabresd:~# dmesg | grep ata
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Kernel command line: noinitrd console=ttymxc0,115200 mem=768M root=/dev/nfs nfsroot=10.192.224.44:/data/rootfs_home/r65037/yacto/rootfs_2014_310_110ga, tcp ip=dhcp no_console_suspend earlyprintk rw
[    0.000000] Memory: 743828K/786432K available (7211K kernel code, 388K rwdata, 2500K rodata, 372K init, 8350K bss, 26220K reserved, 16384K cma-reserved, 0K highmem)
[    0.000000]       .data : 0x809e2000 - 0x80a432c0   ( 389 kB)
[    0.184484] libata version 3.00 loaded.
[    2.168019] ahci-imx 2200000.sata: fsl,transmit-level-mV not specified, using 00000024
[    2.175990] ahci-imx 2200000.sata: fsl,transmit-boost-mdB not specified, using 00000480
[    2.184034] ahci-imx 2200000.sata: fsl,transmit-atten-16ths not specified, using 00002000
[    2.192246] ahci-imx 2200000.sata: fsl,receive-eq-mdB not specified, using 05000000
[    2.203138] ahci-imx 2200000.sata: SSS flag set, parallel bus scan disabled
[    2.210167] ahci-imx 2200000.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[    2.218980] ahci-imx 2200000.sata: flags: ncq sntf stag pm led clo only pmp pio slum part ccc apst
[    2.235652] ata1: SATA max UDMA/133 mmio [mem 0x02200000-0x02203fff] port 0x100 irq 312
[    2.789195] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    2.798035] ata1.00: ATAPI: HL-DT-ST DVD+/-RW GH50N, B103, max UDMA/100
[    2.807626] ata1.00: configured for UDMA/100
[   10.676048] EXT4-fs (mmcblk1p1): mounted filesystem with ordered data mode. Opts: (null)
[   10.700946] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
root@imx6sxsabresd:~# mount -t iso9660 /dev/sr0 /mnt/cdrom/
root@imx6sxsabresd:~# df
Filesystem                                                          1K-blocks      Used  Available Use% Mounted on
10.192.224.44:/data/rootfs_home/r65037/yacto/rootfs_2014_310_110ga 1922197336 673351608 1151180756  37% /
devtmpfs                                                               371912         4     371908   1% /dev
tmpfs                                                                      40         0         40   0% /mnt/.psplash
tmpfs                                                                  380292       192     380100   1% /run
tmpfs                                                                  380292        96     380196   1% /var/volatile
/dev/mmcblk1p1                                                        7494760    432628    6658372   7% /run/media/mmcblk1p1
/dev/mmcblk0p1                                                         117760        48     117712   1% /run/media/mmcblk0p1
/dev/sr0                                                                 7274      7274          0 100% /mnt/cdrom
root@imx6sxsabresd:~# uname -a
Linux imx6sxsabresd 4.0.0-rc1 #167 SMP Mon May 11 14:11:59 CST 2015 armv7l GNU/Linux
root@imx6sxsabresd:~#

3.14

----------------logs------------------------------

root@imx6sxsabresd:~# dmesg | grep ata
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Memory policy: Data cache writealloc
Kernel command line: noinitrd console=ttymxc0,115200 mem=768M root=/dev/nfs nfsroot=10.192.224.44:/data/rootfs_home/r65037/yacto/rootfs_2014_310_110ga, tcp ip=dhcp no_console_suspend earlyprintk rw
Memory: 433184K/786432K available (7664K kernel code, 456K rwdata, 8744K rodata, 388K init, 438K bss, 353248K reserved, 0K highmem)
      .data : 0x81072000 - 0x810e42a0   ( 457 kB)
libata version 3.00 loaded.
ahci-imx 2200000.sata: fsl,transmit-level-mV not specified, using 00000024
ahci-imx 2200000.sata: fsl,transmit-boost-mdB not specified, using 00000480
ahci-imx 2200000.sata: fsl,transmit-atten-16ths not specified, using 00002000
ahci-imx 2200000.sata: fsl,receive-eq-mdB not specified, using 05000000
ahci-imx 2200000.sata: SSS flag set, parallel bus scan disabled
ahci-imx 2200000.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode
ahci-imx 2200000.sata: flags: ncq sntf stag pm led clo only pmp pio slum part ccc apst
ata1: SATA max UDMA/133 mmio [mem 0x02200000-0x02203fff] port 0x100 irq 71
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATAPI: HL-DT-ST DVD+/-RW GH50N, B103, max UDMA/100
ata1.00: configured for UDMA/100
mxc_vdoa 21e4000.vdoa: i.MX Video Data Order Adapter(VDOA) driver probed
FAT-fs (mmcblk2p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
EXT4-fs (mmcblk3p1): mounted filesystem with ordered data mode. Opts: (null)
root@imx6sxsabresd:~# mount -t iso9660 /dev/s
shm/    snd/    sr0     stderr  stdin   stdout 
root@imx6sxsabresd:~# mount -t iso9660 /dev/sr0 /mnt/cdrom/
root@imx6sxsabresd:~# df
Filesystem                                                          1K-blocks      Used  Available Use% Mounted on
10.192.224.44:/data/rootfs_home/r65037/yacto/rootfs_2014_310_110ga 1922197336 673337648 1151194716  37% /
devtmpfs                                                               216592         4     216588   1% /dev
tmpfs                                                                      40         0         40   0% /mnt/.psplash
tmpfs                                                                  380624       276     380348   1% /run
tmpfs                                                                  380624        96     380528   1% /var/volatile
/dev/mmcblk2p1                                                         117760        48     117712   1% /run/media/mmcblk2p1
/dev/mmcblk3p1                                                        7494760    432628    6658372   7% /run/media/mmcblk3p1
/dev/sr0                                                                 7274      7274          0 100% /mnt/cdrom
root@imx6sxsabresd:~# ls /mnt/cdrom/ -lt
total 4518
-r-xr-xr-x 1 root root 4423701 Jan 21  2010 WT_3978.exe
-r-xr-xr-x 1 root root  190989 Jan 21  2010 WT_3978.swf
dr-xr-xr-x 1 root root    2048 Jan 18  2010 fscommand
dr-xr-xr-x 1 root root    2048 Dec 22  2009 files
dr-xr-xr-x 1 root root    2048 Dec 22  2009 Scripts
-r-xr-xr-x 1 root root    1653 Dec 22  2009 WT_3978.html
-r-xr-xr-x 1 root root      49 Dec 22  2009 AUTORUN.INF
-r-xr-xr-x 1 root root    1150 May 20  2008 freescale.ico

Linux version 3.14.38-02099-g22acdbb (r65037@shlinux2) (gcc version 4.8.2 (GCC) ) #330 SMP PREEMPT Mon May 11 13:40:26 CST 2015

[Jon_Bagg]

Hongxing,

I can also get the CDROM to mount on the imx6q-sabre, just not 100% of the time.  Please try

cdparanoia -vsQ

with an audio CD and see if you can get a track listing on your setup as it is 100 failure / reproducible on our setup.

[fabio_estevam]

Hi Jonathan,

Just a suggestion:

Could you share your rootfs with cdparanoia application installed? That would makes things easier for Richard to reproduce.

[Jon_Bagg]

https://lenbrook.sharefile.com/d-s59f1181de4f466eb

1. You'll have to replace the password file before booting

2. comment out this line

/etc/rc.d/rc.sovi &

at the end of /etc/rc.d/rcS

if [[ -e /var/data/intertek ]]; then

    mount -o remount junk /

    /usr/bin/etf_serv &

else

    # start sovi

    # /etc/rc.d/rc.sovi &

fi