On Thu, 16 Aug 2007 09:39:54 -0500 James Bottomley wrote:
> On Wed, 2007-08-15 at 22:22 -0700, Randy Dunlap wrote:
> > On Thu, 19 Jul 2007 10:49:30 -0700 Randy Dunlap wrote:
> >
> > > On Thu, 19 Jul 2007 18:57:50 +0300 Boaz Harrosh wrote:
> > >
> > > > Randy Dunlap wrote:
> > > > >
> > > > > Yes, this problem has been around forever AFAIK. You didn't add
> > > > > to it.
> > > > Do we need to file a bug report in Bugzilla or something, so people
> > > > have a
> > > > documentation of the work-around, until it is fixed?
> > >
> > > Wouldn't hurt, I guess, but the SCSI people know about it.
> > >
> > > > I think that for now I will wrap it up as it is. Could you send me the
> > > > right
> > > > BUG_ON() in place, with a printk pointing users to a solution? and I'll
> > > > redo all the patches.
> > >
> > > I didn't add a BUG_ON(), so I don't have that patch.
> > > (I just used a .slave_alloc function to force no high memory data
> > > addresses, just like ppa.c does.)
> > >
> > > You could just do a BUG_ON() just before there is an outsw()
> > > or insw() to a NULL pointer, e.g., in datao_run:
> > >
> > > BUG_ON(CURRENT_SC->SCp.ptr);
> > >
> > > or we could make building the driver depend on !HIGHMEM.
> > >
> > > I prefer either of the !HIGHMEM or slave_alloc changes to adding
> > > a BUG_ON(). However, the SCSI people likely won't want to use the
> > > slave_alloc() change because then the driver may never get fixed.
> > > (Of course, it hasn't got fixed with the BUG happening either.)
> > >
> > > Anyway, I'll re-read Documentation/DMA*.txt to see if I can fix it.
> >
> >
> > I have asked this once before, but I don't like the answer.
> >
> > Currently aha152x.c only works with !HIGHMEM due to highmem-pages
> > not being mapped into the driver's memory space. James and hch
> > tell me that using DMA mapping functions is the way to fix this,
> > but those appear to me to be for DMA (!!), and this driver is (only)
> > using PIO.
> >
> > I did try to use dma_map_sg() & dma_unmap_sg() here, but they end up
> > giving the driver physical buffer addresses, which aren't what is
> > needed for PIO. Should this driver be using
> > scsi_kmap_atomic_sg() and scsi_kunmap_atomic_sg()
> > or other API functions, or should the driver just use
> > kmap_atomic() + kunmap_atomic()
> > for each highmem page?
>
> For DMA transfers ... which is where you give the device a bus physical
> address and a length and tell it to go off and perform the transfer on
> its own, you need to use the dma_map_ functions.
>
> For PIO transfers, which are usually ones where you have to feed the
> data into a special device register, since the kernel needs access to do
> this, it has to be done via kmap_atomic()/kunmap_atomic(). So, if
> everything has to go via pio, you use a sequence like
>
>
> scsi_for_each_sg(cmd, sg, max, i) {
> offset = sg->offset;
> len = sg->len;
> do {
> coffset = offset; clen =len;
> buf = scsi_kmap_atomic_sg(sg, 1, &coffset, &clen)
> offset -= coffset; clen -= len;
> <feed buf+coffset to/from PIO for clen>
> scsi_kunmap_atomic_sg(buf);
> } while (len > 0);
> }
I'm hitting a WARN_ON(1) in scsi_kmap_atomic_sg():
(I added the sg address to make sure that it's the same one that
I am passing in to scsi_kmap_atomic_sg())
scsi_kmap_atomic_sg: sg at: 0xc25fd180, bytes in sg: 36, requested offset 304,
elements 1
WARNING: at drivers/scsi/scsi_lib.c:2246 scsi_kmap_atomic_sg()
The sg that I am passing in looks like:
data segs[0], sg=c25fd180, page=c18a9698, offset=0x130, dma_adr: 0x0, len=0x24
so I'm calling like so:
coffset = offset; // offset = sg->offset; // == 0x130
clen = len; // len = sg->length; // == 36
buf = scsi_kmap_atomic_sg(sg, 1, &coffset, &clen);
Or consider a 1-element sg(list) that wants to read 0x800 bytes into
a page at page offset 0x800. How does scsi_kmap_atomic_sg() handle this?
thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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
