Re: systat total freeze
so i had another systat complete freeze, this time remotely, so again, no dump... sorry about another useless report, but looking at the mailing list looks like other people are experiencing hangs during disk activity. (i am speculating in this direction simply because systat's first screen after starting is the disk activity.) what kind of bug could be triggered by a process started as non-root that kills the whole system is the 20 euro question of course. as nowadays virtually everyone is in X, i think i am not the only who has difficulties getting panic messages. at any rate, i am just writing this to perhaps have an openbsd systat day (together with a towel, being douglas adams' death anniversary) and simply run systat randomly on as many machines as possible. if absolutely noone else speaks up, i'll just assume any hw of mine is simply cursed and i am d.n.a.lusional. -f -- i may be wrong, but i'm never in doubt!
Re: systat total freeze
hmm, on Sun, May 06, 2012 at 12:38:49PM -0700, Philip Guenther said that On Sun, May 6, 2012 at 3:38 AM, frantisek holop min...@obiit.org wrote: ... however on the other notebook systat froze the system solid. i have no idea how to reproduce this, obviously, running systat now works fine. Could you see the machine's console and see whether it paniced? For those that are interested in debugging from a kernel crash dump but that have Sandybridge video chipsets and similar that are unable to return to the console once they go into X, it's often still possible to type blindly into ddb and trigger a kernel core dump. Just type boot crash. If it works, the system will pause a moment and then you'll see a pile of disk activity. You'll need your swap partition to be somewhat bigger than your total memory, and then you'll need somewhat more than that free on your /var partition. Check out the crash(8) manpage for some info on what you can do with a kernel crash dump. would ddb would show up in xconsole? i will try the blind method next time. -f -- i used to be a sci fi fan. then i started living it.
systat total freeze
hi there, i was copying using rsync between two openbsd notebooks on LAN, and i tried to run systat on both of them to try and see why the transfer speed hovered around 700KB/s both notebooks are -current. first i ran it on the receiving machine, no problem. however on the other notebook systat froze the system solid. i have no idea how to reproduce this, obviously, running systat now works fine. could the reason be, that after the update both libkvm.so.13.0 and libkvm.so.13.1 were still under /usr/lib? dmesg of the system that bought the farm: OpenBSD 5.1-current (GENERIC.MP) #253: Thu Apr 26 01:45:24 MDT 2012 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM real mem = 2137387008 (2038MB) avail mem = 2091622400 (1994MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/18/07, BIOS32 rev. 0 @ 0xfd690, SMBIOS rev. 2.4 @ 0xe0010 (67 entries) bios0: vendor LENOVO version 7BETC9WW (2.10 ) date 04/18/2007 bios0: LENOVO 1705CTO acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 166MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xf000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus 4 (EXP2) acpiprt5 at acpi0: bus 12 (EXP3) acpiprt6 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 97 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 42T4629 serial 327 type LION oem SANYO acpibat1 at acpi0: BAT1 not present acpibat2 at acpi0: BAT2 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) bios0: ROM list: 0xc/0xea00! 0xcf000/0x1000 0xd/0x1000 0xdc000/0x4000! 0xe/0x1! cpu0: Enhanced SpeedStep 1663 MHz: speeds: 1667, 1333, 1000 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03 vga1 at pci0 dev 2 function 0 Intel 82945GM Video rev 0x03 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1: apic 1 int 16 drm0 at inteldrm0 Intel 82945GM Video rev 0x03 at pci0 dev 2 function 1 not configured azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi azalia0: codecs: Analog Devices AD1981HD, 0x/0x, using Analog Devices AD1981HD audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 1 int 20 pci1 at ppb0 bus 2 em0 at pci1 dev 0 function 0 Intel PRO/1000MT (82573L) rev 0x00: msi, address 00:16:d3:b6:19:57 ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 1 int 21 pci2 at ppb1 bus 3 ath0 at pci2 dev 0 function 0 Atheros AR5212 (IBM MiniPCI) rev 0x01: apic 1 int 17 ath0: AR5424 10.3 phy 6.1 rf5424 10.2, WOR2W, address 00:19:7e:4c:f7:1f ppb2 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: apic 1 int 22 pci3 at ppb2 bus 4 ppb3 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 1 int 23 pci4 at ppb3 bus 12 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 1 int 16 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 1 int 17 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 1 int 18 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 1 int 19 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 1 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb4 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xe2 pci5 at ppb4 bus 21 cbb0 at pci5 dev 0 function 0 Ricoh 5C476 CardBus rev 0xb4: apic 1 int 16 Ricoh 5C552 Firewire rev 0x09 at pci5 dev 0 function 1 not configured sdhc0
Re: systat total freeze
Hi, frantisek holop min...@obiit.org wrote: | hi there, [.] | could the reason be, that after the update both | libkvm.so.13.0 and libkvm.so.13.1 were still under /usr/lib? The dynamic linker will use the first library it encounters to resolve the symbols (which can be used for nice tricks via some LD_PRELOAD environment, if supported by the link mechanism). ldd(1) shows up which library is linked into a program (or other dynamic library): ?0%0[steffen@obsdc steffen]$ ldd /usr/bin/systat /usr/bin/systat: StartEnd Type Open Ref GrpRef Name 0040 00824000 exe 10 0 /usr/bin/systat 000200a0c000 000200e65000 rlib 01 0 /usr/lib/libcurses.so.12.1 00020ccf8000 00020d12 rlib 01 0 /usr/lib/libm.so.7.0 000200602000 000200a0c000 rlib 01 0 /usr/lib/libkvm.so.13.1 00020c812000 00020ccf8000 rlib 01 0 /usr/lib/libc.so.64.0 00020c40 00020c40 rtld 01 0 /usr/libexec/ld.so So the answer to the question above is no. However, file descriptor reference counting changed recently and if an old libkvm would work with a new kernel then this could surely result in such behaviour (let me quote this as i don't know the real codeflow, please). According to my plus log all that work has been done rather atomically on 2012-05-01, though. | -f | -- | death is proven to be 99.9% fatal to all laboratory rats. I think i belong to the other 0.1%. Thanks --steffen Forza Figa!
Re: systat total freeze
On Sun, May 6, 2012 at 3:38 AM, frantisek holop min...@obiit.org wrote: ... however on the other notebook systat froze the system solid. i have no idea how to reproduce this, obviously, running systat now works fine. Could you see the machine's console and see whether it paniced? For those that are interested in debugging from a kernel crash dump but that have Sandybridge video chipsets and similar that are unable to return to the console once they go into X, it's often still possible to type blindly into ddb and trigger a kernel core dump. Just type boot crash. If it works, the system will pause a moment and then you'll see a pile of disk activity. You'll need your swap partition to be somewhat bigger than your total memory, and then you'll need somewhat more than that free on your /var partition. Check out the crash(8) manpage for some info on what you can do with a kernel crash dump. could the reason be, that after the update both libkvm.so.13.0 and libkvm.so.13.1 were still under /usr/lib? No. The libkvm changes there are mostly to permit analysis of kernel crash dumps, though some of netstat's options still involve reading structures directly from kernel memory and so may fail if libkvm isn't in sync with the running kernel. If out of sync, netstat may coredump or simply fail, but that won't crash the kernel. A process not running as root should never be able to crash the system. Philip Guenther
