| 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
| ||
|
Date: Tue, 29 Jan 2008 21:58:36 +0200
From: Boaz Harrosh <bharrosh@...asas.com>
To: Jens Axboe <jens.axboe@...cle.com>
CC: James Bottomley <James.Bottomley@...senPartnership.com>,
Matthew Dharm <mdharm-kernel@...-eyed-alien.net>,
Oliver Neukum <oliver@...kum.org>, Greg KH <greg@...ah.com>,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
linux-scsi@...r.kernel.org
Subject: Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008 at 21:45 +0200, Jens Axboe <jens.axboe@...cle.com> wrote:
> On Tue, Jan 29 2008, Jens Axboe wrote:
>> On Tue, Jan 29 2008, James Bottomley wrote:
>>> On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
>>>> On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote:
>>>>> On Tue, Jan 29 2008, Jens Axboe wrote:
>>>>>> On Tue, Jan 29 2008, Oliver Neukum wrote:
>>>>>>> Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
>>>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
>>>>>>>>> On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@...cle.com> wrote:
>>>>>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
>>>>>>>>>>> Greg KH wrote:
>>>>>>>
>>>>>>>>>> No difference, still just a lot of resets.
>>>>>>>>>>
>>>>>>>>> Where you able to figure out which usb storage transport is used?
>>>>>>>>>
>>>>>>>>> in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
>>>>>>>>> functions. I'm not sure if these get stored in sysfs perhaps. This will
>>>>>>>>> pinpoint better where to look. Let me research a bit.
>>>>>>>> Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
>>>>>>>> transport is 'Bulk'
>>>>>>> You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
>>>>>>> That should tell the reason for the resets.
>>>>>> Sure, I'll do that. Will post the results tonight.
>>>>> OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
>>>>> in the device, waited 10 seconds or so and pulled it out. These are the
>>>>> messages.
>>>>>
>>>>> It all looks good until the MODE_SENSE command, where it only transfers
>>>>> 4 of 192 bytes.
>>>> No, that's not the problem. This is the problem:
>>>>
>>>>> usb-storage: *** thread awakened.
>>>>> usb-storage: Command TEST_UNIT_READY (6 bytes)
>>>>> usb-storage: 00 00 00 00 00 00
>>>>> usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6
>>>>> usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
>>>>> usb-storage: Status code 0; transferred 31/31
>>>>> usb-storage: -- transfer complete
>>>>> usb-storage: Bulk command transfer result=0
>>>>> usb-storage: Attempting to get CSW...
>>>>> usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
>>>>> usb-storage: Status code 0; transferred 13/13
>>>>> usb-storage: -- transfer complete
>>>>> usb-storage: Bulk status result = 0
>>>>> usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1
>>>>> usb-storage: -- transport indicates command failure
>>>>> usb-storage: Issuing auto-REQUEST_SENSE
>>>>> usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6
>>>>> usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
>>>>> usb-storage: Status code 0; transferred 31/31
>>>>> usb-storage: -- transfer complete
>>>>> usb-storage: Bulk command transfer result=0
>>>>> usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries
>>>>> usb-storage: usb_sg_init returned -22
>>>>> usb-storage: Bulk data transfer result 0x4
>>>>> usb-storage: -- auto-sense failure
>>>>> usb-storage: storage_pre_reset
>>>>> ehci_hcd 0000:00:1d.7: port 1 high speed
>>>>> ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>> ehci_hcd 0000:00:1d.7: port 1 high speed
>>>>> ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
>>>>> usb-storage: storage_post_reset
>>>>> usb-storage: usb_reset_composite_device returns 0
>>>>> usb-storage: scsi cmd done, result=0x70000
>>>>> usb-storage: *** thread sleeping.
>>>> For some reason, usb_sg_init is boned during auto-sense.
>>> OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
>>> code ... that was also an update in 2.6.24
>> yeah, already found the bug - it's assuming ->request_buffer holds the
>> sglist, oops. Preparing a fix.
>
> ok here goes, this saves and restores the sg table correctly. it also
> fixes the usb bug for me.
>
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index 547e85a..12770ef 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct scsi_eh_save *ses,
> ses->use_sg = scmd->use_sg;
> ses->resid = scmd->resid;
> ses->result = scmd->result;
> + memcpy(&ses->sense_sgl, &scmd->sg_table, sizeof(ses->sense_sgl));
>
> if (sense_bytes) {
> scmd->request_bufflen = min_t(unsigned,
> SCSI_SENSE_BUFFERSIZE, sense_bytes);
> sg_init_one(&ses->sense_sgl, scmd->sense_buffer,
> scmd->request_bufflen);
> - scmd->request_buffer = &ses->sense_sgl;
> + scmd->sg_table.sgl = &ses->sense_sgl;
> + scmd->sg_table.nents = scmd->sg_table.orig_nents = 1;
> scmd->sc_data_direction = DMA_FROM_DEVICE;
> scmd->use_sg = 1;
> memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
> @@ -679,6 +681,7 @@ void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd, struct scsi_eh_save *ses)
> scmd->request_bufflen = ses->bufflen;
> scmd->request_buffer = ses->buffer;
> scmd->use_sg = ses->use_sg;
> + memcpy(&scmd->sg_table, &ses->sg_table, sizeof(scmd->sg_table));
> scmd->resid = ses->resid;
> scmd->result = ses->result;
> }
> diff --git a/include/scsi/scsi_eh.h b/include/scsi/scsi_eh.h
> index d21b891..d43dc83 100644
> --- a/include/scsi/scsi_eh.h
> +++ b/include/scsi/scsi_eh.h
> @@ -75,6 +75,7 @@ struct scsi_eh_save {
>
> void *buffer;
> unsigned bufflen;
> + struct sg_table sg_table;
> unsigned short use_sg;
> int resid;
>
>
Ok this is not in Linus tree is it? Hence I did not have that failure.
Boaz
--
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/
Powered by blists - more mailing lists