Douglas Gilbert wrote:
> So this beta adds transport information, both target
> and initiator (host) for these transports:
> - FC
> - SAS
>
> I hope to add iSCSI if I can find a way through its maze.
> Perhaps USB and 1394 are candidates as well, even SPI.
In case you find the ieee1394/sbp2 t
The last announcement I made to this list about lsscsi
was back in March and that was a beta for lsscsi version
0.18 . The change proposed by James Bottomley that prompted
the beta has not materialized. So I decided to release
version 0.18 without fanfare a week ago and start adding
transport infor
On Tue, Dec 05, 2006 at 11:26:51PM -0800, Greg KH wrote:
> > If this looks good, I'll post a diff for gregkh.
>
> This looks very good, thanks for doing this work.
welcome - feels like the most significant contribution I've made
to kernel in a long time.
> I do have a few minor comments:
I'll f
Mike Christie wrote:
> Jeremy Linton wrote:
>> On Wednesday 06 December 2006 17:42, Jeremy Linton wrote:
>>> On Wednesday 06 December 2006 16:50, Mike Christie wrote:
> For iscsi, we could negotiate a value like MaxBurstLength which says
> don't send commands with a payload larger than that
Mike Christie wrote:
> Jeremy Linton wrote:
>> On Wednesday 06 December 2006 17:42, Jeremy Linton wrote:
>>> On Wednesday 06 December 2006 16:50, Mike Christie wrote:
> For iscsi, we could negotiate a value like MaxBurstLength which says
> don't send commands with a payload larger than that
Jeremy Linton wrote:
> On Wednesday 06 December 2006 17:42, Jeremy Linton wrote:
>> On Wednesday 06 December 2006 16:50, Mike Christie wrote:
For iscsi, we could negotiate a value like MaxBurstLength which says
don't send commands with a payload larger than that size. I would guess
o
On Wed, Nov 22, 2006 at 11:09:01AM -0700, Grant Grundler wrote:
> On Wed, Nov 22, 2006 at 05:06:07PM +0900, Hidetoshi Seto wrote:
> > --- linux-2.6.19-rc6.orig/drivers/pci/pci.c
> > +++ linux-2.6.19-rc6/drivers/pci/pci.c
> > @@ -558,12 +558,18 @@
> > {
> > int err;
> >
> > + if (dev->is_ena
Does drivers/scsi/qlogicfas408.c have a maintainer?
Begin forwarded message:
Date: Wed, 6 Dec 2006 16:14:31 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 7644] New: Race: host lock is not acquired before
calling ql_icmd
http://bugzilla.kernel.org/show_bug.cgi?
On Wednesday 06 December 2006 17:42, Jeremy Linton wrote:
> On Wednesday 06 December 2006 16:50, Mike Christie wrote:
> > > For iscsi, we could negotiate a value like MaxBurstLength which says
> > > don't send commands with a payload larger than that size. I would guess
> > > other transports have
On Wednesday 06 December 2006 16:50, Mike Christie wrote:
> > For iscsi, we could negotiate a value like MaxBurstLength which says
> > don't send commands with a payload larger than that size. I would guess
> > other transports have something similar. We have to check or make sure
...
> Oh yeah the
Mike Christie wrote:
> Douglas Gilbert wrote:
>> James Bottomley wrote:
>>> On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote:
Well, accept the patch if it works.
>>> It's not about work/not work: it's about correctness.
>>>
And in case that you don't like it, make sure that the _
On Wed, 6 Dec 2006, Mike Christie wrote:
> Alternatively, if we do start not checking values like max sectors and
> send requests down to the drivers, the block layer mapping functions can
> be modified to not check certain values and LLDs/scsi-ml can return
> these BLKERR values all the way up to
Douglas Gilbert wrote:
> James Bottomley wrote:
>> On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote:
>>> Well, accept the patch if it works.
>> It's not about work/not work: it's about correctness.
>>
>>> And in case that you don't like it, make sure that the _parameter_ is
>>> moved to wh
On Wed, 6 Dec 2006, James Bottomley wrote:
> On Wed, 2006-12-06 at 13:58 -0500, Alan Stern wrote:
> > I'd love to do that -- but blkdev_ioctl() wants inode->i_bdev to be set,
> > and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue(). So
> > it won't work with sg, which uses char
James,
Please review the patch below. Presuming that you lke it,
please forward upstream.
--linas
This patch adds PCI Error recovery support to the
Emulex Lightpulse Fibrechannel (lpfc) SCSI device driver.
Lightly tested at this point, works.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
C
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-12-05 at 21:08 -0800, Andrew Morton wrote:
> > case MEDIUM_ERROR:
> > + if (sshdr.asc == 0x11 || /* UNRECOVERED READ ERR */
> > + sshdr.asc == 0x13 || /* AMNF DATA FIELD */
> > + sshdr.asc == 0x1
James Bottomley wrote:
> On Wed, 2006-12-06 at 13:38 -0500, Douglas Gilbert wrote:
>> SPI is dead. Get used to it. SCSI has not meant SPI for
>> years. We should be in the business of disabusing people
>> of that idea, not reinforcing it.
>
> I don't believe I said anything in favour of or against
On Wed, 2006-12-06 at 13:58 -0500, Alan Stern wrote:
> I'd love to do that -- but blkdev_ioctl() wants inode->i_bdev to be set,
> and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue(). So
> it won't work with sg, which uses character device nodes.
Well, even sg has the queue ...
On Wed, 6 Dec 2006, James Bottomley wrote:
> On Wed, 2006-12-06 at 12:21 -0500, Alan Stern wrote:
> > So only the legacy sg character-device files need attention, which
> > means
> > that only the part of the patch affecting sg.c is necessary. The new
> > SG_GET_MAX_TRANSFER_LENGTH ioctl can re
On Wed, 2006-12-06 at 13:38 -0500, Douglas Gilbert wrote:
> SPI is dead. Get used to it. SCSI has not meant SPI for
> years. We should be in the business of disabusing people
> of that idea, not reinforcing it.
I don't believe I said anything in favour of or against SPI.
I think you'll find the w
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-12-06 at 18:49 +0100, Joerg Schilling wrote:
> > Please keep in mind: all CD/DVD burners are SCSI devices.
>
> This is probably semantics, but nowadays, SCSI means SPI (or parallel
> SCSI). I think you're trying to say that they're all dev
James Bottomley wrote:
> On Wed, 2006-12-06 at 18:49 +0100, Joerg Schilling wrote:
>> Please keep in mind: all CD/DVD burners are SCSI devices.
>
> This is probably semantics, but nowadays, SCSI means SPI (or parallel
> SCSI). I think you're trying to say that they're all devices that obey
> the
James Bottomley wrote:
> On Wed, 2006-12-06 at 11:32 -0500, Alan Stern wrote:
>>> But how did he get the file descriptor? He opened a device name, which
>>> could have been used to get the sysfs file.
>> The device name was probably something like /dev/sg0. This doesn't easily
>> permit one to fi
On Wed, 2006-12-06 at 18:49 +0100, Joerg Schilling wrote:
> Please keep in mind: all CD/DVD burners are SCSI devices.
This is probably semantics, but nowadays, SCSI means SPI (or parallel
SCSI). I think you're trying to say that they're all devices that obey
the MMC standard? Which is true, but
Alan Stern <[EMAIL PROTECTED]> wrote:
> It turns out that for block device files we don't need to change anything.
> The BLKSECTGET ioctl already does almost exactly what we want:
>
> int n;
>
> if (ioctl(fd, BLKSECTGET, &n) == 0)
> max_transfer_size = n * 512;
>
> So onl
James Bottomley <[EMAIL PROTECTED]> wrote:
> All CD/DVD burners are block devices, which is the problem set under
> discussion.
Please keep in mind: all CD/DVD burners are SCSI devices.
You cannot write or even retrieve special information without SCSI.
Jörg
--
EMail:[EMAIL PROTECTED] (home)
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote:
> > Well, accept the patch if it works.
>
> It's not about work/not work: it's about correctness.
>
> > And in case that you don't like it, make sure that the _parameter_ is
> > moved to where i
On Wed, 2006-12-06 at 12:21 -0500, Alan Stern wrote:
> So only the legacy sg character-device files need attention, which
> means
> that only the part of the patch affecting sg.c is necessary. The new
> SG_GET_MAX_TRANSFER_LENGTH ioctl can remain unimplemented by the
> block
> layer -- just as
On Wed, 6 Dec 2006, James Bottomley wrote:
> Realistically, no-one makes SCSI CDs or DVDs any more ... I know, I've
> tried to get some for some of my older boxes. Most of them nowadays are
> IDE attachments, which don't have a /dev/sg node. So /dev/sg is really
> the legacy mode for burning.
W
James Bottomley wrote:
> On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote:
>> Well, accept the patch if it works.
>
> It's not about work/not work: it's about correctness.
>
>> And in case that you don't like it, make sure that the _parameter_ is
>> moved to where it belongs: to the low
On Wed, 2006-12-06 at 11:32 -0500, Alan Stern wrote:
> > But how did he get the file descriptor? He opened a device name, which
> > could have been used to get the sysfs file.
>
> The device name was probably something like /dev/sg0. This doesn't easily
> permit one to find the corresponding sys
On Tue, 5 Dec 2006, Joerg Schilling wrote:
> If the number in "sectors" is not a value in sectors but a value in 512 byte
> units, it looks OK.
That's right. This is one of those places where the kernel converts
between the hardware's actual sector size and a fictitious 512-byte sector
size.
>
On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote:
> Well, accept the patch if it works.
It's not about work/not work: it's about correctness.
> And in case that you don't like it, make sure that the _parameter_ is
> moved to where it belongs: to the low level transport layer.
It's not a
On Tue, 2006-12-05 at 21:08 -0800, Andrew Morton wrote:
> case MEDIUM_ERROR:
> + if (sshdr.asc == 0x11 || /* UNRECOVERED READ ERR */
> + sshdr.asc == 0x13 || /* AMNF DATA FIELD */
> + sshdr.asc == 0x14) { /* RECORD NOT FOUND */
> +
On Thu, 30 Nov 2006, Andrew Morton wrote:
That looks like it prevents the IO error. But why was an IO error causing
an infinite loop? What piece of code was initiating the retries?
Maybe it's related to the infinite domain validation retry loop problem
I reported on linux-scsi a few weeks
Hello Douglas,
thanks for your help, I was just a bit worried when I read the thread.
> On reviewing that thread, the original poster was
> jumping to premature conclusions. Justin Gibbs told
> him there was no such problem (and Justin is well
> placed to know). Then the final post shows a trace
36 matches
Mail list logo
