Re: apmd hangs
On 09/08/14 23:35, Mark Kettenis wrote: The more code documentation I read, the more I'm convinced that coordinating state changes between logical processors isn't necessary and actually is responsible for the hangs people have been seeing. So here is a diff that does away with it all. I've tested it on a few laptops here, but it could use testing on a somewhat wider range of machines. I'm especially interested in seeing this tested on a dual socket machine with apmd -A. finally no more hangs on this machine running with apmd -A Cheers Giovanni OpenBSD 5.6-current (GENERIC.MP) #9: Wed Sep 10 12:33:43 CEST 2014 giova...@bigio.paclan.it:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3835400192 (3657MB) avail mem = 3724570624 (3552MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae3a000 (60 entries) bios0: vendor LENOVO version H5ET69WW (1.12 ) date 11/15/2012 bios0: LENOVO 62742QG acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI UEFI MSDM UEFI DBG2 acpi0: wakeup devices P0P1(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-2348M CPU @ 2.30GHz, 2295.13 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i3-2348M CPU @ 2.30GHz, 2294.79 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i3-2348M CPU @ 2.30GHz, 2294.79 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-2348M CPU @ 2.30GHz, 2294.79 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus 2 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus 3 (RP04) acpiprt6 at acpi0: bus -1 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpicpu2 at acpi0: C3, C2, C1, PSS acpicpu3 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 83 degC acpitz1 at acpi0: critical temperature is 126 degC acpibat0 at acpi0: BAT0 model 45N1045 serial 2329 type LION oem 313100504d53 acpithinkpad0 at acpi0 acpiac0 at acpi0: AC unit offline acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: SLPB cpu0: Enhanced SpeedStep 2295 MHz: speeds: 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core 2G Host rev 0x09 vga1 at pci0 dev 2 function 0 Intel HD Graphics 3000 rev 0x09 intagp at vga1 not configured inteldrm0 at vga1 drm0 at inteldrm0 drm: Memory usable by graphics device = 2048M inteldrm0: 1366x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 7 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured ehci0 at pci0 dev 26
Re: apmd hangs
On 2014/09/10 04:44, Ingo Schwarze wrote: Sure. When i see ld(1) dying from signals, i'll bump limits. But that's not what what i'm talking about. Memory allocation failure in ld(1) is hopefully not going to cause a hard kernel lockup. Besides, almost all the kernel lockups i saw today happened while trying to build either archivers/gtar or misc/fileutils. Those are not going to hit any limits. There are certainly some hard kernel lockups that are hit frequently on systems where memory is exhausted (limits or not), though a gtar build (with a 58MB maximum RSS on my laptop) is unlikely to trigger this unless the machine is otherwise under very high memory pressure.. Anyway, i'm going to shut up now. As i can't even provide a backtrace, tech@ is clearly the wrong list. Not necessarily, as some things are resistant to traditional debugging and people who don't have deep experience of the involved subsystems are unlikely to know where to start poking to get additional data points that might help track things down..
Re: apmd hangs
On 2014/09/08 23:35, Mark Kettenis wrote: The more code documentation I read, the more I'm convinced that coordinating state changes between logical processors isn't necessary and actually is responsible for the hangs people have been seeing. So here is a diff that does away with it all. I've tested it on a few laptops here, but it could use testing on a somewhat wider range of machines. I'm especially interested in seeing this tested on a dual socket machine with apmd -A. I'm running with this on my amd64 X220 with apm -C, this configuration used to hang every couple of days. It's a bit soon to say if it fixes things yet (IIRC some others hit the hangs more easily than me), but I haven't noticed any regressions. I've also run a cycle of lots of apm -L / apm -H in a loop while otherwise stressing the cpu, no problems seen there.
Re: apmd hangs
Hi Mark, Mark Kettenis wrote on Mon, Sep 08, 2014 at 11:35:36PM +0200: The more code documentation I read, the more I'm convinced that coordinating state changes between logical processors isn't necessary and actually is responsible for the hangs people have been seeing. So here is a diff that does away with it all. I've tested it on a few laptops here, but it could use testing on a somewhat wider range of machines. I'm especially interested in seeing this tested on a dual socket machine with apmd -A. i'm sorry to say it makes no difference for me (i'm not opposed to the diff, though). On my laptop, building ports works fine, running firefox works fine, but whenever i surf the web with firefox while building ports, the machine locks up hard. Sometimes, the lockup already happens when merely starting firefox while building ports. Often, it happens not when requesting a new URI, but when merely scrolling within the page in firefox. After the lockup, CapsLk and NmLk still toggle the respective LEDs, Fn-PgUp still switches on and off the torch, but nothing else has any effect, not even Ctrl-Alt-Esc, Ctrl-Alt-Delete, Ctrl-Alt-Backspace or Ctrl-Alt-F1. Unfortunately, i cannot break into ddb because i don't have a docking station, hence no serial console, and when going to the PC virtual console (Ctrl-Alt-F1), setting export DISPLAY=:0, and starting firefox from the console, i was unable to get any lockup. Apparently, it only happens when X (or whatever) is actually painting something onto the screen. Whether i run with the defaults or with apm -A doesn't appear to make a difference. Yours, Ingo OpenBSD 5.6-current (GENERIC.MP) #4: Tue Sep 9 18:06:19 CEST 2014 ischwa...@isnote.usta.de:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Genuine Intel(R) CPU T2300 @ 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,PBE,NXE,SSE3,MWAIT,EST,TM2,xTPR,PDCM,PERF real mem = 3211096064 (3062MB) avail mem = 3146219520 (3000MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 08/26/09, BIOS32 rev. 0 @ 0xfd6b0, SMBIOS rev. 2.4 @ 0xe0010 (68 entries) bios0: vendor LENOVO version 7FETA9WW (2.27 ) date 08/26/2009 bios0: LENOVO 94504BG acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB3(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) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 166MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Genuine Intel(R) CPU T2300 @ 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,PBE,NXE,SSE3,MWAIT,EST,TM2,xTPR,PDCM,PERF 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, resource for USB0, USB1, USB7 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 92P1129 serial 1896 type LION oem Panasonic acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) bios0: ROM list: 0xc/0xea00! 0xcf000/0x1600 0xd0800/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 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1280x800 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) 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, Conexant/0x2bfa, 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
Re: apmd hangs
On Tue, Sep 9, 2014 at 7:27 PM, Ingo Schwarze schwa...@usta.de wrote: i'm sorry to say it makes no difference for me (i'm not opposed to the diff, though). On my laptop, building ports works fine, running firefox works fine, but whenever i surf the web with firefox while building ports, the machine locks up hard. Sometimes, the lockup already happens when merely starting firefox while building ports. Often, it happens not when requesting a new URI, but when merely scrolling within the page in firefox. After the lockup, CapsLk and NmLk still toggle the respective LEDs, Fn-PgUp still switches on and off the torch, but nothing else has any effect, not even Ctrl-Alt-Esc, Ctrl-Alt-Delete, Ctrl-Alt-Backspace or Ctrl-Alt-F1. Unfortunately, i cannot break into ddb because i don't have a docking station, hence no serial console, and when going to the PC virtual console (Ctrl-Alt-F1), setting export DISPLAY=:0, and starting firefox from the console, i was unable to get any lockup. Apparently, it only happens when X (or whatever) is actually painting something onto the screen. Whether i run with the defaults or with apm -A doesn't appear to make a difference. I'm a bit confused... Is this hang happening without apmd running?
Re: apmd hangs
Date: Tue, 9 Sep 2014 19:27:42 +0200 From: Ingo Schwarze schwa...@usta.de Hi Mark, Mark Kettenis wrote on Mon, Sep 08, 2014 at 11:35:36PM +0200: The more code documentation I read, the more I'm convinced that coordinating state changes between logical processors isn't necessary and actually is responsible for the hangs people have been seeing. So here is a diff that does away with it all. I've tested it on a few laptops here, but it could use testing on a somewhat wider range of machines. I'm especially interested in seeing this tested on a dual socket machine with apmd -A. i'm sorry to say it makes no difference for me (i'm not opposed to the diff, though). On my laptop, building ports works fine, running firefox works fine, but whenever i surf the web with firefox while building ports, the machine locks up hard. Sometimes, the lockup already happens when merely starting firefox while building ports. Often, it happens not when requesting a new URI, but when merely scrolling within the page in firefox. After the lockup, CapsLk and NmLk still toggle the respective LEDs, Fn-PgUp still switches on and off the torch, but nothing else has any effect, not even Ctrl-Alt-Esc, Ctrl-Alt-Delete, Ctrl-Alt-Backspace or Ctrl-Alt-F1. Unfortunately, i cannot break into ddb because i don't have a docking station, hence no serial console, and when going to the PC virtual console (Ctrl-Alt-F1), setting export DISPLAY=:0, and starting firefox from the console, i was unable to get any lockup. Apparently, it only happens when X (or whatever) is actually painting something onto the screen. Whether i run with the defaults or with apm -A doesn't appear to make a difference. Not sure what you mean with defaults, but if the crashes happen even in manual performance adjustment mode, this diff certainly won't magically fix things.
Re: apmd hangs
Hi David, David Coppa wrote on Tue, Sep 09, 2014 at 07:44:47PM +0200: On Tue, Sep 9, 2014 at 7:27 PM, Ingo Schwarze schwa...@usta.de wrote: i'm sorry to say it makes no difference for me (i'm not opposed to the diff, though). On my laptop, building ports works fine, running firefox works fine, but whenever i surf the web with firefox while building ports, the machine locks up hard. Sometimes, the lockup already happens when merely starting firefox while building ports. Often, it happens not when requesting a new URI, but when merely scrolling within the page in firefox. After the lockup, CapsLk and NmLk still toggle the respective LEDs, Fn-PgUp still switches on and off the torch, but nothing else has any effect, not even Ctrl-Alt-Esc, Ctrl-Alt-Delete, Ctrl-Alt-Backspace or Ctrl-Alt-F1. Unfortunately, i cannot break into ddb because i don't have a docking station, hence no serial console, and when going to the PC virtual console (Ctrl-Alt-F1), setting export DISPLAY=:0, and starting firefox from the console, i was unable to get any lockup. Apparently, it only happens when X (or whatever) is actually painting something onto the screen. Whether i run with the defaults or with apm -A doesn't appear to make a difference. I'm a bit confused... Is this hang happening without apmd running? Yes. That doesn't make a difference, either. Usually, i run with apmd in default mode: ischwarze@isnote $ grep apm /etc/rc.conf.local apmd_flags= But with apmd_flags=-A or apmd_flags=NO the hangs happen in exactly the same way. Yours, Ingo
Re: apmd hangs
On Tue, Sep 9, 2014 at 7:58 PM, Ingo Schwarze schwa...@usta.de wrote: Hi David, David Coppa wrote on Tue, Sep 09, 2014 at 07:44:47PM +0200: On Tue, Sep 9, 2014 at 7:27 PM, Ingo Schwarze schwa...@usta.de wrote: i'm sorry to say it makes no difference for me (i'm not opposed to the diff, though). On my laptop, building ports works fine, running firefox works fine, but whenever i surf the web with firefox while building ports, the machine locks up hard. Sometimes, the lockup already happens when merely starting firefox while building ports. Often, it happens not when requesting a new URI, but when merely scrolling within the page in firefox. After the lockup, CapsLk and NmLk still toggle the respective LEDs, Fn-PgUp still switches on and off the torch, but nothing else has any effect, not even Ctrl-Alt-Esc, Ctrl-Alt-Delete, Ctrl-Alt-Backspace or Ctrl-Alt-F1. Unfortunately, i cannot break into ddb because i don't have a docking station, hence no serial console, and when going to the PC virtual console (Ctrl-Alt-F1), setting export DISPLAY=:0, and starting firefox from the console, i was unable to get any lockup. Apparently, it only happens when X (or whatever) is actually painting something onto the screen. Whether i run with the defaults or with apm -A doesn't appear to make a difference. I'm a bit confused... Is this hang happening without apmd running? Yes. That doesn't make a difference, either. Usually, i run with apmd in default mode: ischwarze@isnote $ grep apm /etc/rc.conf.local apmd_flags= But with apmd_flags=-A or apmd_flags=NO the hangs happen in exactly the same way. So I'm with Mark here, I also think your hang is unrelated to this diff. ciao! David
Re: apmd hangs
On Tue, Sep 9, 2014 at 2:13 PM, David Coppa dco...@gmail.com wrote: On Tue, Sep 9, 2014 at 7:58 PM, Ingo Schwarze schwa...@usta.de wrote: Hi David, David Coppa wrote on Tue, Sep 09, 2014 at 07:44:47PM +0200: On Tue, Sep 9, 2014 at 7:27 PM, Ingo Schwarze schwa...@usta.de wrote: i'm sorry to say it makes no difference for me (i'm not opposed to the diff, though). On my laptop, building ports works fine, running firefox works fine, but whenever i surf the web with firefox while building ports, the machine locks up hard. Sometimes, the lockup already happens when merely starting firefox while building ports. Often, it happens not when requesting a new URI, but when merely scrolling within the page in firefox. After the lockup, CapsLk and NmLk still toggle the respective LEDs, Fn-PgUp still switches on and off the torch, but nothing else has any effect, not even Ctrl-Alt-Esc, Ctrl-Alt-Delete, Ctrl-Alt-Backspace or Ctrl-Alt-F1. Unfortunately, i cannot break into ddb because i don't have a docking station, hence no serial console, and when going to the PC virtual console (Ctrl-Alt-F1), setting export DISPLAY=:0, and starting firefox from the console, i was unable to get any lockup. Apparently, it only happens when X (or whatever) is actually painting something onto the screen. Whether i run with the defaults or with apm -A doesn't appear to make a difference. I'm a bit confused... Is this hang happening without apmd running? Yes. That doesn't make a difference, either. Usually, i run with apmd in default mode: ischwarze@isnote $ grep apm /etc/rc.conf.local apmd_flags= But with apmd_flags=-A or apmd_flags=NO the hangs happen in exactly the same way. So I'm with Mark here, I also think your hang is unrelated to this diff. +1 Ingo, A basic rule of thumb when building ports: raise your /etc/login.conf limits...especially datasize-cur needs to be 2G and datasize-max needs to be 3G. The reason being there are some ports where the linker blows up to 2G or slightly over. The worst offenders are usually the www/webkit or chrome or firefox. Though py-py also takes a lot of memory. There is also another well-known bug in the I/O path which espie@ referred to a few months ago. But it is as yet undetected? It rears its ugly head when your machine does a lot of I/O. Try running cvsync, building ports, run a find/grep over ports tree, and try to browse with firefox all at the same time. The system feels as if it goes into a hang. But give it a few seconds and it comes back normally. Is this what is happening with you?
Re: apmd hangs
Hi Amit, Amit Kulkarni wrote on Tue, Sep 09, 2014 at 08:47:22PM -0500: A basic rule of thumb when building ports: raise your /etc/login.conf limits...especially datasize-cur needs to be 2G and datasize-max needs to be 3G. The reason being there are some ports where the linker blows up to 2G or slightly over. The worst offenders are usually the www/webkit or chrome or firefox. Though py-py also takes a lot of memory. Sure. When i see ld(1) dying from signals, i'll bump limits. But that's not what what i'm talking about. Memory allocation failure in ld(1) is hopefully not going to cause a hard kernel lockup. Besides, almost all the kernel lockups i saw today happened while trying to build either archivers/gtar or misc/fileutils. Those are not going to hit any limits. There is also another well-known bug in the I/O path which espie@ referred to a few months ago. But it is as yet undetected? It rears its ugly head when your machine does a lot of I/O. Try running cvsync, building ports, run a find/grep over ports tree, and try to browse with firefox all at the same time. The system feels as if it goes into a hang. But give it a few seconds and it comes back normally. Is this what is happening with you? I did see temporary userland lockups caused by firefox in the past, though not lately, and i'm not sure it was the same you are referring to. Besides, those could always be interrupted with Ctrl-Alt-Backspace. What i'm seeing here locks up the kernel, not merely X, and for good. Anyway, i'm going to shut up now. As i can't even provide a backtrace, tech@ is clearly the wrong list. At least i should bisect when asking for help, but i can't afford the time right now. I'll continue to test floating patches that seem possibly related (to my naive understanding), and i'm sure kettenis@ will continue to fondly remind me that a patch for FOO is not going to magically fix BAR whenever my understanding turns out to be nothing but a mis- (thanks for that). Yours, Ingo
