Hi,
On 08/04/2010 05:25 PM, Alan Stern wrote:
On Wed, 4 Aug 2010, Hans de Goede wrote:
Hi,
On 08/04/2010 04:41 PM, Alan Stern wrote:
On Tue, 3 Aug 2010, Matthew Dharm wrote:
I'm willing to bet there are more devices out there like this. Experience
has shown that the more we make the stack issue commands to the device like
one of the "popular" OSes, the fewer problems we have. Thus, I prefer to
fix these where commands originate.
This is a good point. Since Windows apparently never sends
READ_DISC_INFO commands, we court trouble by using those commands in
the cdrom driver. Is there any way to avoid using them?
As far as the READ-CAPACITY(16) bug, there may be a simpler fix. In
sd_read_capacity(), change
if (sdp->fix_capacity ||
to
if ((sdp->fix_capacity&& sdkp->capacity> 0) ||
That won't work, the trouble happens before fix_capacity comes into play. The
overflow is happening inside the mp3 player. When there is no card in the slot
the mp3 player tries to report a size of 0. But as scsi get_capacity uses
the last sector number, the mp3 player returns its internal size variable -1,
resulting in it returning 0xffffffff. This then gets increased by 1 by
read_capacity_10 to 0x100000000, which triggers the following bit:
if ((sizeof(sdkp->capacity)> 4)&&
(sdkp->capacity> 0xffffffffULL)) {
int old_sector_size = sector_size;
sd_printk(KERN_NOTICE, sdkp, "Very big device. "
"Trying to use READ CAPACITY(16).\n");
sector_size = read_capacity_16(sdkp, sdp, buffer);
This issues a READ CAPACITY(16) and the mp3 player dies (until reset). Also
notice that my sd.c patch for this does more then just stop sd.c from
sending READ CAPACITY(16), it also turns a READ CAPACITY(10) answer
of 0xffffffff into 0 instead of 0x100000000 when the quirk flag is set.
Okay, so much for that bright idea.
On the other hand, it's clear that the sd driver doesn't even try to
issue a READ CAPACITY command if there's no medium present. How come
this is happening at all? Does the device report that a card is
present even when the slot is empty? Or does it claim not to have
removable media in the first place?
I have not investigated, but this is not something which we can easily fix
with a quirk AFAIK, as some of the LUN's of the device are not removable
and others are, and we don't know if there is a card present or not.
More over I guess (but have not verified) the answer is:
It claims not to have removable media in the first place
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
