Re: can't boot 2.6.13

On Thu, Sep 08 2005, Miller, Mike (OS Dev) wrote: > Thanks, Eric. > Anyone have any ideas why my cciss based system won't boot? Hmm I thought Eric's suggestion was quite good, it bit me on a tiger as well (you have to set _SPI or _FCI variant of the driver now). I see no CISS detection at all, if

Re: [PATCH 1/5] SCSI scanning and removal fixes

On 09/08/05 16:15, James Bottomley wrote: > On Thu, 2005-09-08 at 14:58 -0400, Alan Stern wrote: > >>On Thu, 8 Sep 2005, James Bottomley wrote: >> >>>Actually, no, that's why we have the parallel EH states ... let me put >>>in the events that trigger state transitions so you can see what >>>happen

Re: [PATCH 1/5] SCSI scanning and removal fixes

On 09/08/05 14:36, Alan Stern wrote: > On Thu, 8 Sep 2005, Luben Tuikov wrote: > > >>>No. There are only two reset mechanisms available for USB Mass Storage. >> >>I see. >> >> >>>One is a class-specific reset command (which usb-storage issues when asked >>>to do a device reset), >> >>So as fa

RE: can't boot 2.6.13

Thanks, Eric. Anyone have any ideas why my cciss based system won't boot? mikem > -Original Message- > From: Moore, Eric Dean [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 08, 2005 5:52 PM > To: Miller, Mike (OS Dev); linux-kernel@vger.kernel.org; > linux-scsi@vger.kernel.org >

RE: can't boot 2.6.13

On Thursday, September 08, 2005 3:19 PM, Mike Miller(HP) wrote: > I am not able to boot the 2.6.13 version of the kernel. I've > tried different systems, tried downloading again, still > nothing. Here's the last thing I see from the serial port: > > md: Autodetecting RAID arrays. > md: autorun .

can't boot 2.6.13

I am not able to boot the 2.6.13 version of the kernel. I've tried different systems, tried downloading again, still nothing. Here's the last thing I see from the serial port: md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. RAMDISK: Compressed image found at block 0 input: A

[PATCH 6/8] aacraid: initialization timeout

Received from Mark Salyzyn from Adaptec. In the rare instances where the adapter, or the motherboard, is misbehaving; driver initialization or shutdown becomes problematic. By introducing a 3 minute timeout on the first interrupt driven command during initialization, or the issuance of the adapter

[PATCH 5/8] aacraid: error return checking

Received from Mark Salyzyn from Adaptec This patch adds some additional error return checking and error return value propagation during initialization. Also, the deprecation of pci_module_init with pci_register_driver along with the change in return values. Applies to the scsi-misc-2.6 git tree.

[PATCH 8/8] aacraid: remove aac_insert_entry

Received from Mark Salyzyn from Adaptec. High Priority Queues have *never* been used in the entire history of the aac based adapters. Associated with this, aac_insert_entry can be removed, SavedIrql can be removed & padding variable can be removed. With the movement of SavedIrql out & replaced wit

[PATCH 7/8] aacraid: fib size math fix

Received from Mark Salyzyn from Adaptec. The size of the command packet's scatter gather list maximum size was miscalculated in the low range leading to the driver initialization limiting the maximum i/o size that could go to the Adapter. There were no negative operational side effects resulting f

[PATCH 3/8] aacraid: handle AIF hotplug events

Received from Mark Salyzyn from Adaptec. Hotplug sniffs the AIFs (events) from the adapter and if a container change resulting in the device going offline (container zero), online (container zero completed) or changing capacity (morph) it will take actions by calling the appropriate API. Applies

[PATCH 2/8] aacraid: AIF preallocation

Recevied from Mark Salyzyn from Adaptec. Aif pre-allocation is used to pull the kmalloc outside of the locks. Applies to the scsi-misc-2.6 git tree. Signed-off-by: Mark Haverkamp <[EMAIL PROTECTED]> Index: scsi-misc-aac-2/drivers/scsi/aacraid/commsup.c =

[PATCH 4/8] aacraid: add name to driver template

Received from Mark Salyzyn from Adaptec. This permits the system log to report the Adapter's branded name rather than the generic 'AAC' that it currently reports. Applies to the scsi-misc-2.6 git tree. Signed-off-by: Mark Haverkamp <[EMAIL PROTECTED]> Index: scsi-misc-aac-2/drivers/scsi/aacrai

[PATCH 0/8] aacraid driver updates

The following 8 patches contain various aacraid driver updates described in each mail. Patches apply to the latest scsi-misc-2.6 git tree. -- Mark Haverkamp <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]

Re: [PATCH] SCSI core: fix leakage of scsi_cmnd's

On Thu, 8 Sep 2005, James Bottomley wrote: > Sigh, I might have guessed we'd have a leak somewhere ... > > Is not a better way to fix this actually to have the > scsi_requeue_command put the command and reset req->special to NULL? > That way the command gets reprepared as well and the prep fn ass

[PATCH 1/8] aacraid: Greater than 2TB capacity support

Received from Mark Salyzyn from Adaptec. Greater than 2TB capacity patch. There are a few adapters that are capable of creating devices with this large of a capacity, but now that we have the large fib support in, the management applications will be capable of generating them. The problem is, on

Re: [Linux-usb-users] Possible bug in usb storage (2.6.11 kernel)

On Thu, Sep 08, 2005 at 02:28:09PM -0600, Jim Ramsay wrote: > On 9/8/05, Jim Ramsay <[EMAIL PROTECTED]> wrote: > > On 9/8/05, Matthew Dharm <[EMAIL PROTECTED]> wrote: > > > On Thu, Sep 08, 2005 at 11:14:36AM -0600, Jim Ramsay wrote: > > > > I think I have found a possible bug: > > > > [...] > > > >

Re: [Linux-usb-users] Possible bug in usb storage (2.6.11 kernel)

On Thu, 8 Sep 2005, Jim Ramsay wrote: > More information: > > The error only occurrs during device sensing when the > srb->request_buffer is assigned as follows, by usb/storage/transport.c > in the routine usb_stor_invoke_transport: > > old_request_buffer = srb->request_buffer; > srb->request_bu

Re: [Linux-usb-users] Possible bug in usb storage (2.6.11 kernel)

On 9/8/05, Jim Ramsay <[EMAIL PROTECTED]> wrote: > On 9/8/05, Matthew Dharm <[EMAIL PROTECTED]> wrote: > > On Thu, Sep 08, 2005 at 11:14:36AM -0600, Jim Ramsay wrote: > > > I think I have found a possible bug: > > > [...] > > > I suppose the scsi code could be changed to guarantee that > > > srb->r

Re: [PATCH 1/5] SCSI scanning and removal fixes

On Thu, 2005-09-08 at 14:58 -0400, Alan Stern wrote: > On Thu, 8 Sep 2005, James Bottomley wrote: > > Actually, no, that's why we have the parallel EH states ... let me put > > in the events that trigger state transitions so you can see what > > happens: > > > > > > EH thread finishes > >

[PATCH 1/1][BUG] undefined symbol in legacy megaraid driver on 2. 6.12-mm1

Hi, I've created a patch to address "legacy megaraid driver compilation error on 2.6.12-mm1 kernel. Please take this patch and let me know for any further concern. Thank you, Seokmann Sign-off by: Seokmann JU <[EMAIL PROTECTED]> --- diff -Naur old/drivers/scsi/megaraid.c new/drivers/scsi/megara

RE: legacy megaraid driver bug in mm-series

Hi, On Thursday, September 08, 2005 3:01 PM, Ju, Seokmann wrote: > I've tried and it works fine. > I'm not sure where the problem is related to compilation. > Please provide more details. My applogize to all for confusion. There is an issue on compiling legacy megaraid driver on 2.6.12-mm1 kernel

Re: [PATCH] move iscsi to a better place in Kconfig

James Bottomley wrote: Now it looks like we'll have multiple users of the iscsi transport class, the iscsi initiator shouldn't really be a dependency of it. This patch moves iscsi to being an initiator in its own right which selects the transport attributes. I think the reason it was a depende

Re: [PATCH] iscsi_tcp: make iscsi compile again after recent netlink changes

James Bottomley wrote: netlink_kernel_create now has two new arguments; the module (which is easy) and the number of groups, which I arbitrarily set to one. Thanks. Are you going to apply this to scsi-misc? We are building a patchset for fixes to send this weekend hopefully so we can take the

Re: [PATCH 1/5] SCSI scanning and removal fixes

On Thu, 8 Sep 2005, James Bottomley wrote: > Actually, no, that's why we have the parallel EH states ... let me put > in the events that trigger state transitions so you can see what > happens: > > > EH thread finishes > <--- > > EH thread begins >

Re: [PATCH 1/5] SCSI scanning and removal fixes

On Thu, 8 Sep 2005, Luben Tuikov wrote: > > No. There are only two reset mechanisms available for USB Mass Storage. > > I see. > > > One is a class-specific reset command (which usb-storage issues when asked > > to do a device reset), > > So as far as I can see it sends a reset on the wire

Re: [PATCH] SCSI core: fix leakage of scsi_cmnd's

On Thu, 2005-09-08 at 12:44 -0400, Alan Stern wrote: > You _are_ missing something: scsi_requeue_command turns off the > REQ_DONTPREP flag before calling blk_requeue_request. So requeued > requests do indeed get re-prepped. This is needed for allocating > scatter-gather lists and so on; the origi

Re: [PATCH] SCSI core: fix leakage of scsi_cmnd's

On Thu, 8 Sep 2005, James Bottomley wrote: > > The SCSI core has a problem with leakage of scsi_cmnd structs. It occurs > > when a request is requeued; the request keeps its associated scsi_cmnd so > > that the core doesn't need to assign a new one. However, the routines > > that read the device

Re: FW: [Fwd: Re: [PATCH scsi-misc 2/2] megaraid_sas: LSI Logic MegaR AID SAS RA ID D river]

On Tue, Sep 06, 2005 at 03:30:33PM +0200, '[EMAIL PROTECTED]' wrote: > It's still wrapped, unfortunately. Let's retry as an attachment. > Anyway, I think we can put the patch in now. I have a few more really > small things that I'd like to address, I will submit patches as soon > as I have a code

Re: [PATCH 1/5] SCSI scanning and removal fixes

On Thu, 2005-09-08 at 11:59 -0400, Alan Stern wrote: > I don't understand your reasoning. With your new system, you end up with > two threads doing this: > > Removal thread Error handler thread > - --- >

Re: [PATCH 1/5] SCSI scanning and removal fixes

On Wed, 7 Sep 2005, James Bottomley wrote: > Actually, alloc_target is properly guarded so it doesn't need the scan > mutex. It might be nice to update the SDEV_ state model to include a > "scanning" state, that way we could properly guard the sdev_alloc as > well and dump the scan mutex ... that

Re: [PATCH 1/5] SCSI scanning and removal fixes

On 09/08/05 11:19, Alan Stern wrote: > On Wed, 7 Sep 2005, Luben Tuikov wrote: > > >>Is it possible to implement LU Reset TMF for USB storage devices? >>If so, then you do not need to do a "bus reset". > > > Sorry, I don't know that acronym. What is TMF? Good morning Alan, I meant Task Manag

Re: [PATCH 1/5] SCSI scanning and removal fixes

On Wed, 7 Sep 2005, James Bottomley wrote: > I agree (about the deadlocks). However, as things stand RECOVERY is a > state in the model and the model can only be in a single state. If you > permit the transition, and recovery is going on in parallel with > removal, they'll race to set the final

Re: [PATCH] SCSI core: fix leakage of scsi_cmnd's

> The SCSI core has a problem with leakage of scsi_cmnd structs. It occurs > when a request is requeued; the request keeps its associated scsi_cmnd so > that the core doesn't need to assign a new one. However, the routines > that read the device queue sometimes delete entries without bothering to

Re: [PATCH 1/2] fix EH thread teardown

Christoph Hellwig wrote: >As Rolf Eike Beer noted we might not actually get to the >kthread_should_stop() because we are waiting in the semaphore forever. >I didn't get a rmmod hang because of this, but my instrumentation showed >the thread defitiyly didn't exit. > >So make sure to wake the EH thre

Re: [PATCH 1/5] SCSI scanning and removal fixes

On Wed, 7 Sep 2005, Stefan Richter wrote: > usb-storage implements scsi_mod bus reset as USB port reset. This > affects only the failing device. Correct, but you're forgetting that in USB a single device can contain more than one "interface", and drivers bind to interfaces, not devices. Doing a

[PATCH] iscsi_tcp: make iscsi compile again after recent netlink changes

netlink_kernel_create now has two new arguments; the module (which is easy) and the number of groups, which I arbitrarily set to one. James diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c --- a/drivers/scsi/scsi_transport_iscsi.c +++ b/drivers/scsi/scsi_tra

[PATCH] SCSI core: fix leakage of scsi_cmnd's

[This message is completely separate from the concurrent discussion of earlier patches, as542-as546; this patch fixes a different problem.] James: The SCSI core has a problem with leakage of scsi_cmnd structs. It occurs when a request is requeued; the request keeps its associated scsi_cmnd so t

Re: Fw: legacy megaraid driver bug in mm-series

On Wed, Sep 07, 2005 at 02:52:58AM -0700, Andrew Morton wrote: > > > Begin forwarded message: This looks preyyu much like a breakage because we're now always sending S/G list down the scsi layer. The patch below brings over code to handle that case from the megaraid_mbox driver. It's still wro

RE: MegaRAID 511 i4 IDE

> Is there any hope that just adding the entry to the PCI table would make this work? Or would the 511 need special-case code? The 511 should work just fine. It looks just like a MegaRAID SCSI controller. Gerry -Original Message- From: Kenneth Porter [mailto:[EMAIL PROTECTED] Sent: T

Re: [SCSI] qla1280: endianess annotations

On Wed, Sep 07, 2005 at 10:13:21PM -0400, Jeff Garzik wrote: > Linux Kernel Mailing List wrote: > >diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c > >--- a/drivers/scsi/qla1280.c > >+++ b/drivers/scsi/qla1280.c > >@@ -1546,7 +1546,7 @@ qla1280_return_status(struct response * > > i

MegaRAID 511 i4 IDE

Alas, I've got one of these critters, and I don't see it listed in megaraid_mbox.c. (The subsystem device is 0x0511.) The I4_133 (0x0522) is listed, though. Is there any hope that just adding the entry to the PCI table would make this work? Or would the 511 need special-case code?

Re: legacy megaraid driver bug in mm-series

Andrew Morton wrote: "Ju, Seokmann" <[EMAIL PROTECTED]> wrote: Hi Andrew, On Wednesday, September 07, 2005 5:53 AM, Andrew Morton forwarded: 2.6.11-mm1: works 2.6.11-mm4: works 2.6.12-rc5-mm1: will not compile 2.6.12-rc6-mm1: works 2.6.12-mm1: will not compile megaraid driv