On Mon, 2005-08-15 at 20:52 -0400, [EMAIL PROTECTED] wrote:
> What is ":00:04:0" in this case ? The "device" is not a serial
> port, which is what the ttyXX back link would lead you to believe.
> Thus, it's a serial port multiplexer that supports up to N ports,
> right ? and wouldn't the more c
Actually, I view this as being a little odd...
What is ":00:04:0" in this case ? The "device" is not a serial
port, which is what the ttyXX back link would lead you to believe.
Thus, it's a serial port multiplexer that supports up to N ports,
right ? and wouldn't the more correct representatio
On Sun, 2005-08-14 at 16:02 +0100, Matthew Wilcox wrote:
> /sys/class/tty/ttyS0/device ->
> ../../../devices/parisc/0/0:0/pci:00/:00:04.0
> /sys/class/tty/ttyS1/device ->
> ../../../devices/parisc/0/0:0/pci:00/:00:04.0
> /sys/class/tty/ttyS2/device ->
> ../../../devices/parisc/0/
On Mon, Aug 15, 2005 at 04:32:53PM -0500, James Bottomley wrote:
> On Mon, 2005-08-15 at 16:22 -0500, mikem wrote:
> > +#ifdef CONFIG_IA64
> > +case BLKGETLASTSECT:
> > +case BLKSETLASTSECT:
> > +#endif
> > return blk_ioctl(inode->i_rdev, cmd, arg);
>
> What makes these
On Mon, Aug 15, 2005 at 04:24:25PM -0500, mikem wrote:
> This patch fixes a warning during compile.
> --- lx2431-p003/drivers/block/cciss_scsi.c
> +++ lx2431/drivers/block/cciss_scsi.c
> @@ -220,8 +220,7 @@ scsi_cmd_stack_free(int ctlr)
> printk( "cciss: %d scsi commands are still ou
Hi
It might be more an electrical than software question, sorry if somewhat
OT.
If I connect an external 100MB zip and an internal HP DDS-1 tape drive to
the dc390 adapter, I can tar zip to the tape. If I connect them to the
TRM-S1040 (dc315) it aborts with
tar: /dev/st0: Wrote only 0 of 1024
On Mon, 2005-08-15 at 16:22 -0500, mikem wrote:
> +#ifdef CONFIG_IA64
> +case BLKGETLASTSECT:
> +case BLKSETLASTSECT:
> +#endif
> return blk_ioctl(inode->i_rdev, cmd, arg);
What makes these two ioctls IA64 specific? I think they're completely
general in 2.4, so there
Patch 4/4
This patch fixes a warning during compile.
Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
cciss_scsi.c |3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
diff -
Patch 3/4
This patch adds 2 ioctls required for IPF systems. Without this change
parted may fail. This causes some vendor installs to fail.
Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
cciss.c |5 +
1 files changed, 5 insertions(+)
--
Patch 2/4
This patch adds the BLKSSZGET ioctl for Oracle. Please consider this for
inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
cciss.c |1 +
1 files changed, 1 insertion(+)
diff -burNp lx2431-p001
Patch 1/4
This patch
1) adds support for next series of Smart Array contollers.
2) bumps version to 2.4.60.
3) changes our copyright dates.
4) adds code to bind to any HP controller with a cciss signature.
Built against 2.4.31. Please consider this for inclusion.
Si
If your transport class sets the ATTRIBUTE_CONTAINER_NO_CLASSDEVS flag,
then its configure method never gets called. This patch fixes that so
that the configure method is called with a NULL classdev.
Also remove a spurious inverted comma in the transport_class comments.
James
diff --git a/drive
On 15.08.2005 [20:34:27 +], Willem Riede wrote:
> On 08/15/2005 02:27:51 PM, Nishanth Aravamudan wrote:
> > Description: Use schedule_timeout_uninterruptible() instead of
> > set_current_state()/schedule_timeout() to reduce kernel size.
> >
> > Signed-off-by: Nishanth Aravamudan <[EMAIL PROTEC
On 08/15/2005 02:27:51 PM, Nishanth Aravamudan wrote:
> Description: Use schedule_timeout_uninterruptible() instead of
> set_current_state()/schedule_timeout() to reduce kernel size.
>
> Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
>
> ---
>
> drivers/scsi/osst.c |9 +++-
Mike Christie wrote:
Block layer defines the max segment size as 65536. We need
new block layer helpers to do the mapping. Although one late night
I thought I could use a modified blk_rq_map_kern some how. If sg or
st allocate the reserve buffers then we could make a
oops, I meant sg or st wou
Douglas Gilbert wrote:
sg_io_hdr::info could be used to indicate whether DIO
was done or not (as is the present case in sg).
But if you are changing things, why not follow the
user supplied O_DIRECT open() flag?
It was only becuase the block layer functions that the
SG_IO code used to map a b
ic. thanks a lot for explanation.
so these are level sensitive interrupt.
i need to find a hw book now...
Ming
On Mon, 2005-08-15 at 11:47 -0700, Bryan Henderson wrote:
> >so it is possible that both card raise intr quicker than isr run, then
> >both isr will do mmio and go ahead, but then what
>so it is possible that both card raise intr quicker than isr run, then
>both isr will do mmio and go ahead, but then what is
>
>device 1 raise intr
>device 2 isr run and not belong to it, so quit, but before it clear intr
>and quit
>device 2 raise intr
>device 1 isr run and handle device 1, then c
Description: Use schedule_timeout_uninterruptible() instead of
set_current_state()/schedule_timeout() to reduce kernel size.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
---
drivers/scsi/NCR5380.c|5 +
drivers/scsi/aacraid/rkt.c|6 ++
drivers/scsi/aacraid/r
On Mon, 15 Aug 2005, Guennadi Liakhovetski wrote:
> On Sun, 14 Aug 2005, James Bottomley wrote:
>
> > OK, why don't we do this. Instead of having me trawl through the trees
> > looking for the correct patch to reverse, why don't you attach it in an
> > email and I'll try to get it in to 2.6.13?
On Mon, 2005-08-15 at 13:28 -0400, Salyzyn, Mark wrote:
> BTW, while applying this patch to my code, I discovered a missing
> component (applied post patch)
>
> @@ -1389,4 +1369,5 @@
> setinqstr(cardtype, (void *)
> (inq_data.inqd_vid), (sizeof(container_types)/sizeof(char
BTW, while applying this patch to my code, I discovered a missing
component (applied post patch)
@@ -1389,4 +1369,5 @@
setinqstr(cardtype, (void *)
(inq_data.inqd_vid), (sizeof(container_types)/sizeof(char *)));
inq_data.inqd_pdt = INQD_PDT_PROC;
On Mon, 2005-08-15 at 13:06 -0400, Salyzyn, Mark wrote:
> The code does not 'damage' the scsi-misc tree version, so why not apply
> it to the scsi-misc tree as well at least to make sure it does not
> (extending the test coverage)? What is the scsi-block timetable for
> downstream?
OK, that's true
The code does not 'damage' the scsi-misc tree version, so why not apply
it to the scsi-misc tree as well at least to make sure it does not
(extending the test coverage)? What is the scsi-block timetable for
downstream?
I have almost religiously applied all patches that touch the driver to
the Adap
On Mon, 2005-08-15 at 09:53 -0700, Mark Haverkamp wrote:
> This patch fixes the bad assumption of the aacraid driver with use_sg.
> I used the 3w- driver fix as a guide for this.
Yes, that looks about right
> The patch applies to the scsi-block-2.6 git tree. Is that the right
> place for the
On Wed, 2005-08-10 at 12:27 -0500, James Bottomley wrote:
> On Wed, 2005-08-10 at 10:20 -0700, Mark Haverkamp wrote:
> > While trying out a recent mm kernel I noticed that when I loaded the
> > aacraid driver I saw errors probing the disks:
> >
> > sdc : sector size 0 reported, assuming 512.
> >
On 08/15/05 12:32, James Bottomley wrote:
>>What will SCSI Core do with the RAID members? Why is SCSI Core
>>concerned with this information? What kind of parameters will
>>it have to set, without the RAID device server knowing about it
>>(which is implemented on the chip if HW RAID)?
>
>
> Not
On Mon, 2005-08-15 at 12:10 -0400, Luben Tuikov wrote:
> Isn't DV an SPI paradigm?
Yes, but that's only one of the reasons to expose the underlying device.
> If the whole point of the LLDD+controller is to _give_ you this,
> "an LU which is actually RAID", abstraction, why does SCSI Core
> need t
On Mon, 2005-08-15 at 12:21 -0400, Jeff Garzik wrote:
> Make sure this gets tested before its applied.
Yes, I'm already doing that.
James
-
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.ker
Christoph Hellwig wrote:
remove ahd_tailq and do sane pci probing. ported over from aic7xxx.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Make sure this gets tested before its applied.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the bod
On 08/15/05 11:53, James Bottomley wrote:
> On Mon, 2005-08-15 at 11:41 -0400, Luben Tuikov wrote:
>
>>Hmm, you've
>>"found an actual use for channel (exposing underlying physical discs
>> of raid devices)".
>>
>>I'm completely befuddled James.
>
>
> For RAID cards in the SCSI subsystem
On Mon, 2005-08-15 at 11:41 -0400, Luben Tuikov wrote:
> Hmm, you've
> "found an actual use for channel (exposing underlying physical discs
> of raid devices)".
>
> I'm completely befuddled James.
For RAID cards in the SCSI subsystem that export RAID devices as SCSI
devices, there's a n
Hi guys, :-)
That's a lot of email. :-)
On 08/15/05 11:23, James Bottomley wrote:
> On Mon, 2005-08-15 at 11:18 -0400, Luben Tuikov wrote:
>
>>While you're at it, rip out the extremely broken "channel" and "id",
>>and leave only the opaque token.
>
>
> Unfortunately, I just found an actual use
On 08/15/05 11:21, Christoph Hellwig wrote:
> On Mon, Aug 15, 2005 at 11:13:30AM -0400, Luben Tuikov wrote:
>
>>>+void sas_add_target(struct sas_port *port, struct sas_identify *attached,
>>>+uint channel, uint target)
>>>+{
>>>+if (attached->target_port_protocols &
>>>+(SA
On Mon, Aug 15, 2005 at 11:18:10AM -0400, Luben Tuikov wrote:
> On 08/15/05 09:42, Christoph Hellwig wrote:
> > Add a new void *transport_data argument to scsi_scan_target so that a
> > transport-class can fill in known information before actually scanning
> > the target. This is needed by the upc
On Mon, 2005-08-15 at 11:18 -0400, Luben Tuikov wrote:
> While you're at it, rip out the extremely broken "channel" and "id",
> and leave only the opaque token.
Unfortunately, I just found an actual use for channel (exposing
underlying physical discs of raid devices) and, unfortunately, we're
stil
On Mon, Aug 15, 2005 at 11:13:30AM -0400, Luben Tuikov wrote:
> > +void sas_add_target(struct sas_port *port, struct sas_identify *attached,
> > + uint channel, uint target)
> > +{
> > + if (attached->target_port_protocols &
> > + (SAS_PROTOCOL_SSP|SAS_PROTOCOL_STP|SAS_PROTOCOL_SA
On 08/15/05 09:42, Christoph Hellwig wrote:
> Add a new void *transport_data argument to scsi_scan_target so that a
> transport-class can fill in known information before actually scanning
> the target. This is needed by the upcoming SAS transport class patch.
Hmm, yes, this has been due for 5 ye
On Mon, 2005-08-15 at 15:42 +0200, Christoph Hellwig wrote:
> Add a new void *transport_data argument to scsi_scan_target so that a
> transport-class can fill in known information before actually scanning
> the target. This is needed by the upcoming SAS transport class patch.
Given that you're te
> +void sas_add_target(struct sas_port *port, struct sas_identify *attached,
> + uint channel, uint target)
> +{
> + if (attached->target_port_protocols &
> + (SAS_PROTOCOL_SSP|SAS_PROTOCOL_STP|SAS_PROTOCOL_SATA))
> + scsi_scan_target(&port->dev, channel, target,
On 08/15/05 10:35, Arjan van de Ven wrote:
> On Mon, 2005-08-15 at 15:55 +0200, Christoph Hellwig wrote:
>
>>+EXPORT_SYMBOL(sas_add_target);
>
>
> should these exports be _GPL? After all they're very much linux specific
> functionality...
Someone needs this for a binary only driver? ;-)
On Mon, 2005-08-15 at 15:55 +0200, Christoph Hellwig wrote:
> +EXPORT_SYMBOL(sas_add_target);
should these exports be _GPL? After all they're very much linux specific
functionality...
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROT
Good stuff, Christoph!
Luben
--- Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> This is a minmal, bottom-up SAS transport class. So far it only exposed
> information about the SAS port/phy and SAS device (scsi target). I hope
> this will integrate nicely with the top-down work Luben has d
This is a minmal, bottom-up SAS transport class. So far it only exposed
information about the SAS port/phy and SAS device (scsi target). I hope
this will integrate nicely with the top-down work Luben has done once he
finally releases it publically, but for now I think we should have
something so
Add a new void *transport_data argument to scsi_scan_target so that a
transport-class can fill in known information before actually scanning
the target. This is needed by the upcoming SAS transport class patch.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: scsi-misc-2.6/drivers/sc
Mike Christie wrote:
> Douglas Gilbert wrote:
>
>> James Bottomley wrote:
>>
>>> On Sun, 2005-08-14 at 16:24 -0700, Luben Tuikov wrote:
>>>
>>>
Did someone have a patch or was there a talk
that SCSI Core is moving towards sending _only_ scatterlists
down to LLDDs? (effectively BUG_
Partially true regarding RAID cards. We publish sources for all our processor
based RAID cards (dpt_i2o, aacraid). For the HostRAID cards, the RAID stack is
in the driver, we publish the binaries for the one-piece drivers. We released a
GPL driver for the HostRAID card as a raw driver + Enhanced
Mike Christie wrote:
> Make sg.c use block layer functions so we always use
> scatterlists in scsi.
>
> Changes from original driver (junk that is broken or
> new *features* :) ):
>
> - mmap currently not supported. Need some block layer helpers
> so we can support this for all ULDs. Is this need
remove ahd_tailq and do sane pci probing. ported over from aic7xxx.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: scsi-misc-2.6/drivers/scsi/aic7xxx/aic79xx.h
===
--- scsi-misc-2.6.orig/drivers/scsi/aic7xxx/aic79xx.h
remove some dead cruft, as done already in aic7xxx
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: scsi-misc-2.6/drivers/scsi/aic7xxx/aic79xx_osm.h
===
--- scsi-misc-2.6.orig/drivers/scsi/aic7xxx/aic79xx_osm.h 2005
On Mon, Aug 15, 2005 at 04:21:37PM +1000, Douglas Gilbert wrote:
> I haven't looked at what would be involved with the sg
> driver but it is good to hear Mike C. is working on it.
>
> Hopefully scsi_cmnd::buffer and bufflen get _less_ generic
> names in the process.
I'm not sure it's a that good
On Sat, Aug 13, 2005 at 02:03:01PM +0200, Pascal Terjan wrote:
> Hello,
> here is a small patch that allow building both drivers by removing the
> devices supported by the new driver from the id_table of the old driver
> when you want both.
> It is usefull for distributions wanting to keep supporti
On Mon, Aug 15, 2005 at 01:43:03AM +0100, Matthew Wilcox wrote:
> On Sun, Aug 14, 2005 at 11:25:25PM +0100, Russell King wrote:
> > Eww. Do you really want one struct device per tty with all the
> > memory each one eats?
> >
> > If that's really what you want you need to talk to Alan and not me.
53 matches
Mail list logo
