linux-kernel - Re: 2.6.27.3, ata_piix: cannot play audio CD, "disk change detected"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49061803.4060707@garzik.org>
Date:	Mon, 27 Oct 2008 15:35:31 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Harald Dunkel <harald.dunkel@...nline.de>
CC:	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.27.3, ata_piix: cannot play audio CD, "disk change detected"

Harald Dunkel wrote:
> Hi folks,
> 
> If I insert an audio CD in my sata drive to play it via grip, then
> it fails. Grip does not even show the list of audio tracks, nor does
> it play the CD. Instead there is a kernel message saying
> 
> [ 6730.836999] sr0: CDROM not ready yet.
> [ 6732.838572] sr0: disc change detected.
> [ 6783.659021] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> [ 6783.659034] ata4.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
> [ 6783.659035]          cdb 1b 00 00 00 02 00 00 00  00 00 00 00 00 00 00 00
> [ 6783.659036]          res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> [ 6783.659038] ata4.00: status: { DRDY }
> [ 6783.659046] ata4: hard resetting link
> [ 6784.115039] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 6785.622185] ata4.00: configured for UDMA/100
> [ 6785.622193] ata4: EH complete
> 
> 
> The same CDs work fine with an USB CD drive attached to the same
> PC, so this might be a sata driver issue. (BTW, stopping hal doesn't
> make a difference. Data CDs work fine.)
> 
> Any idea what goes wrong here? Does grip violate the SCSI protocol
> here?  Is there something I could try to help to track this down?

hmmmm, I used to see something similar on ICH7 but it went away.

Can you try various strategies associated with interrupts (trying to 
determine the cause of the timeouts), such as booting with "noapic", 
"acpi=off", and/or pci=biosirq.

	Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/