Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help
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
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
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
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
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
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/
ANNOUNCE: Driver for Rocky 4782E WDT and pls help
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. 6 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= 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 0c80-0e7f : 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 (2x6 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
ANNOUNCE: Driver for Rocky 4782E WDT and pls help
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. 6 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= 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 0c80-0e7f : 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 (2x6 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
