headers
Grant Grundler | 1 Aug 2008 01:44
Picon
Favicon

Re: [DO NOT APPLY] sd take advantage of rotation speed

On Thu, Jul 31, 2008 at 3:26 PM, Ric Wheeler <rwheeler <at> redhat.com> wrote:
> Grant Grundler wrote:
...
>> rpm isn't a great gauge of performance either since the perf is a
>> function of rpm * bit density.
>>
>
> Is this real rotational latency, or normalized?

Sorry... I was thinking throughput (MB/s) and not rotational latency.
mkp is right that rotaional latency (ie rpm) is a significant part of
total avg latency.

>  I think that the avg seek
> time is usually a bit more predictive of how well we do with the worst case
> load (fsck).

*nod*

....
>> erase and/or write times could be exported as well somehow for SSDs
>> if the FS (or other higher layer that wants to know) can't avoid
>> garbage collection and erase cycles. I was just told today that flash
>> devices
>> have 10x higher write time than read time. erase is another order of
>> magnitude higher. This doesn't include any garbage collection overhead.
>>
>
> This is changing - they have various ways of getting them much closer
> together. On the other hand, a USB flash drive is much slower than a high
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugme-daemon | 1 Aug 2008 01:45

[Bug 11194] megaraid_mbox kernel panic during st driver initialization

http://bugzilla.kernel.org/show_bug.cgi?id=11194

------- Comment #2 from cshore <at> fionavar.ca  2008-07-31 16:45 -------
On Thu, 31 Jul 2008 10:48:10 -0700
Andrew Morton <akpm <at> linux-foundation.org> wrote:

> > 
> > Latest working kernel version: 2.6.24
> > Earliest failing kernel version: 2.6.26
> 
> The kernel versions are ambiguous.
> 
> Which is the earliest failing kernel version?

Sorry about that; I did latest failing (unless .27 is out; I haven't
tested it). Earliest failing is 2.6.25.

> 
> > Distribution: Debian Lenny (-testing + -unstable + kernel trunk for
> > debian)
> > 
> > Hardware Environment: ASUS P4B 2.0 GHz P4 Motherboard, Dell
> > PERC3/DC (like AMI MegraRAID Elite 1600) LVD Ultra3 SCSI Adaptor
> > with four 80 GB drives on Channel 0 and a SCSI-U2 Seagate DDS-4
> > tape drive on Channel 1 Software Environment:  Debian Lenny
> > (up-to-date), with some unstable and tested with the testing kernel
> > (.25) and the trunk kernel (.26)
> > 
> > Problem Description: The kernel panics (claiming it's in the
> > megaraid_mbox driver) during boot when the st driver would normally
(Continue reading)

Permalink | Reply | 0 comments |
headers
James.Smart | 1 Aug 2008 02:35
Favicon

RE: [PATCH 1/2] scsi:netlink support in scsi and fc transports for hbaspecific messages


David Somayajulu wrote:
> > I'm a little bothered that there's nothing that qualifies the driver
> > to the shost before invoking the LLDD handler (e.g. driver has a
> > signature, message header contains signature, and the two 
> must match).
> The idea was to let the Low Level Driver validate the message 
> contents -
> signature, etc.

But that's the point - if we have a common action and a common point,
lets
do it once. Why have all LLDs perform the same kind of thing but in
completely different manners ? And worse, what happens if one doesn't
validate ?  The check doesn't have to be extensive, and the LLD
can certainly do more checks.

> I would appreciate if you can explain your comment a bit more, if my
> reasoning below does not suffice. I have already provided a function
> "fc_host_post_vendor_event_to_pid() [in 
> scsi_transport_fc.c]", which enables
> an LLD to post a message to a specific pid. This may be used 
> by the LLD to
> send response messages to the pid, for command messages sent 
> by the pid. 

it's not about sending...

What happens if the pid unexpectedly dies ? The event notices are an
easy way to find out that it died - thus releasing the "cached pid", or
(Continue reading)

Permalink | Reply | 1 comment |
headers
Divy Le Ray | 1 Aug 2008 02:51
Favicon

Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator

On Wednesday 30 July 2008 02:35:51 pm Roland Dreier wrote:
>  > * From a networking standpoint, our main concern becomes how this
>  > interacts with the networking stack.  In particular, I'm concerned
>  > based on reading the source that this driver uses "TCP port stealing"
>  > rather than using a totally separate MAC address (and IP).
>  >
>  > Stealing a TCP port on an IP/interface already assigned is a common
>  > solution in this space, but also a flawed one.  Precisely because the
>  > kernel and applications are unaware of this "special, magic TCP port"
>  > you open the potential for application problems that are very
>  > difficult for an admin to diagnose based on observed behavior.
>
> That's true, but using a separate MAC and IP opens up a bunch of other
> operational problems.  I don't think the right answer for iSCSI offload
> is clear yet.
>
>  - R.

Hi Jeff,

We've considered the approach of having a separate IP/MAC addresses to manage
iSCSI connections. In such a context, the stack would have to be unaware of
this iSCSI specific IP address. The iSCSI driver would then have to implement
at least its own ARP reply mechanism. DHCP too would have to be managed
separately. Most network setting/monitoring tools would also be unavailable.

The open-iscsi initiator is not a huge consumer of TCP connections, allocating
a TCP port from the stack would be reasonable in terms of resources in this
context. It is however unclear if it is an acceptable approach.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vladislav Bolkhovitin | 1 Aug 2008 14:28

Re: [PATCH] qla2xxx: Fix dpc_thread race on the module unload

Andrew Vasquez wrote:
> On Thu, 31 Jul 2008, Vladislav Bolkhovitin wrote:
> 
>>> The changes above are large (170k diffs so far), and at this point are
>>> being run-through our testing.  The hope is to get the changes
>>> upstream during one of the next two merge windows.
>>>
>>> Given the infrustructure mods and our focus on that front, if there's
>>> something small and contained you can offer above what I've proposed
>>> we'll be interested in reviewing any patches you'd push forward.
>> Then, I believe, my patch should go in as a temporal measure. I don't think 
>> we should crash users for 2 more major releases.
> 
> So the 'online' check concerns you?  So, add an 'unloading' flag, set
> it on remove_one(), save a copy of dpc_thread at qla2xxx_wake_dpc(),
> then wake_up() saved value if not 'unloading'.  Of course the direct
> wake_up() in request_acqusition should be modded to call
> qla2xxx_wake_dpc().  We're not talking about some huge window here.

My main concern is not about the 'online' flag, but about that your 
patch doesn't fix the race, which it's intended to fix, because:

1. It doesn't handle possibility of CPU to reorder commands. Hence, it 
could be possible that other CPUs can see 'online' flag set to 0 *after* 
dpc_thread set to NULL, despite in the code "ha->flags.online = 0" 
precede "ha->dpc_thread = NULL". To address that the corresponding 
memory barriers around ha->flags.online assignment and reading are needed.

2. More importantly, it doesn't handle possibility for task_struct, to 
which dpc_thread field refers, to be destroyed exactly between lines
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Bottomley | 1 Aug 2008 16:29

RE: SCSI device rescan, detection of disconnected device,or switched devices.

On Thu, 2008-07-31 at 21:52 +0300, Gal Rosen wrote:
> It won't change the device identification of the existing 10 LUNs, but
> it will report UA of "Power on, reset, or bus device reset occured",
> then I can send read capacity command.

Sending the same email four times doesn't help ... it likely got eaten
by linux-scsi each time because you sent a mixed text/html message ...
the lists only like plain text

But the point is that what happens is highly array dependent ... some
will change the id some won't.  There's nothing we can say for certain
without having knowledge of the array, which really belongs in policy
somewhere.

James

> 
> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley <at> HansenPartnership.com]
> Sent: Thu 7/31/2008 7:20 PM
> To: Gal Rosen
> Cc: Stefan Richter; linux-scsi <at> vger.kernel.org
> Subject: Re: SCSI device rescan, detection of disconnected device,or
> switched devices.
> 
> On Thu, 2008-07-31 at 19:09 +0300, Gal Rosen wrote:
> > On Thu, 2008-07-31 at 09:15 -0500, James Bottomley wrote:
> > > Oh ... you're not really talking about hotplug, which is why
> everyone is
> > > confused.  Hotplug is when you add or remove something from the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Wilcox | 1 Aug 2008 18:11

Re: tools support for non-512 byte sector sizes

On Wed, Jul 30, 2008 at 08:51:47AM -0500, Matt Domsch wrote:
> I have access to disks with native 4KB sectors now too.  Would
> interested parties be willing to share test plans, so we could be sure
> we have coverage wrt correctness: kernel internals, userspace tools like parted,
> fdisk, kpartx, apps using O_DIRECT)?  Benchmarking winds up being an
> NDA activity this early in the game so I don't want the focus of any
> joint work to be benchmarks yet.

Are they SCSI?  I just got round to trying 4k sector sizes in ata_ram
(after adding file backed capability) and found that libata currently
silently ignores the identify bits that report sector size.  I'll work
on fixing that this afternoon if nobody beats me to it.

--

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Yang, Bo | 1 Aug 2008 18:19

[PATCH 1/4] scsi: megaraid_sas - Add the dumy readl to force PCI flush

MegaRAID SAS Driver get unexpected Interrupt.  Add the dumy readl to force PCI flush will fix this issue.

Signed-off-by Bo Yang<bo.yang <at> lsi.com>

---
drivers/scsi/megaraid/megaraid_sas.c |    6 ++++++
1 files changed, 6 insertions(+)

diff -rupN linux-2.6.28_orig/drivers/scsi/megaraid/megaraid_sas.c linux-2.6.28_new/drivers/scsi/megaraid/megaraid_sas.c
--- linux-2.6.28_orig/drivers/scsi/megaraid/megaraid_sas.c      2008-07-31 12:00:58.000000000 -0400
+++ linux-2.6.28_new/drivers/scsi/megaraid/megaraid_sas.c       2008-07-31 12:30:35.000000000 -0400
 <at>  <at>  -198,6 +198,9  <at>  <at>  megasas_clear_intr_xscale(struct megasas
         */
        writel(status, &regs->outbound_intr_status);

+       /* Dummy readl to force pci flush */
+       readl(&regs->outbound_intr_status);
+
        return 0;
 }

 <at>  <at>  -293,6 +296,9  <at>  <at>  megasas_clear_intr_ppc(struct megasas_re
         */
        writel(status, &regs->outbound_doorbell_clear);

+       /* Dummy readl to force pci flush */
+       readl(&regs->outbound_doorbell_clear);
+
        return 0;
 }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yang, Bo | 1 Aug 2008 18:48

[PATCH 2/4] scsi: megaraid_sas - Add the shutdown DCMD cmd to driver shutdown routine

Add the shutdown DCMD cmd to driver shutdown routine to make megaraid sas FW shutdown proper.

Signed-off-by Bo Yang<bo.yang <at> lsi.com>

---
 drivers/scsi/megaraid/megaraid_sas.c |    1 +
 1 files changed, 1 insertion(+)

diff -rupN linux-2.6.28_orig/drivers/scsi/megaraid/megaraid_sas.c linux-2.6.28_new/drivers/scsi/megaraid/megaraid_sas.c
--- linux-2.6.28_orig/drivers/scsi/megaraid/megaraid_sas.c      2008-07-31 12:51:06.000000000 -0400
+++ linux-2.6.28_new/drivers/scsi/megaraid/megaraid_sas.c       2008-07-31 12:54:09.000000000 -0400
 <at>  <at>  -2863,6 +2863,7  <at>  <at>  static void megasas_shutdown(struct pci_
 {
        struct megasas_instance *instance = pci_get_drvdata(pdev);
        megasas_flush_cache(instance);
+       megasas_shutdown_controller(instance, MR_DCMD_CTRL_SHUTDOWN);
 }

 /**
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
David Somayajulu | 1 Aug 2008 20:03

Re: [PATCH 1/2] scsi:netlink support in scsi and fc transports for hbaspecific messages


On 7/31/08 5:35 PM, "James.Smart <at> Emulex.Com" <James.Smart <at> Emulex.Com> wrote:

>  
> 
> David Somayajulu wrote:
>>> I'm a little bothered that there's nothing that qualifies the driver
>>> to the shost before invoking the LLDD handler (e.g. driver has a
>>> signature, message header contains signature, and the two
>> must match).
>> The idea was to let the Low Level Driver validate the message
>> contents -
>> signature, etc.
> 
> But that's the point - if we have a common action and a common point,
> lets
> do it once. Why have all LLDs perform the same kind of thing but in
> completely different manners ? And worse, what happens if one doesn't
> validate ?  The check doesn't have to be extensive, and the LLD
> can certainly do more checks.
In that case is it o.k to have the first 4 bytes of the LLD payload (i.e.,
following struct scsi_nl_hdr) define a signature. Let us also define the
signature to be the first 4 bytes in shost->hostt->name. This we can still
have some validation without much overhead.
> 
>> I would appreciate if you can explain your comment a bit more, if my
>> reasoning below does not suffice. I have already provided a function
>> "fc_host_post_vendor_event_to_pid() [in
>> scsi_transport_fc.c]", which enables
>> an LLD to post a message to a specific pid. This may be used
(Continue reading)

Permalink | Reply | 0 comments |

Gmane