Greetings all,
After the release of JeOS yesterday, which is the Ubuntu based VM that
is intended to be used a virtual appliance, I have gone ahead and
generated the kernel and userspace builds for the Linux-iSCSI.org Target
stack. The .debs are currently available from the iSCSI build cluster:
On Wed, 2007-11-21 at 09:39 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2007-11-20 at 15:10 -0600, James Bottomley wrote:
> > We're talking about trying to fix this for 2.4; which is already at
> > -rc3 ... Is an entire arch change for dma alignment really a merge
> > candidate at this stage?
>
> > Management stuff always seems to be tied to a single card. It's one of
> > the things that puts me off hardware RAID.
>
> There are 113 cards this driver works for in concert. Maybe my tail
> feathers are showing ;->
You might want to mention the card firmware in question run on 3 or 4
entire
On Tue, 2007-11-20 at 15:10 -0600, James Bottomley wrote:
> We're talking about trying to fix this for 2.4; which is already at
> -rc3 ... Is an entire arch change for dma alignment really a merge
> candidate at this stage?
Well, as I said before... it's a matter of what seems to be the less
like
On Tue, 2007-11-20 at 12:05 -0800, Roland Dreier wrote:
> > Actually, we already established on IRC that the lasi700 driver doesn't
> > need this, principally because the parisc architecture doesn't do an
> > invalidate for DMA_FROM_DEVICE but a flush and invalidate
> > (architecturally, if you
Jonathan McDowell [mailto:[EMAIL PROTECTED] sez:
> On Tue, Nov 20, 2007 at 12:49:49PM -0500, Salyzyn, Mark wrote:
> > The aacraid cards, which uses hba_monitor_version,
> > hba_kernel_version and hba_bios_version for each piece
> > does not fit into the single 'firmware revision' common ideal
> Wh
On Wed, Nov 21, 2007 at 08:40:56AM +, bo yang wrote:
> Sense buffer ptr data type in the ioctl path is reverted back to u32 *
> for x86 and x86_64 as in previous versions of driver. For IA64 it will
> be unsigned long *. Compile time flag added for ia64 for this.
This changelog tells us what y
Sense buffer ptr data type in the ioctl path is reverted back to u32 *
for x86 and x86_64 as in previous versions of driver. For IA64 it will
be unsigned long *. Compile time flag added for ia64 for this.
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
Documentation/scsi/ChangeLog.megaraid_sas |
> Actually, we already established on IRC that the lasi700 driver doesn't
> need this, principally because the parisc architecture doesn't do an
> invalidate for DMA_FROM_DEVICE but a flush and invalidate
> (architecturally, if you read our manuals, even pdc is entitled to write
> back dirty l
On Tue, Nov 20, 2007 at 12:49:49PM -0500, Salyzyn, Mark wrote:
> Jonathan McDowell sez:
> > On Tue, Nov 20, 2007 at 11:35:26AM -0500, James Smart wrote:
> > > The hearburn I have with these patches is that you are changing
> > > driver-specific attributes, not common ones as enforced/requested
> >
On Tue, 2007-11-20 at 14:14 +1100, Benjamin Herrenschmidt wrote:
> FYI, Here's what I have for the SCSI change. I haven't updated drivers
> to care for the new return code though, help appreciated with that as I
> don't know much about these drivers.
It looks to me like the return problem could b
On Tue, 20 Nov 2007, James Bottomley wrote:
> > The main point I'm aiming for is to have the midlayer to inform the LLD
> > when all the devices on a particular bus are "idle".
>
> This is the wrong assumption ... the mid layer would provide an API to
> inform the transport. Transport and host
James Bottomley wrote:
I'm not sure your conclusions necessarily follow your data. What was
the reason for the TASK ABORTED (I'd guess QErr settings, right)?
It was my desire/curiosity during tests of SCST (http://scst.sf.net),
when it working with several initiators with different transports
On Tue, 2007-11-20 at 20:45 +0300, Vladislav Bolkhovitin wrote:
> James Bottomley wrote:
> >I'm not sure your conclusions necessarily follow your data. What was
> >the reason for the TASK ABORTED (I'd guess QErr settings, right)?
>
> It was my desire/curiosity during tests of SCS
On Tue, Nov 20, 2007 at 08:45:12PM +0300, Vladislav Bolkhovitin wrote:
> James Bottomley wrote:
> >We handle TASK ABORTED as well as we can (by failing it). For better
> >handling set TAS=0 and we'll handle the individual cases according to
> >the sense codes.
>
> So, should I consider your words
Jonathan McDowell sez:
> On Tue, Nov 20, 2007 at 11:35:26AM -0500, James Smart wrote:
> > The hearburn I have with these patches is that you are changing
> > driver-specific attributes, not common ones as
> > enforced/requested by a
> > subsystem. As such, you are breaking a management interface f
James Bottomley wrote:
I'm not sure your conclusions necessarily follow your data. What was
the reason for the TASK ABORTED (I'd guess QErr settings, right)?
It was my desire/curiosity during tests of SCST (http://scst.sf.net),
when it working with several initiators with different transports
On Tue, 2007-11-20 at 20:17 +0300, Vladislav Bolkhovitin wrote:
> James Bottomley wrote:
> > On Tue, 2007-11-20 at 19:15 +0300, Vladislav Bolkhovitin wrote:
> >
> >>James Bottomley wrote:
> >>
> >>>I'm not sure your conclusions necessarily follow your data. What was
> >>>the reason for the TASK
James Bottomley wrote:
On Tue, 2007-11-20 at 19:15 +0300, Vladislav Bolkhovitin wrote:
James Bottomley wrote:
I'm not sure your conclusions necessarily follow your data. What was
the reason for the TASK ABORTED (I'd guess QErr settings, right)?
It was my desire/curiosity during tests of SC
On Tue, Nov 20, 2007 at 11:35:26AM -0500, James Smart wrote:
> The hearburn I have with these patches is that you are changing
> driver-specific attributes, not common ones as enforced/requested by a
> subsystem. As such, you are breaking a management interface for
> existing tools/scripts.
Yes, t
On Tue, 2007-11-20 at 19:15 +0300, Vladislav Bolkhovitin wrote:
> James Bottomley wrote:
> > I'm not sure your conclusions necessarily follow your data. What was
> > the reason for the TASK ABORTED (I'd guess QErr settings, right)?
>
> It was my desire/curiosity during tests of SCST (http://scst
The hearburn I have with these patches is that you are changing driver-specific
attributes, not common ones as enforced/requested by a subsystem. As such, you
are breaking a management interface for existing tools/scripts.
There's been a long-standing request to create common device attributes, s
James Bottomley wrote:
On Tue, 2007-11-20 at 18:04 +0300, Vladislav Bolkhovitin wrote:
James Bottomley wrote:
And please close this as invalid. FS ordering guarantees in linux
aren't done via ordered tags.
I had a related question. I was working on the attached patch for soe
other testing
On Tue, 2007-11-20 at 11:02 -0500, Alan Stern wrote:
> On Tue, 20 Nov 2007, James Bottomley wrote:
>
> > I don't really know ... I don't have a clear idea of what you're trying
> > to do. I know Alan said it was something simple, but from what you're
> > saying it sounds like you need a full blo
On Tue, 20 Nov 2007, James Bottomley wrote:
> I don't really know ... I don't have a clear idea of what you're trying
> to do. I know Alan said it was something simple, but from what you're
> saying it sounds like you need a full blown power management
> infrastructure in all three places.
Basic
On Tue, 20 Nov 2007, Douglas Gilbert wrote:
> There should have always been at least two types of "block":
>a) block media access commands
>b) block all commands because the transport has told us
> (or we know that we are about to remove some component)
> that commands cannot b
On Tue, 2007-11-20 at 16:36 +0100, Oliver Neukum wrote:
> Am Dienstag 20 November 2007 schrieb James Bottomley:
> >
> > On Tue, 2007-11-20 at 16:07 +0100, Oliver Neukum wrote:
> > > Am Dienstag 20 November 2007 schrieb James Bottomley:
> > > > I don't understand why you want to do this. Power ma
Am Dienstag 20 November 2007 schrieb James Bottomley:
>
> On Tue, 2007-11-20 at 16:07 +0100, Oliver Neukum wrote:
> > Am Dienstag 20 November 2007 schrieb James Bottomley:
> > > I don't understand why you want to do this. Power management is a
> > > layered issue on SCSI, divided (as always) into
On Tue, 2007-11-20 at 18:04 +0300, Vladislav Bolkhovitin wrote:
> James Bottomley wrote:
> >>>And please close this as invalid. FS ordering guarantees in linux
> >>>aren't done via ordered tags.
> >>
> >>I had a related question. I was working on the attached patch for soe
> >>other testing (pat
On Tue, 2007-11-20 at 16:07 +0100, Oliver Neukum wrote:
> Am Dienstag 20 November 2007 schrieb James Bottomley:
> > I don't understand why you want to do this. Power management is a
> > layered issue on SCSI, divided (as always) into host, device and
> > transport. The idle you're talking about
On Tue, 2007-11-20 at 10:39 +, Alistair John Strachan wrote:
> On Tuesday 20 November 2007 01:53:31 Joe Perches wrote:
> > diff --git a/drivers/scsi/NCR_D700.c b/drivers/scsi/NCR_D700.c
> > index 9e64b21..99403a6 100644
> > --- a/drivers/scsi/NCR_D700.c
> > +++ b/drivers/scsi/NCR_D700.c
> > @@
Am Dienstag 20 November 2007 schrieb James Bottomley:
> I don't understand why you want to do this. Power management is a
> layered issue on SCSI, divided (as always) into host, device and
> transport. The idle you're talking about is a pure device thing, so it
> can be managed by the ULD (and cu
James Bottomley wrote:
And please close this as invalid. FS ordering guarantees in linux
aren't done via ordered tags.
I had a related question. I was working on the attached patch for soe
other testing (patch made against scsi-rc-fixes, but is not stable so do
not apply), which does the scs
On Mon, 2007-11-19 at 14:16 -0500, Alan Stern wrote:
> On Mon, 19 Nov 2007, James Bottomley wrote:
>
> > > Here's how it will work: scsi_prep_state_check() will see that the
> > > device is in a suspended state (probably a substate of SDEV_QUIESCE).
> > > The return value will depend on the typ
Alan Stern wrote:
> Oliver (or anybody else):
>
> Adding dynamic (AKA runtime) power management to the SCSI core is
> looking a little difficult. (Actually, since as far as I know the SCSI
> specification takes no heed of power management, perhaps this should be
> called "idle-device management".
On Tue, 2007-11-20 at 09:29 +0100, Thomas Bogendoerfer wrote:
> On Tue, Nov 20, 2007 at 06:51:14AM +1100, Benjamin Herrenschmidt wrote:
> >
> > On Mon, 2007-11-19 at 00:38 -0800, David Miller wrote:
> > > From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> > > Date: Mon, 19 Nov 2007 16:35:23 +1100
Looking around sysfs in an attempt to pull out SCSI card firmware
versions I found 5 different filenames used to store the information.
Only one, fw_version, was used more than once. The patch below changes
the other drivers to use this filename too.
I suspect the same applies to other subsystem d
On Tuesday 20 November 2007 01:53:31 Joe Perches wrote:
> diff --git a/drivers/scsi/NCR_D700.c b/drivers/scsi/NCR_D700.c
> index 9e64b21..99403a6 100644
> --- a/drivers/scsi/NCR_D700.c
> +++ b/drivers/scsi/NCR_D700.c
> @@ -182,7 +182,7 @@ NCR_D700_probe_one(struct NCR_D700_private *p, int
> siop, i
On Tue, Nov 20, 2007 at 06:51:14AM +1100, Benjamin Herrenschmidt wrote:
>
> On Mon, 2007-11-19 at 00:38 -0800, David Miller wrote:
> > From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> > Date: Mon, 19 Nov 2007 16:35:23 +1100
> >
> > > I'm not sure what is the best way to fix that. Internally, I'
On Mon, Nov 19 2007, Mike Miller wrote:
> Patch 2 of 3
> This patch adds support for the blktrace utility. Please consider this for
> inclusion. Seems there was already a call to blk_add_trace. This patch adds
> ifdef's and includes the header file.
>
> Signed-off-by: Mike Miller <[EMAIL PROTECTED
40 matches
Mail list logo
