Re: [linux-usb-devel] 2.6.11-rc3-bk5, oops in scsi_try_bus_reset
On Wed, 2 Mar 2005, Olaf Hering wrote: > When a device is plugged in, rmmod sd_mod fails, does that work for you? > sda is already unregistered, but rmmod is stuck like that: > > rmmod D 000F4240 0 11501 4 (NOTLB) > d7a03f1c 0086 db8b95a0 000f4240 0001e848 a4c98fc0 000f4236 >c03b58c8 df666560 dfb4 e0dbc36c df666560 0246 e0dbc374 c02cfcbe >0001 df666560 c01171a0 e0dbc374 e0dbc374 c0165981 e0dbc37c e0dfdd40 > Call Trace: > [] __down+0x6e/0xd0 > [] default_wake_function+0x0/0x10 > [] dput+0x21/0x180 > [] __down_failed+0x7/0xc > [] kobject_release+0x0/0x10 > [] .text.lock.driver+0x8/0x18 > [] exit_sd+0x1d/0x46 [sd_mod] > [] sys_delete_module+0x154/0x170 > [] vfs_write+0xa7/0x110 > [] sys_write+0x3c/0x70 > [] sysenter_past_esp+0x52/0x79 This is a known bug in the way the SCSI midlayer interacts with the driver model core. It's not related to usb-storage or the patch you've been trying out. You can unblock the rmmod process by unplugging the device. Alan Stern - 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: Whitelist-Entry (FORCELUN) for SGS Thomson Microelectronics Cytronix 6in1 card reader in scsi_devinfo.c
I have an usb-cardreader here that needs some FORCELUN-entries in
scsi_devinfo.c.
lsusb says about the device:
Bus 001 Device 003: ID 0483:1307 SGS Thomson Microelectronics Cytronix 6in1
card reader
Patch see below. Please apply.
--- linux-2.6.11-buju/drivers/scsi/scsi_devinfo.c 2005-03-02
08:37:54.0 +0100
+++ linux-2.6.11/drivers/scsi/scsi_devinfo.c2005-03-02 23:42:56.961751736
+0100
@@ -148,6 +148,10 @@
{"Generic", "USB SD Reader", "1.00", BLIST_FORCELUN | BLIST_INQUIRY_36},
{"Generic", "USB Storage-SMC", "0180", BLIST_FORCELUN |
BLIST_INQUIRY_36},
{"Generic", "USB Storage-SMC", "0207", BLIST_FORCELUN |
BLIST_INQUIRY_36},
+ {"Generic", "USB Reader-SMC", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
+ {"Generic", "USB Reader-CF", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
+ {"Generic", "USB Reader-SD", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
+ {"Generic", "USB Reader-MS", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
{"HITACHI", "DF400", "*", BLIST_SPARSELUN},
{"HITACHI", "DF500", "*", BLIST_SPARSELUN},
{"HITACHI", "DF600", "*", BLIST_SPARSELUN},
-
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] 2/2 Use bus dev_attrs to create scsi_device attributes
Use bus dev_attrs to create the default scsi_device attributes.
Note sdev_default_attrs is not a pointer to an array (like
scsi_sysfs_sdev_attrs), and so DEVICE_ATTR's can be removed, and __ATTR
used instaed.
Signed-off-by: Patrick Mansfield <[EMAIL PROTECTED]>
--- sattrs-linux-2.6.11/drivers/scsi/s1-scsi_sysfs.c2005-03-02
09:58:21.0 -0800
+++ sattrs-linux-2.6.11/drivers/scsi/scsi_sysfs.c 2005-03-02
10:22:25.0 -0800
@@ -193,40 +193,6 @@
.release= scsi_device_cls_release,
};
-/* all probing is done in the individual ->probe routines */
-static int scsi_bus_match(struct device *dev, struct device_driver *gendrv)
-{
- struct scsi_device *sdp = to_scsi_device(dev);
- if (sdp->no_uld_attach)
- return 0;
- return (sdp->inq_periph_qual == SCSI_INQ_PQ_CON)? 1: 0;
-}
-
-struct bus_type scsi_bus_type = {
-.name = "scsi",
-.match = scsi_bus_match,
-};
-
-int scsi_sysfs_register(void)
-{
- int error;
-
- error = bus_register(&scsi_bus_type);
- if (!error) {
- error = class_register(&sdev_class);
- if (error)
- bus_unregister(&scsi_bus_type);
- }
-
- return error;
-}
-
-void scsi_sysfs_unregister(void)
-{
- class_unregister(&sdev_class);
- bus_unregister(&scsi_bus_type);
-}
-
/*
* sdev_show_function: macro to create an attr function that can be used to
* show a non-bit field.
@@ -245,8 +211,7 @@
* read only field.
*/
#define sdev_rd_attr(field, format_string) \
- sdev_show_function(field, format_string)\
-static DEVICE_ATTR(field, S_IRUGO, sdev_show_##field, NULL);
+ sdev_show_function(field, format_string)
/*
@@ -263,8 +228,7 @@
sdev = to_scsi_device(dev); \
snscanf (buf, 20, format_string, &sdev->field); \
return count; \
-} \
-static DEVICE_ATTR(field, S_IRUGO | S_IWUSR, sdev_show_##field,
sdev_store_##field);
+}
/* Currently we don't export bit fields, but we might in future,
* so leave this code in */
@@ -288,8 +252,7 @@
ret = count;\
} \
return ret; \
-} \
-static DEVICE_ATTR(field, S_IRUGO | S_IWUSR, sdev_show_##field,
sdev_store_##field);
+}
/*
* scsi_sdev_check_buf_bit: return 0 if buf is "0", return 1 if buf is "1",
@@ -336,15 +299,13 @@
sdev->timeout = timeout * HZ;
return count;
}
-static DEVICE_ATTR(timeout, S_IRUGO | S_IWUSR, sdev_show_timeout,
sdev_store_timeout);
static ssize_t
-store_rescan_field (struct device *dev, const char *buf, size_t count)
+sdev_store_rescan (struct device *dev, const char *buf, size_t count)
{
scsi_rescan_device(dev);
return count;
}
-static DEVICE_ATTR(rescan, S_IWUSR, NULL, store_rescan_field);
static ssize_t sdev_store_delete(struct device *dev, const char *buf,
size_t count)
@@ -352,10 +313,9 @@
scsi_remove_device(to_scsi_device(dev));
return count;
};
-static DEVICE_ATTR(delete, S_IWUSR, NULL, sdev_store_delete);
static ssize_t
-store_state_field(struct device *dev, const char *buf, size_t count)
+sdev_store_state(struct device *dev, const char *buf, size_t count)
{
int i;
struct scsi_device *sdev = to_scsi_device(dev);
@@ -378,7 +338,7 @@
}
static ssize_t
-show_state_field(struct device *dev, char *buf)
+sdev_show_state(struct device *dev, char *buf)
{
struct scsi_device *sdev = to_scsi_device(dev);
const char *name = scsi_device_state_name(sdev->sdev_state);
@@ -389,8 +349,6 @@
return snprintf(buf, 20, "%s\n", name);
}
-static DEVICE_ATTR(state, S_IRUGO | S_IWUSR, show_state_field,
store_state_field);
-
sdev_show_function (queue_depth, "%d\n");
static ssize_t sdev_store_queue_depth(struct device *dev, const char *buf,
@@ -420,7 +378,7 @@
sdev_store_queue_depth);
static ssize_t
-show_queue_type_field(struct device *dev, char *buf)
+sdev_show_queue_type(struct device *dev, char *buf)
{
struct scsi_device *sdev = to_scsi_device(dev);
const char *name = "none";
@@ -461,25 +419,29 @@
return count;
}
-static struct device_attribute dev_attr_queue_type =
- __ATTR(queue_type, S_IRUGO | S_IWUSR, show_queue_type_field,
- sdev_store_queue_type);
+#define SDEV_ATTR_RO(_name) __ATTR(_name, S_IRUGO, sdev_show_##_name, NULL)
+#define SDEV_ATTR_WO(_name) __ATTR(_name, S_IWUSR, NULL, sdev_store_##_name)
+#define SDEV_ATTR_RW(_name) __ATT
[PATCH] 1/2 remove attr_changed_internally
Get rid of the attr_changed_internally(), and always create queue_type and
queue_depth as read/write, and then writes fail if not supported.
Signed-off-by: Patrick Mansfield <[EMAIL PROTECTED]>
--- linux-2.6.11/drivers/scsi/scsi_sysfs.c 2005-03-02 02:59:50.0
-0800
+++ sattrs-linux-2.6.11/drivers/scsi/scsi_sysfs.c 2005-03-02
09:27:15.0 -0800
@@ -312,7 +312,6 @@
* Create the actual show/store functions and data structures.
*/
sdev_rd_attr (device_blocked, "%d\n");
-sdev_rd_attr (queue_depth, "%d\n");
sdev_rd_attr (type, "%d\n");
sdev_rd_attr (scsi_level, "%d\n");
sdev_rd_attr (vendor, "%.8s\n");
@@ -392,41 +391,9 @@
static DEVICE_ATTR(state, S_IRUGO | S_IWUSR, show_state_field,
store_state_field);
-static ssize_t
-show_queue_type_field(struct device *dev, char *buf)
-{
- struct scsi_device *sdev = to_scsi_device(dev);
- const char *name = "none";
-
- if (sdev->ordered_tags)
- name = "ordered";
- else if (sdev->simple_tags)
- name = "simple";
-
- return snprintf(buf, 20, "%s\n", name);
-}
-
-static DEVICE_ATTR(queue_type, S_IRUGO, show_queue_type_field, NULL);
-
-
-/* Default template for device attributes. May NOT be modified */
-static struct device_attribute *scsi_sysfs_sdev_attrs[] = {
- &dev_attr_device_blocked,
- &dev_attr_queue_depth,
- &dev_attr_queue_type,
- &dev_attr_type,
- &dev_attr_scsi_level,
- &dev_attr_vendor,
- &dev_attr_model,
- &dev_attr_rev,
- &dev_attr_rescan,
- &dev_attr_delete,
- &dev_attr_state,
- &dev_attr_timeout,
- NULL
-};
+sdev_show_function (queue_depth, "%d\n");
-static ssize_t sdev_store_queue_depth_rw(struct device *dev, const char *buf,
+static ssize_t sdev_store_queue_depth(struct device *dev, const char *buf,
size_t count)
{
int depth, retval;
@@ -448,11 +415,25 @@
return count;
}
-static struct device_attribute sdev_attr_queue_depth_rw =
+static struct device_attribute dev_attr_queue_depth =
__ATTR(queue_depth, S_IRUGO | S_IWUSR, sdev_show_queue_depth,
- sdev_store_queue_depth_rw);
+ sdev_store_queue_depth);
-static ssize_t sdev_store_queue_type_rw(struct device *dev, const char *buf,
+static ssize_t
+show_queue_type_field(struct device *dev, char *buf)
+{
+ struct scsi_device *sdev = to_scsi_device(dev);
+ const char *name = "none";
+
+ if (sdev->ordered_tags)
+ name = "ordered";
+ else if (sdev->simple_tags)
+ name = "simple";
+
+ return snprintf(buf, 20, "%s\n", name);
+}
+
+static ssize_t sdev_store_queue_type(struct device *dev, const char *buf,
size_t count)
{
struct scsi_device *sdev = to_scsi_device(dev);
@@ -480,23 +461,26 @@
return count;
}
-static struct device_attribute sdev_attr_queue_type_rw =
+static struct device_attribute dev_attr_queue_type =
__ATTR(queue_type, S_IRUGO | S_IWUSR, show_queue_type_field,
- sdev_store_queue_type_rw);
-
-static struct device_attribute *attr_changed_internally(
- struct Scsi_Host *shost,
- struct device_attribute * attr)
-{
- if (!strcmp("queue_depth", attr->attr.name)
- && shost->hostt->change_queue_depth)
- return &sdev_attr_queue_depth_rw;
- else if (!strcmp("queue_type", attr->attr.name)
- && shost->hostt->change_queue_type)
- return &sdev_attr_queue_type_rw;
- return attr;
-}
+ sdev_store_queue_type);
+/* Default template for device attributes. May NOT be modified */
+static struct device_attribute *scsi_sysfs_sdev_attrs[] = {
+ &dev_attr_device_blocked,
+ &dev_attr_queue_depth,
+ &dev_attr_queue_type,
+ &dev_attr_type,
+ &dev_attr_scsi_level,
+ &dev_attr_vendor,
+ &dev_attr_model,
+ &dev_attr_rev,
+ &dev_attr_rescan,
+ &dev_attr_delete,
+ &dev_attr_state,
+ &dev_attr_timeout,
+ NULL
+};
static struct device_attribute *attr_overridden(
struct device_attribute **attrs,
@@ -602,10 +586,8 @@
for (i = 0; scsi_sysfs_sdev_attrs[i]; i++) {
if (!attr_overridden(sdev->host->hostt->sdev_attrs,
scsi_sysfs_sdev_attrs[i])) {
- struct device_attribute * attr =
- attr_changed_internally(sdev->host,
-
scsi_sysfs_sdev_attrs[i]);
- error = device_create_file(&sdev->sdev_gendev, attr);
+ error = device_create_file(&sdev->sdev_gendev,
+ scsi_sysfs_sdev_attrs[i]);
if (error) {
scsi_remove_device(sdev);
[PATCH] 0/2 use sysfs bus dev_attrs for scsi_device attributes
A couple patches so that when pending changes to sysfs/hotplug are made, patches discussed here: http://marc.theaimsgroup.com/?t=11093974272&r=1&w=2 We will get the hotplug event for a scsi_device only after all the default scsi_device attributes are created. The removal of the attr_changed_internally() was done so queue_type can more easily be used as a default attribute (using the bus dev_attrs, there is no way for some devices to create it read only, and for others to create it as read write). Tested with qla2300 and qla1280 drivers - neither currently support writable queue_depth or queue_type. The attr_overridden (and post these patches, scsi_sysfs_sdev_attrs) should someday be removed, the only attribute being overridden (versus a host specific scsi_device attribute) today is queue_depth, and we have shost->change_queue_depth that can be used instead. -- Patrick Mansfield - 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: [ANNOUNCE] iSCSI enterprise target software
On Wed, 2005-03-02 at 13:20, Bryan Henderson wrote: > >u are talking about application aware caching/prefetching stuff. but i > >prefer to modifying kernel page cache a little bit while make use of > >most of the code there. > > That's a powerful argument for using the page cache, and further, for > using it from within the kernel. I once started a project to port a > particular filesystem driver from the kernel to user space. It was to be > used in a Linux system whose sole purpose was to export one filesystem via > NFS. I was looking for engineering ease. Everything about porting the > driver to user space was almost trivial except for duplicating the page > cache, and that was enough work to call into question the whole strategy > (I never went far enough to actually make a decision). > i tried several time before on implementing own cache structures in user space/ kernel space. every time i think i can do it better than before. but frankly, there are always corner cases that make it performs poor. > But I'm sure there are cases where the tradeoff works. yes. i am sure about this as well. > > -- > Bryan Henderson San Jose California > IBM Almaden Research Center Filesystems - 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: [ANNOUNCE] iSCSI enterprise target software
>Bryan Henderson wrote: >>>You want to *use* the kernel pagecache as much as you can. >> >> >> No, I really don't. Not always. I can think of only 2 reasons to >> maximize my use of the kernel pagecache: 1) saves me duplicating code; 2) >> allows me to share resources (memory and disk bandwidth come to mind) with >> others in the same Linux system fairly. There are many cases where those >> two benefits are outweighed by the benefits of using some other cache. If >> you're thinking of other benefits of using the pagecache, let's hear them. > >You forgot the third reason (benefit), though it doesn't directly >related to the page cache: read ahead. It greatly influences on the >performance and a direct I/O application has to reimplement this logic, >which generally isn't straightforward task. Actually, that's the first reason I gave. The readahead that the page cache does can be duplicated, and sometimes far exceeded, by a special purpose user space cache. As you say, it isn't straightforward, so saving that duplication is a good reason to use the page cache. Using the page cache is clearly better than using no cache at all (we're including readahead and writebehind buffers in the term "cache") in nearly all cases. - 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: [ANNOUNCE] iSCSI enterprise target software
>except that in iscsi a big chunk of the access patterns are *external*; >eg the real smarts are on that other machine on the network, not in the >iscsi server. We strayed a little from the topic; I don't claim that a private user-space cache is better than the page cache for an ISCSI server. My only point is that some of the reasons given for the kernel being a better place for ISCSI server code than user space are reasons only if you use assume using the page cache in both cases. Of course, one can always argue first that the page cache is better for an ISCSI server than any other kind of cache, and therefore that the kernel is a better place than user space for the server code. We just hadn't gone there yet. -- Bryan Henderson San Jose California IBM Almaden Research Center Filesystems - 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: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Wednesday, March 02, 2005 6:42 AM, Gerhard wrote: > It's a megaraid issue (not a tape issue..) We are looking at this issue and will post here for details. What version of megaraid driver and which megaraid controller are you using? Thanks, Seokmann LSI Logic Corporation. - 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: [ANNOUNCE] iSCSI enterprise target software
>u are talking about application aware caching/prefetching stuff. but i >prefer to modifying kernel page cache a little bit while make use of >most of the code there. That's a powerful argument for using the page cache, and further, for using it from within the kernel. I once started a project to port a particular filesystem driver from the kernel to user space. It was to be used in a Linux system whose sole purpose was to export one filesystem via NFS. I was looking for engineering ease. Everything about porting the driver to user space was almost trivial except for duplicating the page cache, and that was enough work to call into question the whole strategy (I never went far enough to actually make a decision). But I'm sure there are cases where the tradeoff works. -- Bryan Henderson San Jose California IBM Almaden Research Center Filesystems - 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: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Wed, 2005-03-02 at 10:49 -0500, Guy wrote: > You did: > dd if=/dev/zero of=/dev/nst0 bs=1M and different mt setblk > > Since tape drives can compress data, /dev/zero is a bad source of data, > since it compresses real good. /dev/urandom is a better source. > > You would like IBM's LTO-2 tape drive. It does 35M/s! They claim the LTO-3 > does 70M/s! > > Guy > I did want the tape to do NOTHING. It's a test of the SCSI transfer speed, handshake etc. When compression is on the tape has to write file marks and very little information. So you get the real transfer performance. Not the performance of the tape. GS -- Gerhard Schneider Institute of Lightweight Design and e-Mail:[EMAIL PROTECTED] Structural Biomechanics (E317) Tel.: +43 1 58801 31716 Vienna University of Technology / AustriaFax:+43 1 58801 31799 A-1040 Wien, Gusshausstrasse 27-29http://www.ilsb.tuwien.ac.at/~gs/ signature.asc Description: This is a digitally signed message part
RE: One question about SCSI device hotplug
> Thank you, Matt. Then I have another question: > As we know SCSI mid-layer issue a command to LLDD by > host->hostt->queuecommand(cmd, scsi_done); and in the meantime a > timer is set. When the timer expires, SCSI mid-layer know the > execution of command has failed. > My question is: when SCSI device is surprise-removed, if SCSI > mid-layer > issue a command to this removed device, will mid-layer has to wait > a timeout before it can know the execution of command failed? Or is > there > any other mechanism that LLDD can notify mid-layer that execution of > command failed without waiting for a timeout? What we did in the FC transport - there's a transport level timeout at the target level that controls how long we "insulate" the system from the device's disappearance. When the device is first removed, the transport has the midlayer suspend i/o (e.g block) the device, so no i/o failures, other than timeouts on in-flight i/o's occur. As the midlayer (for disk devices) typically retries i/o's, even the in-flight errors don't result in an error to the application, as the retry get's delayed due the blocked state of the device. If the device returns within the insulation period, i/o resumes, and the system continues happily along it's way. If the device does not return, the timeout fires, and the device is restarted. The i/o then reaches the LLDD, who is expected to fail the i/o immediately as the target doesn't exist. The midlayer reacts accordingly and places the device into an offline state. If the device is readded, the LLDD sets the target to a good state, but the midlayer keeps the devices in an offline state until steps are taken to bring them back online. E.g. The admin takes whatever steps are necessary to clean up the system for the previous failure of the device, then brings the device online by writing the device state to running and rescanning the device. If multipath solutions are in place, they will want to set the "insulation" timeout as low as possible so that access so that it's alternate pathing can kick in as soon as possible. The multipathing solution, upon device re-addition, is required to take the steps to bring the device back online. -- james s - 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: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
You did: dd if=/dev/zero of=/dev/nst0 bs=1M and different mt setblk Since tape drives can compress data, /dev/zero is a bad source of data, since it compresses real good. /dev/urandom is a better source. You would like IBM's LTO-2 tape drive. It does 35M/s! They claim the LTO-3 does 70M/s! Guy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gerhard Schneider Sent: Wednesday, March 02, 2005 5:30 AM To: Kai Makisara Cc: scsi Subject: Re: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid On Sun, 2005-02-27 at 22:46 +0200, Kai Makisara wrote: > > This shows that your application is not using very large block size (3 > pages, 10 kB?). You might get better throughput with larger block size (32 > kB or 64 kB is usually large enough). If the Megaraid command processing > speed is not fast enough, this might explain the problem (not probable but > I can't see any probable problems ;-) > After different tries (I had problems w/ my backup schedule - ever tried to back up 600 GB with 2.6MB/s? :-) Tape block sizes between 10k and a few MB don't make any difference For better understanding I did the tests with dd if=/dev/zero of=/dev/nst0 bs=1M and different mt setblk No chance to go above 2.6 MB/s Gerhard Schneider -- Gerhard Schneider Institute of Lightweight Design and e-Mail:[EMAIL PROTECTED] Structural Biomechanics (E317) Tel.: +43 1 58801 31716 Vienna University of Technology / AustriaFax:+43 1 58801 31799 A-1040 Wien, Gusshausstrasse 27-29http://www.ilsb.tuwien.ac.at/~gs/ - 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: [linux-usb-devel] 2.6.11-rc3-bk5, oops in scsi_try_bus_reset
On Thu, Feb 17, Alan Stern wrote: > On Thu, 17 Feb 2005, Olaf Hering wrote: > > > On Mon, Feb 14, Alan Stern wrote: > > > > > https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-November/001201.html > > > > Alan, > > > > this patch seems to fix the crashes. Is it ready for production use, or > > should I wait for a differnt patch? > > It hasn't been tested very much. (Would you like to be a beta tester? :-) > Right now I'm in the middle of cleaning it up and submitting it to Matt > Dharm for official inclusion. When a device is plugged in, rmmod sd_mod fails, does that work for you? sda is already unregistered, but rmmod is stuck like that: rmmod D 000F4240 0 11501 4 (NOTLB) d7a03f1c 0086 db8b95a0 000f4240 0001e848 a4c98fc0 000f4236 c03b58c8 df666560 dfb4 e0dbc36c df666560 0246 e0dbc374 c02cfcbe 0001 df666560 c01171a0 e0dbc374 e0dbc374 c0165981 e0dbc37c e0dfdd40 Call Trace: [] __down+0x6e/0xd0 [] default_wake_function+0x0/0x10 [] dput+0x21/0x180 [] __down_failed+0x7/0xc [] kobject_release+0x0/0x10 [] .text.lock.driver+0x8/0x18 [] exit_sd+0x1d/0x46 [sd_mod] [] sys_delete_module+0x154/0x170 [] vfs_write+0xa7/0x110 [] sys_write+0x3c/0x70 [] sysenter_past_esp+0x52/0x79 - 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: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Wed, 2005-03-02 at 11:30 +0100, Gerhard Schneider wrote: > On Sun, 2005-02-27 at 22:46 +0200, Kai Makisara wrote: > > > > > This shows that your application is not using very large block size (3 > > pages, 10 kB?). You might get better throughput with larger block size (32 > > kB or 64 kB is usually large enough). If the Megaraid command processing > > speed is not fast enough, this might explain the problem (not probable but > > I can't see any probable problems ;-) > > > > After different tries (I had problems w/ my backup schedule - ever tried > to back up 600 GB with 2.6MB/s? :-) > > Tape block sizes between 10k and a few MB don't make any difference > > For better understanding I did the tests with > > dd if=/dev/zero of=/dev/nst0 bs=1M and different mt setblk > > No chance to go above 2.6 MB/s > Moved the tape drive to another machine w/Fusion chipset, but w/o Megaraid controller. Absolutely the same software. dd if=/dev/zero of=/dev/nst0 bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 24.597061 seconds (42630134 bytes/sec) That's the transfer rate the tape drive is able when receiving bullshit (/dev/zero). It's a megaraid issue (not a tape issue..) GS changing all backup scripts to the new machine -- Gerhard Schneider Institute of Lightweight Design and e-Mail:[EMAIL PROTECTED] Structural Biomechanics (E317) Tel.: +43 1 58801 31716 Vienna University of Technology / AustriaFax:+43 1 58801 31799 A-1040 Wien, Gusshausstrasse 27-29http://www.ilsb.tuwien.ac.at/~gs/ signature.asc Description: This is a digitally signed message part
Re: [ANNOUNCE] iSCSI enterprise target software
Bryan Henderson wrote: You want to *use* the kernel pagecache as much as you can. No, I really don't. Not always. I can think of only 2 reasons to maximize my use of the kernel pagecache: 1) saves me duplicating code; 2) allows me to share resources (memory and disk bandwidth come to mind) with others in the same Linux system fairly. There are many cases where those two benefits are outweighed by the benefits of using some other cache. If you're thinking of other benefits of using the pagecache, let's hear them. You forgot the third reason (benefit), though it doesn't directly related to the page cache: read ahead. It greatly influences on the performance and a direct I/O application has to reimplement this logic, which generally isn't straightforward task. Vlad - 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: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Sun, 2005-02-27 at 22:46 +0200, Kai Makisara wrote: > > This shows that your application is not using very large block size (3 > pages, 10 kB?). You might get better throughput with larger block size (32 > kB or 64 kB is usually large enough). If the Megaraid command processing > speed is not fast enough, this might explain the problem (not probable but > I can't see any probable problems ;-) > After different tries (I had problems w/ my backup schedule - ever tried to back up 600 GB with 2.6MB/s? :-) Tape block sizes between 10k and a few MB don't make any difference For better understanding I did the tests with dd if=/dev/zero of=/dev/nst0 bs=1M and different mt setblk No chance to go above 2.6 MB/s Gerhard Schneider -- Gerhard Schneider Institute of Lightweight Design and e-Mail:[EMAIL PROTECTED] Structural Biomechanics (E317) Tel.: +43 1 58801 31716 Vienna University of Technology / AustriaFax:+43 1 58801 31799 A-1040 Wien, Gusshausstrasse 27-29http://www.ilsb.tuwien.ac.at/~gs/ signature.asc Description: This is a digitally signed message part
