[EMAIL PROTECTED] wrote:
- There are some real challenges in supporting a udev-named boot
device. For the most part, it's a distro issue, which is becoming
better. PS: for $10, name a 2.6 distro that uses udev out
of the box for disk names and its installation. For $10 more,
can it
Hans-Joachim Baader [EMAIL PROTECTED] wrote:
Hi,
I do nightly backups on tape. Every 3 to 4 weeks a process is stuck in
D state while accessing the drive:
12398 ?D 0:00 /usr/sbin/amcheck -ms daily
There are no messages in the log. Only a reboot can remove
On Mon, Aug 22 2005, Douglas Gilbert wrote:
if (scsicmd[0] == READ_6 || scsicmd[0] == WRITE_6) {
- qc-nsect = tf-nsect = scsicmd[4];
+ if (scsicmd[4] == 0) {
+ /*
+ * For READ_6 and WRITE_6 (only)
+ *
Luben Tuikov wrote:
On 08/22/05 00:55, Matt Domsch wrote:
On Sat, Aug 20, 2005 at 12:15:41AM -0400, [EMAIL PROTECTED] wrote:
- There are some real challenges in supporting a udev-named boot
device. For the most part, it's a distro issue, which is becoming
better. PS: for $10, name a 2.6
Jeff Garzik wrote:
Douglas Gilbert wrote:
This is a revised patch following this post:
http://marc.theaimsgroup.com/?l=linux-scsim=112461881419898w=2
The plan is to add MODE SELECT SCSI command support to
libata so that parameters such as WCE and DRA can be
changed by a user (i.e.
Jens Axboe wrote:
On Mon, Aug 22 2005, Douglas Gilbert wrote:
if (scsicmd[0] == READ_6 || scsicmd[0] == WRITE_6) {
- qc-nsect = tf-nsect = scsicmd[4];
+ if (scsicmd[4] == 0) {
+ /*
+ * For READ_6 and WRITE_6 (only)
+
On Tue, Aug 23 2005, Douglas Gilbert wrote:
Jens Axboe wrote:
On Mon, Aug 22 2005, Douglas Gilbert wrote:
if (scsicmd[0] == READ_6 || scsicmd[0] == WRITE_6) {
- qc-nsect = tf-nsect = scsicmd[4];
+ if (scsicmd[4] == 0) {
+ /*
+
I know that scsi procfs is legacy code but this is a fix for a memory leak.
While reading through sg.c I realized that the implementation of
/proc/scsi/sg/devices with seq_file is leaking memory due to freeing the
pointer returned by the next() iterator method. Since next() might
return NULL or
On Sat, Aug 20, 2005 at 12:15:41AM -0400, [EMAIL PROTECTED] wrote:
- the target id is logical for everything but SPI
For FC, target ids are typically assigned to devices on a
1st-seen-1st-assigned basis. For several reasons, there can be
changes in port discovery order after link events
As others stated, id is already a tag/label. You should be
able to pass
whatever id you want to scsi_scan_target, like the FC ID
(port_id), and
then we also want an abstract iterator in fc transport for the id for
usage in scsi_scan.c:scsi_scan_channel. Then you can lose all the
[EMAIL PROTECTED] wrote:
As others stated, id is already a tag/label. You should be
able to pass
whatever id you want to scsi_scan_target, like the FC ID
(port_id),
[...]
If the port id changes during run time, what are you to do ?
[...]
This approach only works as long as the transport's
On Tue, Aug 23, 2005 at 09:40:40AM -0700, Mark Haverkamp wrote:
I'm not sure if people care about /proc/scsi, but here is a patch so you
can cat /proc/scsi/scsi when you have a large number of scsi devices. I
have over 4000 devices configured and when I would cat /proc/scsi/scsi I
would see
On Tue, Aug 23, 2005 at 06:42:06PM +0100, Christoph Hellwig wrote:
We had this before, and the answer is: don't use /proc/scsi if you have
lots of device. Don't even enable the config option.
We still don't have sysfs scsi devinfo support, we need to represent it as
a modifiable list or such
I thought by the target id is logical for everything but
SPI you meant
that FC enumerated the scsi_device id.
Yes, I meant that.
I didn't mean to address problems with persistent names, just map the
scsi_device id to an FC value.
True. Port ID is just a bad example. Unfortunately, there's
I apologize if this is the wrong list to ask this kind of question on;
I've posted on Dell's PowerEdge list and Red Hat's lists as well, but I
figure the people here might know better what to try for this problem.
I have 2 Dell PowerEdge 2850's, one with a PERC 4e/DC raid controller,
and the
On 08/22/05 01:12, Douglas Gilbert wrote:
I was surprised how much code needed changing.
With MODE SELECT's issues with libata addressed
various other SAT extras should be much easier
to implement. That should make libata more attractive
as a SAT layer for SAS LLDDs (that don't do it already
On 08/23/05 13:28, Stefan Richter wrote:
[EMAIL PROTECTED] wrote:
As others stated, id is already a tag/label. You should be
able to pass
whatever id you want to scsi_scan_target, like the FC ID
(port_id),
[...]
If the port id changes during run time, what are you to do ?
[...]
This
On 08/23/05 11:42, Patrick Mansfield wrote:
On Sat, Aug 20, 2005 at 12:15:41AM -0400, [EMAIL PROTECTED] wrote:
- the target id is logical for everything but SPI
For FC, target ids are typically assigned to devices on a
1st-seen-1st-assigned basis. For several reasons, there can be
changes
The problem is that klists claim to provide semantics for safe traversal
of lists which are being modified. The failure case is when traversal
of a list causes element removal (a fairly common case). The issue is
that although the list node is refcounted, if it is embedded in an
object (which is
On Mon, 2005-08-22 at 15:09 -0700, Andrew Morton wrote:
James Bottomley [EMAIL PROTECTED] wrote:
Of course, if we're going to go to all this trouble, the next question
that arises naturally is why not just reuse the radix-tree code to
implement idr anyway ... ?
Yes, we could probably
On 8/23/05, Jim Ramsay [EMAIL PROTECTED] wrote:
Then I must have found an undocumented feature! I've applied this set
of patches to a 2.6.11 kernel (with few problems) and ran into a bunch
of scheduling while atomic errors when hotplugging a drive, culprit
being probably scsi_sysfs.c where
On 8/1/05, Lukasz Kosewski [EMAIL PROTECTED] wrote:
Patch 03: Have sata_promise use the perfect, flawless API from the
previous patch
Hmmm... Flawless :)
Then I must have found an undocumented feature! I've applied this set
of patches to a 2.6.11 kernel (with few problems) and ran into a
22 matches
Mail list logo
