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.
2.5.29 worked ok on this box, as does 2.4 and 2.2+Andre's IDE code.
ASUS P3B-F, 440BX UDMA(33) chipset, disks on a Promise Ultra100 card.
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);'
Test in the ifdef is exactly opposite, and #ifdef is also wrong.
Petr Vandrovec
[email protected]
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.
/Mikael
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
[email protected]
On Fri, 16 Aug 2002, Petr Vandrovec wrote:
> Yes. If you'll look at d1510r0c.pdf from ATA guys, you'll find that
BUZZIT!
That is an totally new transport protocol and if you research the pci
device class you would know that it has nothing to do with the problem.
If you guys are playing with ADMA on DMA Hosts, oh my!
The context of what is the EOT between the two HOST protocols has no
meaning.
Regards,
Andre Hedrick
LAD Storage Consulting Group
On 16 Aug 02 at 2:27, Andre Hedrick wrote:
> On Fri, 16 Aug 2002, Petr Vandrovec wrote:
>
> > Yes. If you'll look at d1510r0c.pdf from ATA guys, you'll find that
>
> BUZZIT!
>
> That is an totally new transport protocol and if you research the pci
> device class you would know that it has nothing to do with the problem.
> If you guys are playing with ADMA on DMA Hosts, oh my!
No. It just reveals that you have no idea what you are talking about.
It was proven when you talked about EDD, and now it is proven again.
Table 3 of rev 0f, page 11:
Byte offset Description Attribute Value
09h Programming Interface Code | See Table 4 | Defined in table 1
0Ah Subclass code Read-only 01h - IDE
0Bh Base class code Read-only 01h - Mass Storage
and to your surprise, my IDE interface is:
00:1f.1 Class 0101: 8086:244b (rev 05) (prog-if 80 [Master])
so if this device should not have Class 0101, then there is certainly
some problem somewhere.
> The context of what is the EOT between the two HOST protocols has no
> meaning.
Yes? Then please tell me what chapter 6, PCI Compatibility and Native
Bus Master Adapters, pages 22-28 of rev 0c, talks about...
In rev 0f it is chapter 5, same name, PDF pages 19-26, document pages 10-17.
EOT is back here in this revision, so actually current standard is OK,
and Intel is misbehaving (or maybe just "extending" standard?).
And if you insist that this chapter does not describe UDMA busmastering
programming interface, then please point me to the correct document.
There is no other document with simillar name on the T13 web.
Petr Vandrovec
[email protected]
Petr,
No d1510r0c.pdf refers to a new created device class 0x0105.
But then again you do not read or vote on the documents so why should I
expect more from you?
[root@xathy root]# lspci
00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System Controller (rev 11)
00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP Bridge00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 02)
00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev 03)
00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ACPI (rev 02)
00:08.0 Unknown mass storage controller: CMD Technology Inc: Unknown device 3112 (rev 01)
00:09.0 Ethernet controller: Intel Corp. 82543GC Gigabit Ethernet Controller (rev 02)
00:10.0 PCI bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] PCI (rev 02)
01:05.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01)
02:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-768 [Opus] USB (rev 07)
02:04.0 Class 0105: Pacific Digital Corp: Unknown device 1841 (rev 40)
02:06.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 21)
Now LOOK who is STUPID NOW!
Now read the head of the document and the name of the company?
Now go look at page 26 table 14.
Some day you will learn I am an expert in my field. I have the hardware
that document refers to and you are smoking a crack pipe.
Proper document you want, heh? e02105r0 amendment to d1510r0c.pdf
For those who are clueless "Petr Vandrovec", e02105r0 is a direct
reference to the retired SFF-8038i document orginally put forward by
Intel.
If I did not know any better, you are becoming what I used to be.
Regards,
Andre Hedrick
LAD Storage Consulting Group
On Fri, 16 Aug 2002, Petr Vandrovec wrote:
> On 16 Aug 02 at 2:27, Andre Hedrick wrote:
> > On Fri, 16 Aug 2002, Petr Vandrovec wrote:
> >
> > > Yes. If you'll look at d1510r0c.pdf from ATA guys, you'll find that
> >
> > BUZZIT!
> >
> > That is an totally new transport protocol and if you research the pci
> > device class you would know that it has nothing to do with the problem.
> > If you guys are playing with ADMA on DMA Hosts, oh my!
>
> No. It just reveals that you have no idea what you are talking about.
> It was proven when you talked about EDD, and now it is proven again.
> Table 3 of rev 0f, page 11:
>
>
> Byte offset Description Attribute Value
> 09h Programming Interface Code | See Table 4 | Defined in table 1
> 0Ah Subclass code Read-only 01h - IDE
> 0Bh Base class code Read-only 01h - Mass Storage
>
> and to your surprise, my IDE interface is:
> 00:1f.1 Class 0101: 8086:244b (rev 05) (prog-if 80 [Master])
> so if this device should not have Class 0101, then there is certainly
> some problem somewhere.
>
> > The context of what is the EOT between the two HOST protocols has no
> > meaning.
>
> Yes? Then please tell me what chapter 6, PCI Compatibility and Native
> Bus Master Adapters, pages 22-28 of rev 0c, talks about...
>
> In rev 0f it is chapter 5, same name, PDF pages 19-26, document pages 10-17.
> EOT is back here in this revision, so actually current standard is OK,
> and Intel is misbehaving (or maybe just "extending" standard?).
>
> And if you insist that this chapter does not describe UDMA busmastering
> programming interface, then please point me to the correct document.
> There is no other document with simillar name on the T13 web.
> Petr Vandrovec
> [email protected]
>
>
Petr,
Try reading the entire document first before commenting and showing why
people should not believe you.
The author went through great lengths to explain and capture what
SFF-8038i defined. The object is to show the difference.
Now carefully look and see that BAR4 in d1510 is not the same as
BAR 4 for SFF-8038i.
Regards,
Andre Hedrick
LAD Storage Consulting Group
On Fri, 16 Aug 2002, Petr Vandrovec wrote:
> On 16 Aug 02 at 2:27, Andre Hedrick wrote:
> > On Fri, 16 Aug 2002, Petr Vandrovec wrote:
> >
> > > Yes. If you'll look at d1510r0c.pdf from ATA guys, you'll find that
> >
> > BUZZIT!
> >
> > That is an totally new transport protocol and if you research the pci
> > device class you would know that it has nothing to do with the problem.
> > If you guys are playing with ADMA on DMA Hosts, oh my!
>
> No. It just reveals that you have no idea what you are talking about.
> It was proven when you talked about EDD, and now it is proven again.
> Table 3 of rev 0f, page 11:
>
>
> Byte offset Description Attribute Value
> 09h Programming Interface Code | See Table 4 | Defined in table 1
> 0Ah Subclass code Read-only 01h - IDE
> 0Bh Base class code Read-only 01h - Mass Storage
>
> and to your surprise, my IDE interface is:
> 00:1f.1 Class 0101: 8086:244b (rev 05) (prog-if 80 [Master])
> so if this device should not have Class 0101, then there is certainly
> some problem somewhere.
>
> > The context of what is the EOT between the two HOST protocols has no
> > meaning.
>
> Yes? Then please tell me what chapter 6, PCI Compatibility and Native
> Bus Master Adapters, pages 22-28 of rev 0c, talks about...
>
> In rev 0f it is chapter 5, same name, PDF pages 19-26, document pages 10-17.
> EOT is back here in this revision, so actually current standard is OK,
> and Intel is misbehaving (or maybe just "extending" standard?).
>
> And if you insist that this chapter does not describe UDMA busmastering
> programming interface, then please point me to the correct document.
> There is no other document with simillar name on the T13 web.
> Petr Vandrovec
> [email protected]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On 16 Aug 02 at 3:23, Andre Hedrick wrote:
> Try reading the entire document first before commenting and showing why
> people should not believe you.
>
> The author went through great lengths to explain and capture what
> SFF-8038i defined. The object is to show the difference.
>
> Now carefully look and see that BAR4 in d1510 is not the same as
> BAR 4 for SFF-8038i.
Chapter 5 describes IDE class devices, PCI class 0101. If this chapter
is not normative definition, then it should be clearly stated in the
document, besides that it has no bussiness being there if it is just
for comparsion - just replace whole chapter with reference to the SFF-8038i.
Chapter 3, ATA Host Adapters, and also document name, ATA Host Adapters
Standards, makes strong impression to me that document is normative
for all host adapters. If you'll write chapter 5 in same style
chapter 4 is written (few lines, no registers description), and you'll
change document name, nobody will use it as normative document for
non-ADMA devices. But with current wording it is just normative
document for both PCI IDE DMA and ADMA hosts, even if T13 intentions
were different - document language matters, not intentions.
And amendment you pointed me to strongly signals that also Intel
believe[sd] that document is (in future) normative for PCI IDE DMA host
adapters, not only for ADMA ones.
I was also impression (from the T13 meeting notes in Feb 20-22 2001
(meetings/e01114r0.pdf, 12.6)) that d1510 is successor of SFF8038.
If it adopts PCI DMA, it should document it (as it does now). If
it obsolete this interface, it should not document it...
Petr Vandrovec
[email protected]
Petr,
I know exactly what the document started out as and the intentions and the
transformations to what it is now.
The intent was to describe a new HOST protocol.
Something like FP-DMA which is similar to what SBP-2 maps.
Now the document I pointed to as an ammendment had a pre-release only
handed out in paper. There are no e-copies, and it was the intent of the
second author to preserve the original definition and terms used by 8038i.
Next T13 has no business defining HOST standards it is DISK committee.
Go fish :-/
Now if the lastest evolution of the d1510 has an error well it needs to be
fixed. Since I know what it is to do and how it does and the intent, I do
not used them for references.
But for the record you are required to have the EOT set if you are using
8038i protocols.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Fri, 16 Aug 2002, Petr Vandrovec wrote:
> On 16 Aug 02 at 3:23, Andre Hedrick wrote:
> > Try reading the entire document first before commenting and showing why
> > people should not believe you.
> >
> > The author went through great lengths to explain and capture what
> > SFF-8038i defined. The object is to show the difference.
> >
> > Now carefully look and see that BAR4 in d1510 is not the same as
> > BAR 4 for SFF-8038i.
>
> Chapter 5 describes IDE class devices, PCI class 0101. If this chapter
> is not normative definition, then it should be clearly stated in the
> document, besides that it has no bussiness being there if it is just
> for comparsion - just replace whole chapter with reference to the SFF-8038i.
>
> Chapter 3, ATA Host Adapters, and also document name, ATA Host Adapters
> Standards, makes strong impression to me that document is normative
> for all host adapters. If you'll write chapter 5 in same style
> chapter 4 is written (few lines, no registers description), and you'll
> change document name, nobody will use it as normative document for
> non-ADMA devices. But with current wording it is just normative
> document for both PCI IDE DMA and ADMA hosts, even if T13 intentions
> were different - document language matters, not intentions.
>
> And amendment you pointed me to strongly signals that also Intel
> believe[sd] that document is (in future) normative for PCI IDE DMA host
> adapters, not only for ADMA ones.
>
> I was also impression (from the T13 meeting notes in Feb 20-22 2001
> (meetings/e01114r0.pdf, 12.6)) that d1510 is successor of SFF8038.
> If it adopts PCI DMA, it should document it (as it does now). If
> it obsolete this interface, it should not document it...
> Petr Vandrovec
> [email protected]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Fri, 16 Aug 2002, Petr Vandrovec wrote:
> On 16 Aug 02 at 3:23, Andre Hedrick wrote:
> > Try reading the entire document first before commenting and showing why
> > people should not believe you.
> >
> > The author went through great lengths to explain and capture what
> > SFF-8038i defined. The object is to show the difference.
> >
> > Now carefully look and see that BAR4 in d1510 is not the same as
> > BAR 4 for SFF-8038i.
>
> Chapter 5 describes IDE class devices, PCI class 0101. If this chapter
>
> Chapter 3, ATA Host Adapters, and also document name, ATA Host Adapters
ATA class devices, PCI class 0105.
This what you missed, this what we are debating. :-/
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Petr,
First an apology for the earlier pounce, please accept.
Second, we did this already and I think vger barfed.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On 20 Aug 2002, Petr Vandrovec wrote:
> On 16 Aug 02 at 2:27, Andre Hedrick wrote:
> > On Fri, 16 Aug 2002, Petr Vandrovec wrote:
> >
> > > Yes. If you'll look at d1510r0c.pdf from ATA guys, you'll find that
> >
> > BUZZIT!
> >
> > That is an totally new transport protocol and if you research the pci
> > device class you would know that it has nothing to do with the problem.
> > If you guys are playing with ADMA on DMA Hosts, oh my!
>
> No. It just reveals that you have no idea what you are talking about.
> It was proven when you talked about EDD, and now it is proven again.
> Table 3 of rev 0f, page 11:
>
>
> Byte offset Description Attribute Value
> 09h Programming Interface Code | See Table 4 | Defined in table 1
> 0Ah Subclass code Read-only 01h - IDE
> 0Bh Base class code Read-only 01h - Mass Storage
>
> and to your surprise, my IDE interface is:
> 00:1f.1 Class 0101: 8086:244b (rev 05) (prog-if 80 [Master])
> so if this device should not have Class 0101, then there is certainly
> some problem somewhere.
>
> > The context of what is the EOT between the two HOST protocols has no
> > meaning.
>
> Yes? Then please tell me what chapter 6, PCI Compatibility and Native
> Bus Master Adapters, pages 22-28 of rev 0c, talks about...
>
> In rev 0f it is chapter 5, same name, PDF pages 19-26, document pages 10-17.
> EOT is back here in this revision, so actually current standard is OK,
> and Intel is misbehaving (or maybe just "extending" standard?).
>
> And if you insist that this chapter does not describe UDMA busmastering
> programming interface, then please point me to the correct document.
> There is no other document with simillar name on the T13 web.
> Petr Vandrovec
> [email protected]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>