Bridgeport Retrofit - keyboard input delays noted

Mother board is a FOXCONN 45CTP
Processor is an Intel Atom 230 @1.60GHz
Graphics (from BIOS)
Internal Graphics = PCI/IGD (other option is IGD)
Internal Graphics Mode = ena, 8M (no other option)
DVMT Mode Selected = DVMT Mode (options are FIXED MODE, DVMT MODE, COMBO MODE)
DVMT Fixed Memory = 128M
Hi Performance Event Timer = enabled

Ok. Was the lspci -vv thing a test? Figured that one out. Not intuitive for a novice. Learning all kinds of new things here. File attached.

Thanks to all for the assistance.
Mark

Sorry. Forgot to respond to the question about the isolcpus parameter. The only thing changed (at the very beginning of this adventure) was the grub.cfg file. Added statement to the line which started the rtai process to turn off acpi and that quiet splash param. See cut paste below.

linux /boot/vmlinuz-2.6.32-122-rtai root=UUID=4624519c-a479-4085-9013-92cb54476840 ro quiet splash acpi=off

Since I believe this is not a dual core processor, I ignored all of the data/dialog around cpu hog et al.

I don't know how to tell if this is set but I don't believe so. isolcpus=1 on the kernel parameter line

Mark

Here is an update showing the halcmd show all.

The machine was in its "delayed state" when I executed the line.

If I am reading this right I have one cpu. See attached.

well nothing obvious there, the RT stuff seems OK

It may be the only way to debug this is start with a very basic config
without all the bells and whistles and slowly add stuff back to see where it goes bad...

Processor is an Intel Atom 230 @1.60GHz

OK its a very early single core processor, so forget the dual core stuff

00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
Subsystem: Foxconn International, Inc. Device 0d4b
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 10
Region 0: Memory at fe980000 (32-bit, non-prefetchable) [size=512K]
Region 1: I/O ports at dc00
Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]
Region 3: Memory at fe940000 (32-bit, non-prefetchable) [size=256K]
Capabilities: <access denied>
Kernel modules: i915

This Intel driver does not normally give problems, it is being used on my machine, nor does intel-agp on the host bridge

Would be worth doing
apt-get install --reinstall xserver-xorg-video-intel
to make sure everything is as it should be and you have the latest version.

regards

I had considered backing out all of the custom Hal stuff used to enable the shuttlepro but wanted to engage you experts before I used my typical brute force approach. I.e. Back out the most recent change. Repeat until symptoms return to normal. Other custom stuff is used to interface into my interact electronics.

It seems to me that my customization isn't the root cause. It has just exposed a deeper problem. .

Think I will wait until I hear back re. ArcEye comments.

Mark

ArcEye, I reinstalled that xserver video package.

No change in performance. I did confirm that the delay is still evident.

Do you agree with PWC? Is my next best step to start removing the "bells and whistles" from my hal files? Or is there something else which can be done to further t/s this bugger?

Mark

I had considered backing out all of the custom Hal stuff used to enable the shuttlepro but wanted to engage you experts before I used my typical brute force approach. I.e. Back out the most recent change. Repeat until symptoms return to normal. Other custom stuff is used to interface into my interact electronics.

It seems to me that my customization isn't the root cause. It has just exposed a deeper problem. .

Think I will wait until I hear back re. ArcEye comments.

A suggestion was made yesterday about increasing beyond the installed1G memory. I dismissed it because i don't have a 2G simm laying around and the SYS monitor showed that I wasn't using more than half of it now. I think I now understand that the monitor does record real time CPU so does it follow that the mem stats are also misleading? Is it possible that I am starved for memory?

Mark

As much as I dislike troubleshooting with my wallet, I went out and bought memory. It is now at 2GB. I checked BIOS and confirmed the system sees the full 2 G. I booted the system and looked at the System Monitor and confirmed the OS sees the memory.

Is there something that I need to do to ensure/confirm that LinuxCNC has magically reconfigured itself (if necessary) to use the 2G? Because....

I have seen no change in symptoms. With a single exception...

The more I work with this the more I observe so I will convey another observation. When I initially installed the memory and fired up LinuxCNC I ran through the "Mark Process" which I use to observe the symptoms. Interestingly enough, the dang thing seemed better. I ran through the Mark Process 3x and it didn't fail. No delays. So naturally, I go have dinner.

When I came back, I ran the Mark Process. Lo and behold, it exhibits the symptoms again.

I'm now thinking "memory leak". That is what we non-technical types hear you techies say when memory is not properly released/de-allocated. My thinking was if more memory was available (for misuse by the OS) then it would logically take longer to be consumed to the point where a symptom presented itself. So I figure I'll clean up the memory. I'll reboot and observe. Hmmmm. So much for my logic. No difference.

So now I wonder if there is some magical commands to ensure LinuxCNC can use my newly purchased memory?

Thoughts?

Mark