Re: [PATCH 09/24] libata-scsi: convert to use the data buffer accessors
On 9/12/07, Matthew Dharm [EMAIL PROTECTED] wrote: On Tue, Sep 11, 2007 at 08:09:51PM -0400, Jeff Garzik wrote: I would much rather see the !use_sg cleanup in a separate patch series... Are we really sure this can all go? No requests, not even ones from SG_IO will ever use the non-sg paths? Matt The last place that did !use_sg was fixed Yesterday. It was the REQUEST_SENSE in usb's transport.c The before the last one was removed by Christoph in 2.6.18 Boaz - 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
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 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: [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
[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 linux/notifier.h
+
+#include scsi/scsi.h
+#include scsi/scsi_cmnd.h
+#include scsi/scsi_dbg.h
+#include scsi/scsi_device.h
+#include scsi/scsi_driver.h
+#include scsi/scsi_eh.h
+#include scsi/scsi_host.h
+
+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
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
