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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.