From: "Kathy Frazier" <kfrazier@mdc-dayton.com>
To: <linux-kernel@vger.kernel.org>
Subject: Problems related to DMA or DDR memory on Intel 845 chipset?
Date: Mon, 28 Jul 2003 11:03:36 -0500 [thread overview]
Message-ID: <PMEMILJKPKGMMELCJCIGEEIACDAA.kfrazier@mdc-dayton.com> (raw)
Hello all,
I posted a message a few weeks back concerning a problem I was having with
our device not receiving interrupts. Our system will run for awhile and
then "hang". I had discovered that upon this failure, the logic analyzer
shows that our device is asserting the interrupt. However, I also found (by
adding my own debug to the kernel) that the 8259 Programmable Interrupt
Controller never received the interrupt (it's bit was not set in the
Interrupt Request Register, nor did I ever reach my ISR to clear the
interrupt on the device). At this point of failure, no other IRQs are
getting through, so the system appears to be completely hard hung even
though various software components are still running. We are operating in a
system with an ASUS P4PE motherboard (uses the Intel 845PE chipset and
employs the DDR memory technology) running Linux 2.4.20-8. Further testing
has shown that "not receiving an interrupt" is just a nasty side affect from
something that has gone wrong during a DMA transfer by our device. This was
discovered when I changed the driver to poll for a DMA completion rather
than have it interrupt me. Our system still hung. We are have tried
tweaking various BIOS settings (set memory freq, DDR reference voltage, PCI
latency amoung others) but have not had any luck. We also tried some slower
DDR memory without luck. Another thing worth mentioning: When I built a
debug version of the kernel, I turned on several of the kernel hacking
features and added some of my own debug in the do_IRQ routine. I had a user
application query a new home grown debug routine in the kernel (via another
driver) to see what the status was with respect to the interrupt I was
watching and the state of the 8259. All of this changed the timing enough
that the system would complete a 3 hour test instead of the usual case in
which it dies in minutes under a non-debug kernel. Also, our device and
software work fine in a Pentium III system (using Intel 815E chipset with
133/100 MHz SDRAM) with the same (non-debug) version of Linux. So it seems
that this problem is sensitive to timing/speed.
In posting this, I'm hoping that someone may be able to lend some advice on
the situation. I have seen some past threads on this mailing list dealing
with issues of IDE DMA problems with Intel 845 chipset in version 2.4.19 of
the kernel. There were evidently some patches to this version (-ac1
through -ac3) which address these problems. Did these changes make it to
2.4.20? Or could the problem be due to the faster DDR memory? I have seen
some references to the memtest86 tool, but I'm not sure if that would shed
any light on this problem. I've downloaded, but have not tried it yet. Any
advice is welcome. Please let me know if I can provide you with any
additional information.
Thanks in advance for your help.
Kathy Frazier
Senior Software Engineer
Max Daetwyler Corporation-Dayton Division
2133 Lyons Road
Miamisburg, OH 45342
Tel #: 937.439-1582 ext 6158
Fax #: 937.439-1592
Email: kfrazier@daetwyler.com
http://www.daetwyler.com
next reply other threads:[~2003-07-28 14:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-28 16:03 Kathy Frazier [this message]
[not found] <20030728194025.GB11006@www.13thfloor.at>
2003-07-28 21:31 ` Kathy Frazier
2003-07-28 23:14 ` Krzysztof Halasa
2003-07-29 13:51 ` Kathy Frazier
2003-07-29 13:57 ` Krzysztof Halasa
2003-07-29 17:07 ` Kathy Frazier
[not found] <Pine.LNX.4.44.0307281610170.25853-100000@coffee.psychology.mcmaster.ca>
2003-07-28 21:56 ` 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
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=PMEMILJKPKGMMELCJCIGEEIACDAA.kfrazier@mdc-dayton.com \
--to=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®