* Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help
2005-07-18 22:08 ANNOUNCE: Driver for Rocky 4782E WDT and pls help Gyorgy Horvath
@ 2005-07-18 16:34 ` Alan Cox
2005-07-19 17:48 ` Gyorgy Horvath
2005-07-20 0:28 ` Gyorgy Horvath
0 siblings, 2 replies; 6+ messages in thread
From: Alan Cox @ 2005-07-18 16:34 UTC (permalink / raw)
To: Gyorgy Horvath; +Cc: linux-kernel
On Llu, 2005-07-18 at 15:08 -0700, Gyorgy Horvath wrote:
> - Half of the RAM were stolen from Linux.
> (mem=xxxx 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* ANNOUNCE: Driver for Rocky 4782E WDT and pls help
@ 2005-07-18 22:08 Gyorgy Horvath
2005-07-18 16:34 ` Alan Cox
0 siblings, 1 reply; 6+ messages in thread
From: Gyorgy Horvath @ 2005-07-18 22:08 UTC (permalink / raw)
To: linux-kernel
Hi out there,
I am VERY SAD to announce a new driver for the
watchdog on Rocky 4782E2V processor card.
The architecture is very close to "Acquire WDT".
Effectivelly one or two additional line is needed, that allow
programming the timeout and properly kick the dog.
Writing a byte with the number of seconds to 0x0443
in the device open function will configure the timeout.
Ping needs a close before rearming.
I have compiled with CONFIG_WATCHDOG_NOWAYOUT and worked.
echo "1" > /dev/watchdog
15,14,13,...3,2,1,0 Booom.
The driver - rockywdt - can be downloaded from here
http://alpha.tmit.bme.hu/~horvaath/lk/rockywdt.tar.gz
The watchdog daemon can be pulled from the Debian pool.
CC-me on replies please.
P.S. Why I am so sad?
---------------------
I'll tell you.
In the most recent application of SGA155D dual
SONET/SDH PCI adapter I have to pass thru POS
traffic - but hold on the packets for a while.
The things are now perfect. It can do 20..30 Mbytes/sec
but there is a very strange side effect - decribed below.
1. Metrics: Moderate load
- cca. 60000 packets/second A-In, B-Out, B-In, A-Out - for each
- cca. 4x5 Mbytes/sec R/W on the PCI bus, a Concorde can
easily land between my two DMA R/Ws.
- packet size = 80 bytes
- SGA155D generates interrupt in every 100 usec. Everything is
made here resulting 5% system load when idle, and 14% when fired.
- Half of the RAM were stolen from Linux.
(mem=xxxx kernel parameter)
This range was requeset_mem_region-ed, then
ioremap-ped for bus mastering DMA transfer.
Actually 30 M is used.
(cat /proc/iomem shows 0c800000-0e7fffff : sga155d0)
- The granulity of the DMA transfer is 128 bytes (64 DWORDS) per turn.
The card reqests the PCI bus for each turn, then release it.
(Note that each packet can get thru in one turn)
- Total of 16M small blocks were vmalloc-ed to keep track on
flows. This blocks has been kicked randomly upon each packet
arrival (2x60000 times/sec) by the Interrupt routine.
- Linux: Latest Debian woody
- Kernel: kernel-source-2.4.18 (1..3)
2. Technique
- On Rx - the card do everything. Once it fired - it fills the DMA
buffer, and once reach the end it restarts from the beginning.
There is no need for any kind of intervention from the PC.
It's progress is snooped through a stabilized regitser showing
where the DMA write address currently is.
- The interrupt routine contact the vmalloc-ed blocks to schedule
the transmission.
- On Tx - the interrupt routine writes a register with the
address of the packet to send. There is no flow control here either.
If the transmit queue (taking that register) is full, the
packet is then simply dropped and counted.
3. Good news
- Every single inbound packet has been succesfully sent at
this load. No miss-sequence, no CRC, none... Seamless.
- PCI slots behind the backplane's DECHIP PCI bridge
can perform up to this rate without packet loss.
At higher rates rx drops arises.
- Slots routed directly from the CPU card well outperform this.
- It can do for more than a day continously if unattended (see below).
4. Bad news
- Issuing a simple ls -la / surelly causes instant death.
Instant mean -> not a single last breath. (no kernel printouts)
Death mean -> plain dead. Only hard reset is working here.
5. The chalenge
5.1 - Fire up the card
- Apply the load
- Issue - let say - lynx
- Dead :-(
5.2 - Fire up the card
- Issue lynx - OK
- Apply the load
- Issue lynx again - OK :-O
- Issue ls -la /
- Dead :-S
5.3 - Fire up the card
- issue lynx - OK
- issue ls -la / -OK
- Apply the load
- Issue pos sga155d0 -x (thats a control app)
- Dead :-Z
5.4 - Fire up the card
- issue lynx - OK
- Apply the load
- issue lynx - OK
- Sieze the load !!!!!!
- issue ls -la / -OK !!
- Reapply the load
- Issue pos sga155d0 -x
- Dead ;-/
... etc ...
6. Investigation
At the very beginning I spent a lot of time finding a
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.
Therefore at at higher load some packet loss may occur.
(I'will enlarge some FIFO's to bridge out this)
I have gdb-d my 'crashing' controll app and found that a
simple sscanf causes the sudden death.
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?
Besides the system is responsive and stable during that load
- if I try things have been tried already before the load
is applied. I am using ssh to control the box for example.
This is the point where I gave up. I will modify the fire-up
script so that every usual app will be preloaded/cahced once
before applying the load. Also, a watchdog will be settled.
(Just in case someone issuing a fortune accidentally :-).
Hmmm... I am wondering how to preload reboot or halt...
That is why I AM SO SAD.
7. Suspects
Yes, I know that I am using Linux for something - not intended to.
My suspects are the following:
- The way I do the things eats-up something that is vital for Linux.
- Linux hangs at the very point when a portion of a shared object, or
an application is going to be mapped? or cached? into the memory
space.
I smell some MMU/VM's smoke. I tried ioremap_nocache, but none
- except that system load is up to 75% when fired.
I put kmalloc/vmalloc-ed stuff under my ioremap-ped region.
None.
8. Reason: Unknown (for me)
Can anybody help out there with this?
http://alpha.tmit.bme.hu/~horvaath/lk/sga155d.tar.gz
-- --
sga155d.c - Core driver for IP-Core management
d1550382.c - This the real driver for the IP-Core (0xD1550382)
-- --
Do not beat me for the aboves. I am in terrible hurry, so
there are a lot of Quick-And-Dirty work in them.
Best regards
Gyuri
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help
2005-07-19 17:48 ` Gyorgy Horvath
@ 2005-07-19 9:20 ` Alan Cox
2005-07-19 19:29 ` Gyorgy Horvath
0 siblings, 1 reply; 6+ messages in thread
From: Alan Cox @ 2005-07-19 9:20 UTC (permalink / raw)
To: Gyorgy Horvath; +Cc: linux-kernel
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help
2005-07-18 16:34 ` Alan Cox
@ 2005-07-19 17:48 ` Gyorgy Horvath
2005-07-19 9:20 ` Alan Cox
2005-07-20 0:28 ` Gyorgy Horvath
1 sibling, 1 reply; 6+ messages in thread
From: Gyorgy Horvath @ 2005-07-19 17:48 UTC (permalink / raw)
To: Alan Cox, linux-kernel
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: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000010000000 (usable)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffb00000 - 0000000100000000 (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 0x08000000 upto,
and I did not see any overlapping/conflicts.
cat /proc/iomem shows:
----- /proc/iomem portion ---------
08000000-09ffffff : sga155d0
0a000000-0a07ffff : sga155d0
0a080000-0a0fffff : sga155d0
0a100000-0a13ffff : sga155d0
0a140000-0a77ffff : sga155d0
0a780000-0a7bffff : sga155d0
0a7c0000-0adfffff : sga155d0
d0000000-dfffffff : 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 --
name value min max mode
---- ----- --- --- ----
bios_cyl 2482 0 65535 rw
bios_head 255 0 255 rw
bios_sect 63 0 63 rw
.... blah-blah ...
pio_mode write-only 0 255 w
slow 0 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.......... 46967648 46943282
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.......... 47020352 46967837
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 e0000000 (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: 0000c000-0000cfff
Memory behind bridge: e5000000-e50fffff
Prefetchable memory behind bridge: d0000000-dfffffff
BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-
00:1e.0 PCI bridge: Intel Corp. 82820 820 (Camino 2) Chipset PCI (rev
05) (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: 0
Bus: primary=00, secondary=02, subordinate=03, sec-latency=32
I/O behind bridge: 00008000-0000bfff
Memory behind bridge: e4000000-e4ffffff
Prefetchable memory behind bridge: fff00000-000fffff
BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
00:1f.0 ISA bridge: Intel Corp. 82820 820 (Camino 2) Chipset ISA Bridge
(ICH2) (rev 05)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
00:1f.1 IDE interface: Intel Corp. 82820 820 (Camino 2) Chipset IDE U100
(rev 05) (prog-if 80 [Master])
Subsystem: Intel Corp.: Unknown device 2442
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Region 4: I/O ports at f000 [size=16]
00:1f.3 SMBus: Intel Corp. 82820 820 (Camino 2) Chipset SMBus (rev 05)
Subsystem: Intel Corp.: Unknown device 2442
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin B routed to IRQ 17
Region 4: I/O ports at 5000 [size=16]
00:1f.5 Multimedia audio controller: Intel Corp. 82820 820 (Camino 2)
Chipset AC'97 Audio Controller (rev 05)
Subsystem: Unknown device 414c:4710
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 17
Region 0: I/O ports at dc00 [size=256]
Region 1: I/O ports at e000 [size=64]
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS]:
Unknown device 0325 (prog-if 00 [VGA])
Subsystem: Silicon Integrated Systems [SiS]: Unknown device 0325
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 39 (750ns min, 4000ns max)
BIST result: 00
Region 0: Memory at d0000000 (32-bit, prefetchable) [size=256M]
Region 1: Memory at e5000000 (32-bit, non-prefetchable) [size=256K]
Region 2: I/O ports at c000 [size=128]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] AGP version 2.0
Status: RQ=15 SBA- 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
02:08.0 Ethernet controller: Intel Corp. 82820 (ICH2) Chipset Ethernet
Controller (rev 03)
Subsystem: Intel Corp.: Unknown device 3010
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), cache line size 08
Interrupt: pin A routed to IRQ 20
Region 0: Memory at e4e01000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at ac00 [size=64]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
02:0b.0 Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev 08)
Subsystem: Intel Corp. EtherExpress PRO/100+ Server Adapter (PILA8470B)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), cache line size 08
Interrupt: pin A routed to IRQ 17
Region 0: Memory at e4e02000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at a000 [size=64]
Region 2: Memory at e4d00000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at <unassigned> [disabled] [size=1M]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
02:0c.0 ATM network controller: Technical University of Budapest:
Unknown device d155 (rev 11) (prog-if ff)
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: 32
Interrupt: pin A routed to IRQ 16
Region 0: Memory at e4e05000 (32-bit, non-prefetchable) [size=64]
Region 1: Memory at e4e00000 (32-bit, non-prefetchable) [size=1K]
Region 2: Memory at e4000000 (32-bit, non-prefetchable) [size=2M]
Region 3: I/O ports at a400 [size=256]
Region 4: I/O ports at a800 [size=256]
02:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 06)
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Bus: primary=02, secondary=03, subordinate=03, sec-latency=32
I/O behind bridge: 00008000-00009fff
Memory behind bridge: e4200000-e49fffff
Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
02:0f.0 ATM network controller: Technical University of Budapest:
Unknown device d155 (rev 11) (prog-if ff)
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: 32
Interrupt: pin A routed to IRQ 17
Region 0: Memory at e4e03000 (32-bit, non-prefetchable) [size=64]
Region 1: Memory at e4e04000 (32-bit, non-prefetchable) [size=1K]
Region 2: Memory at e4a00000 (32-bit, non-prefetchable) [size=2M]
Region 3: I/O ports at b000 [size=256]
Region 4: I/O ports at b400 [size=256]
03:05.0 ATM network controller: Technical University of Budapest:
Unknown device d155 (rev 11) (prog-if ff)
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: 32
Interrupt: pin A routed to IRQ 16
Region 0: Memory at e4805000 (32-bit, non-prefetchable) [size=64]
Region 1: Memory at e4802000 (32-bit, non-prefetchable) [size=1K]
Region 2: Memory at e4200000 (32-bit, non-prefetchable) [size=2M]
Region 3: I/O ports at 8000 [size=256]
Region 4: I/O ports at 8400 [size=256]
03:07.0 ATM network controller: Technical University of Budapest:
Unknown device d155 (rev 11) (prog-if ff)
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: 32
Interrupt: pin A routed to IRQ 18
Region 0: Memory at e4800000 (32-bit, non-prefetchable) [size=64]
Region 1: Memory at e4801000 (32-bit, non-prefetchable) [size=1K]
Region 2: Memory at e4400000 (32-bit, non-prefetchable) [size=2M]
Region 3: I/O ports at 8800 [size=256]
Region 4: I/O ports at 8c00 [size=256]
03:09.0 ATM network controller: Technical University of Budapest:
Unknown device d155 (rev 11) (prog-if ff)
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: 32
Interrupt: pin A routed to IRQ 16
Region 0: Memory at e4803000 (32-bit, non-prefetchable) [size=64]
Region 1: Memory at e4804000 (32-bit, non-prefetchable) [size=1K]
Region 2: Memory at e4600000 (32-bit, non-prefetchable) [size=2M]
Region 3: I/O ports at 9000 [size=256]
Region 4: I/O ports at 9400 [size=256]
---------------- lspci -vvv end
---------------------------------------------
Best regards
Gyuri
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help
2005-07-19 9:20 ` Alan Cox
@ 2005-07-19 19:29 ` Gyorgy Horvath
0 siblings, 0 replies; 6+ messages in thread
From: Gyorgy Horvath @ 2005-07-19 19:29 UTC (permalink / raw)
To: Alan Cox, linux-kernel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help
2005-07-18 16:34 ` Alan Cox
2005-07-19 17:48 ` Gyorgy Horvath
@ 2005-07-20 0:28 ` Gyorgy Horvath
1 sibling, 0 replies; 6+ messages in thread
From: Gyorgy Horvath @ 2005-07-20 0:28 UTC (permalink / raw)
To: Alan Cox, linux-kernel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-07-19 15:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-07-18 22:08 ANNOUNCE: Driver for Rocky 4782E WDT and pls help Gyorgy Horvath
2005-07-18 16:34 ` Alan Cox
2005-07-19 17:48 ` Gyorgy Horvath
2005-07-19 9:20 ` Alan Cox
2005-07-19 19:29 ` Gyorgy Horvath
2005-07-20 0:28 ` Gyorgy Horvath
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox