Sounds like it is probably hanging in sbp2 while it is trying to logout.
Perhaps you can turn on spinlock debug to see if there is a deadlock
somewhere? Check wstat for the knodemgrd process aswell, see what it is
waiting for.
On Sat, Jul 23, 2005 at 09:58:18PM +0200, Stefan Richter wrote:
> I wr
On 7/26/05, Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 25, 2005 at 11:02:39AM +0900, Rajat Jain wrote:
> > I'm using Kernel 2.6.9 and am having a Qlogic QLE2362 FC-HBA in my
> > system. I selected all the Qlogic SCSI drivers while buiding the
> > kernel. Now the problem is that every time I r
On Tue, 26 Jul 2005 00:21:50 +0200 Pierre Ossman wrote:
> randy_dunlap wrote:
>
> >
> >
> >That's a highmem bug. IIRC, Guennadi said that highmem does not
> >(or may not) work correctly in this driver, so I should have
> >asked you to test with HIGHMEM disabled so that the other bug
> >can be
On Mon, Jul 25, 2005 at 11:02:39AM +0900, Rajat Jain wrote:
> I'm using Kernel 2.6.9 and am having a Qlogic QLE2362 FC-HBA in my
> system. I selected all the Qlogic SCSI drivers while buiding the
> kernel. Now the problem is that every time I reboot, I have to
> MANUALLY modprobe the qla2322.ko mod
randy_dunlap wrote:
>
>
>That's a highmem bug. IIRC, Guennadi said that highmem does not
>(or may not) work correctly in this driver, so I should have
>asked you to test with HIGHMEM disabled so that the other bug
>can be addressed.
>
>
>
I have now tried 2.6.12{,.1,.2} and only 2.6.12.2 bre
These endian fix's have already been submitted long ago.
Try a newer kernel, such as 2.6.13-rc3.
Thankyou,
Eric Moore
LSI Logic
On Monday, July 25, 2005 3:48 PM, Mark Bellon wrote:
>
>
> A PPC 970 kernel with the MPT FUSION driver configured in would cause
> the kernel to panic. The problem o
A PPC 970 kernel with the MPT FUSION driver configured in would cause
the kernel to panic. The problem occurs because of some apparently
incorrect logic dealing with the cpu_to_le* and le*_to_cpu routines.
Patch is attached. Comments?
mark
Index: linux-2.6.10/drivers/message/fusion/mptbase.
mptscsih will cast a sector_t to an int which is causing cylinders
to be zero in some cases. This patch just sets cylinders to the
max value when the capacity is over the limit that the geometry
struct can support. With the patch if access a large Fibre Channel
disk using Emulex on a 64 bit system
Hello,
[EMAIL PROTECTED] wrote:
1. Repeatable Kernel Panic on Adaptec 2015S I20 device on bootup
2. I can get this to panic on every bootup, I have included the Kernel
boot output below.
3. Linux SCSI panic Adaptec 2015 bootup
4. Kernel version: 2.6.12.3
5. Kernel Output/Oops
Linux version 2.6.1
This is just a resend with Andries Brouwer ccd to make sure
I did not mess up any of the disk geometry stuff up.
On 32 bit archs with LBD set, setsize can cast a capacity so
that we result in heads==0 (capacity is sector_t which would
be a 64 bit value with LBD but it gets cast to a unsigned long
In article <[EMAIL PROTECTED]> you write:
>> >I'm a little confused here. Tape devices have variable sector sizes.
>> >I believe they're required to handle up to 64K in a unix environment.
>> >The drives I work on go up to 256k.
>> Tapes are different. The UDO drive that Johann was asking about is
Jay Denebeim wrote:
>On Mon, 25 Jul 2005, Steve McIntyre wrote:
>
>> Jay Denebeim wrote:
>>>
>>> I'm a little confused here. Tape devices have variable sector sizes.
>>> I believe they're required to handle up to 64K in a unix environment.
>>> The drives I work on go up to 256k.
>>
>> Tapes are di
> >I'm a little confused here. Tape devices have variable sector sizes.
> >I believe they're required to handle up to 64K in a unix environment.
> >The drives I work on go up to 256k.
> Tapes are different. The UDO drive that Johann was asking about is an
> optical _disk_ drive...
Hmm... would it
I just tested out your patch on the latest git tree and this patch
fixes the scsi tape hot unplug problems I was seeing as well.
Brian
Dailey, Nate wrote:
> I've attached patches against 2.6.13rc2. These are basically identical
> to my earlier patches, as I found that all issues I'd seen in earl
1. Repeatable Kernel Panic on Adaptec 2015S I20 device on bootup
2. I can get this to panic on every bootup, I have included the Kernel
boot output below.
3. Linux SCSI panic Adaptec 2015 bootup
4. Kernel version: 2.6.12.3
5. Kernel Output/Oops
Linux version 2.6.12.3 ([EMAIL PROTECTED]) (gcc v
On Mon, 25 Jul 2005, Steve McIntyre wrote:
Jay Denebeim wrote:
I've already got the FUSE driver (udofs-1.1-92.i386.rpm, based on
FUSE 1.4, is this current?!). It is nice for a standalone drive, but
we use a SCSI robotic changer in conjunction with an HSM system
(Legato DiskXtender 2.9) which ne
Jay Denebeim wrote:
>In article <[EMAIL PROTECTED]>,
>Johann Hanne <[EMAIL PROTECTED]> wrote:
>>Wow, an answer directly from Plasmon, that's nice. :-)
>
>>I've already got the FUSE driver (udofs-1.1-92.i386.rpm, based on
>>FUSE 1.4, is this current?!). It is nice for a standalone drive, but
>>we us
In article <[EMAIL PROTECTED]>,
Johann Hanne <[EMAIL PROTECTED]> wrote:
>Wow, an answer directly from Plasmon, that's nice. :-)
>I've already got the FUSE driver (udofs-1.1-92.i386.rpm, based on
>FUSE 1.4, is this current?!). It is nice for a standalone drive, but
>we use a SCSI robotic changer in
James:
This patch (as541) adds a missing check for an error return code from
scsi_sysfs_add_sdev. This resolves entry #4863 in the OSDL bugzilla.
Although in that bug report the failure occurred because of a confusion
over scanning vs. rescanning, in general add_sdev can fail for a number of
On Mon, 2005-07-25 at 08:46 -0400, Hammer, Jack wrote:
> I am resubmitting the 2.6 kernel patch for the Version 7.12.02 ips
> driver.
> I have eliminated a couple of inappropriate changes pointed out by
> Arjan.
>
> Signed-off-by: Jack Hammer <[EMAIL PROTECTED]>
>
> --- a/drivers/scsi/ips.c
I am resubmitting the 2.6 kernel patch for the Version 7.12.02 ips
driver.
I have eliminated a couple of inappropriate changes pointed out by
Arjan.
Signed-off-by: Jack Hammer <[EMAIL PROTECTED]>
--- a/drivers/scsi/ips.cTue Jul 19 13:15:24 2005
+++ b/drivers/scsi/ips.cTue Jul 19
On Mon, 2005-07-25 at 10:30 +0200, Hannes Reinecke wrote:
> it appears that the fallback sequence in
> scsi_transport_spi.c:spi_dv_retrain()
> is somewhat incorrect.
>
> According to SPI-3 (spi3r14, actually), the flags DT, IU, and QAS can be
> set in the following order of precedence (Table 55, p
Hi James,
it appears that the fallback sequence in
scsi_transport_spi.c:spi_dv_retrain()
is somewhat incorrect.
According to SPI-3 (spi3r14, actually), the flags DT, IU, and QAS can be
set in the following order of precedence (Table 55, p 155):
- DT
- IU
- QAS
This implies that for QAS DT and IU
James Bottomley wrote:
> On Fri, 2005-07-22 at 16:40 +0200, Hannes Reinecke wrote:
>>I've finished the update of aic79xx to make use of the
>>scsi_transport_spi infrastructure.
>>The first patch is actually jgarzik's one, with some additions to make
>>it work :-)
>>The second patch is the integrati
lists
-
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.kernel.org/majordomo-info.html
help
-
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.kernel.org/majordomo-info.html
26 matches
Mail list logo
