On Tue, 4 May 1999 17:35:06 +0200, "Mateu Batle i Sastre"
<mbatle@iname.com> said:
> I've tried the raw I/O patch for Linux 2.2.4 (located in
> ftp://ftp.uk.linux.org/pub/linux/sct/fs/raw-io/). It works
> fine but there are a few problems.
> 1st) It does not work with memory located in a PCI device.
Linux cannot perform IO on such memory right now. End of story. It
will in the future: this is just one of a whole raft of related problems
we have due to the backwards-compatible way virt_to_phys works.
> Of course, already mapped to a user space process. I could
> workaround this in an *ugly* way by patching my SCSI controller
> driver (Adaptec 2940UW). The patch was simply to change
> #define VIRT_TO_BUS(x) (virt_to_bus(x))
> by
> #define VIRT_TO_BUS(x) (__pa(x))
Yes, that's the one, but this change breaks a number of other device
drivers.
> Apparently, there is some problem with the translation from kernel
> virtual address to bus address. I've seen in one place is done
> using arithmetic and in the other using bit operations, and they
> are not always interchangeable.
Correct. __va and __pa use arithmetic which is fine for pure memory
operations but which breaks some IO operations due to ISA memory region
backwards compatibility. We'll be fixing this in 2.3.
> 2nd) The patch I did makes the system working as it should, but
> after some time running it crashes. I got the error:
> "kmem_alloc: Bad slab magic (corrupt) (name=size-128)".
> I think the problem in this case is that some memory is not
> deallocated in the kernel.
Such a leak wouldn't by itself lead to slab corruption.
> But this does not seem to happen with the raw I/O patch and normal
> system memory. Any idea ?
Given that you are treading in completely untested waters by breaking
virt_to_bus and by doing dma from PCI space, it's hard to debug this
remotely!
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/