Re: Problems with USB disk [solved]
On Wed, Sep 12, 2007 at 06:10:50PM -0400, Mark Lord wrote: > Chuck Ebbert wrote: >> On 08/13/2007 10:50 AM, Niels wrote: >>> On Sunday 12 August 2007 11:54, Niels wrote: >>> On Friday 10 August 2007 14:43, Niels wrote: > On Wednesday 08 August 2007 12:57, Ismail D??nmez wrote: > >> On Wednesday 08 August 2007 13:48:29 you wrote: >>> On Tuesday 07 August 2007 23:18, Greg KH wrote: On Tue, Aug 07, 2007 at 10:26:15PM +0200, Niels wrote: > Hi, > > I'm having problems with a new 500 GB USB disk. It works, but > sometimes I get these in dmesg: > > > usb 1-3: reset high speed USB device using ehci_hcd and address 2 > usb 5-1: USB disconnect, address 2 > drivers/usb/class/usblp.c: usblp0: removed > sd 0:0:0:0: Device not ready: <6>: Sense Key : 0x2 [current] > > : ASC=0x4 ASCQ=0x2 > > end_request: I/O error, dev sda, sector 254148215 > sd 0:0:0:0: Device not ready: <6>: Sense Key : 0x2 [current] > > : ASC=0x4 ASCQ=0x2 > > end_request: I/O error, dev sda, sector 252434023 > EXT3-fs error (device sda1): ext3_find_entry: reading directory > #15761836 offset 0 > > > There's also a printer connected. This is on a pci/usb2 card. When > the above happens, I get I/O errors. When I mount the drive next, > there are errors and often missing files. Quite annoying! > > Kernel is 2.6.21 > > What's going on? You have a low voltage issue, or a bad cable. The device is electronically disconnecting itself. Try using a externally-powered hub, or a new cable. >> I am seeing a similar problem with 2.6.22 and 2.6.23-* kernels with my >> 60G iPod Video, works fine with 2.6.18 kernel though. >> > So far I'm seeing this: > > - On 2.6.21 I mount the drive. After a while it spins down, and when I > then unmount it, an error pops up in dmesg. > > - On 2.6.18 I can't provoke the same error. The drive doesn't appear to > spin down. I don't know if the data corruption from 2.6.21 occurs with > regular use. > > There are a number of other factor I need to eliminate on my system, > but > that's it so far. CONFIG_USB_SUSPEND is not set on either kernel. OK, on a vanilla 2.6.18.8 I also have this problem, with both the pci/usb2 card, and the usb1 on the board. I listen to music from the drive, and after some time (10-20 minutes or so), it freaks out: = sd 1:0:0:0: Device not ready: <6>: Current: sense key=0x2 ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 126693711 sd 1:0:0:0: Device not ready: <6>: Current: sense key=0x2 ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 126693711 sd 1:0:0:0: Device not ready: <6>: Current: sense key=0x2 ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 126693711 = >>> Using a new PSU and a powered hub made no difference. But I found a >>> solution >>> here: >>> >>> http://alienghic.livejournal.com/382903.html >>> >>> Basically, the problem is, as suspected, that the drive spins down / goes >>> to >>> suspend. This can be disabled with "sdparm --clear STANDBY -6 /dev/sda". >>> >>> It seems to me to be an error that the kernel reports this as something >>> like >>> a hardware failure. Or at least very misleading. >>> >> Oh, nice. The usb-storage (SCSI) disk spins itself down and we can't >> handle that. >> Should we be disabling auto-spindown when we connect the device, or be >> able to >> handle this by sending the start command when needed? > > There's more to this. > > My Sandisk Cruzer Micro 1GB USB sticks suffer from this regression. > Plug one in, it works for about 5 seconds, then the light goes off (bad). > Next access requires a 30s timeout + reset. Etc.. > > This is with 2.6.23-rc6. > Works without any problems in 2.6.22. REGRESSION. Disable CONFIG_USB_SUSPEND, that will fix the problem for you, or we can add your device to the quirk list. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata & scsi suggestion for make menuconfig
On Sun, Sep 09, 2007 at 05:11:44PM -0400, Jeff Garzik wrote: > Andi Kleen wrote: >>> I can see where you're coming from, but logically, this is wrong. >>> There's a huge slew of enterprise machines that only have DVD on SATA. >> ... and enterprise systems don't really care about a few KB more of code. >> In fact you definitely want to have SATA compiled in in case you need >> to recover the machine later when the SAN is down. >>> On the other hand, all of these machines will have SCSI disk devices on >>> various other transports, so no harm is done, it's just an inelegant >>> solution. >> Do you know of a better one? > > Let's step back a moment and consider the actual scale and impact of the > problem at hand. > > The vast majority of users are consumers of pre-compiled kernels, built by > People With Clue(tm), who figured this stuff out as soon as it was > introduced. We are talking about a patch to kconfig, and the users using pre-compiled kernels are not kconfig users. > The current setup expresses the dependencies as they exist -- OPTIONAL > extras, and that is a problem once a year or so, when someone builds their > own kernel but must learn this fact anew. > > There is simply no compelling need at all to change things from the current > setup. > > Our Kconfig system is for people who already know the kernel, not Aunt > Tillie. Couldn't we just remove kconfig and assume that all "people who already know the kernel" anyway prefer to edit their .config using vi? ;-) In my experience, the vast majority of kconfig users are not the few people working on distribution kernels, most of the kconfig userbase could be better described by the use case "sysadmin who knows about the hardware in his machine and which filesystems he uses". And there must have been a reason why a leading kernel developer has written a complete book covering only configuration and building of the kernel - the target audience of this book are most likely not "people who already know the kernel". > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with USB disk [solved]
Chuck Ebbert wrote: On 08/13/2007 10:50 AM, Niels wrote: On Sunday 12 August 2007 11:54, Niels wrote: On Friday 10 August 2007 14:43, Niels wrote: On Wednesday 08 August 2007 12:57, Ismail Dönmez wrote: On Wednesday 08 August 2007 13:48:29 you wrote: On Tuesday 07 August 2007 23:18, Greg KH wrote: On Tue, Aug 07, 2007 at 10:26:15PM +0200, Niels wrote: Hi, I'm having problems with a new 500 GB USB disk. It works, but sometimes I get these in dmesg: usb 1-3: reset high speed USB device using ehci_hcd and address 2 usb 5-1: USB disconnect, address 2 drivers/usb/class/usblp.c: usblp0: removed sd 0:0:0:0: Device not ready: <6>: Sense Key : 0x2 [current] : ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 254148215 sd 0:0:0:0: Device not ready: <6>: Sense Key : 0x2 [current] : ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 252434023 EXT3-fs error (device sda1): ext3_find_entry: reading directory #15761836 offset 0 There's also a printer connected. This is on a pci/usb2 card. When the above happens, I get I/O errors. When I mount the drive next, there are errors and often missing files. Quite annoying! Kernel is 2.6.21 What's going on? You have a low voltage issue, or a bad cable. The device is electronically disconnecting itself. Try using a externally-powered hub, or a new cable. I am seeing a similar problem with 2.6.22 and 2.6.23-* kernels with my 60G iPod Video, works fine with 2.6.18 kernel though. So far I'm seeing this: - On 2.6.21 I mount the drive. After a while it spins down, and when I then unmount it, an error pops up in dmesg. - On 2.6.18 I can't provoke the same error. The drive doesn't appear to spin down. I don't know if the data corruption from 2.6.21 occurs with regular use. There are a number of other factor I need to eliminate on my system, but that's it so far. CONFIG_USB_SUSPEND is not set on either kernel. OK, on a vanilla 2.6.18.8 I also have this problem, with both the pci/usb2 card, and the usb1 on the board. I listen to music from the drive, and after some time (10-20 minutes or so), it freaks out: = sd 1:0:0:0: Device not ready: <6>: Current: sense key=0x2 ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 126693711 sd 1:0:0:0: Device not ready: <6>: Current: sense key=0x2 ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 126693711 sd 1:0:0:0: Device not ready: <6>: Current: sense key=0x2 ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 126693711 = Using a new PSU and a powered hub made no difference. But I found a solution here: http://alienghic.livejournal.com/382903.html Basically, the problem is, as suspected, that the drive spins down / goes to suspend. This can be disabled with "sdparm --clear STANDBY -6 /dev/sda". It seems to me to be an error that the kernel reports this as something like a hardware failure. Or at least very misleading. Oh, nice. The usb-storage (SCSI) disk spins itself down and we can't handle that. Should we be disabling auto-spindown when we connect the device, or be able to handle this by sending the start command when needed? There's more to this. My Sandisk Cruzer Micro 1GB USB sticks suffer from this regression. Plug one in, it works for about 5 seconds, then the light goes off (bad). Next access requires a 30s timeout + reset. Etc.. This is with 2.6.23-rc6. Works without any problems in 2.6.22. REGRESSION. -ml - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] scsi: use notifier chain for Asynchronous Event Notification
Add a notifier chain for SCSI asynchronous events. Add a
notifier block for events which should be sent to user
space, and add support for the MEDIA_CHANGE event, which
would be used by a driver when new media has been inserted.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
---
This patch is against the latest -mm and is on top of what
has already been put in for AN support. It just moves the
event notification thread out of scsi_lib.c and into it's own
file, as well as adding notifier chain support.
Index: 2.6-mm/drivers/scsi/scsi.c
===
--- 2.6-mm.orig/drivers/scsi/scsi.c
+++ 2.6-mm/drivers/scsi/scsi.c
@@ -1045,6 +1045,8 @@ static int __init init_scsi(void)
if (error)
goto cleanup_sysctl;
+ scsi_aen_init();
+
scsi_netlink_init();
printk(KERN_NOTICE "SCSI subsystem initialized\n");
Index: 2.6-mm/drivers/scsi/scsi_aen.c
===
--- /dev/null
+++ 2.6-mm/drivers/scsi/scsi_aen.c
@@ -0,0 +1,168 @@
+/*
+ * SCSI Asynchronous Event Notification
+ *
+ * Copyright (c) 2007, Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Send Feedback to: Kristen Carlson Accardi <[EMAIL PROTECTED]>
+ */
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int scsi_aen_uevent_notifier(struct notifier_block *nb,
+ unsigned long action, void *sdev);
+
+BLOCKING_NOTIFIER_HEAD(scsi_aen_chain);
+
+static struct notifier_block scsi_aen_nb = {
+ .notifier_call = scsi_aen_uevent_notifier,
+};
+
+/* must match scsi_device_event enum in scsi_device.h */
+static char * scsi_device_event_strings[] = {
+ "MEDIA_CHANGE=1",
+};
+
+/**scsi_aen_notifier_register - register to receive aen events
+ * @nb: callers notifier_block
+ *
+ * Add a callers notifier_block to the AEN notify chain.
+ */
+int scsi_aen_notifier_register(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(&scsi_aen_chain, nb);
+}
+EXPORT_SYMBOL_GPL(scsi_aen_notifier_register);
+
+/**scsi_aen_notifier_register - register to receive aen events
+ * @nb: callers notifier_block
+ *
+ * remove a callers notifier_block from the AEN notify chain.
+ */
+int scsi_aen_notifier_unregister(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&scsi_aen_chain, nb);
+}
+EXPORT_SYMBOL_GPL(scsi_aen_notifier_unregister);
+
+/**
+ * scsi_device_set_event - Add a new Async event to the event list
+ * @sdev: scsi_device event occurred on
+ * @event: the scsi device event
+ *
+ * Add a new scsi_device_event_info struct to the scsi_device_event_list
+ * queue. This may be called from interrupt context.
+ *
+ * Returns 0 if successful, -ENOMEM otherwise.
+ */
+static int
+scsi_device_set_event(struct scsi_device *sdev, enum scsi_device_event event)
+{
+ struct scsi_device_event_info *scsi_event;
+ unsigned long flags;
+
+ scsi_event = kzalloc(sizeof(*scsi_event), GFP_ATOMIC);
+ if (!scsi_event)
+ return -ENOMEM;
+ INIT_LIST_HEAD(&scsi_event->link);
+ scsi_event->event = event;
+ spin_lock_irqsave(&sdev->list_lock, flags);
+ list_add_tail(&scsi_event->link, &sdev->sdev_event_list);
+ spin_unlock_irqrestore(&sdev->list_lock, flags);
+ return 0;
+}
+
+/**
+ * scsi_device_event_notify_thread - send a uevent for each scsi event
+ * @work: work struct for scsi_device
+ *
+ * Traverse the queue of scsi device events, dequeue each event and
+ * send a uevent. Frees event. May not be called from interrupt.
+ */
+static void scsi_event_notify_thread(struct work_struct *work)
+{
+ struct scsi_device *sdev;
+ struct list_head *tmp;
+ struct list_head *next;
+ struct scsi_device_event_info *sdev_event;
+ unsigned long flags;
+
+ sdev = container_of(work, struct scsi_device, ew.work);
+ list_for_each_safe(tmp, next, &sdev->sdev_event_list) {
+ sdev_event = list_entry(tmp, struct scsi_device_event_info,
+ link);
+ spin_lock_irqsave(&
Re: [patchset 0/24] Lots of the Accessors patches and !use_sg cleanup
On Tue, 11 Sep 2007, Boaz Harrosh wrote: > [esp family] - Maciej W. Rozycki <[EMAIL PROTECTED]> > 0020 drivers/scsi/NCR53C9x.c drivers/scsi/NCR53C9x.h > drivers/scsi/dec_esp.c drivers/scsi/oktagon_esp.c > drivers/scsi/sun3x_esp.c Not really, but I have suitable hardware and can test your changes to drivers/scsi/NCR53C9x.c, drivers/scsi/NCR53C9x.h and drivers/scsi/dec_esp.c only. Fortunately it does not really matter that much, because the the whole family of drivers has been deprecated and is going away at some pace in favour to the framework around the new drivers/scsi/esp_scsi.c core. Thanks for your effort though! Maciej - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH ver2 5/5] arm: fas216 Use scsi_eh API for REQUEST_SENSE invocation
Russell King wrote: On Mon, Sep 10, 2007 at 10:39:11PM +0300, Boaz Harrosh wrote: - Use new scsi_eh_prep/restor_cmnd() for synchronous REQUEST_SENSE invocation. Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]> --- drivers/scsi/arm/fas216.c | 16 +++- drivers/scsi/arm/fas216.h |3 +++ 2 files changed, 6 insertions(+), 13 deletions(-) diff --git a/drivers/scsi/arm/fas216.c b/drivers/scsi/arm/fas216.c index fb5f202..a715632 100644 --- a/drivers/scsi/arm/fas216.c +++ b/drivers/scsi/arm/fas216.c @@ -2018,6 +2018,7 @@ static void fas216_rq_sns_done(FAS216_Info *info, struct scsi_cmnd *SCpnt, * the upper layers to process. This would have been set * correctly by fas216_std_done. */ + scsi_eh_restore_cmnd(SCpnt, &info->ses); SCpnt->scsi_done(SCpnt); } @@ -2103,23 +2104,12 @@ request_sense: if (SCpnt->cmnd[0] == REQUEST_SENSE) goto done; + scsi_eh_prep_cmnd(SCpnt, &info->ses, NULL, 0, ~0); fas216_log_target(info, LOG_CONNECT, SCpnt->device->id, "requesting sense"); - memset(SCpnt->cmnd, 0, sizeof (SCpnt->cmnd)); - SCpnt->cmnd[0] = REQUEST_SENSE; - SCpnt->cmnd[1] = SCpnt->device->lun << 5; - SCpnt->cmnd[4] = sizeof(SCpnt->sense_buffer); - SCpnt->cmd_len = COMMAND_SIZE(SCpnt->cmnd[0]); - SCpnt->SCp.buffer = NULL; - SCpnt->SCp.buffers_residual = 0; - SCpnt->SCp.ptr = (char *)SCpnt->sense_buffer; - SCpnt->SCp.this_residual = sizeof(SCpnt->sense_buffer); - SCpnt->SCp.phase = sizeof(SCpnt->sense_buffer); + init_SCp(SCpnt); SCpnt->SCp.Message = 0; SCpnt->SCp.Status = 0; - SCpnt->request_bufflen = sizeof(SCpnt->sense_buffer); - SCpnt->sc_data_direction = DMA_FROM_DEVICE; - SCpnt->use_sg = 0; SCpnt->tag = 0; SCpnt->host_scribble = (void *)fas216_rq_sns_done; So where do we end up setting up the request sense command? In scsi_eh_prep_cmnd(), when (sense_bytes != 0), called here: + scsi_eh_prep_cmnd(SCpnt, &info->ses, NULL, 0, ~0); - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH ver2 5/5] arm: fas216 Use scsi_eh API for REQUEST_SENSE invocation
On Mon, Sep 10, 2007 at 10:39:11PM +0300, Boaz Harrosh wrote: > > - Use new scsi_eh_prep/restor_cmnd() for synchronous > REQUEST_SENSE invocation. > > Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]> > --- > drivers/scsi/arm/fas216.c | 16 +++- > drivers/scsi/arm/fas216.h |3 +++ > 2 files changed, 6 insertions(+), 13 deletions(-) > > diff --git a/drivers/scsi/arm/fas216.c b/drivers/scsi/arm/fas216.c > index fb5f202..a715632 100644 > --- a/drivers/scsi/arm/fas216.c > +++ b/drivers/scsi/arm/fas216.c > @@ -2018,6 +2018,7 @@ static void fas216_rq_sns_done(FAS216_Info *info, > struct scsi_cmnd *SCpnt, >* the upper layers to process. This would have been set >* correctly by fas216_std_done. >*/ > + scsi_eh_restore_cmnd(SCpnt, &info->ses); > SCpnt->scsi_done(SCpnt); > } > > @@ -2103,23 +2104,12 @@ request_sense: > if (SCpnt->cmnd[0] == REQUEST_SENSE) > goto done; > > + scsi_eh_prep_cmnd(SCpnt, &info->ses, NULL, 0, ~0); > fas216_log_target(info, LOG_CONNECT, SCpnt->device->id, > "requesting sense"); > - memset(SCpnt->cmnd, 0, sizeof (SCpnt->cmnd)); > - SCpnt->cmnd[0] = REQUEST_SENSE; > - SCpnt->cmnd[1] = SCpnt->device->lun << 5; > - SCpnt->cmnd[4] = sizeof(SCpnt->sense_buffer); > - SCpnt->cmd_len = COMMAND_SIZE(SCpnt->cmnd[0]); > - SCpnt->SCp.buffer = NULL; > - SCpnt->SCp.buffers_residual = 0; > - SCpnt->SCp.ptr = (char *)SCpnt->sense_buffer; > - SCpnt->SCp.this_residual = sizeof(SCpnt->sense_buffer); > - SCpnt->SCp.phase = sizeof(SCpnt->sense_buffer); > + init_SCp(SCpnt); > SCpnt->SCp.Message = 0; > SCpnt->SCp.Status = 0; > - SCpnt->request_bufflen = sizeof(SCpnt->sense_buffer); > - SCpnt->sc_data_direction = DMA_FROM_DEVICE; > - SCpnt->use_sg = 0; > SCpnt->tag = 0; > SCpnt->host_scribble = (void *)fas216_rq_sns_done; So where do we end up setting up the request sense command? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/24] arm: scsi convert to accessors and !use_sg cleanup
On Wed, Sep 12, 2007 at 02:55:19AM +0300, Boaz Harrosh wrote:
> - if (SCpnt->request_bufflen != len)
> + if (scsi_bufflen(SCpnt) != len) {
> + WARN_ON(1);
NAK. The call trace generally doesn't provide any additional information
on the cause of the error.
> printk(KERN_WARNING "scsi%d.%c: bad request buffer "
> "length %d, should be %ld\n",
> SCpnt->device->host->host_no,
> -'0' + SCpnt->device->id, SCpnt->request_bufflen,
> len);
> - SCpnt->request_bufflen = len;
> +'0' + SCpnt->device->id, scsi_bufflen(SCpnt),
> len);
> + }
> #endif
> } else {
> - SCpnt->SCp.ptr = (unsigned char *)SCpnt->request_buffer;
> - SCpnt->SCp.this_residual = SCpnt->request_bufflen;
> - SCpnt->SCp.phase = SCpnt->request_bufflen;
> - }
> -
> - /*
> - * If the upper SCSI layers pass a buffer, but zero length,
> - * we aren't interested in the buffer pointer.
> - */
> - if (SCpnt->SCp.this_residual == 0 && SCpnt->SCp.ptr) {
> -#if 0 //def BELT_AND_BRACES
> - printk(KERN_WARNING "scsi%d.%c: zero length buffer passed for "
> -"command ", SCpnt->host->host_no, '0' + SCpnt->target);
> - __scsi_print_command(SCpnt->cmnd);
> -#endif
> SCpnt->SCp.ptr = NULL;
> + SCpnt->SCp.this_residual = 0;
> + SCpnt->SCp.phase = 0;
> }
> }
Also NAK. This was added due to bad behaviour of the SCSI layer and
was found to be necessary.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
