We need to transfer device ownership to the CPU before we can
manipulate the mapped data.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/dc395x.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c
index 8d7a26a33951..f3b65e5efe2b 100644
---
Remove the list wrappers, including the pointless list iteration before
deletion.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/dc395x.c | 152 --
1 file changed, 26 insertions(+), 126 deletions(-)
diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc3
ma_sync_single_for_device(&srb->dcb->acb->dev->dev,
+ srb->sg_bus_addr, SEGMENTX_LEN,
+ DMA_TO_DEVICE);
break;
}
psge++;
@@ -3178,9 +
We can't just transfer ownership to the CPU and then unmap, as this will
break with swiotlb.
Instead unmap the command and sense buffer a little earlier in the I/O
completion handler and get rid of the pci_dma_sync_sg_for_cpu call
entirely.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/dc39
Kees,
> In preparation for unconditionally passing the struct timer_list
> pointer to all timer callbacks, switch to using the new timer_setup()
> and from_timer() to pass the timer pointer explicitly.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Oliver Neukum
Cc: Ali Akcaagac
Cc: Jamie Lenehan
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Use setup_timer function instead of initializing timer with the
function and data fields.
Signed-off-by: Allen Pais
---
drivers/scsi/dc395x.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c
index 5ee7f44..f9aaa8b 100644
-
From: "Lad, Prabhakar"
this patch fixes following sparse warning:
dc395x.c:1525:17: warning: Using plain integer as NULL pointer
Signed-off-by: Lad, Prabhakar
---
Found this issue on linux-next (gcc version 4.9.2,
sparse version 0.4.5-rc1)and applies on top linux-next.
drivers/scsi/dc395
> This is an automatically generated Delivery Status Notification.
>
> Delivery to the following recipients failed.
>
>dc3...@twibble.org
Anyone else seeing this too?
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord
This driver has always contained a check for
CONFIG_SCSI_DC395x_TRMS1040_TRADMAP. But a Kconfig symbol
SCSI_DC395x_TRMS1040_TRADMAP was never added to the tree. Besides, the
code that this check hides can't compile, since "geom" is never defined.
Remove it.
Signed-off-by: Paul Bolle
---
Compile t
https://bugzilla.kernel.org/show_bug.cgi?id=15950
--- Comment #8 from ltski...@gmail.com ---
Could be. Haven't found another inexpensive SCSI adapter.
I say the driver probably needs to get fixed or removed, though. No point in
having it in the kernel giving folks false hope that it'll work!
-
https://bugzilla.kernel.org/show_bug.cgi?id=15950
--- Comment #7 from Alan ---
No need - there is one obscure bug fix in early 2013, but nothing else since
2010. You may be the only person on the planet who still uses one!
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=15950
Alan changed:
What|Removed |Added
Kernel Version|2.6.31 |3.5.3
--
You are receiving this mail because:
You
https://bugzilla.kernel.org/show_bug.cgi?id=15950
ltski...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|OBSOLETE
https://bugzilla.kernel.org/show_bug.cgi?id=15950
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/dc395x.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/dc395x.c b/driv
%p is used, thus NULL should be used instead of 0.
Also, __constant_cpu_to_le16() is added in order to fix
the following sparse warnings:
drivers/scsi/dc395x.c:1525:17: warning: Using plain integer as NULL pointer
drivers/scsi/dc395x.c:4186:48: warning: cast truncates bits from constant value
(1d
On Wed, 2013-08-07 at 15:58 +0900, Jingoo Han wrote:
> On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum wrote:
> > On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
> >
> > > @@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType
> > > *eeprom, unsigned long io_port)
> > >
On Wed, Wednesday, August 07, 2013 5:40 PM, Julian Calaby > wrote:
> On Wed, Aug 7, 2013 at 6:36 PM, Jingoo Han wrote:
> > On Wednesday, August 07, 2013 5:21 PM, Julian Calaby wrote:
> >> On Wed, Aug 7, 2013 at 5:45 PM, Jingoo Han wrote:
> >> > On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum
Ali Akcaagac; Jamie Lenehan;
>> dc3...@twibble.org; James Bottomley;
>> linux-scsi
>> Subject: Re: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0
>>
>> Hi Jingoo,
>>
>> On Wed, Aug 7, 2013 at 5:45 PM, Jingoo Han wrote:
>> > On Wednesday, August 07,
t: Re: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0
>
> Hi Jingoo,
>
> On Wed, Aug 7, 2013 at 5:45 PM, Jingoo Han wrote:
> > On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum wrote:
> >> On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
> >>
&g
Hi Jingoo,
On Wed, Aug 7, 2013 at 5:45 PM, Jingoo Han wrote:
> On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum wrote:
>> On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
>>
>> > @@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType *eeprom,
>> > unsigned long io_port)
>> >
On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum wrote:
> On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
>
> > @@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType *eeprom,
> > unsigned long io_port)
> > */
> > dprintkl(KERN_WARNING,
> >
On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum wrote:
> On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
>
> > @@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType *eeprom,
> > unsigned long io_port)
> > */
> > dprintkl(KERN_WARNING,
> >
On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
> @@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType *eeprom,
> unsigned long io_port)
>*/
> dprintkl(KERN_WARNING,
> "EEProm checksum error: using default values and
> options
%p is used, thus NULL should be used instead of 0.
Also, bit maskings are added in order to fix the following
sparse warnings:
drivers/scsi/dc395x.c:1525:17: warning: Using plain integer as NULL pointer
drivers/scsi/dc395x.c:4186:48: warning: cast truncates bits from constant value
(1de1 becomes
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/scsi/dc395x.c | 24 +---
1 files changed, 1 insertions(+), 23 deletions(-)
diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c
old mode 100644
new mode 100755
index 694
Removing some boilerplate by using module_pci_driver instead of calling
register and unregister in the otherwise empty init/exit functions.
Signed-off-by: Peter Huewe
---
drivers/scsi/dc395x.c | 25 +
1 file changed, 1 insertion(+), 24 deletions(-)
diff --git a/drivers/s
When we enable dprintkdbg, then their is a NULL pointer dereference.
Signed-off-by: Syam Sidhardhan
---
drivers/scsi/dc395x.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c
index 865c64f..6c5b874 100644
--- a/drivers/scsi/dc
On Monday 11 February 2013 22:03:18 Dan Carpenter wrote:
> This bug was introduced back in bitkeeper days in 2003. We use
> "dcb->dev_mode" before it has been initialized.
>
> Signed-off-by: Dan Carpenter
Acked-by: Oliver Neukum
--
To unsubscribe from this list: send the line "unsubscribe linux
This bug was introduced back in bitkeeper days in 2003. We use
"dcb->dev_mode" before it has been initialized.
Signed-off-by: Dan Carpenter
diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c
index 865c64f..fed486bf 100644
--- a/drivers/scsi/dc395x.c
+++ b/drivers/scsi/dc395x.c
@@ -3747,
cmd->sense_buffer[13],
- *((unsigned int *)(cmd->sense_buffer +
3)),
- *((unsigned int *)(cmd->sense_buffer +
8)));
- else
- printk("sense=
Satyam Sharma wrote:
I'll post the info as a reply to the first mail in this series. I have
fairly recent gcc (4.1.1) and I don't see us dropping support for it in
the next few years.
What's important is not support lifetime, but whether or not the warning
persists through version 4.1.2, 4.1.3
On Sun, 2 Sep 2007, Jeff Garzik wrote:
>
> Satyam Sharma wrote:
> > drivers/scsi/dc395x.c: In function ‘dc395x_init_one’:
> > drivers/scsi/dc395x.c:4272: warning: ‘ptr’ may be used uninitialized in this
> > function
> >
> > has been verified to be a bogus warning. Let's shut it up.
> >
> > Sig
Satyam Sharma wrote:
drivers/scsi/dc395x.c: In function ‘dc395x_init_one’:
drivers/scsi/dc395x.c:4272: warning: ‘ptr’ may be used uninitialized in this
function
has been verified to be a bogus warning. Let's shut it up.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/scsi/dc395
drivers/scsi/dc395x.c: In function ‘dc395x_init_one’:
drivers/scsi/dc395x.c:4272: warning: ‘ptr’ may be used uninitialized in this
function
has been verified to be a bogus warning. Let's shut it up.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/scsi/dc395x.c |2 +-
1 file
On Thu, 15 Feb 2007, Aldo Barreto wrote:
> I'am trying to install Mandriva 2007 with kernel 2.6.17 in my system. It's
> a Pentium IV P4P 800 ASSUS system with 1 Gb of memory and a scsi board
> Tekram dc395. System doesn't end startup and syslog sends me a messagge:
> kernel: drivers/scsi/dc395x.c
I'am trying to install Mandriva 2007 with kernel 2.6.17 in my system. It's
a Pentium IV P4P 800 ASSUS system with 1 Gb of memory and a scsi board
Tekram dc395. System doesn't end startup and syslog sends me a messagge:
kernel: drivers/scsi/dc395x.c: Please, contact (your address).
This occurs boot
Hi all
I've been buggering the list with this ridiculous problem for quite some
time now:-) I understand, it is too risky to apply an untested patch to
mainline, but could we either
1) get it into -mm
or
2) try to find some beta-testers by applying something like the below:
Thanks
Guennadi
-
10240 bytes
tar: Error is not recoverable: exiting now
and in dmesg:
dc395x: eh_abort: (pid#37555) target=<06-0> cmd=c5c16b40
dc395x: eh_abort: Command in progress<6>dc395x: eh_abort: (pid#37556)
target=<06-0> cmd=c5f6ed00
dc395x: eh_abort: Command was waiting
dc395x: eh_abort:
On Sun, 7 Aug 2005, Mike Christie wrote:
> Well, iscsi too, but there is the scatterwalk code which the crypto api
> uses today and looks similar to what ide, libata, and scsi need.
Ok, I see what you mean now. Well, my impression is that one could,
certainly, merge the 2 APIs, but this would in
Guennadi Liakhovetski wrote:
> On Sun, 7 Aug 2005, Mike Christie wrote:
>
>
>>Guennadi Liakhovetski wrote:
>>
>>>Now, it would be best, I think, if somebody could review the patches to
>>>dc395x and tmscsim. In case the 2 functions are correct, they
On Sun, 7 Aug 2005, Mike Christie wrote:
> Guennadi Liakhovetski wrote:
> > Now, it would be best, I think, if somebody could review the patches to
> > dc395x and tmscsim. In case the 2 functions are correct, they could be
> > included in a central file (scsi_lib?) for all
Guennadi Liakhovetski wrote:
> Now, it would be best, I think, if somebody could review the patches to
> dc395x and tmscsim. In case the 2 functions are correct, they could be
> included in a central file (scsi_lib?) for all drivers, needing PIO (I
would it be possible to m
Hi all
A problem has first been reported in
Date: Thu, 6 Jan 2005 05:18:25 -0500
From: Andrew Schulman <[EMAIL PROTECTED]>
Subject: dc395x: can't write to tape
whereby a bug has become apparent in driver's virtual address calculation.
I wrote a patch, which propagated into the
Guennadi Liakhovetski wrote:
>So, now that we have somebody to test alternative patches, let's try it...
>Please, first revert the first patch (apply with -R), and then apply the
>second one. There, probably, will be offsets, don't worry about them.
>Warning: untested. Please, try some read-onl
discussion that followed the review by Jens Axboe, who revealed its bogus
nature, didn't produce a replacement patch, mainly because there wasn't
anybody with dc395x and highmem, until you came...:-) I just forgot /
didn't realise it actually made its way into the mainline...
So,
Ok, I've now figured out where the bug appears. 2.6.12-rc4 runs fine
while -rc5 does not.
Rgds
Pierre
-
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
On Fri, 29 Jul 2005 01:05:48 +0200 Pierre Ossman wrote:
> randy_dunlap wrote:
>
> >
> >oh drat. Please test 2.6.12.2 with the following patch segment
> >backed out (-R, reversed). I don't see any other patches that could
> >be the cause. If this isn't the problem, I would have to begin
> >to s
randy_dunlap wrote:
>
>oh drat. Please test 2.6.12.2 with the following patch segment
>backed out (-R, reversed). I don't see any other patches that could
>be the cause. If this isn't the problem, I would have to begin
>to suspect some kind of toolchain problem.
>
>
>
It seems the blame fall
On Tue, 26 Jul 2005 23:06:11 +0200 Pierre Ossman wrote:
> randy_dunlap wrote:
>
> >
> >The only 2 differences that I can see that would affect this
> >(diff patch-2.6.12.1 vs. patch-2.6.1.2) are: (cut-n-paste, so
> >has whitespace munging)
> >
> >
> >
>
> Neither had any effect. :/
oh drat.
randy_dunlap wrote:
>
>The only 2 differences that I can see that would affect this
>(diff patch-2.6.12.1 vs. patch-2.6.1.2) are: (cut-n-paste, so
>has whitespace munging)
>
>
>
Neither had any effect. :/
Rgd
Pierre
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
t
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
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
I'm having some problems with your mailserver Randy. I'll cc the mailing
list hoping you'll see this there.
I get:
<<< 550-Verification failed for <[EMAIL PROTECTED]>
<<< 550-unrouteable mail domain "drzeus.cx"
<<< 550 Sender verify failed
As far as i know my MX records are completely correct.
randy_dunlap wrote:
>
>Does this happen on every boot?
>
>
Yup
>Please send your .config file (or put it on craffe.se).
>
>
Included
>Does this happen with othe kernel versions?
>
>
Not that I've found. I could try compiling the currently running kernel
(2.6.11.7) without highmem if you
On Fri, 22 Jul 2005 01:51:34 +0200 Pierre Ossman wrote:
> I have now tried with highmem disabled and the driver still crashes. See
> the following image:
>
> http://craffe.se/dc395x_kernel_bug.jpg
Hi Pierre,
Does this happen on every boot?
Please send your .config file (or put it on craffe.se)
I have now tried with highmem disabled and the driver still crashes. See
the following image:
http://craffe.se/dc395x_kernel_bug.jpg
Rgds
Pierre
-
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://vg
Finally a dump with a smaller font so that the entire panic is visible:
http://craffe.se/dc395x_panic.jpg
Rgds
Pierre
-
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-inf
Guennadi Liakhovetski wrote:
>>127MB HIGHMEM available.
>>896MB LOWMEM available.
>>
>>
Quite right. The limit is slightly before 1 GB, not exactly at it. My bad.
Rgds
Pierre
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED
On Thu, 14 Jul 2005, Pierre Ossman wrote:
> Guennadi Liakhovetski wrote:
>
> >
> >Have you managed to get netconsole running? Do you have no chance at all
> >to use a serial console? You are, perhaps, the only / last user of dc395x
> >on a high-mem machine,
On Thu, 14 Jul 2005 01:57:54 +0200 Pierre Ossman wrote:
> Guennadi Liakhovetski wrote:
>
> >
> >Have you managed to get netconsole running? Do you have no chance at all
> >to use a serial console? You are, perhaps, the only / last user of dc395x
> >on a high-mem m
Guennadi Liakhovetski wrote:
>
>Have you managed to get netconsole running? Do you have no chance at all
>to use a serial console? You are, perhaps, the only / last user of dc395x
>on a high-mem machine, the driver is known to have a problem there,
>although from your dump I ca
have no chance at all
to use a serial console? You are, perhaps, the only / last user of dc395x
on a high-mem machine, the driver is known to have a problem there,
although from your dump I cannot see yet if that is indeed the problem. As
someone also already suggested, you could also just tr
randy_dunlap wrote:
>Are you using netcat on the receive side?
>
>
>
I've been using tcpdump and not a single packet eminates from the
machine when printk:s show up.
>Matt Mackall says that a common problem is running kernels with
>a log low level:
>
>Kernel command line: ro root=LABEL=/ rhgb
On Sun, 10 Jul 2005 19:22:48 +0200 Pierre Ossman wrote:
| I've tried to get it running on three separate machines now with no
| success (each running a different kernel version), so I'm starting to
| suspect I'm doing something wrong here. I've used the following line to
| load the module:
|
| mo
I've tried to get it running on three separate machines now with no
success (each running a different kernel version), so I'm starting to
suspect I'm doing something wrong here. I've used the following line to
load the module:
modprobe netconsole netconsole=@/,@10.8.0.168/
I've tried changing the
On Sun, 10 Jul 2005 16:01:29 +0200 Pierre Ossman wrote:
| randy_dunlap wrote:
|
| >3c59x ??
| >3c59x.c has CONFIG_NET_POLL_CONTROLLER code in it.
| >I would expect it to work since it's a fairly common NIC, but I
| >can't vouch for it.
| >Did you enable CONFIG_NETPOLL in your kernel .config?
| >
randy_dunlap wrote:
>3c59x ??
>3c59x.c has CONFIG_NET_POLL_CONTROLLER code in it.
>I would expect it to work since it's a fairly common NIC, but I
>can't vouch for it.
>Did you enable CONFIG_NETPOLL in your kernel .config?
>
>
>
Yup. It's enabled. NETPOLL_RX is not enabled though. Is that neede
On Sun, 10 Jul 2005 03:49:08 +0200 Pierre Ossman wrote:
| randy_dunlap wrote:
|
| >Pierre,
| >
| >Can you capture the complete panic message using serial console or
| >netconsole? or at least use a smaller font on the console so that
| >we can see the entire panic message, as some critical parts
randy_dunlap wrote:
>Pierre,
>
>Can you capture the complete panic message using serial console or
>netconsole? or at least use a smaller font on the console so that
>we can see the entire panic message, as some critical parts of it
>have scrolled off the top of the screen.
>
>
>
Hmm... I made
, 09 Jul 2005 23:48:43 +0200
From: Pierre Ossman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: LKML
Subject: Kernel panic with dc395x in 2.6.12.2
I upgraded a machine from 2.6.11.7 to 2.6.12.2 today and the only thanks
I got was a brand new kernel panic. From the backtrace it seems that the
On Thu, Apr 21 2005, Guennadi Liakhovetski wrote:
> +static void *dc390_kmap_atomic_sg(struct scatterlist *sg, int sg_count,
> size_t offset, size_t *len)
> +{
> + int i;
> + size_t sg_len = 0;
> +
> + for (i = 0; i < sg_count; i++) {
> + sg_len += sg[i].length;
> +
Hi again
A patch to tmscsim.c, removing bus_to_virt() and, while at it, cleaning up
cpu / le32 conversions, could look something like this. Notice, it uses
the same <...>_k(un)map_atomic_sg() as proposed for dc395x, so, certainly
this is not a final patch - in the end those function
On Thu, 31 Mar 2005 [EMAIL PROTECTED] wrote:
> On Wed, 30 Mar 2005, James Bottomley wrote:
>
> > On Wed, 2005-03-30 at 23:22 +0200, Guennadi Liakhovetski wrote:
> > > What is going to happen to this stuff? The current Linus' tree contains a
> > > brok
On Wed, 30 Mar 2005, James Bottomley wrote:
> On Wed, 2005-03-30 at 23:22 +0200, Guennadi Liakhovetski wrote:
> > What is going to happen to this stuff? The current Linus' tree contains a
> > broken (by me:-() dc395x, other drivers (including tmscsim) would benefit
>
On Wed, 2005-03-30 at 23:22 +0200, Guennadi Liakhovetski wrote:
> What is going to happen to this stuff? The current Linus' tree contains a
> broken (by me:-() dc395x, other drivers (including tmscsim) would benefit
> from a generic API. I understand, the drivers are not top i
Hi
What is going to happen to this stuff? The current Linus' tree contains a
broken (by me:-() dc395x, other drivers (including tmscsim) would benefit
from a generic API. I understand, the drivers are not top importance, but
still.
I guess, if nothing happens, I'll just have to subm
> sg_map_each_entry(sglist, entries, sg, ouput_ptr, flags) {
> > > /* transfer sg_virt_len(sg) to/from output_ptr */
> > > }
> > >
> > > that maps each entry successively.
> >
> > Well, I don't know how and when o
r in the thread, you need to do
> > something ala
> >
> > sg_map_each_entry(sglist, entries, sg, ouput_ptr, flags) {
> > /* transfer sg_virt_len(sg) to/from output_ptr */
> > }
> >
> > that maps each entry successively.
>
> Well, I don't know
/* transfer sg_virt_len(sg) to/from output_ptr */
> }
>
> that maps each entry successively.
Well, I don't know how and when other drivers use / need this mapping, in
dc395x and tmscsim you just occasionally need to transfer a couple of
bytes per PIO, so, it would be a waste to
On Sun, Mar 20 2005, Guennadi Liakhovetski wrote:
> On Sun, 20 Mar 2005, Christoph Hellwig wrote:
>
> > On Wed, Mar 16, 2005 at 06:04:17PM +0100, Jens Axboe wrote:
> > > On Wed, Mar 16 2005, Christoph Hellwig wrote:
> > > > On Wed, Mar 16, 2005 at 05:53:39PM +0100, Jens Axboe wrote:
> > > > > The
On Sun, 20 Mar 2005, Christoph Hellwig wrote:
> On Wed, Mar 16, 2005 at 06:04:17PM +0100, Jens Axboe wrote:
> > On Wed, Mar 16 2005, Christoph Hellwig wrote:
> > > On Wed, Mar 16, 2005 at 05:53:39PM +0100, Jens Axboe wrote:
> > > > The list doesn't really need dma mapping at that point, the proble
On Wed, Mar 16, 2005 at 06:04:17PM +0100, Jens Axboe wrote:
> On Wed, Mar 16 2005, Christoph Hellwig wrote:
> > On Wed, Mar 16, 2005 at 05:53:39PM +0100, Jens Axboe wrote:
> > > The list doesn't really need dma mapping at that point, the problem here
> > > is that the driver needs to punt to pio mo
Hi
Here's a fixed patch - thanks to everybody for reviewing and commenting!
However, if it is decided to implement helper functions, as suggested by
Christoph and others, feel free to drop it. There, probably, was only 1
user of this card with highmem and he retired his card too:-)
Thanks
Guen
; > pSRB->SGBusAddr = cpu_to_le32(pci_dma_lo32(sg_dma_address(psgl)));
> >
> > I am somewhat confused. In both cases these are bus addresses, right? and
> > sg_dma_address() gives already the bus address, so, both are wrong?
>
> The only reason that would make sens
On Thu, Mar 17 2005, [EMAIL PROTECTED] wrote:
> Hi
>
> On Thu, 17 Mar 2005, Jens Axboe wrote:
>
> > On Wed, Mar 16 2005, Guennadi Liakhovetski wrote:
> > >
> > > On Wed, 16 Mar 2005, Jens Axboe wrote:
> > > > The kmap() isn't just inefficient, it's a problem to iterate over the sg
> > > > list an
Hi
On Thu, 17 Mar 2005, Jens Axboe wrote:
> On Wed, Mar 16 2005, Guennadi Liakhovetski wrote:
> >
> > On Wed, 16 Mar 2005, Jens Axboe wrote:
> > > The kmap() isn't just inefficient, it's a problem to iterate over the sg
> > > list and kmap all the pages. That is illegal.
> >
> > Hm, what do you m
On Wed, Mar 16 2005, Guennadi Liakhovetski wrote:
> Hi
>
> Thanks for reviewing this patch!
>
> On Wed, 16 Mar 2005, Jens Axboe wrote:
>
> > On Wed, Mar 16 2005, James Bottomley wrote:
> ...
> > > I agree the kmap is inefficient. The efficient alternative is to do
> > > dma_map_sg() and use kma
Hi
Thanks for reviewing this patch!
On Wed, 16 Mar 2005, Jens Axboe wrote:
> On Wed, Mar 16 2005, James Bottomley wrote:
...
> > I agree the kmap is inefficient. The efficient alternative is to do
> > dma_map_sg() and use kmap_atomic() in the interrupt routine where we do
> > the PIO cleanup---
On Wed, Mar 16 2005, Mike Christie wrote:
> Jens Axboe wrote:
> >On Wed, Mar 16 2005, Christoph Hellwig wrote:
> >
> >>On Wed, Mar 16, 2005 at 05:53:39PM +0100, Jens Axboe wrote:
> >>
> >>>The list doesn't really need dma mapping at that point, the problem here
> >>>is that the driver needs to punt
Jens Axboe wrote:
On Wed, Mar 16 2005, Christoph Hellwig wrote:
On Wed, Mar 16, 2005 at 05:53:39PM +0100, Jens Axboe wrote:
The list doesn't really need dma mapping at that point, the problem here
is that the driver needs to punt to pio mode because of foo. So calling
pci/dma_map_* is pointless, si
On Wed, Mar 16 2005, Christoph Hellwig wrote:
> On Wed, Mar 16, 2005 at 05:53:39PM +0100, Jens Axboe wrote:
> > The list doesn't really need dma mapping at that point, the problem here
> > is that the driver needs to punt to pio mode because of foo. So calling
> > pci/dma_map_* is pointless, since
On Wed, Mar 16, 2005 at 05:53:39PM +0100, Jens Axboe wrote:
> The list doesn't really need dma mapping at that point, the problem here
> is that the driver needs to punt to pio mode because of foo. So calling
> pci/dma_map_* is pointless, since the CPU will have to do the transfer
> anyways. What t
On Wed, Mar 16 2005, Matthew Wilcox wrote:
> On Wed, Mar 16, 2005 at 05:04:47PM +0100, Jens Axboe wrote:
> > The kmap() isn't just inefficient, it's a problem to iterate over the sg
> > list and kmap all the pages. That is illegal.
> >
> > But it's not so tricky to get right, if the punting just h
On Wed, Mar 16, 2005 at 05:04:47PM +0100, Jens Axboe wrote:
> The kmap() isn't just inefficient, it's a problem to iterate over the sg
> list and kmap all the pages. That is illegal.
>
> But it's not so tricky to get right, if the punting just happens in the
> isr. Basically just iterate over ever
On Wed, Mar 16 2005, James Bottomley wrote:
> On Wed, 2005-03-16 at 08:58 +0100, Jens Axboe wrote:
> > Guys, who reviewed this? It looks completely bogus, using kmap() for tha
> > entire sg list is just wrong and can deadlock easily. The proper way is
> > of course to skip the virtual address requi
On Wed, 2005-03-16 at 08:58 +0100, Jens Axboe wrote:
> Guys, who reviewed this? It looks completely bogus, using kmap() for tha
> entire sg list is just wrong and can deadlock easily. The proper way is
> of course to skip the virtual address requirement and dma map the sg
> array properly.
I suppo
On Thu, Mar 03 2005, Linux Kernel Mailing List wrote:
> ChangeSet 1.1982.29.77, 2005/03/03 10:41:40+02:00, [EMAIL PROTECTED]
>
> [PATCH] dc395x: Fix support for highmem
>
> From: Guennadi Liakhovetski <[EMAIL PROTECTED]>
>
> Removes t
dc395x scsi driver makes many references to __init functions &
__initdata that should be __devinit & __devinitdata.
Error: ./drivers/scsi/dc395x.o .text refers to 21ef R_X86_64_PC32
.init.text+0x00b4
Error: ./drivers/scsi/dc395x.o .text refers to
1 - 100 of 108 matches
Mail list logo
