From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: Mikael Pettersson <mikpe@csd.uu.se>
Cc: martin@dalecki.de, linux-kernel@vger.kernel.org
Subject: Re: 2.5.31 boot failure on pdc20267
Date: Fri, 16 Aug 2002 11:21:20 +0200 [thread overview]
Message-ID: <2298DFF575E@vcnet.vc.cvut.cz> (raw)
On 15 Aug 02 at 22:13, Mikael Pettersson wrote:
> Petr Vandrovec writes:
> > On 15 Aug 02 at 17:15, Mikael Pettersson wrote:
> > > Booting 2.5.31 (non-bk) on hde5, a UDMA(66) Quantum Fireball
> > > on a PDC20267 add-on card, resulted in a complete hang as init
> > > came to its "mount -n -o remount,rw /" point. No visible messages
> > > or anything in the log.
> >
> > Known bug. Apply IDE113 (Aug 06, 11:02 CEST, from Martin), or just open
> > drivers/ide/pcidma.c in your favorite text editor, look for (first)
> > #ifdef CONFIG_BLK_DEV_TRM290, and replace whole ifdef block with
> > '*--table |= cpu_to_le32(0x80000000);'
>
> Tested. First time 2.5.31 + the patch booted it seemed to work, but hung
> later on while compiling a 2.4.19 kernel. No messages of any kind. The
> hang _seemed_ to coincide with the console screen blanker kicking in.
> Second boot went ok and I made sure the screen blanker wouldn't kick
> in while doing the compile, and it didn't hang.
>
> This box is the only one so far I've seen this problem on, my other
> Intel chipset boxes actually seem to work fairly well with 2.5.31.
Yes. If you'll look at d1510r0c.pdf from ATA guys, you'll find that
between 0b and 0c revisions definition of EOT bit (highest bit of
length) was removed. It is very unfortunate because of now host
adapters cannot prefetch across segment boundaries, because of host
adapter does not know when transfer will terminate (unless host monitors
all accesses to the disk and maintains its own set of IDE registers
(including HOB, so using > 256sectors transfers with such host adapters
which do not implement HOB is impossible)). It is also very dangerous
because of for reads when drive generates more data than expected, with
EOT flag transfer was terminated with error, but without EOT host will
just fetch random entries after last valid, and will (silently) corrupt
random memory.
And Promise implements old, safe&prefetchable, interface, while Intel
just fetches more and more PRD entries as long as drive has/wants more
data.
Petr Vandrovec
vandrove@vc.cvut.cz
next reply other threads:[~2002-08-16 9:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-16 9:21 Petr Vandrovec [this message]
2002-08-16 9:27 ` 2.5.31 boot failure on pdc20267 Andre Hedrick
-- strict thread matches above, loose matches on Subject: below --
2002-08-16 9:48 Petr Vandrovec
2002-08-16 10:10 ` Andre Hedrick
2002-08-15 15:34 Petr Vandrovec
2002-08-15 20:13 ` Mikael Pettersson
2002-08-15 15:15 Mikael Pettersson
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=2298DFF575E@vcnet.vc.cvut.cz \
--to=vandrove@vc.cvut.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=martin@dalecki.de \
--cc=mikpe@csd.uu.se \
/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