The io card shall transfer data using pci bus mastership mode. In the app notes
of the pci chip (AMCC S5933) they call it "pci bus mastering dma", therefore my
inaccurate description. Sorry for the confusion.
[snip]
> > As last test, I disabled all pci->pc memory dma functions for the module, so
> > there is definitely no chance for the module to overwrite any kernel space.
>
> Do you mean that in this case you turned OFF the peripheral device's
> bus mastering? Or removed the code which sets it up, and utilizes it?
I turned the "enable bus master for pci-to-memory transfers" bits in the S5933
off. The test program uses write calls only, so there should be no reason for
pci-to-memory transfers anyway.
> > Running a test program which only reads data from the main memory via dma (and
> > writes to the pci device) gives different effects depending on the value of the
> > PCI_LATENCY_TIMER:
> >
> > o with a small value (e. g. 8), I get "holes" (blank or unprintible characters)
> > in the console output. They are scrolled correctly, so they anyhow seem to go
> > into memory. The kernel is locked after some 10 kb of transferred data,
> > sometimes after a message "Uhhuh. NMI received etc.etc." (coming from
> > arch/i386/kernel/traps.c).
> >
> > o with large values (e. g. 64), it runs smoother, but will also lock up
> > sometimes.
> >
>
> Hmmm. Perhaps this is a language problem, but rather than using the
> CPU's DMA engine, use the peripheral device's bus mastering for it to
> collect the data on it's own.
See above. The io card _uses_ pci bus master mode for _reading_ some part of the
cpu's memory, and the errors described above occur! Any explanation possible?
> > The addresses are o.k. (I think): I use virt_to_bus (), and kmalloc () as
> > decribed in `Linux device drivers'. As kernel space will never get swapped, this
> > should work. Anyway _reading_ from memory should always work even if the
> > contents is not what I want to have. Also, all the data which was transferred
> > before the lockup is correct (the io card is connected to a dsp which checks a
> > crc).
> >
>
> A kernel module reading from space it doesn't have access to will
> segfault you in a hurry!
>
> Once a send_packet is started, what does the module need to do? Wait
> for completion?
The io card reads data from (physical) memory using pci bus master mode, so no
reason for a segfault. The module is simply in an interruptible_sleep_on phase.
> > Therefore, I suspect that there might be a hardware problem (as the computer has
> > a CompactPCI bus, and we only have one piece, I can't test it with a different
> > model). Does this sound reasonable for the kernel gurus (in this case I will try
> > to get some support from the vendor of the CompactPCI pc)?
> >
>
> Whose CPU? We use Ziatech. I'm familiar with ORI also.
or Ind. computers type CC5 with latest firmware upgrades.
> Next time, post to the list your syslog tail ( var/log/messages) from
> the crash. That can help a bit. Also, I assume you are familiar with
> printk() and all that...
The point is that there is absolutely no output from syslog except for the
occasional NMI message, no oops, no panic, etc. I restarted klogd with "-c 8",
so I get all messages to console. Only the debug stuff from my module is
visible, than it hangs, and I have to use the bit button...
Thanks, Albrecht.
-- +-----------------------------------------------------------------------------+ | Dr.-Ing. Albrecht Dre\ss ---- | | Max-Planck-Institut f\"ur Radioastronomie |\ / /o o\ | | Technische Abt. Optische Interferometrie | \ / | / | | | Auf dem H\"ugel 69 | \ | \ ---/ | | D-53121 Bonn (Germany) ------------+------+------------------- | | | / | | | Phone (+49) 228 525 319 | / / | | Fax (+49) 228 525 411 |/ / | | Mail ad@mpifr-bonn.mpg.de | +-------------- electrical engineers do it with less resistance --------------+- 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/