Re: ULE problems on HTT SMP
- Jeff Roberson's Original Message - On Mon, 30 Jun 2003, Andrew Gallatin wrote: Does this mean that if, as a temporary measure, I disable machdep.cpu_idle_hlt, ULE should work for me? Yes, but it needs to be disabled before booting so you'll have to adjust it in the code. See i386/i386/mp_machdep.c Success :-) Making the above change in mp_machdep.c allows a SMP HTT ULE kernel to boot and run. I ran a few 'make buildworld's with the BSD ULE schedulers: bankshot# tail bw.ule*.log | grep real 4324.49 real 1829.01 user 1460.72 sys 4324.20 real 1831.00 user 1459.55 sys 4324.50 real 1829.10 user 1462.96 sys bankshot# tail bw.bsd*.log | grep real 3317.29 real 1859.33 user 1360.96 sys 3237.46 real 1846.39 user 1367.89 sys 3243.40 real 1848.00 user 1369.43 sys Any tunable ideas to help bring sys and real times back inline? Dmesg for the machine used above is http://rtp.freebsd.org/~jwd/dmesg/dmesg.bankshot Keep up the good work! -John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE problems on HTT SMP
On 28-Jun-2003 Jeff Roberson wrote: On Fri, 27 Jun 2003, John Baldwin wrote: On 27-Jun-2003 Andrew Gallatin wrote: Jeff Roberson writes: Can you call kseq_print(0) and kseq_print(1) from ddb? I found a different problem which is nearly as interesting. Note that ps thinks sysctl is on cpu 255... #define NOCPU 0xff/* For when we aren't on a CPU. (SMP) */ So that isn't but so interesting. :) The problem is that the logical cpu halting code does not put the halted CPU in the stopped cpus set. ULE has no way of knowing that it can not migrate a thread to this cpu. I'd prefer it if you could make this change John, but I can certainly do it if you're busy. Probably we should add a flags field to struct pcpu and add a flag meaning that a CPU is disabled and magic code to choosethread() or some other appropriate place that doesn't schedule real threads on a disabled CPU. The logical CPU halting code could then be changed to set this flag on the appropriate CPUs. Thanks, Jeff db ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 62 c41ec000 d8d9a00006042 0004002 [CPU 255] sysctl 60 c4175d3c d7bcc00005842 002 [SLP]wait 0xc4175d3c] sh 58 c4175790 d7ba200005142 002 [SLP]wait 0xc4175790] sh 51 c4175b58 d7bcb00004242 002 [SLP]wait 0xc4175b58] sh 42 c4025b58 d7b660000 142 0004002 [SLP]wait 0xc4025b58] sh 41 c4025d3c d7b670000 0 0 204 [SLP]nfsidl 0xc03f9b8c] nfsiod 3 40 c4173000 d7b960000 0 0 204 [SLP]nfsidl 0xc03f9b88] nfsiod 2 39 c41731e4 d7b970000 0 0 204 [SLP]nfsidl 0xc03f9b84] nfsiod 1 38 c41733c8 d7b980000 0 0 204 [SLP]nfsidl 0xc03f9b80] nfsiod 0 37 c41735ac d7b990000 0 0 204 [SLP]vlruwt 0xc41735ac] vnlru 36 c4173790 d7b9a0000 0 0 204 [SLP]syncer 0xc03cacc0] syncer 35 c4173974 d7b9b0000 0 0 204 [SLP]psleep 0xc03f7e3c] bufdaemon 34 c4173b58 d7b9c0000 0 0 20c [SLP]pgzero 0xc03ffc08] pagezero 9 c4173d3c d7b9d0000 0 0 204 [SLP]psleep 0xc03ffc34] vmdaemon 8 c4175000 d7b9e0000 0 0 204 [SLP]psleep 0xc03ffc20] pagedaemon 33 c41751e4 d7b9f0000 0 0 204 new [IWAIT] irq8: rtc 32 c3f795ac d7b2b0000 0 0 204 new [IWAIT] irq0: clk 31 c3f79790 d7b2c0000 0 0 204 [IWAIT] irq6: fdc0 30 c3f79974 d7b2d0000 0 0 204 new [IWAIT] irq7: ppc0 29 c3f79b58 d7b2e0000 0 0 204 new [IWAIT] irq3: sio1 28 c3f79d3c d7b2f0000 0 0 204 new [IWAIT] irq4: sio0 27 c4025000 d7b390000 0 0 204 [IWAIT] swi0: tty:sio 26 c40251e4 d7b3a0000 0 0 204 new [IWAIT] irq11: em0 25 c40253c8 d7b3b0000 0 0 204 [IWAIT] irq15: ata1 24 c40255ac d7b3c0000 0 0 204 [IWAIT] irq14: ata0 23 c4025790 d7b3d0000 0 0 204 new [IWAIT] irq5: fxp0 7 c4025974 d7b3e0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task2 6 c150a1e4 d69290000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task1 5 c150a3c8 d692a0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task0 22 c150a5ac d692b0000 0 0 204 new [IWAIT] irq9: acpi0 21 c150a790 d692c0000 0 0 204 [IWAIT] swi3: cambio 20 c150a974 d692d0000 0 0 204 new [IWAIT] swi2: camnet 19 c150ab58 d692e0000 0 0 204 new [IWAIT] swi5:+ 18 c150ad3c d69560000 0 0 204 new [IWAIT] swi6: task queue 17 c3f79000 d7b280000 0 0 204 [IWAIT] swi6: acpitaskq 16 c3f791e4 d7b290000 0 0 204 [SLP]sleep 0xc03b5dc0] random 4 c3f793c8 d7b2a0000 0 0 204 [SLP]- 0xc03c41fc] g_down 3 c1503000 d68d20000 0 0 204 [SLP]- 0xc03c41f8] g_up 2 c15031e4 d69210000 0 0 204 [SLP]- 0xc03c41f0] g_event 15 c15033c8 d69220000 0 0 204 new [IWAIT] swi4: vm 14 c15035ac d69230000 0 0 20c [IWAIT] swi7: tty:sio clock 13 c1503790 d69240000 0 0 204 new [IWAIT] swi1: net 12 c1503974 d69250000 0 0 20c [CPU 0] idle: cpu0 11 c1503b58 d69260000 0 0 20c [CPU 1] idle: cpu1 1 c1503d3c d69270000 0 1 0004200 [SLP]wait 0xc1503d3c] init 10 c150a000 d69280000 0 0 204 [CV]ktrace 0xc03c7794] ktrace 0 c03c42c0 c05130000 0 0 200 [SLP]sched 0xc03c42c0] swapper db sho pcpu cpuid= 0 curthread= 0xc1504980: pid 12 idle: cpu0 curpcb = 0xd68edda0 fpcurthread = none idlethread = 0xc1504980: pid 12 idle: cpu0 currentldt = 0x28 spin locks held: db sho
Re: ULE problems on HTT SMP
On Mon, 30 Jun 2003, Andrew Gallatin wrote: Jeff Roberson writes: On Fri, 27 Jun 2003, John Baldwin wrote: On 27-Jun-2003 Andrew Gallatin wrote: Jeff Roberson writes: Can you call kseq_print(0) and kseq_print(1) from ddb? I found a different problem which is nearly as interesting. Note that ps thinks sysctl is on cpu 255... #define NOCPU 0xff/* For when we aren't on a CPU. (SMP) */ So that isn't but so interesting. :) The problem is that the logical cpu halting code does not put the halted CPU in the stopped cpus set. ULE has no way of knowing that it can not migrate a thread to this cpu. I'd prefer it if you could make this change John, but I can certainly do it if you're busy. Does this mean that if, as a temporary measure, I disable machdep.cpu_idle_hlt, ULE should work for me? Yes, but it needs to be disabled before booting so you'll have to adjust it in the code. See i386/i386/mp_machdep.c Cheers, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE problems on HTT SMP
Jeff Roberson writes: On Fri, 27 Jun 2003, John Baldwin wrote: On 27-Jun-2003 Andrew Gallatin wrote: Jeff Roberson writes: Can you call kseq_print(0) and kseq_print(1) from ddb? I found a different problem which is nearly as interesting. Note that ps thinks sysctl is on cpu 255... #define NOCPU 0xff/* For when we aren't on a CPU. (SMP) */ So that isn't but so interesting. :) The problem is that the logical cpu halting code does not put the halted CPU in the stopped cpus set. ULE has no way of knowing that it can not migrate a thread to this cpu. I'd prefer it if you could make this change John, but I can certainly do it if you're busy. Does this mean that if, as a temporary measure, I disable machdep.cpu_idle_hlt, ULE should work for me? Thanks, Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE problems on HTT SMP
On Fri, 27 Jun 2003, John Baldwin wrote: On 27-Jun-2003 Andrew Gallatin wrote: Jeff Roberson writes: Can you call kseq_print(0) and kseq_print(1) from ddb? I found a different problem which is nearly as interesting. Note that ps thinks sysctl is on cpu 255... #define NOCPU 0xff/* For when we aren't on a CPU. (SMP) */ So that isn't but so interesting. :) The problem is that the logical cpu halting code does not put the halted CPU in the stopped cpus set. ULE has no way of knowing that it can not migrate a thread to this cpu. I'd prefer it if you could make this change John, but I can certainly do it if you're busy. Thanks, Jeff db ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 62 c41ec000 d8d9a00006042 0004002 [CPU 255] sysctl 60 c4175d3c d7bcc00005842 002 [SLP]wait 0xc4175d3c] sh 58 c4175790 d7ba200005142 002 [SLP]wait 0xc4175790] sh 51 c4175b58 d7bcb00004242 002 [SLP]wait 0xc4175b58] sh 42 c4025b58 d7b660000 142 0004002 [SLP]wait 0xc4025b58] sh 41 c4025d3c d7b670000 0 0 204 [SLP]nfsidl 0xc03f9b8c] nfsiod 3 40 c4173000 d7b960000 0 0 204 [SLP]nfsidl 0xc03f9b88] nfsiod 2 39 c41731e4 d7b970000 0 0 204 [SLP]nfsidl 0xc03f9b84] nfsiod 1 38 c41733c8 d7b980000 0 0 204 [SLP]nfsidl 0xc03f9b80] nfsiod 0 37 c41735ac d7b990000 0 0 204 [SLP]vlruwt 0xc41735ac] vnlru 36 c4173790 d7b9a0000 0 0 204 [SLP]syncer 0xc03cacc0] syncer 35 c4173974 d7b9b0000 0 0 204 [SLP]psleep 0xc03f7e3c] bufdaemon 34 c4173b58 d7b9c0000 0 0 20c [SLP]pgzero 0xc03ffc08] pagezero 9 c4173d3c d7b9d0000 0 0 204 [SLP]psleep 0xc03ffc34] vmdaemon 8 c4175000 d7b9e0000 0 0 204 [SLP]psleep 0xc03ffc20] pagedaemon 33 c41751e4 d7b9f0000 0 0 204 new [IWAIT] irq8: rtc 32 c3f795ac d7b2b0000 0 0 204 new [IWAIT] irq0: clk 31 c3f79790 d7b2c0000 0 0 204 [IWAIT] irq6: fdc0 30 c3f79974 d7b2d0000 0 0 204 new [IWAIT] irq7: ppc0 29 c3f79b58 d7b2e0000 0 0 204 new [IWAIT] irq3: sio1 28 c3f79d3c d7b2f0000 0 0 204 new [IWAIT] irq4: sio0 27 c4025000 d7b390000 0 0 204 [IWAIT] swi0: tty:sio 26 c40251e4 d7b3a0000 0 0 204 new [IWAIT] irq11: em0 25 c40253c8 d7b3b0000 0 0 204 [IWAIT] irq15: ata1 24 c40255ac d7b3c0000 0 0 204 [IWAIT] irq14: ata0 23 c4025790 d7b3d0000 0 0 204 new [IWAIT] irq5: fxp0 7 c4025974 d7b3e0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task2 6 c150a1e4 d69290000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task1 5 c150a3c8 d692a0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task0 22 c150a5ac d692b0000 0 0 204 new [IWAIT] irq9: acpi0 21 c150a790 d692c0000 0 0 204 [IWAIT] swi3: cambio 20 c150a974 d692d0000 0 0 204 new [IWAIT] swi2: camnet 19 c150ab58 d692e0000 0 0 204 new [IWAIT] swi5:+ 18 c150ad3c d69560000 0 0 204 new [IWAIT] swi6: task queue 17 c3f79000 d7b280000 0 0 204 [IWAIT] swi6: acpitaskq 16 c3f791e4 d7b290000 0 0 204 [SLP]sleep 0xc03b5dc0] random 4 c3f793c8 d7b2a0000 0 0 204 [SLP]- 0xc03c41fc] g_down 3 c1503000 d68d20000 0 0 204 [SLP]- 0xc03c41f8] g_up 2 c15031e4 d69210000 0 0 204 [SLP]- 0xc03c41f0] g_event 15 c15033c8 d69220000 0 0 204 new [IWAIT] swi4: vm 14 c15035ac d69230000 0 0 20c [IWAIT] swi7: tty:sio clock 13 c1503790 d69240000 0 0 204 new [IWAIT] swi1: net 12 c1503974 d69250000 0 0 20c [CPU 0] idle: cpu0 11 c1503b58 d69260000 0 0 20c [CPU 1] idle: cpu1 1 c1503d3c d69270000 0 1 0004200 [SLP]wait 0xc1503d3c] init 10 c150a000 d69280000 0 0 204 [CV]ktrace 0xc03c7794] ktrace 0 c03c42c0 c05130000 0 0 200 [SLP]sched 0xc03c42c0] swapper db sho pcpu cpuid= 0 curthread= 0xc1504980: pid 12 idle: cpu0 curpcb = 0xd68edda0 fpcurthread = none idlethread = 0xc1504980: pid 12 idle: cpu0 currentldt = 0x28 spin locks held: db sho pcpu 1 cpuid= 1 curthread= 0xc1504850: pid 11 idle: cpu1 curpcb = 0xd68eada0 fpcurthread = none idlethread = 0xc1504850: pid 11 idle: cpu1 currentldt = 0x28 spin locks held: db t 62 mi_switch(c4177720,df,c036cbb1,ef,1) at mi_switch+0x210 ast(d7bb8d48) at ast+0x3a0 doreti_ast() at doreti_ast+0x17 I hope that
ULE problems on HTT SMP
Jeff, On an SMP box I have, which is really a p4 box with one physical CPU, and 2 HTT cores, I've seen some strange behaviour with ULE. With ULE enabled, I've see jobs wedge for no apparent reason. Some examples are fsck, dhclient and gcc. Here's an example of fsck after it stopped responding: load: 1.00 cmd: fsck_ufs 46 [physrd] 0.15u 0.31s 1% 1976k [halt - sent] Stopped at siointr1+0xd5: jmp siointr1+0x200 db ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 46 c41e05ac d8d9d0000 143 0004002 [SLP]physrd 0xce588fe8] fsck_ufs 42 c4025b58 d7b660000 142 0004002 [SLP]biord 0xce58a488] sh 41 c4025d3c d7b670000 0 0 204 [SLP]nfsidl 0xc03f9b8c] nfsiod3 40 c4173000 d7b960000 0 0 204 [SLP]nfsidl 0xc03f9b88] nfsiod2 39 c41731e4 d7b970000 0 0 204 [SLP]nfsidl 0xc03f9b84] nfsiod1 38 c41733c8 d7b980000 0 0 204 [SLP]nfsidl 0xc03f9b80] nfsiod0 37 c41735ac d7b990000 0 0 204 [SLP]vlruwt 0xc41735ac] vnlru 36 c4173790 d7b9a0000 0 0 204 [SLP]syncer 0xc03cacc0] syncer 35 c4173974 d7b9b0000 0 0 204 [SLP]psleep 0xc03f7e3c] bufdaemon 34 c4173b58 d7b9c0000 0 0 20c [SLP]pgzero 0xc03ffc08] pagezero 9 c4173d3c d7b9d0000 0 0 204 [SLP]psleep 0xc03ffc34] vmdaemon 8 c4175000 d7b9e0000 0 0 204 [SLP]psleep 0xc03ffc20] pagedaemon 33 c41751e4 d7b9f0000 0 0 204 new [IWAIT] irq8: rtc 32 c3f795ac d7b2b0000 0 0 204 new [IWAIT] irq0: clk 31 c3f79790 d7b2c0000 0 0 204 [IWAIT] irq6: fdc0 30 c3f79974 d7b2d0000 0 0 204 new [IWAIT] irq7: ppc0 29 c3f79b58 d7b2e0000 0 0 204 new [IWAIT] irq3: sio1 28 c3f79d3c d7b2f0000 0 0 204 new [IWAIT] irq4: sio0 27 c4025000 d7b390000 0 0 204 [IWAIT] swi0: tty:sio 26 c40251e4 d7b3a0000 0 0 204 new [IWAIT] irq11: em0 25 c40253c8 d7b3b0000 0 0 204 [IWAIT] irq15: ata1 24 c40255ac d7b3c0000 0 0 204 [IWAIT] irq14: ata0 23 c4025790 d7b3d0000 0 0 204 new [IWAIT] irq5: fxp0 7 c4025974 d7b3e0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task2 6 c150a1e4 d69290000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task1 5 c150a3c8 d692a0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task0 22 c150a5ac d692b0000 0 0 204 new [IWAIT] irq9: acpi0 21 c150a790 d692c0000 0 0 204 [IWAIT] swi3: cambio 20 c150a974 d692d0000 0 0 204 new [IWAIT] swi2: camnet 19 c150ab58 d692e0000 0 0 204 new [IWAIT] swi5:+ 18 c150ad3c d69560000 0 0 204 new [IWAIT] swi6: task queue 17 c3f79000 d7b280000 0 0 204 [IWAIT] swi6: acpitaskq 16 c3f791e4 d7b290000 0 0 204 [SLP]sleep 0xc03b5dc0] random 4 c3f793c8 d7b2a0000 0 0 204 [RUNQ] g_down 3 c1503000 d68d20000 0 0 204 [SLP]- 0xc03c41f8] g_up 2 c15031e4 d69210000 0 0 204 [SLP]- 0xc03c41f0] g_event 15 c15033c8 d69220000 0 0 204 new [IWAIT] swi4: vm 14 c15035ac d69230000 0 0 20c [IWAIT] swi7: tty:sio clock 13 c1503790 d69240000 0 0 204 new [IWAIT] swi1: net 12 c1503974 d69250000 0 0 20c [CPU 0] idle: cpu0 11 c1503b58 d69260000 0 0 20c [CPU 1] idle: cpu1 1 c1503d3c d69270000 0 1 0004200 [SLP]wait 0xc1503d3c] init 10 c150a000 d69280000 0 0 204 [CV]ktrace 0xc03c7794] ktrace 0 c03c42c0 c05130000 0 0 200 [SLP]sched 0xc03c42c0] swapper db c load: 1.00 cmd: fsck_ufs 46 [physrd] 0.15u 0.31s 1% 1976k load: 1.00 cmd: fsck_ufs 46 [physrd] 0.15u 0.31s 1% 1976k At this point, fsck never makes any progress, and is unkillable with ^C. This is a kernel from Tuesday's sources. The last time I updated the machine was early April, and all worked fine then.. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE problems on HTT SMP
On Fri, 27 Jun 2003, Andrew Gallatin wrote: Jeff, On an SMP box I have, which is really a p4 box with one physical CPU, and 2 HTT cores, I've seen some strange behaviour with ULE. With ULE enabled, I've see jobs wedge for no apparent reason. Some examples are fsck, dhclient and gcc. Can you call kseq_print(0) and kseq_print(1) from ddb? Thanks, Jeff Here's an example of fsck after it stopped responding: load: 1.00 cmd: fsck_ufs 46 [physrd] 0.15u 0.31s 1% 1976k [halt - sent] Stopped at siointr1+0xd5: jmp siointr1+0x200 db ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 46 c41e05ac d8d9d0000 143 0004002 [SLP]physrd 0xce588fe8] fsck_ufs 42 c4025b58 d7b660000 142 0004002 [SLP]biord 0xce58a488] sh 41 c4025d3c d7b670000 0 0 204 [SLP]nfsidl 0xc03f9b8c] nfsiod3 40 c4173000 d7b960000 0 0 204 [SLP]nfsidl 0xc03f9b88] nfsiod2 39 c41731e4 d7b970000 0 0 204 [SLP]nfsidl 0xc03f9b84] nfsiod1 38 c41733c8 d7b980000 0 0 204 [SLP]nfsidl 0xc03f9b80] nfsiod0 37 c41735ac d7b990000 0 0 204 [SLP]vlruwt 0xc41735ac] vnlru 36 c4173790 d7b9a0000 0 0 204 [SLP]syncer 0xc03cacc0] syncer 35 c4173974 d7b9b0000 0 0 204 [SLP]psleep 0xc03f7e3c] bufdaemon 34 c4173b58 d7b9c0000 0 0 20c [SLP]pgzero 0xc03ffc08] pagezero 9 c4173d3c d7b9d0000 0 0 204 [SLP]psleep 0xc03ffc34] vmdaemon 8 c4175000 d7b9e0000 0 0 204 [SLP]psleep 0xc03ffc20] pagedaemon 33 c41751e4 d7b9f0000 0 0 204 new [IWAIT] irq8: rtc 32 c3f795ac d7b2b0000 0 0 204 new [IWAIT] irq0: clk 31 c3f79790 d7b2c0000 0 0 204 [IWAIT] irq6: fdc0 30 c3f79974 d7b2d0000 0 0 204 new [IWAIT] irq7: ppc0 29 c3f79b58 d7b2e0000 0 0 204 new [IWAIT] irq3: sio1 28 c3f79d3c d7b2f0000 0 0 204 new [IWAIT] irq4: sio0 27 c4025000 d7b390000 0 0 204 [IWAIT] swi0: tty:sio 26 c40251e4 d7b3a0000 0 0 204 new [IWAIT] irq11: em0 25 c40253c8 d7b3b0000 0 0 204 [IWAIT] irq15: ata1 24 c40255ac d7b3c0000 0 0 204 [IWAIT] irq14: ata0 23 c4025790 d7b3d0000 0 0 204 new [IWAIT] irq5: fxp0 7 c4025974 d7b3e0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task2 6 c150a1e4 d69290000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task1 5 c150a3c8 d692a0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task0 22 c150a5ac d692b0000 0 0 204 new [IWAIT] irq9: acpi0 21 c150a790 d692c0000 0 0 204 [IWAIT] swi3: cambio 20 c150a974 d692d0000 0 0 204 new [IWAIT] swi2: camnet 19 c150ab58 d692e0000 0 0 204 new [IWAIT] swi5:+ 18 c150ad3c d69560000 0 0 204 new [IWAIT] swi6: task queue 17 c3f79000 d7b280000 0 0 204 [IWAIT] swi6: acpitaskq 16 c3f791e4 d7b290000 0 0 204 [SLP]sleep 0xc03b5dc0] random 4 c3f793c8 d7b2a0000 0 0 204 [RUNQ] g_down 3 c1503000 d68d20000 0 0 204 [SLP]- 0xc03c41f8] g_up 2 c15031e4 d69210000 0 0 204 [SLP]- 0xc03c41f0] g_event 15 c15033c8 d69220000 0 0 204 new [IWAIT] swi4: vm 14 c15035ac d69230000 0 0 20c [IWAIT] swi7: tty:sio clock 13 c1503790 d69240000 0 0 204 new [IWAIT] swi1: net 12 c1503974 d69250000 0 0 20c [CPU 0] idle: cpu0 11 c1503b58 d69260000 0 0 20c [CPU 1] idle: cpu1 1 c1503d3c d69270000 0 1 0004200 [SLP]wait 0xc1503d3c] init 10 c150a000 d69280000 0 0 204 [CV]ktrace 0xc03c7794] ktrace 0 c03c42c0 c05130000 0 0 200 [SLP]sched 0xc03c42c0] swapper db c load: 1.00 cmd: fsck_ufs 46 [physrd] 0.15u 0.31s 1% 1976k load: 1.00 cmd: fsck_ufs 46 [physrd] 0.15u 0.31s 1% 1976k At this point, fsck never makes any progress, and is unkillable with ^C. This is a kernel from Tuesday's sources. The last time I updated the machine was early April, and all worked fine then.. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE problems on HTT SMP
Jeff Roberson writes: On Fri, 27 Jun 2003, Andrew Gallatin wrote: Jeff, On an SMP box I have, which is really a p4 box with one physical CPU, and 2 HTT cores, I've seen some strange behaviour with ULE. With ULE enabled, I've see jobs wedge for no apparent reason. Some examples are fsck, dhclient and gcc. Can you call kseq_print(0) and kseq_print(1) from ddb? Next time I see it, I will. (I've booted into a sched_4bsd kernel for a while..) Thanks, Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE problems on HTT SMP
Jeff Roberson writes: Can you call kseq_print(0) and kseq_print(1) from ddb? I found a different problem which is nearly as interesting. Note that ps thinks sysctl is on cpu 255... Boot hangs here: cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/ad0s1a Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point. hang, hit ^T a few times, neither that nor ^C helps load: 0.97 cmd: sysctl 62 [running] 0.00u 0.00s 0% 200k load: 0.97 cmd: sysctl 62 [running] 0.00u 0.00s 0% 200k load: 0.97 cmd: sysctl 62 [running] 0.00u 0.00s 0% 200k load: 0.97 cmd: sysctl 62 [running] 0.00u 0.00s 0% 200k [halt - sent] Stopped at siointr1+0xd5: jmp siointr1+0x200 db kseq_print(0) No such command db call kseq_print(0) kseq: load: 0 load ITHD: 0 load REALTIME: 0 load TIMESHARE: 0 load IDLE: 0 nicemin:0 nice counts: 0xe db call kseq_print(1) kseq: load: 1 load ITHD: 0 load REALTIME: 0 load TIMESHARE: 1 load IDLE: 0 nicemin:0 nice counts: 0 = 1 0x8 db c db ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 62 c41ec000 d8d9a00006042 0004002 [CPU 255] sysctl 60 c4175d3c d7bcc00005842 002 [SLP]wait 0xc4175d3c] sh 58 c4175790 d7ba200005142 002 [SLP]wait 0xc4175790] sh 51 c4175b58 d7bcb00004242 002 [SLP]wait 0xc4175b58] sh 42 c4025b58 d7b660000 142 0004002 [SLP]wait 0xc4025b58] sh 41 c4025d3c d7b670000 0 0 204 [SLP]nfsidl 0xc03f9b8c] nfsiod 3 40 c4173000 d7b960000 0 0 204 [SLP]nfsidl 0xc03f9b88] nfsiod 2 39 c41731e4 d7b970000 0 0 204 [SLP]nfsidl 0xc03f9b84] nfsiod 1 38 c41733c8 d7b980000 0 0 204 [SLP]nfsidl 0xc03f9b80] nfsiod 0 37 c41735ac d7b990000 0 0 204 [SLP]vlruwt 0xc41735ac] vnlru 36 c4173790 d7b9a0000 0 0 204 [SLP]syncer 0xc03cacc0] syncer 35 c4173974 d7b9b0000 0 0 204 [SLP]psleep 0xc03f7e3c] bufdaemon 34 c4173b58 d7b9c0000 0 0 20c [SLP]pgzero 0xc03ffc08] pagezero 9 c4173d3c d7b9d0000 0 0 204 [SLP]psleep 0xc03ffc34] vmdaemon 8 c4175000 d7b9e0000 0 0 204 [SLP]psleep 0xc03ffc20] pagedaemon 33 c41751e4 d7b9f0000 0 0 204 new [IWAIT] irq8: rtc 32 c3f795ac d7b2b0000 0 0 204 new [IWAIT] irq0: clk 31 c3f79790 d7b2c0000 0 0 204 [IWAIT] irq6: fdc0 30 c3f79974 d7b2d0000 0 0 204 new [IWAIT] irq7: ppc0 29 c3f79b58 d7b2e0000 0 0 204 new [IWAIT] irq3: sio1 28 c3f79d3c d7b2f0000 0 0 204 new [IWAIT] irq4: sio0 27 c4025000 d7b390000 0 0 204 [IWAIT] swi0: tty:sio 26 c40251e4 d7b3a0000 0 0 204 new [IWAIT] irq11: em0 25 c40253c8 d7b3b0000 0 0 204 [IWAIT] irq15: ata1 24 c40255ac d7b3c0000 0 0 204 [IWAIT] irq14: ata0 23 c4025790 d7b3d0000 0 0 204 new [IWAIT] irq5: fxp0 7 c4025974 d7b3e0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task2 6 c150a1e4 d69290000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task1 5 c150a3c8 d692a0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task0 22 c150a5ac d692b0000 0 0 204 new [IWAIT] irq9: acpi0 21 c150a790 d692c0000 0 0 204 [IWAIT] swi3: cambio 20 c150a974 d692d0000 0 0 204 new [IWAIT] swi2: camnet 19 c150ab58 d692e0000 0 0 204 new [IWAIT] swi5:+ 18 c150ad3c d69560000 0 0 204 new [IWAIT] swi6: task queue 17 c3f79000 d7b280000 0 0 204 [IWAIT] swi6: acpitaskq 16 c3f791e4 d7b290000 0 0 204 [SLP]sleep 0xc03b5dc0] random 4 c3f793c8 d7b2a0000 0 0 204 [SLP]- 0xc03c41fc] g_down 3 c1503000 d68d20000 0 0 204 [SLP]- 0xc03c41f8] g_up 2 c15031e4 d69210000 0 0 204 [SLP]- 0xc03c41f0] g_event 15 c15033c8 d69220000 0 0 204 new [IWAIT] swi4: vm 14 c15035ac d69230000 0 0 20c [IWAIT] swi7: tty:sio clock 13 c1503790 d69240000 0 0 204 new [IWAIT] swi1: net 12 c1503974 d69250000 0 0 20c [CPU 0] idle: cpu0 11 c1503b58 d69260000 0 0 20c [CPU 1] idle: cpu1 1 c1503d3c d69270000 0 1 0004200 [SLP]wait 0xc1503d3c] init 10 c150a000 d69280000 0 0 204 [CV]ktrace 0xc03c7794] ktrace 0 c03c42c0 c05130000 0 0 200 [SLP]sched 0xc03c42c0] swapper db sho pcpu cpuid= 0 curthread= 0xc1504980: pid 12 idle: cpu0 curpcb = 0xd68edda0 fpcurthread
Re: ULE problems on HTT SMP
On 27-Jun-2003 Andrew Gallatin wrote: Jeff Roberson writes: Can you call kseq_print(0) and kseq_print(1) from ddb? I found a different problem which is nearly as interesting. Note that ps thinks sysctl is on cpu 255... #define NOCPU 0xff/* For when we aren't on a CPU. (SMP) */ So that isn't but so interesting. :) db ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 62 c41ec000 d8d9a00006042 0004002 [CPU 255] sysctl 60 c4175d3c d7bcc00005842 002 [SLP]wait 0xc4175d3c] sh 58 c4175790 d7ba200005142 002 [SLP]wait 0xc4175790] sh 51 c4175b58 d7bcb00004242 002 [SLP]wait 0xc4175b58] sh 42 c4025b58 d7b660000 142 0004002 [SLP]wait 0xc4025b58] sh 41 c4025d3c d7b670000 0 0 204 [SLP]nfsidl 0xc03f9b8c] nfsiod 3 40 c4173000 d7b960000 0 0 204 [SLP]nfsidl 0xc03f9b88] nfsiod 2 39 c41731e4 d7b970000 0 0 204 [SLP]nfsidl 0xc03f9b84] nfsiod 1 38 c41733c8 d7b980000 0 0 204 [SLP]nfsidl 0xc03f9b80] nfsiod 0 37 c41735ac d7b990000 0 0 204 [SLP]vlruwt 0xc41735ac] vnlru 36 c4173790 d7b9a0000 0 0 204 [SLP]syncer 0xc03cacc0] syncer 35 c4173974 d7b9b0000 0 0 204 [SLP]psleep 0xc03f7e3c] bufdaemon 34 c4173b58 d7b9c0000 0 0 20c [SLP]pgzero 0xc03ffc08] pagezero 9 c4173d3c d7b9d0000 0 0 204 [SLP]psleep 0xc03ffc34] vmdaemon 8 c4175000 d7b9e0000 0 0 204 [SLP]psleep 0xc03ffc20] pagedaemon 33 c41751e4 d7b9f0000 0 0 204 new [IWAIT] irq8: rtc 32 c3f795ac d7b2b0000 0 0 204 new [IWAIT] irq0: clk 31 c3f79790 d7b2c0000 0 0 204 [IWAIT] irq6: fdc0 30 c3f79974 d7b2d0000 0 0 204 new [IWAIT] irq7: ppc0 29 c3f79b58 d7b2e0000 0 0 204 new [IWAIT] irq3: sio1 28 c3f79d3c d7b2f0000 0 0 204 new [IWAIT] irq4: sio0 27 c4025000 d7b390000 0 0 204 [IWAIT] swi0: tty:sio 26 c40251e4 d7b3a0000 0 0 204 new [IWAIT] irq11: em0 25 c40253c8 d7b3b0000 0 0 204 [IWAIT] irq15: ata1 24 c40255ac d7b3c0000 0 0 204 [IWAIT] irq14: ata0 23 c4025790 d7b3d0000 0 0 204 new [IWAIT] irq5: fxp0 7 c4025974 d7b3e0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task2 6 c150a1e4 d69290000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task1 5 c150a3c8 d692a0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task0 22 c150a5ac d692b0000 0 0 204 new [IWAIT] irq9: acpi0 21 c150a790 d692c0000 0 0 204 [IWAIT] swi3: cambio 20 c150a974 d692d0000 0 0 204 new [IWAIT] swi2: camnet 19 c150ab58 d692e0000 0 0 204 new [IWAIT] swi5:+ 18 c150ad3c d69560000 0 0 204 new [IWAIT] swi6: task queue 17 c3f79000 d7b280000 0 0 204 [IWAIT] swi6: acpitaskq 16 c3f791e4 d7b290000 0 0 204 [SLP]sleep 0xc03b5dc0] random 4 c3f793c8 d7b2a0000 0 0 204 [SLP]- 0xc03c41fc] g_down 3 c1503000 d68d20000 0 0 204 [SLP]- 0xc03c41f8] g_up 2 c15031e4 d69210000 0 0 204 [SLP]- 0xc03c41f0] g_event 15 c15033c8 d69220000 0 0 204 new [IWAIT] swi4: vm 14 c15035ac d69230000 0 0 20c [IWAIT] swi7: tty:sio clock 13 c1503790 d69240000 0 0 204 new [IWAIT] swi1: net 12 c1503974 d69250000 0 0 20c [CPU 0] idle: cpu0 11 c1503b58 d69260000 0 0 20c [CPU 1] idle: cpu1 1 c1503d3c d69270000 0 1 0004200 [SLP]wait 0xc1503d3c] init 10 c150a000 d69280000 0 0 204 [CV]ktrace 0xc03c7794] ktrace 0 c03c42c0 c05130000 0 0 200 [SLP]sched 0xc03c42c0] swapper db sho pcpu cpuid= 0 curthread= 0xc1504980: pid 12 idle: cpu0 curpcb = 0xd68edda0 fpcurthread = none idlethread = 0xc1504980: pid 12 idle: cpu0 currentldt = 0x28 spin locks held: db sho pcpu 1 cpuid= 1 curthread= 0xc1504850: pid 11 idle: cpu1 curpcb = 0xd68eada0 fpcurthread = none idlethread = 0xc1504850: pid 11 idle: cpu1 currentldt = 0x28 spin locks held: db t 62 mi_switch(c4177720,df,c036cbb1,ef,1) at mi_switch+0x210 ast(d7bb8d48) at ast+0x3a0 doreti_ast() at doreti_ast+0x17 I hope that helps.. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED]
