On Thu, 2007-04-05 at 15:36 -0700, David Miller wrote:
> From: Andrew Burgess <[EMAIL PROTECTED]>
> Date: Thu, 5 Apr 2007 15:13:27 -0700
>
> > David, do you see any other problems with scsi_send_eh_cmnd?
> >
> > I've switched back to 2.6.18 which seems to not oops
> > and am happy to try patche
On Thu, 2007-04-05 at 17:15 -0700, David Miller wrote:
> This won't work I believe.
>
> There are cases that use smaller sense buffers than the minimum
> specified by the SCSI layer.
>
> One example is that do_sr_ioctl() stuff when the cgc passed
> in has a sense buffer. That will only be as lar
From: James Bottomley <[EMAIL PROTECTED]>
Date: Thu, 05 Apr 2007 19:02:19 -0500
> On Thu, 2007-04-05 at 15:36 -0700, David Miller wrote:
> > From: Andrew Burgess <[EMAIL PROTECTED]>
> > Date: Thu, 5 Apr 2007 15:13:27 -0700
> >
> > > David, do you see any other problems with scsi_send_eh_cmnd?
> >
On Thu, 2007-04-05 at 15:36 -0700, David Miller wrote:
> From: Andrew Burgess <[EMAIL PROTECTED]>
> Date: Thu, 5 Apr 2007 15:13:27 -0700
>
> > David, do you see any other problems with scsi_send_eh_cmnd?
> >
> > I've switched back to 2.6.18 which seems to not oops
> > and am happy to try patches
My .config is attached.. I cannot reproduce this problem, it only happened
once, but I want to find out how to make sure it does not happen again.
On Thu, 5 Apr 2007, Justin Piszcz wrote:
On Thu, 5 Apr 2007, Justin Piszcz wrote:
http://www.ussg.iu.edu/hypermail/linux/kernel/0701.3/0315.h
From: Andrew Burgess <[EMAIL PROTECTED]>
Date: Thu, 5 Apr 2007 15:13:27 -0700
> David, do you see any other problems with scsi_send_eh_cmnd?
>
> I've switched back to 2.6.18 which seems to not oops
> and am happy to try patches.
Does 2.6.20 with my patch OOPS too? Does reverting my patch
make
Chuck Ebbert wrote:
>Andrew Burgess wrote:
>
>> Apr 5 03:45:16 cichlid kernel: 3w-: scsi2: Command failed: status =
>> 0xc7, flags = 0x7f, unit #4.
>> Apr 5 03:45:20 cichlid kernel: 3w-: scsi2: Command failed: status =
>> 0xc7, flags = 0x80, unit #4.
>> Apr 5 03:47:20 cichlid kernel:
Andrew Burgess wrote:
> The machine is x86_64 SMP. I also got the oops in the Fedora kernels:
> 2.6.20-1.2933.fc6 and 2.6.20-1.3017.fc7. The system isn't locked solid but
> it seems anything touching the scsi disks hangs. I also twice got this early
> in the boot and it stopped booting.
>
> Any
On Thu, 5 Apr 2007, Justin Piszcz wrote:
Had a quick question, this is the first time I have seen this happen, and it
was not even under during heavy I/O, hardly anything was going on with the
box at the time.
.. snip ..
# /usr/bin/time badblocks -b 512 -s -v -w /dev/sdl
Checking for bad b
Had a quick question, this is the first time I have seen this happen, and
it was not even under during heavy I/O, hardly anything was going on with
the box at the time.
Any idea what could have caused this? I am running a badblocks test right
now, but so far the disk looks OK.
[369143.91609
The machine is x86_64 SMP. I also got the oops in the Fedora kernels:
2.6.20-1.2933.fc6 and 2.6.20-1.3017.fc7. The system isn't locked solid but
it seems anything touching the scsi disks hangs. I also twice got this early
in the boot and it stopped booting.
Anything I can do to help just ask.
On Fri, Apr 06, 2007 at 03:30:52AM +0200, mahesh wrote:
> Where can I find documents for Linux SCSI mid layer
How about
Documentation/scsi/scsi_mid_low_api.txt
Documentation/scsi/scsi_eh.txt
and Documentation/scsi in general as a start?
Regards,
Andreas
--
AMD Saxony, Dresden, Germany
O
James wrote:
>
> On Thu, 2007-04-05 at 11:03 +0100, Christoph Hellwig wrote:
> > On Thu, Apr 05, 2007 at 11:58:06AM +0200, Hannes Reinecke wrote:
> > > Hi All,
> > >
> > > this patch adds the SG_IO ioctl to the cciss driver.
> > > As the driver is capable of sending SCSI CDBs to the controller
On Thu, 2007-04-05 at 11:03 +0100, Christoph Hellwig wrote:
> On Thu, Apr 05, 2007 at 11:58:06AM +0200, Hannes Reinecke wrote:
> > Hi All,
> >
> > this patch adds the SG_IO ioctl to the cciss driver.
> > As the driver is capable of sending SCSI CDBs to the controller there is
> > no reason why we
On Thu, 2007-04-05 at 08:42 +0100, Christoph Hellwig wrote:
> On Wed, Apr 04, 2007 at 08:05:59PM -0500, James Bottomley wrote:
> > Erm, there's a simple way out of this: That's the BLIST_FORCELUN
> > option. This is why most of the RAID devices have entries in
> > scsi_devinfo.c like:
> >
> >
Hi All,
this patch adds the SG_IO ioctl to the cciss driver.
As the driver is capable of sending SCSI CDBs to the controller there is
no reason why we shouldn't exploit it.
This way we get to use all the nice sg_utils for the cciss driver.
And a persistent device name for free.
Makes one wonder w
On Wednesday 04 April 2007 23:54, Kai Makisara wrote:
> On Wed, 4 Apr 2007, Kern Sibbald wrote:
>
> > On Wednesday 04 April 2007 20:46, Kai Makisara wrote:
> ...
> > > > > c. There is a real lack of information about any error condition
> > > > > (read/write). One can probably get it via d
Tejun Heo wrote:
Jeff Garzik wrote:
AN is a generic concept that I feel will propagate elsewhere.
I think SCSI already has it or am I imagining things again? :-)
Though perhaps it should be in a 'capability_flags' file rather than a
'media_change_event' file.
IMHO, if it's genhd.capabilit
On Wed, Apr 04, 2007 at 08:05:59PM -0500, James Bottomley wrote:
> Erm, there's a simple way out of this: That's the BLIST_FORCELUN
> option. This is why most of the RAID devices have entries in
> scsi_devinfo.c like:
>
> {"ADAPTEC", "AACRAID", NULL, BLIST_FORCELUN},
>
> Which overrides
On Thu, Apr 05, 2007 at 11:58:06AM +0200, Hannes Reinecke wrote:
> Hi All,
>
> this patch adds the SG_IO ioctl to the cciss driver.
> As the driver is capable of sending SCSI CDBs to the controller there is
> no reason why we shouldn't exploit it.
> This way we get to use all the nice sg_utils for
20 matches
Mail list logo
