From: Daniel Drake <dsd@gentoo.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux list <linux-kernel@vger.kernel.org>, linux-ide@vger.kernel.org
Subject: Re: "Fix ATAPI transfer lengths" causes CD writing regression
Date: Tue, 30 Oct 2007 17:45:46 +0000 [thread overview]
Message-ID: <47276DCA.1000808@gentoo.org> (raw)
In-Reply-To: <20071030153417.59b9182c@the-village.bc.nu>
[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]
Alan Cox wrote:
> Not immediately - but if you've got wrong transfer lengths its a
> candidate for this.
>
> Ok lets start with the basics
>
> If you mount a CD and use it does it work
Yep.
> If you use cdrecord does it work ?
Yep (tested with wodim from debburn, effectively the same thing)
> What vendor drive and does it seem to be a specific box/drive that
> triggers this ?
Device type : Removable CD-ROM
Version : 5
Response Format: 2
Capabilities :
Vendor_info : 'PHILIPS '
Identification : 'DVD+-RW SDVD8820'
Revision : 'AD15'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
This is on my laptop (Dell Inspiron 640m). I won't have access to
another system to test this there until next week.
The nutty app I was using for burning is Brasero, a GNOME app which does
some SG_IO directly with the drive. (I guess it has some bad error
handling and doesn't realise when some I/O path has failed)
I have narrowed down the exact command submission which causes those
nasty messages in dmesg. The function which submits this is named
"brasero_medium_get_page_2A_write_speed_desc".
The test program that I've attached can now reproduce this error every
time it is run. The output is:
result 0
check sense data:
72 0b 47 00 00 00 00 0e 09 0c 00 00 00 02 00 00 00 0a 00
I get the same output and dmesg errors even when there is no media in
the drive.
I have had a quick look at the SCSI command being submitted there, and
don't see anything wrong.
What next?
Daniel
[-- Attachment #2: testsg.c --]
[-- Type: text/plain, Size: 1471 bytes --]
#include <stdio.h>
#include <scsi/sg.h>
#include <scsi/scsi.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int main(void)
{
struct sg_io_hdr transport;
unsigned char cmd[] = {
0x5a, //opcode -- mode sense(10)
0x08, //dbd, llbaa -- dbd=1
0x2a, //page code -- BRASERO_SPC_PAGE_STATUS
// spc-3 says thats "CD capabilities and mechanical status"
//
0x00, //brasero says reserved, spc3 says subpage code
0x00, //reserved
0x00, //reserved
0x00, //alloc len
0x0a, //alloc len
0x00, //ctl
};
unsigned char buffer[10];
unsigned char sense_data[19];
int r;
int i;
int fd = open("/dev/sr0", O_RDONLY|O_NONBLOCK);
if (fd < 0) {
printf("open failed\n");
exit(1);
}
memset(&transport, 0, sizeof(transport));
memset(buffer, 0, sizeof(buffer));
memset(sense_data, 0, sizeof(sense_data));
transport.interface_id = 'S';
transport.cmdp = cmd;
transport.cmd_len = sizeof(cmd);
transport.dxferp = buffer;
transport.dxfer_len = sizeof(buffer);
transport.sbp = sense_data;
transport.mx_sb_len = sizeof(sense_data);
transport.dxfer_direction = SG_DXFER_FROM_DEV;
r = ioctl(fd, SG_IO, &transport);
printf("result %d\n", r);
if ((transport.masked_status & CHECK_CONDITION) && transport.sb_len_wr) {
printf("check sense data:\n");
for (i = 0; i < sizeof(sense_data); i++)
printf("%02x ", sense_data[i]);
printf("\n");
}
}
next prev parent reply other threads:[~2007-10-30 17:46 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-30 15:14 "Fix ATAPI transfer lengths" causes CD writing regression Daniel Drake
2007-10-30 15:34 ` Alan Cox
2007-10-30 17:45 ` Daniel Drake [this message]
2007-10-30 18:26 ` Frans Pop
2007-10-30 19:01 ` Alan Cox
2007-10-30 19:21 ` Daniel Drake
2007-10-31 11:49 ` Alan Cox
2007-10-31 11:57 ` Jens Axboe
2007-10-31 12:20 ` Jeff Garzik
2007-10-31 12:26 ` Jens Axboe
2007-10-31 16:05 ` Jeff Garzik
2007-10-31 16:29 ` Alan Cox
2007-10-31 16:34 ` Daniel Drake
2007-10-31 17:55 ` Jens Axboe
2007-11-01 0:40 ` Tejun Heo
2007-11-01 7:24 ` Tejun Heo
2007-11-01 10:50 ` Alan Cox
2007-10-31 12:49 ` Alan Cox
2007-11-01 9:48 ` Jeff Garzik
2007-11-01 10:53 ` Alan Cox
2007-11-01 11:09 ` Jeff Garzik
2007-11-01 14:15 ` Alan Cox
2007-11-01 15:33 ` Daniel Drake
2007-11-01 15:57 ` Alan Cox
2007-11-01 16:06 ` Tejun Heo
2007-11-01 16:04 ` Tejun Heo
2007-11-02 21:19 ` Daniel Drake
2007-11-03 1:17 ` Tejun Heo
2007-11-03 12:34 ` Jeff Garzik
2007-11-03 20:02 ` Daniel Drake
2007-11-04 0:07 ` Tejun Heo
2007-11-04 4:02 ` Albert Lee
2007-11-04 23:42 ` Alan Cox
2007-11-05 0:05 ` Tejun Heo
2007-11-05 13:03 ` Alan Cox
2007-11-06 10:18 ` Tejun Heo
2007-11-06 12:48 ` Alan Cox
2007-11-05 0:15 ` Daniel Drake
2007-11-02 17:58 ` Jeff Garzik
2007-10-30 16:02 ` Jeff Garzik
2007-10-30 16:10 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47276DCA.1000808@gentoo.org \
--to=dsd@gentoo.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).