Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help

2005-07-19 Thread Gyorgy Horvath

Hi again,

I have scanned IHC errata for this Rocky stuff.

First, lspi -vvv said that Rocky has 82820.
Hmm... I have a phy look at the card and see 82801.
OK.
I went to the Intel site, and downloaded the spec updates
for it.

http://www.intel.com/design/chipsets/mobile/documentation845.htm#specupdates
Intel (R) 82801CAM I/O Controller Hub 3 (ICH3-M)
Specification Update

-- -- --
Errata 22. IDE Hang Issue

Problem:

An arbitration deadlock in the ICH3-M may occur if
IDE traffic is combined with heavy graphic traffic and
internal/external PCI Bus Master traffic to memory.

Implication:

This issue may lockup the IDE bus master causing a
system hang. This issue was found during ongoing internal
validation using a synthetic test environment and there
have been no failures reported by customers.

Workaround:

BIOS needs to set configuration register
(Device 31, Function 0, offset FCh, bit 23) to prevent the
arbitration deadlock. Contact your local Intel Field
representative if you require more detailed
BIOS workaround information.

-- -- --
Errata 24. DWORD I/O Cycle Native Mode IDE Issue

Problem:

An I/O read crossing a DWORD boundary being sent
from processor to the ICH3-M may not complete correctly.
The ICH3-M will treat such a transaction as two single DWORD
I/O accesses.
If native mode IDE addressing is enabled, the ICH3-M will
return the first I/O cycle completion request to the MCH
but the second I/O cycle may get decoded to the IDE
controller instead of its intended address.

Implication:

System may hang while processor waits for return of I/O cycle.

Workaround:

Disable Native Mode IDE in BIOS. See ICH3-M BIOS Specification
Update for more details.
-- -- --
There are A LOT of other issues, but the aboves may be relevant.
I am going to try them.
Can you guide me where can I place the mentioned workarounds?
Also - how can I check that we are REALLY facing this chipset?
Are the PCI ID's enough?
(btw. lspci makes me fool)

Also, disabling IDE DMA caused an other side effect.
At a Poisson distributed moment - my interrupt from
the SGA155D simply can not get thru.

It is a known issue for me. SGA1GED dual gigabit
ethernet (monitor) card produced the same on a brand new
PC (blue lights from the power supply, etc... :-).

Since the chipset is so new - no IDE DMA in 2.4.18 for this.
It is not a real problem since we have a 3ware raid in place.
Now it is 14 days up, and cca. 160 Giga of headers were captured.
(students are on their holliday - that is why so few data)
The workaround was QED. The capture task reads AMCC S5933
when the IT count is stalled for a while.
That rearms the IT logic - and the show goes on.

Unfortunatelly, for the POS stuff this trick cannot be used.
Precise timing for TX schedule is vital.

So I have to dig further.

Best regards

Gyuri

-
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/


Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help

2005-07-19 Thread Gyorgy Horvath

Alan Cox wrote:


There are not, but I've seen various boxes behave the way you describe
with IDE DMA enabled as IDE DMA uses a lot of the PCI bandwidth. Usually
it indicates a hardware bug and as far as ICH errata are concerned I
know of none relevant. You can check however as Intel put most chipset
errata docs on their website.
 


Thank you for your help.
Now I temporarily put the box back to the fields with IDE-DMA disabled.

Thought I rememeber IDE busmastering prefers very long bursts in contrast to
my very short but high-rate bursts. This can lead it into trouble...
Anyway,  I'm going after and report back if I found something.

Best regards,

Gyuri

-
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/


Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help

2005-07-19 Thread Alan Cox
On Maw, 2005-07-19 at 10:48 -0700, Gyorgy Horvath wrote:
>  Alan - YOU KNOW SOMETHING !!
> 
> The system can go without IDE dma for this particular application,
> but it would be better to go with it ...
> 
> Are there any known issues about the chipsets down here?
> Concerning IDE's ultra DMA?

There are not, but I've seen various boxes behave the way you describe
with IDE DMA enabled as IDE DMA uses a lot of the PCI bandwidth. Usually
it indicates a hardware bug and as far as ICH errata are concerned I
know of none relevant. You can check however as Intel put most chipset
errata docs on their website.


-
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/


Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help

2005-07-19 Thread Gyorgy Horvath

Hi,

Alan Cox wrote:


Did you make sure none of that is ACPI owned in the E820 map and that if
you set any cache properties they match and are consistent with any
Linux pagetable uses ?
 


dmesg shows:
- dmesg portion begin -
BIOS-provided physical RAM map:
BIOS-e820:  - 000a (usable)
BIOS-e820: 000f - 0010 (reserved)
BIOS-e820: 0010 - 1000 (usable)
BIOS-e820: fec0 - fec01000 (reserved)
BIOS-e820: fee0 - fee01000 (reserved)
BIOS-e820: ffb0 - 0001 (reserved)
found SMP MP-table at 000f51b0
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f2000 reserved twice.
- end of dmesg portion 

Seems OK since I claimed it from 0x0800 upto,
and I did not see any overlapping/conflicts.

cat /proc/iomem shows:
- /proc/iomem portion -
0800-09ff : sga155d0
0a00-0a07 : sga155d0
0a08-0a0f : sga155d0
0a10-0a13 : sga155d0
0a14-0a77 : sga155d0
0a78-0a7b : sga155d0
0a7c-0adf : sga155d0
d000-dfff : PCI Bus #01
 end of /proc/iomem portion ---


> Is this also true with ide=nodma ?

Let us see (lilo,reboot):
 /proc/ide/ide0/hda/settings --
namevalue   min max mode
-   --- --- 
bios_cyl24820   65535   rw
bios_head   255 0   255 rw
bios_sect   63  0   63  rw
 blah-blah ...
pio_modewrite-only  0   255 w
slow0   0   1   rw
unmaskirq   0   0   1   rw
using_dma   0   0   1   rw
-----
DMA is now off...

- Heat up the box

- Issue - let say - lynx - :-O

- Issue fortune - :-O
 It sais:
 "I never failed to convince an audience that the best thing they"
 "could do was to go away."

- Issue for files in /usr/bin/*; do eval "$files --help 1> /dev/null 
2>/dev/null&"; done


 Wooow... Still alive! Although... Hehehehehe... Pretty funny... Uuuups...
 No! Not that!

 Phuhhh It seemed the firework stopped. But cca. 100 processes 
remained up -

 like notangle,   and markup :-)
 Anyway - the DMA load is still up - 20 Mbytes/sec - and stable.

-- sga155d0 --- POS if0 --- Rx --- Other Tx--
Packets..   4696764846943282
Bytes 4132286576  4132286576
Errors-Total.  0   0
-Dropped.   9907 116
-Frame/Abort.  0   0
-CRC.  0   0
-Overrun/Underrun  0   0
-FIFO  0

-- sga155d0 --- POS if1 --- Rx --- Other Tx--
Packets..   4702035246967837
Bytes 4134610216  4134610216
Errors-Total.  0   0
-Dropped.  36172 127
-Frame/Abort.  0   0
-CRC.  0   0
-Overrun/Underrun  0   0
-FIFO  0

Only thoose dropped packets shows that something
really nasty happened to the system during my stress test.
(Normally it did not drop anything at that rate)
The watchdog slept fine - no hangs.
Time to reboot (who knows).  Succeded too - it survived.

 Alan - YOU KNOW SOMETHING !!

The system can go without IDE dma for this particular application,
but it would be better to go with it ...

Are there any known issues about the chipsets down here?
Concerning IDE's ultra DMA?

 lspci -vvv begin 
---
00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host 
Bridge (rev 04)

   Subsystem: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge
   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
   Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
SERR- 
   Latency: 0
   Region 0: Memory at e000 (32-bit, prefetchable) [size=64M]
   Capabilities: [e4] #09 [9104]
   Capabilities: [a0] AGP version 2.0
   Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2
   Command: RQ=0 SBA- AGP- 64bit- FW- Rate=

00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge 
(rev 04) (prog-if 00 [Normal decode])
   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
   Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
SERR- 
   Latency: 64
   Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
   I/O behind bridge: c000-cfff
   Memory behind bridge: 

Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help

2005-07-19 Thread Gyorgy Horvath

Hi,

Alan Cox wrote:


Did you make sure none of that is ACPI owned in the E820 map and that if
you set any cache properties they match and are consistent with any
Linux pagetable uses ?
 


dmesg shows:
- dmesg portion begin -
BIOS-provided physical RAM map:
BIOS-e820:  - 000a (usable)
BIOS-e820: 000f - 0010 (reserved)
BIOS-e820: 0010 - 1000 (usable)
BIOS-e820: fec0 - fec01000 (reserved)
BIOS-e820: fee0 - fee01000 (reserved)
BIOS-e820: ffb0 - 0001 (reserved)
found SMP MP-table at 000f51b0
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f2000 reserved twice.
- end of dmesg portion 

Seems OK since I claimed it from 0x0800 upto,
and I did not see any overlapping/conflicts.

cat /proc/iomem shows:
- /proc/iomem portion -
0800-09ff : sga155d0
0a00-0a07 : sga155d0
0a08-0a0f : sga155d0
0a10-0a13 : sga155d0
0a14-0a77 : sga155d0
0a78-0a7b : sga155d0
0a7c-0adf : sga155d0
d000-dfff : PCI Bus #01
 end of /proc/iomem portion ---


 Is this also true with ide=nodma ?

Let us see (lilo,reboot):
 /proc/ide/ide0/hda/settings --
namevalue   min max mode
-   --- --- 
bios_cyl24820   65535   rw
bios_head   255 0   255 rw
bios_sect   63  0   63  rw
 blah-blah ...
pio_modewrite-only  0   255 w
slow0   0   1   rw
unmaskirq   0   0   1   rw
using_dma   0   0   1   rw
-----
DMA is now off...

- Heat up the box

- Issue - let say - lynx - :-O

- Issue fortune - :-O
 It sais:
 I never failed to convince an audience that the best thing they
 could do was to go away.

- Issue for files in /usr/bin/*; do eval $files --help 1 /dev/null 
2/dev/null; done


 Wooow... Still alive! Although... Hehehehehe... Pretty funny... Uuuups...
 No! Not that!

 Phuhhh It seemed the firework stopped. But cca. 100 processes 
remained up -

 like notangle,   and markup :-)
 Anyway - the DMA load is still up - 20 Mbytes/sec - and stable.

-- sga155d0 --- POS if0 --- Rx --- Other Tx--
Packets..   4696764846943282
Bytes 4132286576  4132286576
Errors-Total.  0   0
-Dropped.   9907 116
-Frame/Abort.  0   0
-CRC.  0   0
-Overrun/Underrun  0   0
-FIFO  0

-- sga155d0 --- POS if1 --- Rx --- Other Tx--
Packets..   4702035246967837
Bytes 4134610216  4134610216
Errors-Total.  0   0
-Dropped.  36172 127
-Frame/Abort.  0   0
-CRC.  0   0
-Overrun/Underrun  0   0
-FIFO  0

Only thoose dropped packets shows that something
really nasty happened to the system during my stress test.
(Normally it did not drop anything at that rate)
The watchdog slept fine - no hangs.
Time to reboot (who knows).  Succeded too - it survived.

 Alan - YOU KNOW SOMETHING !!

The system can go without IDE dma for this particular application,
but it would be better to go with it ...

Are there any known issues about the chipsets down here?
Concerning IDE's ultra DMA?

 lspci -vvv begin 
---
00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host 
Bridge (rev 04)

   Subsystem: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge
   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
   Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- 
TAbort- MAbort+ SERR- PERR-

   Latency: 0
   Region 0: Memory at e000 (32-bit, prefetchable) [size=64M]
   Capabilities: [e4] #09 [9104]
   Capabilities: [a0] AGP version 2.0
   Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2
   Command: RQ=0 SBA- AGP- 64bit- FW- Rate=none

00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge 
(rev 04) (prog-if 00 [Normal decode])
   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
   Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- 
TAbort- MAbort- SERR- PERR-

   Latency: 64
   Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
   I/O behind bridge: c000-cfff
  

Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help

2005-07-19 Thread Alan Cox
On Maw, 2005-07-19 at 10:48 -0700, Gyorgy Horvath wrote:
  Alan - YOU KNOW SOMETHING !!
 
 The system can go without IDE dma for this particular application,
 but it would be better to go with it ...
 
 Are there any known issues about the chipsets down here?
 Concerning IDE's ultra DMA?

There are not, but I've seen various boxes behave the way you describe
with IDE DMA enabled as IDE DMA uses a lot of the PCI bandwidth. Usually
it indicates a hardware bug and as far as ICH errata are concerned I
know of none relevant. You can check however as Intel put most chipset
errata docs on their website.


-
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/


Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help

2005-07-19 Thread Gyorgy Horvath

Alan Cox wrote:


There are not, but I've seen various boxes behave the way you describe
with IDE DMA enabled as IDE DMA uses a lot of the PCI bandwidth. Usually
it indicates a hardware bug and as far as ICH errata are concerned I
know of none relevant. You can check however as Intel put most chipset
errata docs on their website.
 


Thank you for your help.
Now I temporarily put the box back to the fields with IDE-DMA disabled.

Thought I rememeber IDE busmastering prefers very long bursts in contrast to
my very short but high-rate bursts. This can lead it into trouble...
Anyway,  I'm going after and report back if I found something.

Best regards,

Gyuri

-
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/


Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help

2005-07-19 Thread Gyorgy Horvath

Hi again,

I have scanned IHC errata for this Rocky stuff.

First, lspi -vvv said that Rocky has 82820.
Hmm... I have a phy look at the card and see 82801.
OK.
I went to the Intel site, and downloaded the spec updates
for it.

http://www.intel.com/design/chipsets/mobile/documentation845.htm#specupdates
Intel (R) 82801CAM I/O Controller Hub 3 (ICH3-M)
Specification Update

-- -- --
Errata 22. IDE Hang Issue

Problem:

An arbitration deadlock in the ICH3-M may occur if
IDE traffic is combined with heavy graphic traffic and
internal/external PCI Bus Master traffic to memory.

Implication:

This issue may lockup the IDE bus master causing a
system hang. This issue was found during ongoing internal
validation using a synthetic test environment and there
have been no failures reported by customers.

Workaround:

BIOS needs to set configuration register
(Device 31, Function 0, offset FCh, bit 23) to prevent the
arbitration deadlock. Contact your local Intel Field
representative if you require more detailed
BIOS workaround information.

-- -- --
Errata 24. DWORD I/O Cycle Native Mode IDE Issue

Problem:

An I/O read crossing a DWORD boundary being sent
from processor to the ICH3-M may not complete correctly.
The ICH3-M will treat such a transaction as two single DWORD
I/O accesses.
If native mode IDE addressing is enabled, the ICH3-M will
return the first I/O cycle completion request to the MCH
but the second I/O cycle may get decoded to the IDE
controller instead of its intended address.

Implication:

System may hang while processor waits for return of I/O cycle.

Workaround:

Disable Native Mode IDE in BIOS. See ICH3-M BIOS Specification
Update for more details.
-- -- --
There are A LOT of other issues, but the aboves may be relevant.
I am going to try them.
Can you guide me where can I place the mentioned workarounds?
Also - how can I check that we are REALLY facing this chipset?
Are the PCI ID's enough?
(btw. lspci makes me fool)

Also, disabling IDE DMA caused an other side effect.
At a Poisson distributed moment - my interrupt from
the SGA155D simply can not get thru.

It is a known issue for me. SGA1GED dual gigabit
ethernet (monitor) card produced the same on a brand new
PC (blue lights from the power supply, etc... :-).

Since the chipset is so new - no IDE DMA in 2.4.18 for this.
It is not a real problem since we have a 3ware raid in place.
Now it is 14 days up, and cca. 160 Giga of headers were captured.
(students are on their holliday - that is why so few data)
The workaround was QED. The capture task reads AMCC S5933
when the IT count is stalled for a while.
That rearms the IT logic - and the show goes on.

Unfortunatelly, for the POS stuff this trick cannot be used.
Precise timing for TX schedule is vital.

So I have to dig further.

Best regards

Gyuri

-
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/


Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help

2005-07-18 Thread Alan Cox
On Llu, 2005-07-18 at 15:08 -0700, Gyorgy Horvath wrote:
>- Half of the RAM were stolen from Linux.
>  (mem= kernel parameter)
>  This range was requeset_mem_region-ed, then
>  ioremap-ped for bus mastering DMA transfer.
>  Actually 30 M is used.

Did you make sure none of that is ACPI owned in the E820 map and that if
you set any cache properties they match and are consistent with any
Linux pagetable uses ?

>- Issuing a simple ls -la / surelly causes instant death.

Is this also true with ide=nodma ?

>hardware bug. None. I feel it.  Although I noticed that
>someone (not me) takes control of the PC - time to time -
>for cca. 400..500 usec so that no DMA can occur.

Probably SMM firmware. Make sure you have USB driver loaded. Consider
turning ACPI and APM off

>Moreover, I have applied a breakpoint to sscanf in the
>shared.o. Disassembling the the code causes sudden death
>at a given point. The code portions were not executed, just
>disassembled. What the hell is that?

Smells like broken hardware.

-
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/


Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help

2005-07-18 Thread Alan Cox
On Llu, 2005-07-18 at 15:08 -0700, Gyorgy Horvath wrote:
- Half of the RAM were stolen from Linux.
  (mem= kernel parameter)
  This range was requeset_mem_region-ed, then
  ioremap-ped for bus mastering DMA transfer.
  Actually 30 M is used.

Did you make sure none of that is ACPI owned in the E820 map and that if
you set any cache properties they match and are consistent with any
Linux pagetable uses ?

- Issuing a simple ls -la / surelly causes instant death.

Is this also true with ide=nodma ?

hardware bug. None. I feel it.  Although I noticed that
someone (not me) takes control of the PC - time to time -
for cca. 400..500 usec so that no DMA can occur.

Probably SMM firmware. Make sure you have USB driver loaded. Consider
turning ACPI and APM off

Moreover, I have applied a breakpoint to sscanf in the
shared.o. Disassembling the the code causes sudden death
at a given point. The code portions were not executed, just
disassembled. What the hell is that?

Smells like broken hardware.

-
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/