Alan Cox wrote:
quoted text
> 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.

quoted text
> If you use cdrecord does it work ?

Yep (tested with wodim from debburn, effectively the same thing)

quoted text
> 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