Reports 1-1 of 1 Clear search Modify search
DGS (General)
takahiro.yamamoto - 13:28 Wednesday 07 June 2023 (25543) Print this report
Unexpected reset of GigE settings

Abstract


This is an inspection of GigE trouble reported in klog#25542.
Camera services were (maybe accidentally) restarted.
Around that time, some kernel module process went to out of control.

Details


According to the screen captures, camera settings seemed to be reset between 7:50 JST and 8:00 JST.

When I login camera server, power management module (acpi_pad) went out of control on k1cam1 as shown in Fig.1 and it's difficult to input something from a keyboard.
So I removed acpi_pad process at first and a keyboard response came back.
Because power management function is unnecessary for k1cam, it can be removed from the kernel module list which are launched at booting up computer after O4a.

I'm not sure this out of control is related to the camera trouble, camera service have surely been restarted as shown in Fig.2.

I don't know why system locale is set EDT.
It's not a problem but in addition to this, NTP doesn't work on camera server and system time is ~5min different from correct time.
So it's very tough work to confirm the time of error log.

Anyway, camera service was restarted around 8:00 JST and parameters were reset at that time.
Images attached to this report
Comments to this report:
satoru.ikeda - 15:47 Wednesday 07 June 2023 (25546) Print this report

Ushiba-san, Ikeda.

GigE camera settings that had a value of 0 after restart have been restored to the value of K-Log#25214.

MCE_TRANS, MC_REFL, POP, TMSX_G, TMSX_IR, TMSY_G, TMSY_IR
 ⇒Restored
AS, IFO_REFL, OMC_TRANS, PMC_REFL, PMC_TRANS
 ⇒Unchanged

Non-image files attached to this comment
takahiro.yamamoto - 1:13 Friday 09 June 2023 (25557) Print this report
Today some GigE movies were stopped again and rebooted.

-----
Memory usage by the free command was very small (~500MiB).
And also free region was also very small (~200MiB).
Most of memory region was categorized as "buff/cache" (~31GiB).

I checked the Slab cache as the next.
According to the slabtop, most of memory (~99%) was used by kmalloc-1024.
The details of Slab cache is as follows and most of them are uncollectable.
$ cat /proc/meminfo
Slab: 32101440 kB
SReclaimable: 27112 kB
SUnreclaim: 32074328 kB
So it cannot be released by using /proc/sys/vm/drop_caches.

And also, by seeing /proc/buddyinfo, we can know that fragments of memory region occurs on k1cam1.
It cannot be also improved by using /proc/sys/vm/compact_memory.
Memory leakage might occurs on some processes...
Anyway, k1cam1 should be rebooted once in order to clean up uncollectable RAM.
satoru.ikeda - 11:50 Tuesday 13 June 2023 (25590) Print this report

Oshino-san, Ikeda

Rebooted the k1cam1 server.

1. Appearance check
Before rebooting, we visually checked for any abnormalities around the power supply due to K-Log#25543: Unexpected reset of GigE settings. Fig-1,2

2. Reboot k1cam1
Since no abnormalities were found on the outside, we rebooted the system.
However, during the reboot, the screen hung with a black screen, so we forced a reboot by pressing and holding the power button.
After rebooting, we confirmed that the memory status had improved.Fig.3

3. Stopping the PR3 process
After restart, unused PR3 processes were stopped.

4.Set Exposure to default
We set the default value of GigE according to K-Log#25214.
 

Images attached to this comment
Non-image files attached to this comment
shoichi.oshino - 14:35 Tuesday 13 June 2023 (25595) Print this report
I found that unknown camera process POP2 was running on k1cam1.
I disabled and deleted this process from k1cam1.
Search Help
×

Warning

×