From: Krzysztof Halasa <khc@pm.waw.pl>
To: "Kathy Frazier" <kfrazier@mdc-dayton.com>
Cc: <linux-kernel@vger.kernel.org>, <herbert@13thfloor.at>
Subject: Re: Problems related to DMA or DDR memory on Intel 845 chipset?
Date: 29 Jul 2003 01:14:04 +0200 [thread overview]
Message-ID: <m3u1962qir.fsf@defiant.pm.waw.pl> (raw)
In-Reply-To: <PMEMILJKPKGMMELCJCIGCEIOCDAA.kfrazier@mdc-dayton.com>
"Kathy Frazier" <kfrazier@mdc-dayton.com> writes:
> Sorry for the confusion! My driver sets up our device for a DMA (address
> and length) and then gives the command
> for the DMA to start. Once the device has completed the transfer, it
> asserts its interrupt, the driver clears it and proceeds to set up the next
> data transfer. It runs for awhile, but then eventually hangs (I don't get
> interrupts and neither does anything else - keyboard, ethernet, etc). I
> simply added debug to do_IRQ in the kernel to track the desired IRQ. I also
> added a routine to read the 8259 Interrupt Controller Registers when
> requested. Then I had a user app and driver which simply called this new
> new routine in the kernel to return the status of the 8259 and the debug
> counters I added to do_IRQ. Once the system failed, this debug information
> showed that not only was Linux NOT receiving the interrupt, but neither was
> the 8259. When I changed my driver to poll the device for DMA completion
> instead of rely on an interrupt, it still locked up.
I understand this is your device doing DMA (= access) - i.e. your
PCI card is transfering to/from system RAM? This has nothing to do with
any UDMA and it works with any Linux kernel and system hardware which
support PCI.
Are you using some standard PCI bridge by chance? Are you sure it isn't
a hardware (design or manufacturing) problem with the device (bridge)?
How do you check interrupt request state?
--
Krzysztof Halasa
Network Administrator
next prev parent reply other threads:[~2003-07-29 12:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20030728194025.GB11006@www.13thfloor.at>
2003-07-28 21:31 ` Kathy Frazier
2003-07-28 23:14 ` Krzysztof Halasa [this message]
2003-07-29 13:51 ` Kathy Frazier
2003-07-29 13:57 ` Krzysztof Halasa
2003-07-29 17:07 ` Kathy Frazier
[not found] <20030728202845.GA10304@www.13thfloor.at>
2003-07-29 14:40 ` Kathy Frazier
2003-07-29 14:15 ` Krzysztof Halasa
2003-07-29 17:18 ` Kathy Frazier
[not found] <Pine.LNX.4.44.0307281610170.25853-100000@coffee.psychology.mcmaster.ca>
2003-07-28 21:56 ` Kathy Frazier
2003-07-28 16:03 Kathy Frazier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3u1962qir.fsf@defiant.pm.waw.pl \
--to=khc@pm.waw.pl \
--cc=herbert@13thfloor.at \
--cc=kfrazier@mdc-dayton.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®