2.5.31 boot failure on pdc20267

DISCUSSION Petr Vandrovec 2 participants 4 messages Aug 16, 2002 – Aug 21, 2002

Share & tools

Petr Vandrovec

author

2002-08-16 09:46 UTC #0 lore raw

Quoted 9 lines · Andre Hedrick

Quoted 1 line · Petr Vandrovec
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.

Quoted 2 lines

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]

Andre Hedrick

2002-08-16 10:15 UTC #1 lore raw

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

Quoted 43 lines · Petr Vandrovec

Quoted 9 lines · Andre Hedrick
Quoted 1 line · Petr Vandrovec
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.
Quoted 2 lines
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]

Andre Hedrick

2002-08-16 10:28 UTC #2 lore raw

Part 2: Re: 2.5.31 boot failure on pdc20267

In reply to Petr Vandrovec

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

Quoted 48 lines · Petr Vandrovec

Quoted 9 lines · Andre Hedrick
Quoted 1 line · Petr Vandrovec
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.
Quoted 2 lines
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/

Andre Hedrick

2002-08-21 00:15 UTC #3 lore raw

GroundHog Day ?? {Re: 2.5.31 boot failure on pdc20267}

In reply to Petr Vandrovec

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

Quoted 48 lines · Petr Vandrovec

Quoted 9 lines · Andre Hedrick
Quoted 1 line · Petr Vandrovec
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.
Quoted 2 lines
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/