Re: Hang near end of kernel probes since r213267 (likely earlier)
On Fri, Oct 01, 2010 at 08:38:59PM -0700, David Wolfskill wrote: On Fri, Oct 01, 2010 at 08:56:13PM -0500, Brandon Gooch wrote: ... Any ideas on what mught be causing CURRENT to hang -- sometimes -- given that it appears to involve the Modular Bay (or the specific device that is in the bay during the hang)? If you haven't already, it may be worth trying 'options ATA_CAM' in your kernel config. ... And -- probably more important for this discussion -- I was unable to re-create the failing condition: the machine booted Just Fine every time I tried it, whether the CD/DVD drive was inserted or not. ... That assessment (on my part) was premature. The attempt to boot from slice 4, running: FreeBSD g1-222.catwhisker.org. 9.0-CURRENT FreeBSD 9.0-CURRENT #3 r213357: Sat Oct 2 06:29:23 PDT 2010 r...@g1-222.catwhisker.org.:/usr/obj/usr/src/sys/CANARY i386 immediately prior to the one I just did: * was using a kernel with the ATA_CAM enabled, as may be noted by the device name in: g1-222(9.0-C)[2] df -h / Filesystem SizeUsed Avail Capacity Mounted on /dev/ada0s4a1.4G327M1.0G25%/ g1-222(9.0-C)[3] * hung at the previously-discussed point. It appears that running a kernel with option ATA_CAM may well reduce the probability of this apparently intermittent mode of failure. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpuJoZgT69Jc.pgp Description: PGP signature
Re: Hang near end of kernel probes since r213267 (likely earlier)
on 03/10/2010 14:28 David Wolfskill said the following: [snipped] Can't you just drop to DDB prompt and examine where the threads are? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hang near end of kernel probes since r213267 (likely earlier)
On Sun, Oct 03, 2010 at 02:52:19PM +0300, Andriy Gapon wrote: on 03/10/2010 14:28 David Wolfskill said the following: [snipped] Can't you just drop to DDB prompt and examine where the threads are? Eh -- thanks for the reality check; I needed that. :-} OK; I enabled the KDB DDB options rebuilt the kernel; 2nd reboot after make installkernel huhng as before. Now, unfortunately, the new laptop doesn't have a serial console, so below is hand-transcribed: GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb 524288K of memory above 4GB ignored Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #4 r213380: Sun Oct 3 04:35:15 PDT 2010 ... ugen7.1: Intel at usbus7 uhub7: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered cd0 at ata3 bus 0 scbus2 target 0 lun 0 cd0: TSSTcorp DVD+-RW TS-U633A D200 Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada0 at ata2 bus 0 scbus1 target 0 lun 0 ada0: Seagate ST9250421ASG DE16 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. uhub7: 6 ports with 6 removable, self powered ugen2.2: Broadcom Corp at usbus2 previously-descibed hang; I used Ctl+Alt+Esc to enter DDB. KDB: enter: manual escape to debugger [ thread pid 12 tid 100017 ] Stopped at 0xc08d992a = kdb_enter+0x3a:movl$0,0xc0e33574 = kdb_why db bt Tracing pid 12 tid 100017 td 0xc94575a0 kdb_enter(c0c737ab,c0caf6cb,1,0,1,...) at 0xc06d992a = kdb_enter+0x3a scgetc(c0e21950,0,c0caf5f1,2a1,c9457644,...) at 0xc07930a8 = scgetc+0x568 sckbdevent)c92f7500,0,c0fb3ea0,c92f9400,c6da9c4c,...) at 0xc0793424 = sckbdevent+0x1e4 kbdmux_intr(c92f7500,0,c92f9608,c6da9c78,c08e63e3,...) at 0xc069c86b = kbdmux_intr+0x2b kbdmux_kbd_intr(c92f7500,1,c0ccd301,53,c9194a94,...) at 0xc069ce45 = kbdmux_kbd_intr+0x25 taskqueue_run(c9194a98,0,c0ccd301,4a,c6da9cb8,...) at 0xc08e63e3 = taskqueue_run+0xc3 taskqueue_swi_giant_run(0,0,c0cc37a5,4c3,c945a0b8,...) at 0xc08e6be6 = taskqueue_swi_giant_run+0x66 intr_event_execute_handlers(c91d37f8,c945a080,c0cc37a5,533,c945a0f0,...) at 0xc087e655 = intr_event_execute_handlers+0x125 ithread_loop(c943f980,c6da9d28,c0cc3520,349,c91d37f8,...) at 0xc087f42f = ithread_loop+-x9f fork_exit(c087f390,c943f980,c6da9d28) at 0xc087c3a8 = fork_exit+0xb8 fork_trampoline() at 0xc0bd5824 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc6da9d60, ebp = 0 --- db I used the ps command at that point to see that PID 12 is [intr], with the following assignments: PID state wmesg cmd 100072 I [irq15: ata1] 100071 I [irq14: ata0] 100070 I [irq12: psm0] 100069 I [irq1: atkbd0] 100067 I [irq19: cbb0 atapci+] 100064 I [irq17: fwohci0] 100045 I [irq1258: iwn0] 100044 I [irq1257: hdac0] 100035 I [irq122: uhci2 ehci0+] 100030 I [irq121: uhci1 ehci4] 100025 I [irq120: hpet0 ehci0*] 100023 I [irq19: acpi0] 100018 I [swi6: task queue] 100017 Run CPU 1 [swi6: Giant taskq] 100015 I [swi5: +] 100014 I [swi2: cambio] 18 I [swi4: clock] 17 I [swi4: clock] 16 I [swi1: netisr 0] 15 I [swi3: vm] I then tried panic, but that does not appear to have been successful. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpShZwNQ2lCi.pgp Description: PGP signature
Another clang problem
In updating gnash to 8.8 the build failed while linking with libvgl.so. My current system was built last week, with both kernel and world built with clang. The linkage failure was due to an inlined function, set4pixels which is only referred to, as far as I can tell, within the source file simple.c which contains the function definition. I rebuilt libvgl.so using gcc and gnash linked properly. It seems, at least in this case, that clang has some problems dealing with inlined functions. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Another clang problem
On 3 Oct 2010, at 14:41, Derek Tattersall wrote: In updating gnash to 8.8 the build failed while linking with libvgl.so. My current system was built last week, with both kernel and world built with clang. The linkage failure was due to an inlined function, set4pixels which is only referred to, as far as I can tell, within the source file simple.c which contains the function definition. I rebuilt libvgl.so using gcc and gnash linked properly. It seems, at least in this case, that clang has some problems dealing with inlined functions. We are still in the process of identifying which ports have problems, but we are aware that building ports with clang is not an easy job: several ports assume a gcc behavior and there some LLVM/Clang problems that need to be ironed out. Given this, we need some sort of way to identify ports that can be built with clang, but that requires man-hours. Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Another clang problem
* Rui Paulo rpa...@freebsd.org [101003 09:57]: On 3 Oct 2010, at 14:41, Derek Tattersall wrote: In updating gnash to 8.8 the build failed while linking with libvgl.so. My current system was built last week, with both kernel and world built with clang. The linkage failure was due to an inlined function, set4pixels which is only referred to, as far as I can tell, within the source file simple.c which contains the function definition. I rebuilt libvgl.so using gcc and gnash linked properly. It seems, at least in this case, that clang has some problems dealing with inlined functions. We are still in the process of identifying which ports have problems, but we are aware that building ports with clang is not an easy job: several ports assume a gcc behavior and there some LLVM/Clang problems that need to be ironed out. Given this, we need some sort of way to identify ports that can be built with clang, but that requires man-hours. Regards, -- Rui Paulo I was not completely clear, I'm afraid. Gnash was built with gcc under all circumstances. libvgl.so is part of the world build and is installed in /usr/lib. It was originally built with clang when I built both the kernel and the world with clang last week. I found that building /usr/src/lib/libvgl with gcc was necessary to get gnash to build properly. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Another clang problem
On 2010-10-03 15:41, Derek Tattersall wrote: In updating gnash to 8.8 the build failed while linking with libvgl.so. My current system was built last week, with both kernel and world built with clang. The linkage failure was due to an inlined function, set4pixels which is only referred to, as far as I can tell, within the source file simple.c which contains the function definition. The problem is that set4pixels() and another function set2lines() are defined as 'inline' functions in simple.c, but it is compiled with -std=gnu99. This means that these definitions cannot be called from another object file. So, either libvgl should be compiled with -std=gnu89, or somebody who knows about libvgl's official API should decide whether these functions must be externally accessible or not. Since libvgl looks very old (it was imported 8 years ago, and the last functional change was 6 years ago), the former is probably the easiest fix. I rebuilt libvgl.so using gcc and gnash linked properly. It seems, at least in this case, that clang has some problems dealing with inlined functions. Since gnash has about a gazillion dependencies, and I have the idea that after 12 hours of building stuff, I will not be able to reproduce your error message anyway, could you please post it (or upload it, if it is very large)? Also, please note that building ports with clang is still experimental, although various people are actively working on it. And there are *many* ports that have totally broken configure scripts, or that just assume the only software in the world is GNU. :) See http://wiki.freebsd.org/PortsAndClang for some information (although it is a little outdated now), and a link to patches. Any help in this area is appreciated! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Examining the VM splay tree effectiveness
On 10/01/10 10:54, Andre Oppermann wrote: On 30.09.2010 19:51, Ivan Voras wrote: On 09/30/10 18:37, Andre Oppermann wrote: Both the vmmap and page table make use of splay trees to manage the entries and to speed up lookups compared to long to traverse linked lists or more memory expensive hash tables. Some structures though do have an additional linked list to simplify ordered traversals. The property of splay tree requiring *writes* for nearly every read really is a thorn in the eye for SMP. It seems to me that even if the immediate benefits from converting to something else are not directly observable, it will still be worth doing it. Fully agreed. It's a shame that RCU is still a patent minefield :/ http://mirror.leaseweb.com/kernel/people/npiggin/patches/lockless/2.6.16-rc5/radix-intro.pdf I'm not convinced that RCU is the only scalable way of sharing a data structure across a possibly large number of CPU's. Of course, it's just well understood currently. The term lockless is often used and frequently misunderstood. Having a lockess data structure *doesn't* mean that is either performant, scalable or both. It heavily depends on a number of additional factors. Many times lockless just replaces a simple lock/unlock cycle with a number of atomic operations on the data structure. This can easily backfire because an atomic Yes. operation just hides the computational complexity and also dirties the CPU's cache lines. Generally on cache coherent architectures almost all of the atomic operation is in HW with bus lock cycles, bus snooping and whatnot. While seemingly simple form the programmers point of view, the overhead and latency is still there. Needless Yes, you basically just offload the operation to hardware but the steps it needs to make are the same in concept. a) make sure the lock is held for only a small amount of time to avoid lock contention. b) do everything you can outside of the lock. c) if the lock is found to be heavily contended rethink the whole approach and check if other data structures can be used. d) minimize write accesses to memory in the lock protected shared data structure. e) PROFILE, DON'T SPECULATE! Measure the access pattern and measure the locking/data access strategy's cost in terms of CPU cycles consumed. f) on lookup heavy data structures avoid writing to memory and by it dirtying CPU caches. g) on modify heavy data structures avoid touching too many elements. h) on lookup and modify heavy data structure that are used across many CPU's all bets are off and a different data structure approach should be considered resulting ideally in case f). It all starts with the hypothesis that a data structure is not optimally locked. This looks like material for a developer-centric wiki page :) There is a lot of dispersed wisdom in this thread which would be nice if gathered in one place. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Another clang problem
On Sun, Oct 03, 2010 at 05:21:15PM +0200, Dimitry Andric wrote: On 2010-10-03 15:41, Derek Tattersall wrote: In updating gnash to 8.8 the build failed while linking with libvgl.so. My current system was built last week, with both kernel and world built with clang. The linkage failure was due to an inlined function, set4pixels which is only referred to, as far as I can tell, within the source file simple.c which contains the function definition. The problem is that set4pixels() and another function set2lines() are defined as 'inline' functions in simple.c, but it is compiled with -std=gnu99. This means that these definitions cannot be called from another object file. So, either libvgl should be compiled with -std=gnu89, or somebody who knows about libvgl's official API should decide whether these functions must be externally accessible or not. Since libvgl looks very old (it was imported 8 years ago, and the last functional change was 6 years ago), the former is probably the easiest fix. we compile world with -std=gnu99 even with gcc, why isnt this problem with gcc? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Another clang problem
On Sun, Oct 3, 2010 at 12:50 PM, Roman Divacky rdiva...@freebsd.org wrote: On Sun, Oct 03, 2010 at 05:21:15PM +0200, Dimitry Andric wrote: On 2010-10-03 15:41, Derek Tattersall wrote: In updating gnash to 8.8 the build failed while linking with libvgl.so. My current system was built last week, with both kernel and world built with clang. The linkage failure was due to an inlined function, set4pixels which is only referred to, as far as I can tell, within the source file simple.c which contains the function definition. The problem is that set4pixels() and another function set2lines() are defined as 'inline' functions in simple.c, but it is compiled with -std=gnu99. This means that these definitions cannot be called from another object file. So, either libvgl should be compiled with -std=gnu89, or somebody who knows about libvgl's official API should decide whether these functions must be externally accessible or not. Since libvgl looks very old (it was imported 8 years ago, and the last functional change was 6 years ago), the former is probably the easiest fix. we compile world with -std=gnu99 even with gcc, why isnt this problem with gcc? Has someone tried compiling with clang and c99, as opposed to gnu99? I'm curious as to whether or not the c99 implementation with clang is always correct, and if that works, whether or not the gnu99 implementation on gcc has a subtlety that isn't implemented properly on clang. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Another clang problem
On 2010-10-03 17:21, Dimitry Andric wrote: Since gnash has about a gazillion dependencies, and I have the idea that after 12 hours of building stuff, I will not be able to reproduce your error message anyway, could you please post it (or upload it, if it is very large)? I cannot reproduce your problem, even after installing the gazillion dependencies. :) However, gnash has the same problem that a lot of other ports have: its configure script assumes the verbose output of a linking command has a certain format. The end result is almost always a linking error hidden symbol `__dso_handle' in /usr/lib/crtbegin.o is referenced by DSO, or similar. That problem should be fixed by this patch: http://www.andric.com/freebsd/clang/graphics-gnash-clang.diff There is also a chance this might fix your issue, can you please try it out? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hang near end of kernel probes since r213267 (likely earlier)
On 10/3/10 6:14 AM, David Wolfskill wrote: On Sun, Oct 03, 2010 at 02:52:19PM +0300, Andriy Gapon wrote: on 03/10/2010 14:28 David Wolfskill said the following: [snipped] Can't you just drop to DDB prompt and examine where the threads are? Eh -- thanks for the reality check; I needed that. :-} OK; I enabled the KDB DDB options rebuilt the kernel; 2nd reboot after make installkernel huhng as before. Now, unfortunately, the new laptop doesn't have a serial console, so below is hand-transcribed: GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb 524288K of memory above 4GB ignored Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #4 r213380: Sun Oct 3 04:35:15 PDT 2010 ... ugen7.1:Intel at usbus7 uhub7:Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered cd0 at ata3 bus 0 scbus2 target 0 lun 0 cd0:TSSTcorp DVD+-RW TS-U633A D200 Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada0 at ata2 bus 0 scbus1 target 0 lun 0 ada0:Seagate ST9250421ASG DE16 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. uhub7: 6 ports with 6 removable, self powered ugen2.2:Broadcom Corp at usbus2 previously-descibed hang; I used Ctl+Alt+Esc to enter DDB. KDB: enter: manual escape to debugger [ thread pid 12 tid 100017 ] Stopped at 0xc08d992a = kdb_enter+0x3a:movl$0,0xc0e33574 = kdb_why db bt Tracing pid 12 tid 100017 td 0xc94575a0 kdb_enter(c0c737ab,c0caf6cb,1,0,1,...) at 0xc06d992a = kdb_enter+0x3a scgetc(c0e21950,0,c0caf5f1,2a1,c9457644,...) at 0xc07930a8 = scgetc+0x568 sckbdevent)c92f7500,0,c0fb3ea0,c92f9400,c6da9c4c,...) at 0xc0793424 = sckbdevent+0x1e4 kbdmux_intr(c92f7500,0,c92f9608,c6da9c78,c08e63e3,...) at 0xc069c86b = kbdmux_intr+0x2b kbdmux_kbd_intr(c92f7500,1,c0ccd301,53,c9194a94,...) at 0xc069ce45 = kbdmux_kbd_intr+0x25 taskqueue_run(c9194a98,0,c0ccd301,4a,c6da9cb8,...) at 0xc08e63e3 = taskqueue_run+0xc3 taskqueue_swi_giant_run(0,0,c0cc37a5,4c3,c945a0b8,...) at 0xc08e6be6 = taskqueue_swi_giant_run+0x66 intr_event_execute_handlers(c91d37f8,c945a080,c0cc37a5,533,c945a0f0,...) at 0xc087e655 = intr_event_execute_handlers+0x125 ithread_loop(c943f980,c6da9d28,c0cc3520,349,c91d37f8,...) at 0xc087f42f = ithread_loop+-x9f fork_exit(c087f390,c943f980,c6da9d28) at 0xc087c3a8 = fork_exit+0xb8 fork_trampoline() at 0xc0bd5824 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc6da9d60, ebp = 0 --- db I used the ps command at that point to see that PID 12 is [intr], with the following assignments: PID state wmesg cmd 100072 I [irq15: ata1] 100071 I [irq14: ata0] 100070 I [irq12: psm0] 100069 I [irq1: atkbd0] 100067 I [irq19: cbb0 atapci+] 100064 I [irq17: fwohci0] 100045 I [irq1258: iwn0] 100044 I [irq1257: hdac0] 100035 I [irq122: uhci2 ehci0+] 100030 I [irq121: uhci1 ehci4] 100025 I [irq120: hpet0 ehci0*] 100023 I [irq19: acpi0] 100018 I [swi6: task queue] 100017 Run CPU 1 [swi6: Giant taskq] 100015 I [swi5: +] 100014 I [swi2: cambio] 18 I [swi4: clock] 17 I [swi4: clock] 16 I [swi1: netisr 0] 15 I [swi3: vm] I then tried panic, but that does not appear to have been successful. Peace, david well you got the stacktrace of the keyboard handler since you got into ddb via the keyboard.. you need to see what ELSE is running.. especially the initial threads. and look at THOSE stacks I think bt [thread-ID] works or maybe thread [ID] (it's bee a year). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hang near end of kernel probes since r213267 (likely earlier)
On Sun, Oct 03, 2010 at 03:42:51PM -0700, Julian Elischer wrote: ... well you got the stacktrace of the keyboard handler since you got into ddb via the keyboard.. OK you need to see what ELSE is running.. especially the initial threads. and look at THOSE stacks Ah. My lack of practice is showing. :-} I think bt [thread-ID] works or maybe thread [ID] (it's bee a year). OK. Armed with that, I tried to re-create the problem a few more times. First, I used loader.conf to: boot_verbose=YES dumpdev=/dev/ada0s4b And then just tried rebooting to single-user. I noticed, then, that for *successful* boots, I got start_init: trying /sbin/init Enter full pathname of shell or RETURN for bin/sh: *before* I saw ugen2.2: Broadcom Corp at usbus2 This, together with the observation that DDB's ps output showed just about everything other than interrupt threads in state D or DL encouraged me to check the backtraces for PID 1 (init) and PID 2 [g_event]. Hmm... actually going to single user on a successfull boot issuing ps axwwl shows most things in stat D or DL normally, so maybe I'm chasing a red herring. But at least in this case, init is not in a D state -- it's ILs. Well, maybe this will be of some use anywya: battery0: battery initialization done, tried 1 times uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered (probe0:abp0:0:0:0): Error 22, Unretryable error (probe2:abp0:0:0:0): Error 22, Unretryable error (probe4:abp0:0:0:0): Error 22, Unretryable error (probe5:abp0:0:0:0): Error 22, Unretryable error (probe1:abp0:0:0:0): Error 22, Unretryable error (probe3:abp0:0:0:0): Error 22, Unretryable error (probe6:abp0:0:0:0): Error 22, Unretryable error GEOM: new disk cd0 (cd0:ata3:0:0:0): SCSI status error (cd0:ata3:0:0:0): Requesting SCSI sense data (cd0:ata3:0:0:0): SCSI status error (cd0:ata3:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata3:0:0:0): CAM status: SCSI Status Error (cd0:ata3:0:0:0): SCSI status: Check Condition (cd0:ata3:0:0:0): SCSI sense: NOT READY asc:3a, 1 (Medium not present - tray closed) (cd0:ata3:0:0:0): Error 6, Unretryable error cd0 at ata3 bus 0 scbus2 target 0 lun 0 cd0: TSSTcorp DVD+-RW TS-U633A D200 Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada0 at ata2 bus 0 scbus1 target 0 lun 0 ada0: ST9250421ASG DE16 ATA-8 SATA 2.x device ada0: Serial Number 5TH0BAZX ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) pass0 at ata2 bus 0 scbus2 target 0 lun 0 pass0: ST9250421ASG DE16 ATA-8 SATA 2.x device pass0: Serial Number 5TH0BAZX pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) pass1 at ata3 bus 0 scbus2 target 0 lun 0 pass1: TSSTcorp DVD+-RW TS-U633A D200 Removable CD-ROM SCSI-0 device pass1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x0100 VER: 0x00050014 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400 cmci: 0x CPU1: local APIC error 0x80 ooapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48f wtable ciloeaapniecr0 :s troaurttiendg intpin 12 (ISA IRQ 12) to lapic 1 vector 49 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 50 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 51 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 52 msi: Assigning MSI IRQ 257 to local APIC 1 vector 53 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ugen2.2: Broadcom Corp at usbus2 hang for a while -- keybaord mostly unresponsive battery1: battery initialization failed, giving up hang continues; I enter Ctl+Atl+Esc KDB: enter: manual escape to debugger [ thread pid 12 tid 100017 ] Stopped at 0xc08d992a = kdb_enter+0x3a:movl$0,0xc0e33574 = kdb_why db show locks exclusive sleep mutex Giant (Giant) r = 1 (0xc0e21950) locked @ /usr/src/sys/dev/syscons/syscons.c:673 db bt 1 Tracing pid 1 tid 12 td 0xc91d6b40 sched_switch(c91d6b40,0,104,191,a4bfdaac,...) at 0xc08cccec = sched_switch+0x3bc mi_switch(104,0,c0cccb89,1f3,68,...) at 0xc08af3a0 = mi_switch+0x200 sleepq_switch(c91d6b40,0,c0cccb89,28b,0,...) at 0xc08e4b7b = sleepq_switch+0x15f sleepq_timedwait(c0e1fc24,69,c0cbe3e4,0,0,...) at 0xc08e4b7b = sleepq_timedwait+0x6b _sleep(c0e1fc24,c0e1fc28,68,c0cbe3e4,c8,...) at 0xc08af892 = _sleep+0x342
dmesg mangled by acd0 probe
I suspect that 517 ( are not expected during boot. acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (((cd0 at ata0 bus 0 scbus1 target 0 lun 0 cd0: SONY CDRWDVD CRX880A KD09 Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! Root mount waiting for: usbus6 usbus2 -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dmesg mangled by acd0 probe
On Sun, Oct 3, 2010 at 7:16 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: I suspect that 517 ( are not expected during boot. acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (((cd0 at ata0 bus 0 scbus1 target 0 lun 0 cd0: SONY CDRWDVD CRX880A KD09 Removable CD-ROM SCSI-0 device Does this always happen with acd0? There was another instance I think mav@ saw for a different driver that showed up when I made the sbuf drain additions. I can't think of how my code could cause that, but there's always a possibility. Thanks, matthew cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! Root mount waiting for: usbus6 usbus2 -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dmesg mangled by acd0 probe
On Sun, Oct 03, 2010 at 08:05:49PM -0700, Matthew Fleming wrote:
On Sun, Oct 3, 2010 at 7:16 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
I suspect that 517 ( are not expected during boot.
acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
(517 '(' deleted)
cd0 at ata0 bus 0 scbus1 target 0 lun 0
cd0: SONY CDRWDVD CRX880A KD09 Removable CD-ROM SCSI-0 device
Does this always happen with acd0? There was another instance I think
mav@ saw for a different driver that showed up when I made the sbuf
drain additions. I can't think of how my code could cause that, but
there's always a possibility.
This is first time I spotted this output. My /usr/src and kernel/world
are from Oct 1, roughly 2000 PST. Looking through /var/log/message, the
string of '(' show up after the acd0 probes and once here:
Oct 2 15:58:30 laptop kernel: drm0: [ITHREAD]
Oct 2 15:59:24 laptop kernel:
(((g_vfs_done():da1s1[WRITE(offset=512,
length=4096)]error = 13
Oct 2 15:59:24 laptop kernel:
(((g_vfs_done():da1s1[WRITE(offset=512,
length=4096)]error = 13
I don't know if it matters, but for this kernel I have the following
commented out
#optionsINVARIANTS
#optionsINVARIANT_SUPPORT
#optionsWITNESS
#optionsWITNESS_SKIPSPIN
Is there a kernel option or patch you want me to use to get additional
information?
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dmesg mangled by acd0 probe
On Sun, Oct 03, 2010 at 08:05:49PM -0700, Matthew Fleming wrote:
Does this always happen with acd0?
The long string of '(' appeared in 5 out of 5
'shutdown -r now'. So, this is definitely
reproducible for me.
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
fcntl always fails to delete lock file, and PID is always -6464
It looks very strange. fcntl() always fails to delete lock file and command.l_pid is always -6464. This issue is disclosed in porting Google's Japanese input system called mozc. details follow: http://code.google.com/p/mozc/issues/detail?id=40 % uname -a FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010 r...@parancell.ongs.co.jp:/usr/obj/usr/src/sys/PARANCELL amd64 % My home directory on NFS server. Does anyone have any ideas? -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dmesg mangled by acd0 probe
Matthew Fleming wrote: On Sun, Oct 3, 2010 at 7:16 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: I suspect that 517 ( are not expected during boot. acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (((cd0 at ata0 bus 0 scbus1 target 0 lun 0 cd0: SONY CDRWDVD CRX880A KD09 Removable CD-ROM SCSI-0 device Does this always happen with acd0? There was another instance I think mav@ saw for a different driver that showed up when I made the sbuf drain additions. I can't think of how my code could cause that, but there's always a possibility. I indeed saw that thing. But it gone after few days. AFAIR kib@ fixed missing ++ somewhere there, but I haven't checked especially. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
