Hi!
> How do we "know" when little memory is available?
Kernel already scales its hash tables according to total RAM
available, perhaps you can use similar mechanism?
> Other suggestion which came about was to parse the kernel command line
> and look for "elfcorehdr=". Is this ok? Is kernel comm
On Sun, Sep 30 2007 at 23:26 +0200, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 30, 2007 at 10:09:20PM +0200, Boaz Harrosh wrote:
>> - Return the interrupting host and not it's index.
>> NULL if intr is not by gdth.
>> - fix calling site
>>
>> FIXME:
>>Why are we loopin
Boaz Harrosh wrote:
> On Sun, Sep 30 2007 at 23:26 +0200, Christoph Hellwig <[EMAIL PROTECTED]>
> wrote:
>> On Sun, Sep 30, 2007 at 10:09:20PM +0200, Boaz Harrosh wrote:
>>> - Return the interrupting host and not it's index.
>>> NULL if intr is not by gdth.
>>> - fix calling site
>>>
>>>
James, what is the upstream status of my two aic94xx bug fixes?
Have they been sent to Linus yet?
Since you seem M.I.A., I'll send them upstream if I do not hear from you
today.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to
Pavel Machek sez:
> > Other suggestion which came about was to parse the kernel
> > command line and look for "elfcorehdr=". Is this ok? Is
> > kernel command line visible to the SCSI drivers?
> Kernel command line probably is visible, but I'd recommend
> against doing that.
Probably just as pregn
On Tue, 2007-10-02 at 08:29 -0400, Jeff Garzik wrote:
> James, what is the upstream status of my two aic94xx bug fixes?
>
> Have they been sent to Linus yet?
>
> Since you seem M.I.A., I'll send them upstream if I do not hear from you
> today.
They're hardly -rc8 critical bug fixes, since no-on
James Bottomley wrote:
On Tue, 2007-10-02 at 08:29 -0400, Jeff Garzik wrote:
James, what is the upstream status of my two aic94xx bug fixes?
Have they been sent to Linus yet?
Since you seem M.I.A., I'll send them upstream if I do not hear from you
today.
They're hardly -rc8 critical bug fix
On Mon, 2007-10-01 at 21:22 -0700, Greg KH wrote:
> On Mon, Oct 01, 2007 at 07:39:02PM -0600, Matthew Wilcox wrote:
> > On Mon, Oct 01, 2007 at 07:36:10PM -0400, James Bottomley wrote:
> > > One possibility we could do is to add a
> > >
> > > struct dma_device {
> > > struct device dev;
> > >
On Tue, 2007-10-02 at 10:35 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > On Tue, 2007-10-02 at 08:29 -0400, Jeff Garzik wrote:
> >> James, what is the upstream status of my two aic94xx bug fixes?
> >>
> >> Have they been sent to Linus yet?
> >>
> >> Since you seem M.I.A., I'll send them u
James Bottomley wrote:
On Tue, 2007-10-02 at 10:35 -0400, Jeff Garzik wrote:
James Bottomley wrote:
On Tue, 2007-10-02 at 08:29 -0400, Jeff Garzik wrote:
James, what is the upstream status of my two aic94xx bug fixes?
Have they been sent to Linus yet?
Since you seem M.I.A., I'll send them up
On Tue, 2007-10-02 at 10:48 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > On Tue, 2007-10-02 at 10:35 -0400, Jeff Garzik wrote:
> >> James Bottomley wrote:
> >>> On Tue, 2007-10-02 at 08:29 -0400, Jeff Garzik wrote:
> James, what is the upstream status of my two aic94xx bug fixes?
> >
On 10/2/07, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-01 at 21:22 -0700, Greg KH wrote:
> > On Mon, Oct 01, 2007 at 07:39:02PM -0600, Matthew Wilcox wrote:
> > > On Mon, Oct 01, 2007 at 07:36:10PM -0400, James Bottomley wrote:
> > > > One possibility we could do is to add a
> > >
On Tue, 2007-10-02 at 17:02 +0200, Kay Sievers wrote:
> On 10/2/07, James Bottomley <[EMAIL PROTECTED]> wrote:
> > On Mon, 2007-10-01 at 21:22 -0700, Greg KH wrote:
> > > On Mon, Oct 01, 2007 at 07:39:02PM -0600, Matthew Wilcox wrote:
> > > > On Mon, Oct 01, 2007 at 07:36:10PM -0400, James Bottomle
On Tue, 2007-10-02 at 10:05 -0500, James Bottomley wrote:
> On Tue, 2007-10-02 at 17:02 +0200, Kay Sievers wrote:
> > On 10/2/07, James Bottomley <[EMAIL PROTECTED]> wrote:
> > > On Mon, 2007-10-01 at 21:22 -0700, Greg KH wrote:
> > > > On Mon, Oct 01, 2007 at 07:39:02PM -0600, Matthew Wilcox wrot
On Tue, 2007-10-02 at 17:10 +0200, Kay Sievers wrote:
> On Tue, 2007-10-02 at 10:05 -0500, James Bottomley wrote:
> > On Tue, 2007-10-02 at 17:02 +0200, Kay Sievers wrote:
> > > On 10/2/07, James Bottomley <[EMAIL PROTECTED]> wrote:
> > > > On Mon, 2007-10-01 at 21:22 -0700, Greg KH wrote:
> > > >
On 10/2/07, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-10-02 at 17:10 +0200, Kay Sievers wrote:
> > On Tue, 2007-10-02 at 10:05 -0500, James Bottomley wrote:
> > > On Tue, 2007-10-02 at 17:02 +0200, Kay Sievers wrote:
> > > > On 10/2/07, James Bottomley <[EMAIL PROTECTED]> wrote:
> >
On Tue, Oct 02, 2007 at 05:23:39PM +0200, Kay Sievers wrote:
> Just looking at the number of devices, it seems that allocating it
> dynamically would be the better deal. We allocate the name of every
> kobject dynamically today, so I guess it's fine to do that with the
> DMA data too.
But we don't
Using dev_printk to implement shost_printk leads to somewhat lacklustre
results:
host2: SCSI BUS has been reset
scsi2 : sym-2.2.3
By reimplementing shost_printk directly on top of printk, we can get
the more pleasing:
scsi 0: SCSI BUS has been reset
scsi 0: sym-2.2.3
It fits in well with
scs
On Tue, Oct 02, 2007 at 09:25:34AM -0600, Matthew Wilcox wrote:
> On Tue, Oct 02, 2007 at 05:23:39PM +0200, Kay Sievers wrote:
> > Just looking at the number of devices, it seems that allocating it
> > dynamically would be the better deal. We allocate the name of every
> > kobject dynamically today
I should have CC'ed this to linux-scsi.
--
Burton Windle [EMAIL PROTECTED]
-- Forwarded message --
Date: Tue, 2 Oct 2007 12:48:26 -0400 (EDT)
From: Burton Windle <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: 2.6.23-rc9 boot failure (megaraid?)
2.
James Bottomley wrote:
So I know, beyond a shadow of a doubt, that there are no non-x86 users
of this.
If you don't get the DMA direction right on x86, swiotlb will corrupt
your data.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a mes
The SCSI maintainer wants to wait until 2.6.25 for this obvious data
corruption fix.
I vehemently disagree.
Please pull from 'sas-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git sas-fixes
to receive the following updates:
drivers/scsi/aic94xx/aic94xx_task.c
On Tue, 2007-10-02 at 13:11 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > So I know, beyond a shadow of a doubt, that there are no non-x86 users
> > of this.
>
> If you don't get the DMA direction right on x86, swiotlb will corrupt
> your data.
Er, this is a fully 64 bit device: it shou
Cc's added, the complete bug report is at
http://lkml.org/lkml/2007/10/2/243
On Tue, Oct 02, 2007 at 12:48:26PM -0400, Burton Windle wrote:
> 2.6.23-rc9 fails to boot for me; 2.6.22.9 works fine.
>
> System is a Dell Poweredge with PERC 2/DC with RAID1 volume.
>...
Thanks for your report.
Diff
On Tue, Oct 02 2007 at 19:21 +0200, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> The SCSI maintainer wants to wait until 2.6.25 for this obvious data
> corruption fix.
>
This is a miss communication
Jeff said: "for 2.6.24"
James understood: "for 2.6.23", and said: "NO I'll Q it for 2.6.24"
Jeff und
Boaz Harrosh wrote:
On Tue, Oct 02 2007 at 19:21 +0200, Jeff Garzik <[EMAIL PROTECTED]> wrote:
The SCSI maintainer wants to wait until 2.6.25 for this obvious data
corruption fix.
This is a miss communication
Jeff said: "for 2.6.24"
James understood: "for 2.6.23", and said: "NO I'll Q it f
On Tue, 2 Oct 2007, Adrian Bunk wrote:
Cc's added, the complete bug report is at
http://lkml.org/lkml/2007/10/2/243
On Tue, Oct 02, 2007 at 12:48:26PM -0400, Burton Windle wrote:
2.6.23-rc9 fails to boot for me; 2.6.22.9 works fine.
System is a Dell Poweredge with PERC 2/DC with RAID1 volume
On Tue, 2007-10-02 at 13:21 -0400, Jeff Garzik wrote:
> The SCSI maintainer wants to wait until 2.6.25 for this obvious data
That's 2.6.24 ... and that's not what I said. I said I wanted to take
it via scsi-misc into 2.6.24 and then take it via the stable tree for
2.6.23.x
> corruption fix.
>
>
Hi,
I am using 2.6.23-rc9 with pata_sis. `modprobe -r sd_mod`, which I ran
from initramfs, caused all my disks to spindown - sd even told me so.
I recall there has been talk a while back about whether to spin down
disks on shutdown or not, but I do not think it touched the removal of
sd_mod,
James Bottomley wrote:
Sure, I'll state my case: This is a bug, but it has no affected users,
nor will it because the aic94xx doesn't work on non-x86 architectures by
reason of other longstanding bugs (and TODEVICE/FROMDEVICE only matters
False. It fails to work on _some_ non-x86 platforms.
On Tue, 2007-10-02 at 14:53 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > Sure, I'll state my case: This is a bug, but it has no affected users,
> > nor will it because the aic94xx doesn't work on non-x86 architectures by
> > reason of other longstanding bugs (and TODEVICE/FROMDEVICE only
On Tue, 2007-10-02 at 09:45 -0600, Matthew Wilcox wrote:
> Using dev_printk to implement shost_printk leads to somewhat lacklustre
> results:
>
> host2: SCSI BUS has been reset
> scsi2 : sym-2.2.3
>
> By reimplementing shost_printk directly on top of printk, we can get
> the more pleasing:
>
>
On Tuesday, 2 October 2007 20:46, Burton Windle wrote:
> On Tue, 2 Oct 2007, Adrian Bunk wrote:
>
> > Cc's added, the complete bug report is at
> > http://lkml.org/lkml/2007/10/2/243
> >
> > On Tue, Oct 02, 2007 at 12:48:26PM -0400, Burton Windle wrote:
> >> 2.6.23-rc9 fails to boot for me; 2.6.2
Hi!
following is an attempted at unified patchset for the gdth driver.
They try to incorporate floating patches to gdth from:
Christoph Hellwig
Jeff Garzik
Matthew Wilcox
and Me Boaz Harrosh
They are done in the mindset of "likelihood of inducing breakage",
hence the need for testers. Christoph
On Tue, 2007-10-02 at 20:15 +0200, Adrian Bunk wrote:
> Cc's added, the complete bug report is at
> http://lkml.org/lkml/2007/10/2/243
>
> On Tue, Oct 02, 2007 at 12:48:26PM -0400, Burton Windle wrote:
> > 2.6.23-rc9 fails to boot for me; 2.6.22.9 works fine.
> >
> > System is a Dell Poweredge w
From: Matthew Wilcox <[EMAIL PROTECTED]>
Rather than having internal commands abuse scsi_done to call
gdth_scsi_done, have all the places that use to call scsi_done directly
call gdth_scsi_done, which now checks whether the command was internal,
and calls scsi_done if not.
Signed-off-by:
From: Matthew Wilcox <[EMAIL PROTECTED]>
The ->done member was being used to mark commands as being internal.
I decided to put a magic number in ->underflow instead. I believe this
to be safe as no current user of ->underflow has any of the bottom 9
bits set.
Signed-off-by: Matthew Wilcox <[EMAI
From: Christoph Hellwig <[EMAIL PROTECTED]>
(note: this is ontop of Jeff's pci cleanup patch)
Split out isa probing into a helper of it's own. Error handling is
cleaned up, but errors are not propagated yet. Also enclose the isa
probe under the proper CONFIG_ISA symbol instead of the !IA64 hack
From: Christoph Hellwig <[EMAIL PROTECTED]>
Split eisa probing into it's own helper, and do proper error unwinding.
Protect EISA probind by the proper CONFIG_EISA symbol.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/gdth.c
From: Christoph Hellwig <[EMAIL PROTECTED]>
Split out per-device pci probing and put it under proper CONFIG_PCI.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/gdth.c | 312 +++
From: Jeff Garzik <[EMAIL PROTECTED]>
* Remove in-source changelog. It's archived permanently in git and
various kernel archives, and changelogs should exist purely in git.
* Remove 2.4.x kernel support. It is an active obstacle to
modernizing this driver, at this point. This inclu
From: Jeff Garzik <[EMAIL PROTECTED]>
They are direct equivalents to {read,write}[bwl].
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/gdth.c | 313 +--
1 files changed, 153 insert
From: Jeff Garzik <[EMAIL PROTECTED]>
* shuffle scsi_host_template members such that they appear in the
order in which they are defined in the header. this makes is easier
to verify when initializers are missing members.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by:
From: Christoph Hellwig <[EMAIL PROTECTED]>
The virt_ctr option allows to register a new scsi_host for each bus
on the raid controller. This non-default option makes no sense with
the current scsi code and prevents cleaning up the host registration,
so remove it.
Signed-off-by: Christoph Hellwig
- gdth_get_status() returns a single device interrupt IStatus
- gdth_interrupt split to __gdth_interrupt() that receives
flags if is called from gdth_wait().
- Use dev_id passed from kernel and do not loop on all
controllers.
- gdth_wait(), get read of all global variables and call
From: Christoph Hellwig <[EMAIL PROTECTED]>
- Use scsi_add_host and friends and track instances ourselves. And
generally modernize the driver's structure.
- TODO: Next we can remove the controller table
- TODO: Fix use of deprecated pci_find_device()
Signed-off-by: Christoph Hellwig <[
- Places like Initialization and Reset that Just loop on all devices can
use the link list with the list_for_each_entry macro.
But the io_ctrl from user mode now suffers performance-wise because
code has to do a sequential search for the requested host number.
I have isolated thi
- scsi_cmnd and specifically ->SCp of, where heavily abused
with internal meaning members and flags. So introduce a new
struct gdth_cmndinfo, put it on ->host_scribble and define a
gdth_cmnd_priv() accessor to retrieve it from a scsi_cmnd.
- The structure now holds two members:
- Cleanup the rest of the scsi_cmnd->SCp members and move them
to gdth_cmndinfo:
SCp.this_residual=> priority
SCp.buffers_residual => timeout
SCp.Status => status and dma_dir
SCp.Message => info
SCp.have_data_in => volatile wait_for_completion
gdth_execute() will issue an internal, none scsi-standard commands
onto __gdth_queuecommand(). Since it is not recommended to set
struct scsi_cmnd IO members in llds, gdth now uses internal IO
members for IO. In the case of gdth_execute() these members will be
set properly. In case the c
On Tue, Oct 02 2007 at 22:05 +0200, Boaz Harrosh <[EMAIL PROTECTED]> wrote:
> Hi!
>
> following is an attempted at unified patchset for the gdth driver.
>
> They try to incorporate floating patches to gdth from:
> Christoph Hellwig
> Jeff Garzik
> Matthew Wilcox
> and Me Boaz Harrosh
>
I have m
From: Andrew Morton <[EMAIL PROTECTED]>
drivers/scsi/arcmsr/arcmsr_hba.c:129: error: 'arcmsr_pci_error_detected'
undeclared here (not in a function)
drivers/scsi/arcmsr/arcmsr_hba.c:130: error: 'arcmsr_pci_slot_reset' undeclared
here (not in a function)
Cc: James Bottomley <[EMAIL PROTECTED]>
S
From: "Robert P. J. Day" <[EMAIL PROTECTED]>
Remove the useless references to the obsolete MODULE_PARM macro.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/scsi/ibmmca.c |7 ---
1 file changed, 7 deletions(-)
diff -puN
From: Jesper Juhl <[EMAIL PROTECTED]>
The Coverity checker noticed that we have a potential NULL pointer
deref in drivers/scsi/aic7xxx/aic7xxx_core.c::ahc_print_register().
This patch handles it by adding the same test against NULL that is
used elsewhere in the same function.
Signed-off-by: Jespe
From: Gabriel C <[EMAIL PROTECTED]>
I get this warnings on current git when CONFIG_PCI is not set :
drivers/scsi/fdomain.c:390: warning: 'PCI_dev' defined but not used
drivers/scsi/fdomain.c:1768: warning: 'fdomain_pci_tbl' defined but not used
Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTE
From: Andrew Morton <[EMAIL PROTECTED]>
Fix this:
drivers/scsi/advansys.c: In function 'advansys_board_found':
drivers/scsi/advansys.c:16320: warning: format '%x' expects type 'unsigned
int', but argument 3 has type 'resource_size_t'
and clean the code up a little.
Cc: James Bottomley <[EMAIL
From: Kay Sievers <[EMAIL PROTECTED]>
This will send for a card reader slot (remove/add media):
UEVENT[1187091572.155884] change
/devices/pci:00/:00:1d.7/usb5/5-2/5-2:1.0/host7/target7:0:0/7:0:0:0
(scsi)
UEVENT[1187091572.162314] remove /block/sdb/sdb1 (block)
UEVENT[1187091572
From: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/scsi/pcmcia/nsp_cs.c | 159 +
drivers/scsi/pcmcia/nsp_cs.h |8 -
2 files changed, 5 insertions(+), 162 deletions(
From: Adrian Bunk <[EMAIL PROTECTED]>
The Coverity checker noted that we'll anyway Oops later when we ran into
this condition - and the error check didn't prevent that.
Considering that the error condition shouldn't be possible, and we are
not able to handle it easily, this patch simply removes t
drivers/message/fusion/mptctl.c: In function âmptctl_mpt_commandâ:
drivers/message/fusion/mptctl.c:1764: warning: âbufIn.lenâ may be used
uninitialized in this function
drivers/message/fusion/mptctl.c:1765: warning: âbufOut.lenâ may be used
uninitialized in this function
come becaus
From: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Add a notifier chain for SCSI asynchronous events. Add a notifier block
for events which should be sent to user space, and add support for the
MEDIA_CHANGE event, which would be used by a driver when new media has been
inserted.
Signed-off-by: Kr
From: "Darrick J. Wong" <[EMAIL PROTECTED]>
It appears that the LSI SAS 1064E chip needs to be reset after a
suspend/resume cycle before the driver attempts further communications with
the chip. Without this patch, resuming the chip results in this error
message being printed repeatedly and no mo
From: Adrian Bunk <[EMAIL PROTECTED]>
The Coverity checker spotted that we have already oops'ed if "cmd"
was NULL.
Since "cmd" being NULL doesn't seem to be possible at this point this
patch removes the NULL check.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMA
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
scsi/scsi_transport_iscsi.h uses struct mutex and struct list_head,
so while linux/mutex.h and linux/list.h seem to be pulled in indirectly
by one of the headers it includes, the right thing
is to include linux/mutex.h and linus/list.h directly.
Sign
From: Linas Vepstas <[EMAIL PROTECTED]>
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the Symbios SCSI device
driver. The patch has been tested, and appears to work well.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc:
From: Joe Korty <[EMAIL PROTECTED]>
Fix section mismatch in the Adaptec DPT SCSI Raid driver.
WARNING: vmlinux.o(.init.text+0x1fcd2): Section mismatch:
reference to .exit.text:adpt_exit (between 'adpt_init' and
'ahc_linux_init')
This warning is due to adaptec device detection calling th
From: Alan Stern <[EMAIL PROTECTED]>
Taken from http://bugzilla.kernel.org/show_bug.cgi?id=8904
An updated (by Albert, I assume) version of the fourteen-month-old patch here:
http://marc.info/?l=linux-kernel&m=115412002912837&w=2
Apparently fixes the bug described at
http://bugzilla.kernel.org/
From: Linas Vepstas <[EMAIL PROTECTED]>
Implement the so-called "first failure data capture" (FFDC) for the symbios
PCI error recovery. After a PCI error event is reported, the driver
requests that MMIO be enabled. Once enabled, it then reads and dumps
assorted status registers, and concludes by
On Tue, Oct 02, 2007 at 02:38:00PM -0700, [EMAIL PROTECTED] wrote:
> From: Linas Vepstas <[EMAIL PROTECTED]>
>
> Various PCI bus errors can be signaled by newer PCI controllers. This
> patch adds the PCI error recovery callbacks to the Symbios SCSI device
> driver. The patch has been tested, and
On Tue, Oct 02, 2007 at 02:38:08PM -0700, [EMAIL PROTECTED] wrote:
> From: Joe Korty <[EMAIL PROTECTED]>
>
> Fix section mismatch in the Adaptec DPT SCSI Raid driver.
Acked-by: Matthew Wilcox <[EMAIL PROTECTED]>
> Mathew: isn't a module exit routine a little too strong to be calling on the
> fai
On Tue, Oct 02, 2007 at 02:38:09PM -0700, [EMAIL PROTECTED] wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
>
> Fix this:
>
> drivers/scsi/advansys.c: In function 'advansys_board_found':
> drivers/scsi/advansys.c:16320: warning: format '%x' expects type 'unsigned
> int', but argument 3 has type
On Tue, Oct 02, 2007 at 02:38:11PM -0700, [EMAIL PROTECTED] wrote:
> drivers/message/fusion/mptctl.c: In function ???mptctl_mpt_command???:
Could we lose the UTF-8 garbage?
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in s
On Mon, Oct 01, 2007 at 07:27:30PM -0600, Matthew Wilcox wrote:
>
> Fine by me. Do you have the ability to produce failures on a whim on
> your platforms?
Yes, although it is very platform specific -- there are actually
transistors in the pci bridge chip, which actually short out lines,
and so
On Tue, 2007-10-02 at 14:37 -0700, [EMAIL PROTECTED] wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
>
> drivers/scsi/arcmsr/arcmsr_hba.c:129: error: 'arcmsr_pci_error_detected'
> undeclared here (not in a function)
> drivers/scsi/arcmsr/arcmsr_hba.c:130: error: 'arcmsr_pci_slot_reset'
> undecl
On Tue, 2007-10-02 at 14:38 -0700, [EMAIL PROTECTED] wrote:
> From: Jesper Juhl <[EMAIL PROTECTED]>
>
> The Coverity checker noticed that we have a potential NULL pointer
> deref in drivers/scsi/aic7xxx/aic7xxx_core.c::ahc_print_register().
> This patch handles it by adding the same test against N
On Tuesday, October 02, 2007 3:38 PM, Darrick J. Wong wrote:
>
> It appears that the LSI SAS 1064E chip needs to be reset after a
> suspend/resume cycle before the driver attempts further
> communications with
> the chip. Without this patch, resuming the chip results in this error
> message be
On Tue, Oct 02, 2007 at 04:51:48PM -0600, Moore, Eric wrote:
> I replied to this thread a couple times last week, and no response from
> Darrick. I doubt this is required becase the MESSAGE_UNIT_RESET is
> issued from inside mpt_do_ioc_recovery. I need some logs with debug
> enabled. Darrick
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Michael Reed wrote:
>
> > as having a unique WWN should be a product requirement, is an indicator of
> > a problem. Shouldn't the proper solution be to have the card repaired?
> > Arbitrarily assigning a WWN could mask or introduce other problems, in
On Tue, 02 Oct 2007 15:38:13 -0500
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-10-02 at 20:15 +0200, Adrian Bunk wrote:
> > Cc's added, the complete bug report is at
> > http://lkml.org/lkml/2007/10/2/243
> >
> > On Tue, Oct 02, 2007 at 12:48:26PM -0400, Burton Windle wrote:
> > >
Luben Tuikov wrote:
This still does not justify "let's generate it in the kernel".
Once an admin specifies to use an alternate WWN provision, the method
used to obtain that WWN is an implementation detail and irrelevant.
Jeff
-
To unsubscribe from this list: send the line "unsubscr
The driver was saving a scsi_device for each target, but wasn't doing
anything useful with them. Just delete the array.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/ad
The narrow board used two global structures to set up a command;
unfortunately they weren't locked, so with two boards in the machine,
one call to queuecommand could corrupt the data being used by the other
call to queuecommand.
Fix this by allocating asc_scsi_q on the stack (64 bytes) and using k
- Don't need to set ASC_HOST_IN_RESET any more
- Don't need to test scp->device->host for NULL -- if it's NULL, we
couldn't've been called.
- Use scmd_printk instead of ASC_PRINT
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c | 83 ---
The wide and narrow boards share identical handling of the return value,
except for some trivial error messages. Move the handling to the common
end of the function. Also move variable declarations to the arms of
the `if' that they're used in and delete some pointless comments.
Signed-off-by: Ma
It was only ever set; never tested, nor cleared.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index 52ea41d..5e6bcf2 100644
--- a/drivers/sc
Replace it with !ASC_NARROW_BOARD
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index 5e6bcf2..a5bb4e4 100644
--- a/drivers/scsi/advansys.
It's somewhat neater to make this a pointer to one of two tables
than initialising an array in the driver. Also delete the unused
AscSynIndexToPeriod and rename host_init_sdtr_index to min_sdtr_index
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c | 90 +++
The interrupt number was being stored in 4-5 different places, each with
its own type, rules and usage. Fix this by keeping an unsigned int in
the struct asc_board, and filling it in from the bus probe functions
(since it's different for each of the four bus types). In order to do
this, we have t
With the ASC and ADV libraries merged into the driver, there really is
no point in reporting their version numbers, or even trying to maintain
them.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c | 60 +++---
1 files changed
board->carrp is a duplicate of asc_dvc->carrier_buf, so cut out the
middle-man and assign directly to carrier_buf. Move orig_reqp to adv_dvc
too, since it's wide-board specific. Also eliminate an unnecessary BUG_ON
(we'll never get there with a NULL carrier_buf, and will crash if we do).
The bulk
This rather complex function boiled down to calling virt_to_bus().
Also get rid of some obsolete defines and variables that could never vary.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c | 73 ++-
1 files changed, 3 in
Replace ASC_VADDR_TO_U32 and ASC_U32_TO_VADDR with an auto-expanding
array that maps pointers to 32-bit IDs and back. One of the uses of
ASC_VADDR_TO_U32 was in error; it should have been using ADV_VADDR_TO_U32.
Also replace the use of virt_to_bus when setting the sense_address with
a call to dma
Convert the call to virt_to_bus() into a call to dma_map_single(). Some
architectures may require different DMA addresses for different devices,
so allocate one overrun buffer per host rather than one for all cards.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c |
The board lock was essentially identical with the host lock.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c | 21 +
1 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index 831823e.
It's always a mistake to have your own index of boards; just use the
scsi host number.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c | 236 ---
1 files changed, 100 insertions(+), 136 deletions(-)
diff --git a/drivers/s
There were two blocks of ASC_IERR definitions; one for narrow and one for
wide boards. Some of the same names were used (with the same values),
and some of the same values were used with different names. This could
only lead to confusion, so I unified them in one block of definitions
with no over
asc_board_t was simply a typedef for struct asc_board. ASC_BOARDP()
can be replaced by shost_priv() except in the ASC_STATS* macros which
rely on the cast; add an explicit cast there.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c | 132 ++-
Replace ASC_DBG{,1,2,3,4,5} with a single variadic macro ASC_DBG. As
suggested by Jeff Garzik, include DRV_NAME and __FUNCTION__ in the output.
Change all callers to no longer include the function name in the string.
Enabling ADVANSYS_DEBUG to test this feature shows a lot of other problems
that
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the parameters.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
- convert the statistics to not distinguish between single and sg xfers
- replace ASC_CEILING with DIV_ROUND_UP
- remove an obsolete
Change PortAddr to be an unsigned int instead of an unsigned short (IO
Port address are 24 bit on parisc). Fix a couple of printk argument
warnings. Remove the Kconfig marking as 'BROKEN'.
I haven't removed the #warning yet because virt_to_bus/bus_to_virt are
only eliminated for narrow boards.
1 - 100 of 125 matches
Mail list logo
