Andi Kleen wrote:
to the log because they come from printk_ratelimit(). So all you've
done is halved the volume of flow to the logs and left a dangling printk
suppressed message that keeps spewing, so I don't think the patch even
does what you describe it as doing ... if you reverse the order o
FUJITA Tomonori wrote:
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/sg.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 92b4367..527e2eb 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@
FUJITA Tomonori wrote:
If cdev_add fails in sg_add, sg_remove crashes since class_data is
bogus.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/sg.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index f1871e
On Mon, 14 Jan 2008 14:11:36 -0800
Michael Reed <[EMAIL PROTECTED]> wrote:
> We're seeing an occasional panic in sg_add() when class_device_create()
> fails. It's obvious in the code that it uses the pointer to sg_class_member
> even though it's invalid. We do see the "class_device_create failed
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/sg.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 92b4367..527e2eb 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1430,11 +1430,14 @@ s
If cdev_add fails in sg_add, sg_remove crashes since class_data is
bogus.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/sg.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index f1871ea..92b4367 100644
--- a/d
On Tue, Jan 15, 2008 at 12:04:09PM +0900, K.Tanaka wrote:
> I would like to introduce a SCSI fault injection framework using SystemTap.
>
> Currently, kernel has Fault-injection framework and Faulty mode for md,
> which can also be used for testing the error handling. But, they could
> only produc
This message describes the details about md-RAID1 issue found by
testing the md RAID1 using the SCSI fault injection framework.
Abstract:
Both the error handler for md RAID1 and write access request to the md RAID1
use raid1d kernel thread. The nr_pending flag could cause a race condition
in raid
I would like to introduce a SCSI fault injection framework using SystemTap.
Currently, kernel has Fault-injection framework and Faulty mode for md,
which can also be used for testing the error handling. But, they could
only produce fixed type of errors stochastically. In order to simulate
more re
On Monday, January 14, 2008 5:42 PM, Grant Grundler wrote:
> > mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page:
> type=08h, page=00h, action=01h, form=0001h
>
> My interpretation of this (and Eric should know this alot better) is
> the host is attempting to
> read (action=01h) thi
>-Original Message-
>From: Stefan Richter [mailto:[EMAIL PROTECTED]
>Sent: Friday, January 04, 2008 4:10 PM
>To: Dev, Vasu
>Cc: FUJITA Tomonori; Love, Robert W; [EMAIL PROTECTED]; Zou, Yi; Leech,
>Christopher; linux-scsi@vger.kernel.org
>Subject: Re: Open-FCoE on linux-scsi
>
>Stefan Richte
On Jan 11, 2008 6:01 AM, Karen Shaeffer <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have this server with an LSI Logic SAS1064 RAID
> enabled Ultra320 SCSI controller on the system board.
Karen,
The above doesn't make sense to me. How is "SAS 1064 RAID" related to
"Ultra320 SCSI"?
This card has both tr
When the expander can manage it, shared devices are handled with
affiliations. However, the 1068 firmware doesn't seem to be aware of
this. It always seems to close connections with CLOSE(NORMAL) instead
of CLOSE(CLEAR AFFILIATION).
The upshot is that once mptsas sees an ATA device in a shared
e
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
---
drivers/scsi/ofc/fcoe/fcoe_dev.c | 10 ++
drivers/scsi/ofc/libfc/fc_print.c |2 +-
drivers/scsi/ofc/libfc/fcs_state.c|4 ++--
drivers/scsi/ofc/libsa/sa_state.c | 14 +++---
drivers/scsi/ofc/openfc/open
On Mon, 2008-01-14 at 14:11 -0800, Michael Reed wrote:
> We're seeing an occasional panic in sg_add() when class_device_create()
> fails. It's obvious in the code that it uses the pointer to sg_class_member
> even though it's invalid. We do see the "class_device_create failed" message.
>
>
We're seeing an occasional panic in sg_add() when class_device_create()
fails. It's obvious in the code that it uses the pointer to sg_class_member
even though it's invalid. We do see the "class_device_create failed" message.
class_set_devdata(cl_dev, sdp);
error = cdev_add(cdev,
On Mon, 2008-01-14 at 22:03 +0100, Vojtech Pavlik wrote:
> On Mon, Jan 14, 2008 at 02:03:45PM -0600, James Bottomley wrote:
> >
> > On Mon, 2008-01-14 at 11:45 -0800, Darrick J. Wong wrote:
> > > On Mon, Jan 14, 2008 at 03:49:16PM +0100, Jan Sembera wrote:
> > > > Hi,
> > > >
> > > > we
On Mon, Jan 14, 2008 at 02:03:45PM -0600, James Bottomley wrote:
>
> On Mon, 2008-01-14 at 11:45 -0800, Darrick J. Wong wrote:
> > On Mon, Jan 14, 2008 at 03:49:16PM +0100, Jan Sembera wrote:
> > > Hi,
> > >
> > > we have array of 16 SAS disks connected to Adaptec controllers
> > > ...
> > > th
On Mon, 2008-01-14 at 20:27 +0100, Hans de Goede wrote:
> James Bottomley wrote:
> >>> Plus what is the rq->nr_sectors > sdp->sector_size /
> >>> 512 test supposed to be doing? that being true is supposed to be a
> >>> guarantee of the block layer (and if something goes wrong there's a
> >>> chec
On Mon, 2008-01-14 at 11:45 -0800, Darrick J. Wong wrote:
> On Mon, Jan 14, 2008 at 03:49:16PM +0100, Jan Sembera wrote:
> > Hi,
> >
> > we have array of 16 SAS disks connected to Adaptec controllers
> > ...
> > this elsewhere and I was recommended to send it to linux-scsi.
>
> Hmm... I thin
On Mon, Jan 14, 2008 at 03:49:16PM +0100, Jan Sembera wrote:
> Hi,
>
> we have array of 16 SAS disks connected to Adaptec controllers
> ...
> this elsewhere and I was recommended to send it to linux-scsi.
Hmm... I think Peter Bogdanovic was hitting this error recently (cc'd).
There are a lo
Looks sane to me;
Acked-by: Darrick J. Wong <[EMAIL PROTECTED]>
--D
On Sun, Jan 13, 2008 at 02:20:18AM +0900, FUJITA Tomonori wrote:
>
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> ---
> drivers/scsi/libsas/sas_scsi_host.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
James Bottomley wrote:
Plus what is the rq->nr_sectors > sdp->sector_size /
512 test supposed to be doing? that being true is supposed to be a
guarantee of the block layer (and if something goes wrong there's a
check for this lower down).
It first is was just:
rq->nr_sectors > 1
Then I change
Matthew Dharm wrote:
On Mon, Jan 14, 2008 at 10:33:08AM -0600, James Bottomley wrote:
On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote:
We may be able to convince the SCSI people to enable it for all devices,
regardless of HCD.
No ... I'm not particularly keen to have enterprise vendors
On Mon, 2008-01-14 at 19:37 +0100, Hans de Goede wrote:
> James Bottomley wrote:
> > On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote:
> >> On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote:
> >>> Guillaume Bedot wrote:
> But it fixes only two models.
> Do you think oth
Suppress one of the bogus checkpatch.pl error, the side-effect of the error
highlighted that this constant should be replaced by an existing manifest.
checkpatch.pl needs to be corrected to accept the comment style to deal with
the other cases should they ever be touched by future patches. This
On Mon, Jan 14, 2008 at 10:33:08AM -0600, James Bottomley wrote:
>
> On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote:
> > We may be able to convince the SCSI people to enable it for all devices,
> > regardless of HCD.
>
> No ... I'm not particularly keen to have enterprise vendors after my
James Bottomley wrote:
> On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote:
>> On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote:
>> > Guillaume Bedot wrote:
>> > >Will this be possible to use "LAST_SECTOR_BUG" quirk for testing without
>> > >recompiling a kernel ?
>> >
>> > This
James Bottomley wrote:
On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote:
On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote:
Guillaume Bedot wrote:
But it fixes only two models.
Do you think other devices (hp or not) can be impacted ?
There are hundreds of models with card rea
Bill Adair wrote:
> Is there any way under Linux of forcing use of the sd driver for a
> device on the bus instead of sg?
The INQUIRY data which the SCSI core gets from the device have to
indicate that the device implements SBC or RBC (is of peripheral device
type 00h or 0Eh).
--
Stefan Richter
-
Found one area that needed to be fixed in the 8.2.4 patches.
Remove incorrect use of #ifdef for an on stack waitqueue. Upstream driver
always uses DECLARE_WAIT_QUEUE_HEAD_ONSTACK();
Signed-off-by: James Smart <[EMAIL PROTECTED]>
diff -upNr a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpf
On Friday, January 11, 2008 7:01 AM, Karen Shaeffer wrote:
> mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page:
> type=08h, page=00h, action=01h, form=000Fh
>
> I've traced through the mptbase.c code and can see these
> invalid config pages are read from the controller during
> ini
On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote:
> On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote:
> > Guillaume Bedot wrote:
> > >But it fixes only two models.
> > >Do you think other devices (hp or not) can be impacted ?
> > >There are hundreds of models with card readers o
[EMAIL PROTECTED] wrote on Fri, 11 Jan 2008 19:16 -0500:
> James Bottomley wrote:
>> On Thu, 2008-01-10 at 16:46 -0500, Pete Wyckoff wrote:
>>> [EMAIL PROTECTED] wrote on Thu, 10 Jan 2008 14:55 -0600:
On Thu, 2008-01-10 at 15:43 -0500, Pete Wyckoff wrote:
> [EMAIL PROTECTED] wrote on Wed,
On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote:
> Guillaume Bedot wrote:
> >But it fixes only two models.
> >Do you think other devices (hp or not) can be impacted ?
> >There are hundreds of models with card readers only for hp :
> >http://hplip.sourceforge.net/supported_devices/comb
Boaz pointed out that the current sg table code will bug in the SCSI
index function because it assumes a larger sized allocator that SCSI
possesses. This patch fixes the issue.
James
---
>From 258aae00284d61786758d9e740df08cc4b916f96 Mon Sep 17 00:00:00 2001
From: James Bottomley <[EMAIL PROTEC
Jens pointed out that I need to lower both phys and hw segments in the
drain set up, so an updated patch is attached.
James
---
>From 7d5cff0af8a2d4017d0b5246aaef33327b053495 Mon Sep 17 00:00:00 2001
From: James Bottomley <[EMAIL PROTECTED]>
Date: Thu, 10 Jan 2008 11:30:36 -0600
Subject: block:
The promised min_t() cleanup. Purely cosmetic.
This attached patch is against current scsi-misc-2.6 *after*
http://marc.info/?l=linux-scsi&m=120020681219191&w=2 is applied. James, sorry
if this patch is being submitted too early in the pipeline ...
ObligatoryDisclaimer: Please accept my condole
As of now, compat_ioctl already runs without the BKL, whereas ioctl runs
with the BKL. This patch first converts changer_fops to use a .unlocked_ioctl
member. It applies the same locking rationale than ch_ioctl_compat() uses
to ch_ioctl().
Signed-off-by: Mathieu Segaud <[EMAIL PROTECTED]>
Reviewed
Hi,
we have array of 16 SAS disks connected to Adaptec controllers
(we have ASC-58300 and on-board AIC-9410W, but this bug occurs on both
of them). Controller initializes drives successfully and they seem to work
normally, but when we perform some I/O intensive task (such as create md
raid
As of now, compat_ioctl already runs without the BKL, whereas ioctl runs
with the BKL. This patch first converts changer_fops to use a .unlocked_ioctl
member. It applies the same locking rationale than ch_ioctl_compat() uses
to ch_ioctl().
Signed-off-by: Mathieu Segaud <[EMAIL PROTECTED]>
Reviewed
On Mon, Jan 14, 2008 at 03:31:17PM +0100, Mathieu Segaud wrote:
> + .owner = THIS_MODULE,
> + .open = ch_open,
> + .release= ch_release,
> + .unlocked_ioctl = ch_ioctl,
Do you have a tab setting that's not 8? You seem to have used
Vous m'avez dit récemment :
> On Mon, Jan 14, 2008 at 02:32:13PM +0100, Mathieu Segaud wrote:
>> +#include
> You don't add any uses of lock_kernel() and there are none in the
> driver currently.
yep, it was before I noticed the locking semantics of
ch_ioctl_compat()
>> -.owner= THIS
As of now, compat_ioctl already runs without the BKL, whereas ioctl runs
with the BKL. This patch first converts changer_fops to use a .unlocked_ioctl
member. It applies the same locking rationale than ch_ioctl_compat() uses
to ch_ioctl().
Signed-off-by: Mathieu Segaud <[EMAIL PROTECTED]>
---
dri
On Mon, Jan 14, 2008 at 02:32:13PM +0100, Mathieu Segaud wrote:
> +#include
You don't add any uses of lock_kernel() and there are none in the
driver currently.
> - .owner= THIS_MODULE,
> - .open = ch_open,
> - .release = ch_release,
> - .ioctl= ch_ioc
They are - for display purposes. We have yet to make them settable via
the transport. I'll look into it, as it does make sense.
-- james s
James Bottomley wrote:
On Fri, 2008-01-11 at 01:53 -0500, James Smart wrote:
Made link speed and link topology modifiable via sysfs
Make scatter gather Se
James Bottomley wrote:
You didn't check the diffstat of this one:
lpfc_init.c | 11
lpfc_init.c.orig | 2475 ++-
2 files changed, 2481 insertions(+), 5 deletions(-)
I've manually removed all references to the lpfc_init.c.orig file th
As of now, compat_ioctl already runs without the BKL, whereas ioctl runs
with the BKL. This patch first converts changer_fops to use a .unlocked_ioctl
member. It applies the same locking rationale than ch_ioctl_compat() uses
to ch_ioctl().
Signed-off-by: Mathieu Segaud <[EMAIL PROTECTED]>
---
dri
ACK on ips, aacraid and dpt_i2o bits. Cursory inspection of other bits as well.
Thanks Fujita, looks good!
Will do a 'min()' cleanup on aacraid once patch propagates into scsi-misc-2.6
Sincerely -- Mark Salyzyn
cur*so*ry - adjective
going rapidly over something, without noticing details
ACK on ips bits.
Sincerely -- Mark Salyzyn
. . .
> diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
> index e54d30c..b1b2295 100644
> --- a/drivers/scsi/ips.c
> +++ b/drivers/scsi/ips.c
> @@ -2736,8 +2736,6 @@ ips_next(ips_ha_t * ha, int intr)
> SC->result = DID_OK;
>
I have a device reported as below. It is a PCMCIA card reader with
SCSI-2 connections. I know the device can work as a direct access device
when flash memory is present as I have connected it to an Akai sampler
which can read the card. I am assuming here the sampler's SCSI stack is
not very complex
Guillaume Bedot wrote:
I have tested this time with two PSC 1610 printers, and two SD cards,
the same bug occured without the patch.
And is fixed with your new patch. Good work !
Hi,
Thanks for testing!
But it fixes only two models.
Do you think other devices (hp or not) can be impacted ?
Hello,
On ven, 2008-01-11 at 21:14 +0100, Hans de Goede wrote:
> Boaz Harrosh wrote:
> > Yes, you're right. in ULDs it is a much proper way to do this.
> >
> > So I guess you'll have to do that special host flag or device
> > flag, and add a check for it in sd.c. You'll see that sd.c is
> > alre
53 matches
Mail list logo
