Re: something's wrong
Matthias Drochner m.droch...@fz-juelich.de wrote: On Thu, 14 Nov 2013 23:41:33 +0900 Takahiro HAYASHI t-h...@abox3.so-net.ne.jp wrote: I happened unfortunately to meet this problem, but fortunately entered ddb. I was doing ./build release for amd64 on amd64 HEAD around Nov 9. Does this give any help? Yes, thanks - this helps to narrow down the problem. I don't see the real reason yet, but perhaps someone more familiar with synchronization matters can make more sense of it. Just extracting some interesting data. Thomas, Takahiro: can you try with the following change? http://mail-index.netbsd.org/source-changes/2013/11/26/msg049508.html -- Mindaugas
Re: something's wrong
Thomas Klausner w...@netbsd.org wrote: On Tue, Nov 26, 2013 at 08:34:15PM +, Mindaugas Rasiukevicius wrote: Thomas, Takahiro: can you try with the following change? http://mail-index.netbsd.org/source-changes/2013/11/26/msg049508.html Thanks for looking at this! The immediate effect is worse though: repeatable panic right after avail memory: panic: kernel diagnostic assertion level SOFTINT_CONST failed: file .../sys/kern/kern_softint.c, line 343 fatal breakpoint trap in supervisor mode That was a bit too quick from me. Sorry about that. Please cvs up. -- Mindaugas
Re: something's wrong
Hello, On Tue, 26 Nov 2013 21:20:45 + Mindaugas Rasiukevicius rm...@netbsd.org wrote: Thomas Klausner w...@netbsd.org wrote: On Tue, Nov 26, 2013 at 08:34:15PM +, Mindaugas Rasiukevicius wrote: Thomas, Takahiro: can you try with the following change? http://mail-index.netbsd.org/source-changes/2013/11/26/msg049508.html Thanks for looking at this! The immediate effect is worse though: repeatable panic right after avail memory: panic: kernel diagnostic assertion level SOFTINT_CONST failed: file .../sys/kern/kern_softint.c, line 343 fatal breakpoint trap in supervisor mode That was a bit too quick from me. Sorry about that. Please cvs up. Thank you for debugging. I checked out tree and run new kernel. At least I can say, building speed gets back as fast as it takes on 6.99.23. It took more than 2 hours for amd64 on 6.99.27 w/ 8 cpu, however, now it takes 38 min. -- t-hash
Re: something's wrong
On Sat, Nov 23, 2013 at 10:27:25AM +0100, Lars Heidieker wrote: That's most likely PR/48372 it's fixed in current and needs pull up to the netbsd-6 branches. Can you please send the pullup request ? thanks -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: something's wrong
On 11/24/2013 05:09 PM, Manuel Bouyer wrote: On Sat, Nov 23, 2013 at 10:27:25AM +0100, Lars Heidieker wrote: That's most likely PR/48372 it's fixed in current and needs pull up to the netbsd-6 branches. Can you please send the pullup request ? thanks done.
Re: something's wrong
On 11/23/2013 04:02 AM, Takahiro HAYASHI wrote: Hello, On Tue, 5 Nov 2013 10:07:49 + David Brownlee a...@netbsd.org wrote: I've noticed a recent netbsd-6 xen DOM0 hanging on similar big compiles (firefox24/25) if run while the DOMUs are active. Possibly unrelated, but just as a data point. I saw NetBSD/amd64 6.1_STABLE dom0 panics once while installing netbsd-6 by doing ./build install=/ , but cannot reproduce it. It resembles kern/48372. uvm_fault(0x806f5860, 0x0, 1) - e fatal page fault in supervisor mode trap type 6 code 0 rip 802d4bc0 cs e030 rflags 10206 cr2 10 cpl 8 rsp a0001759bb80 kernel: page fault trap, code=0 Stopped in pid 0.9 (system) at netbsd:vmem_xalloc+0x201: movq 10(%rax) ,%rax ? ds fffd es f1d2 fs bb70 gs b880 rdi 6 rsi 805d25b0static_bts+0x5b0 rbp a0001759bc50 rbx 4 rdx 0 rcx fffd rax 0 r8 0 r9 0 r10 f000 r11 0 r12 805ceaf0static_vmems+0x1090 r13 1000 r14 805ceb08static_vmems+0x10a8 r15 0 rip 802d4bc0vmem_xalloc+0x201 cs e030 rflags 10206 rsp a0001759bb80 ss e02b netbsd:vmem_xalloc+0x201: movq10(%rax),%rax db bt vmem_xalloc() at netbsd:vmem_xalloc+0x201 vmem_alloc() at netbsd:vmem_alloc+0x7f bt_refill() at netbsd:bt_refill+0x14f vmem_xalloc() at netbsd:vmem_xalloc+0x80 vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f bt_refill() at netbsd:bt_refill+0x14f vmem_xalloc() at netbsd:vmem_xalloc+0x80 vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f bt_refill() at netbsd:bt_refill+0x14f vmem_xalloc() at netbsd:vmem_xalloc+0x80 vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f
Re: something's wrong
Hello,
Today I met hangup on 2 logical cpu box.
This box runs -current 2013.11.15.16.06.06 UTC with LOCKDEBUG.
I was doing ./build release for amd64 from HEAD tree
and running systat on console.
There are no network traffics other than ntp and incoming bcast/mcast.
There are no processes waiting on xchicv.
All tstile process waits on proc_lock.
I'll try to do same ./build on main build box w/ 8 threads.
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 8015716d cs 8 rflags 202 cr2 7f7ff780c3d0 ilevel
8 rsp fe8001003a78
curlwp 0xfe813fb27880 pid 0.2 lowest kstack 0xfe800100
Stopped in pid 0.2 (system) at netbsd:breakpoint+0x5: leave
db{0} ps
PIDLID S CPU FLAGS STRUCT LWP * NAME WAIT
219 1 3 1 0 fe811bee9980 as tstile
172851 3 1 0 fe81108ef560 x86_64--netbsd-o tstile
8698 1 3 0 0 fe810c426000cc1 tstile
148471 3 0 0 fe811bee9540 x86_64--netbsd-g tstile
242741 3 080 fe811fdea4e0 sh wait
146761 3 0 4 fe81116b0140 sh wait
4749 1 3 0 4 fe81393ceb00 x86_64--netbsd-g tstile
167931 3 1 40080 fe81393ce6c0 sh wait
249191 3 0 0 fe81209a74a0 nbmake tstile
196581 3 080 fe810912b600 sh wait
292511 3 0 0 fe811d12a500 nbmake tstile
296171 3 080 fe813b4a7260 sh wait
01 3 0 0 fe813b4a76a0 nbmake tstile
148911 3 180 fe8111365040 sh wait
157211 3 180 fe811fdea0a0 nbmake wait
103581 3 180 fe810afe62e0 sh wait
4902 1 3 0 0 fe81393ce280 nbmake tstile
164081 3 080 fe81209a78e0 sh wait
251411 3 0 0 fe813e634240 nbmake tstile
216821 3 0 0 fe8121c2b0e0 systat tstile
2631 1 3 080 fe8119ee52a0 sh wait
2172 1 3 0 0 fe813f1a3600 nbmake tstile
2449 1 3 080 fe813d9712c0 sh wait
2552 1 3 0 0 fe813e634680 nbmake tstile
2121 1 3 080 fe813d971b40 sh wait
2206 1 3 0 0 fe81076ec1a0 nbmake tstile
538 1 3 080 fe813e634ac0 sh wait
556 1 3 180 fe813f1a3a40 sh wait
559 1 3 180 fe813f1e9a60 sh wait
379 1 3 180 fe813f1a31c0 tcsh pause
372 1 3 180 fe81076ec5e0 login wait
341 1 3 080 fe813d8a7220 sshd select
311 1 3 080 fe813f1e9620 powerd kqueue
301 1 3 180 fe813eedc200 ntpd pause
176 1 2 0 0 fe813d8a7660syslogd
11 3 180 fe810779c160 init wait
0 52 3 0 200 fe813eedca80physiod physiod
0 51 3 0 200 fe81076eca20 aiodoned aiodoned
0 50 3 0 200 fe810775a120ioflush syncer
0 49 3 0 200 fe810781c180 pgdaemon pgdaemon
0 45 3 1 200 fe810775a560 usb4 usbevt
0 44 3 1 200 fe810775a9a0 usb3 usbevt
0 43 3 0 200 fe810763f100 usb2 usbevt
0 42 3 0 200 fe810763f540 usb1 usbevt
0 41 3 0 200 fe810775b9c0 usb0 usbevt
0 40 3 0 200 fe810781c5c0 usb5 usbevt
0 39 3 0 200 fe810781ca00 npfgc npfgccv
0 38 3 0 200 fe810775b580 unpgc unpgc
0 37 3 1 200 fe810775b140vmem_rehash vmem_rehash
0 36 3 0 200 fe810779c5a0 coretemp1 coretemp1
0 35 3 1 200 fe810779c9e0 coretemp0 coretemp0
0 26 3 0 200 fe810763f980atabus1 atath
0 25 3 1 200 fe81076210e0atabus0 atath
0 24 3 0 200 fe8107621520 usbtask-dr usbtsk
0 23 3 0 200 fe8107621960 usbtask-hc usbtsk
0 22 3 1 200 fe81074ef0c0xcall/1 xcall
0 21 1 1 200 fe81074ef500 softser/1
0 20 3 1 200 fe81074ef940 softclk/1 tstile
0 19 1 1 200 fe81074b00a0 softbio/1
0 18 1 1 200
Re: something's wrong
Hello, Thank you for your kindly explanation. I will post ddb log in other mail as it gets quite large. Regards, -- t-hash
Re: something's wrong
Hello, On Tue, 5 Nov 2013 10:07:49 + David Brownlee a...@netbsd.org wrote: I've noticed a recent netbsd-6 xen DOM0 hanging on similar big compiles (firefox24/25) if run while the DOMUs are active. Possibly unrelated, but just as a data point. I saw NetBSD/amd64 6.1_STABLE dom0 panics once while installing netbsd-6 by doing ./build install=/ , but cannot reproduce it. It resembles kern/48372. uvm_fault(0x806f5860, 0x0, 1) - e fatal page fault in supervisor mode trap type 6 code 0 rip 802d4bc0 cs e030 rflags 10206 cr2 10 cpl 8 rsp a0001759bb80 kernel: page fault trap, code=0 Stopped in pid 0.9 (system) at netbsd:vmem_xalloc+0x201: movq10(%rax) ,%rax ? ds fffd es f1d2 fs bb70 gs b880 rdi 6 rsi 805d25b0static_bts+0x5b0 rbp a0001759bc50 rbx 4 rdx 0 rcx fffd rax 0 r8 0 r9 0 r10 f000 r11 0 r12 805ceaf0static_vmems+0x1090 r13 1000 r14 805ceb08static_vmems+0x10a8 r15 0 rip 802d4bc0vmem_xalloc+0x201 cs e030 rflags 10206 rsp a0001759bb80 ss e02b netbsd:vmem_xalloc+0x201: movq10(%rax),%rax db bt vmem_xalloc() at netbsd:vmem_xalloc+0x201 vmem_alloc() at netbsd:vmem_alloc+0x7f bt_refill() at netbsd:bt_refill+0x14f vmem_xalloc() at netbsd:vmem_xalloc+0x80 vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f bt_refill() at netbsd:bt_refill+0x14f vmem_xalloc() at netbsd:vmem_xalloc+0x80 vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f bt_refill() at netbsd:bt_refill+0x14f vmem_xalloc() at netbsd:vmem_xalloc+0x80 vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2 vmem_xalloc() at netbsd:vmem_xalloc+0xacd vmem_alloc() at netbsd:vmem_alloc+0x7f pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c pool_grow() at netbsd:pool_grow+0x33 pool_get() at netbsd:pool_get+0x47 pool_cache_put_slow() at
Re: something's wrong
On 5 Nov, 2013, at 08:49 , Chavdar Ivanov ci4...@gmail.com wrote: That was quick; I only managed to find out that it hangs with a kernel from 29th... I don't know if it is related but I'm pretty sure I just got a hang with an amd64 kernel from the 29th. I found several existing ssh sessions into the box were unresponsive, but when I got to the console to see if I could get any information about it, it somehow fixed itself (including the ssh sessions). I know it was hung for a while since a middle-of-the-night build it runs from cron was still running and took 6.5 hours to complete rather than the normal 25 minutes Starting build for beagle at Tue Nov 5 07:52:16 UTC 2013 Completed build for beagle after 00:25:28 Starting build for beagle at Wed Nov 6 07:52:09 UTC 2013 Completed build for beagle after 06:35:40 but I can find no other signs of what happened. Dennis Ferguson
Re: something's wrong
On 5 November 2013 08:27, Chavdar Ivanov ci4...@gmail.com wrote: Tried - the screen stays as it was, no movement whatsoever. No network activity, the keyboard is also dead - does not respond to CtrlAltEsc, even the lights are off and CapsLock/NumLock does not trigger anything. I've noticed a recent netbsd-6 xen DOM0 hanging on similar big compiles (firefox24/25) if run while the DOMUs are active. Possibly unrelated, but just as a data point.
Re: something's wrong
I'll try some bisection. Chavdar On 5 November 2013 10:07, David Brownlee a...@netbsd.org wrote: On 5 November 2013 08:27, Chavdar Ivanov ci4...@gmail.com wrote: Tried - the screen stays as it was, no movement whatsoever. No network activity, the keyboard is also dead - does not respond to CtrlAltEsc, even the lights are off and CapsLock/NumLock does not trigger anything. I've noticed a recent netbsd-6 xen DOM0 hanging on similar big compiles (firefox24/25) if run while the DOMUs are active. Possibly unrelated, but just as a data point. --
Re: something's wrong
On Tue, Nov 05, 2013 at 10:22:29AM +, Chavdar Ivanov wrote: I'll try some bisection. My bisection so far points to a change on the 23rd. I couldn't reproduce the problem (yet?) with a kernel from 'cvs up -D 20131023', but I had a hang with one from 'cvs up -D 20131024'. The changes from the 23rd are: 7766 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/dev/usb just a config change 7767 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/dev/pci gffb, which I don't use 7768 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/arch/macppc/conf kernel config only 7769 L Oct 23 To source-chang (0.3K) CVS commit: src/doc docs 7770 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/dev/pci gffb copyright change 7771 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/arch/amd64/conf + xhci (which I've removed in my kernel) 7772 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/arch/i386/conf same 7773 L Oct 23 To source-chang (0.6K) CVS commit: src use MODULE_CLASS_MISC for Lua modules which looks harmless enough and doesn't really touch the kernel 7774 L Oct 23 To source-chang (3.1K) CVS commit: src/sys Use the MI pcu framework for bookkeeping of npx/fpu states on x86. This reduces the amount of MD code enormously, and makes it easier to implement support for newer CPU features which require more fpu state, or for fpu usage by the kernel. For access to FPU state across CPUs, an xcall kthread is used now rather than a dedicated IPI. No user visible changes intended. 7775 L Oct 23 To source-chang (0.5K) CVS commit: src/sys/arch/arm/arm different architecture So currently it looks to me like the problem might come from the MI pcu framework commit. Matthias, does that sound possible? Could you please check the patch again if it might introduce these symptoms? (see thread for details) Thomas Chavdar On 5 November 2013 10:07, David Brownlee a...@netbsd.org wrote: On 5 November 2013 08:27, Chavdar Ivanov ci4...@gmail.com wrote: Tried - the screen stays as it was, no movement whatsoever. No network activity, the keyboard is also dead - does not respond to CtrlAltEsc, even the lights are off and CapsLock/NumLock does not trigger anything. I've noticed a recent netbsd-6 xen DOM0 hanging on similar big compiles (firefox24/25) if run while the DOMUs are active. Possibly unrelated, but just as a data point. --
Re: something's wrong
That was quick; I only managed to find out that it hangs with a kernel from 29th... Chavdar On 5 November 2013 12:20, Thomas Klausner w...@netbsd.org wrote: On Tue, Nov 05, 2013 at 10:22:29AM +, Chavdar Ivanov wrote: I'll try some bisection. My bisection so far points to a change on the 23rd. I couldn't reproduce the problem (yet?) with a kernel from 'cvs up -D 20131023', but I had a hang with one from 'cvs up -D 20131024'. The changes from the 23rd are: 7766 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/dev/usb just a config change 7767 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/dev/pci gffb, which I don't use 7768 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/arch/macppc/conf kernel config only 7769 L Oct 23 To source-chang (0.3K) CVS commit: src/doc docs 7770 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/dev/pci gffb copyright change 7771 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/arch/amd64/conf + xhci (which I've removed in my kernel) 7772 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/arch/i386/conf same 7773 L Oct 23 To source-chang (0.6K) CVS commit: src use MODULE_CLASS_MISC for Lua modules which looks harmless enough and doesn't really touch the kernel 7774 L Oct 23 To source-chang (3.1K) CVS commit: src/sys Use the MI pcu framework for bookkeeping of npx/fpu states on x86. This reduces the amount of MD code enormously, and makes it easier to implement support for newer CPU features which require more fpu state, or for fpu usage by the kernel. For access to FPU state across CPUs, an xcall kthread is used now rather than a dedicated IPI. No user visible changes intended. 7775 L Oct 23 To source-chang (0.5K) CVS commit: src/sys/arch/arm/arm different architecture So currently it looks to me like the problem might come from the MI pcu framework commit. Matthias, does that sound possible? Could you please check the patch again if it might introduce these symptoms? (see thread for details) Thomas Chavdar On 5 November 2013 10:07, David Brownlee a...@netbsd.org wrote: On 5 November 2013 08:27, Chavdar Ivanov ci4...@gmail.com wrote: Tried - the screen stays as it was, no movement whatsoever. No network activity, the keyboard is also dead - does not respond to CtrlAltEsc, even the lights are off and CapsLock/NumLock does not trigger anything. I've noticed a recent netbsd-6 xen DOM0 hanging on similar big compiles (firefox24/25) if run while the DOMUs are active. Possibly unrelated, but just as a data point. -- --
