On Tue, 2005-03-08 at 18:08 -0500, Bagalkote, Sreenivas wrote:
>
> I will make this an instance parameter if the idea to reduce as many
> global variables as possible. But if the objection is because each
> adapter
> may have different value for variable, then it is indeed a global
> value.
> "is_
On Tue, Mar 08 2005, [EMAIL PROTECTED] wrote:
>
> Hello!
>
> We're seeing a null pointer dereference with certain IDE tape drives on
> 2.6.11 when we use it with ide-scsi (i686 architecture). The problem is
> that the scatter-gather pages aren't mapped to kernel virtual address
> space in idescs
From: Hanno Boeck <[EMAIL PROTECTED]>
I have a usb-cardreader here that needs some FORCELUN-entries in
scsi_devinfo.c.
lsusb says about the device:
Bus 001 Device 003: ID 0483:1307 SGS Thomson Microelectronics Cytronix 6in1
card reader
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25
I found the bus error, the trivial fix is below.
I don't know if this patch will work for others quite yet, since my kernel
has had some work done to slow interrupt handling. I intend to post that
patch soon.
On Tue, 8 Mar 2005, Brad Boyer wrote:
> I notice it got through all the device ident
> Kenn, my macs like your patch :-) Did it make it upstream?
Yes.
http://linux-scsi.bkbits.net:8080/scsi-misc-2.6/[EMAIL PROTECTED]
xrPCoj1REg?nav=index.html|[EMAIL PROTECTED]
Later,
Kenn
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [E
[EMAIL PROTECTED] wrote:
> So, is there a reason we aren't just starting the workq thread
> upon the first call to queue something to it ?
Don't you need to be at task level to create a workq thread?
-Brian
> -- james s
>
>
>>-Original Message-
>>From: Luben Tuikov [mailto:[EMAIL PROT
>> >
>> >> source "drivers/scsi/megaraid/Kconfig.megaraid"
>> >> +source "drivers/scsi/megaraid/Kconfig.megaraid_sas"
>> >>
>> >
>> >why a fully separate file and not add your ONE config option to
>> >Kconfig.megaraid instead ??
>> >
>>
>> Arjan, I didn't want to needlessly couple megaraid and
>>
>> I will make this an instance parameter if the idea to reduce as many
>> global variables as possible. But if the objection is because each
>> adapter
>> may have different value for variable, then it is indeed a global
>> value.
>> "is_dma64" - which is computed using the size of dma_addr_t
> . And since this is compile time
> system-wide property, I kept it as driver global.
that step I don't understand... why is it a global *VARIABLE* if it's
compile time system-wide property...
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [E
On Wed, Mar 09, 2005 at 01:03:32AM -0800, [EMAIL PROTECTED] wrote:
>
> From: Hanno Boeck <[EMAIL PROTECTED]>
>
> I have a usb-cardreader here that needs some FORCELUN-entries in
> scsi_devinfo.c.
>
Hanno -
Instead of the patch, try running with CONFIG_SCSI_MULTI_LUN enabled.
-- Patrick Mansfi
Hi,
I'm new to SCSI. I would appreciate if some one can solve my query:
When a new SCSI device is added to a SCSI channel, how can we find out what
is the target ID of that device?
1) If a channel supports 8 SCSI devices, then each of the 8 ports will have
a specific Target ID. And any device
Jens Axboe wrote:
> On Tue, Mar 08 2005, [EMAIL PROTECTED] wrote:
>>
>> Hello!
>>
>> We're seeing a null pointer dereference with certain IDE tape drives
>> on
>> 2.6.11 when we use it with ide-scsi (i686 architecture). The
>> problem is that the scatter-gather pages aren't mapped to kernel
>>
>
>> . And since this is compile time
>> system-wide property, I kept it as driver global.
>
>that step I don't understand... why is it a global *VARIABLE* if it's
>compile time system-wide property...
>
I see your point! Are you saying I should use if(sizeof(dma_addr_t)==8)
instead of the shortcu
A narrow SCSI bus will support 8 devices.
A wide SCSI bus will support 16 devices.
A narrow bus uses 50 pins.
A wide bus uses 68 pins.
The SCSI card is a device, normally ID 7.
The SCSI ID is configured on the device. You will need to look at the
manual, some devices may have cryptic notes on th
On Wed, 2005-03-09 at 11:01 -0500, Bagalkote, Sreenivas wrote:
> >
> >> . And since this is compile time
> >> system-wide property, I kept it as driver global.
> >
> >that step I don't understand... why is it a global *VARIABLE* if it's
> >compile time system-wide property...
> >
>
> I see your po
Hayes, Stuart wrote:
> Jens Axboe wrote:
>> On Tue, Mar 08 2005, [EMAIL PROTECTED] wrote:
>>>
>>> Hello!
>>>
>>> We're seeing a null pointer dereference with certain IDE tape
>>> drives on
>>> 2.6.11 when we use it with ide-scsi (i686 architecture). The
>>> problem is that the scatter-gather pa
Here is a refresh of an update to the status_byte macro.
Previous mail
http://marc.theaimsgroup.com/?l=linux-scsi&m=110322214824566&w=2
-andmike
--
Michael Anderson
[EMAIL PROTECTED]
Add TASK_ABORTED and ACA_ACTIVE to status_byte macro.
Signed-off-by: Mike Anderson <[EMAIL PROTECTED]>
---
lin
On Wed, Mar 09, 2005 at 11:54:57AM -0500, Guy wrote:
> A narrow SCSI bus will support 8 devices.
> A wide SCSI bus will support 16 devices.
> A narrow bus uses 50 pins.
> A wide bus uses 68 pins.
We need a SCSI Wiki for all this kind of information ... maybe Wikipedia?
> There is a standard for a
>> >
>> >> . And since this is compile time
>> >> system-wide property, I kept it as driver global.
>> >
>> >that step I don't understand... why is it a global
>*VARIABLE* if it's
>> >compile time system-wide property...
>> >
>>
>> I see your point! Are you saying I should use
>if(sizeof(dma_add
On Wed, 2005-03-09 at 12:44 -0500, Bagalkote, Sreenivas wrote:
> >> >
> >> >> . And since this is compile time
> >> >> system-wide property, I kept it as driver global.
> >> >
> >> >that step I don't understand... why is it a global
> >*VARIABLE* if it's
> >> >compile time system-wide property...
> Hayes, Stuart wrote:
>> Jens Axboe wrote:
>>> On Tue, Mar 08 2005, [EMAIL PROTECTED] wrote:
Hello!
We're seeing a null pointer dereference with certain IDE tape
drives on
2.6.11 when we use it with ide-scsi (i686 architecture). The
problem is that the scatte
It's not clear what you're asking. You start off with the question
>When a new SCSI device is added to a SCSI channel, how can we find out
what
>is the target ID of that device?
That's clear enough, except I don't know who "we" is. Depending on who
you are, i.e. from what perspective you're
On Wed, Mar 09, 2005 at 01:03:32AM -0800, Andrew Morton wrote:
>
> From: Hanno Boeck <[EMAIL PROTECTED]>
>
> I have a usb-cardreader here that needs some FORCELUN-entries in
> scsi_devinfo.c.
>
> lsusb says about the device:
>
> Bus 001 Device 003: ID 0483:1307 SGS Thomson Microelectro
>The
>short and long of it: the problem can be solved, and it will. Couple
>simple things we already do: mlockall() to keep the daemon un-swapped,
>and also looking into potential dependency created by syslog (there's
>one for 2.4 kernel, not sure if this is an issue for 2.6).
I think it's pro
On Wed, Mar 09, 2005 at 11:29:03AM -0800, Bryan Henderson wrote:
> I'd like to remind everyone that user space processes aside, there's still
> a basic ISCSI initiator resource inversion that needs to be fixed to avoid
> deadlock:
>
> ISCSI initiator driver sits below the memory pool
> (I..e a
This patch will map the sg buffers to kernel virtual memory space in the
functions idescsi_input_buffers() and idescsi_output_buffers(). Without
this patch, idescsi passes a null pointer to atapi_input_bytes() and
atapi_output_bytes() when sg pages are in high memory (i686
architecture).
I'm att
On Wed, Mar 09, 2005 at 09:43:47AM -0500, Bagalkote, Sreenivas wrote:
> During the module load time, I allocate 32 bit or 64 bit SGLs based on
> whether I can receive 64 bit DMA addresses or not. If size of dma_addr_t
> is 4, then I allocate only 32 bit SGLs. During the run time, I prepare
> 32/64
On 2005-03-08T22:25:29, Alex Aizman <[EMAIL PROTECTED]> wrote:
> There's (or at least was up until today) an ongoing discussion on our
> mailing list at http://groups-beta.google.com/group/open-iscsi. The
> short and long of it: the problem can be solved, and it will. Couple
> simple things we
This patch adds support for 2 new SAS controllers due out this summer.
It also bumps the version to 2.6.6.
Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
Documentation/cciss.txt |2 ++
drivers/block/cciss.c | 14 ++
include/linux/pci_ids.h
This patch adds per disk queue functionality. It seems that the 2.6 kernel
expects a queue per disk. If you have multiple logical drives on a controller
all of the queues actually point back to the same queue. If a drive is deleted
it blows us out of the water.
We hold the lock during any queue
>
>Even for kernels with a 64bit dma_addr_t you can get 32bit dma
>addresses
>only. As a start check whether the pci_set_dma_mask for the 64bit mask
>failed - in that case you can always use 32bit SGLs.
>
Please help me understand: If dma_addr_t is 64 bit, I will get 64bit
addresses in scatterl
>> >
>> >Even for kernels with a 64bit dma_addr_t you can get 32bit dma
>> >addresses
>> >only. As a start check whether the pci_set_dma_mask for
>the 64bit mask
>> >failed - in that case you can always use 32bit SGLs.
>> >
>>
>> Please help me understand: If dma_addr_t is 64 bit, I will get 64
(Found out not to put aic7xxx in subject line because of spam filter...)
Running with latest 2.6.11 bk tree, one of my machines takes for ever to boot.
The driver is builtin (not a module). It worked fine until today, and works
fine with 2.6.11 or earlier. Looks like it is going into some probin
Bryan Henderson wrote:
Its fundamental to Unix architecture that user programs sit above the
kernel and get services from the kernel, and turning that on its head so
that the kernel depends on a user space program to do something as
fundamental as a pageout can't come to any good.
Agreed.
Eve
Lars Marowsky-Bree wrote:
On 2005-03-08T22:25:29, Alex Aizman <[EMAIL PROTECTED]> wrote:
There's (or at least was up until today) an ongoing discussion on our
mailing list at http://groups-beta.google.com/group/open-iscsi. The
short and long of it: the problem can be solved, and it will. Coupl
You said:
"And plugging any SE device onto an LVD bus causes the whole bus to fall
back to SE. This includes terminators."
True, but if your terminator is LVD only, it will get hot!!! Not sure if it
can be damaged, but it does get hot (or warm). :)
I also believe some LVD devices do not support
BINGO !
That answered to a lot extent what I was looking for. Yes, I accept my
question was a little cloudy. I wanted to ask both the perspectives: How
does a SCSI device gets its ID ... And How can the software (kernel / user)
find out the target ID of the new disk.
I'm using a HS disk (Ho
On Wed, Mar 09, 2005 at 05:47:27PM -0500, Bagalkote, Sreenivas wrote:
> >
> >Even for kernels with a 64bit dma_addr_t you can get 32bit dma
> >addresses
> >only. As a start check whether the pci_set_dma_mask for the 64bit mask
> >failed - in that case you can always use 32bit SGLs.
> >
>
> Pleas
This patch adds support for more than 8 controllers. If we run out of
preallocated major numbers we dynamically allocate more.
Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
cciss.c | 36 +++-
cciss.h |3 +++
2 files cha
39 matches
Mail list logo
