Re: usb-regression (Tyan S3992-E)
On Wednesday 05 January 2011 00:36:29 Arno J. Klaassen wrote: Hallo, definitely my Tyan S3992-E based box I didn't touch since a while, has difficulties with recent code; this time I wanted to cross-install from it on a USB-stick and noticed it didn't work. From dmesg : ohci early: SMM active, request owner change found- vendor=0x1166, dev=0x0223, revid=0x01 domain=0, bus=0, slot=3, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0xf8 (7440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xff6ed000, size 12, enabled map[14]: type I/O Port, range 32, base 0xd800, size 8, enabled pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 10 unknown: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff6ed000 ohci early: SMM active, request owner change [same on -current and -8-stable] I compiled and ran a 7-stable kernel of Oct6-sources (last time I cvs updated ...) on it, which gives : ohci0: OHCI (generic) USB controller port 0xd400-0xd4ff mem 0xff6ec000-0xff6ecfff irq 10 at device 3.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff6ec000 ohci0: (New OHCI DeviceId=0x02231166) ioapic0: routing intpin 10 (ISA IRQ 10) to vector 52 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered Pleasure to provide more info and/or test suggestions. This might be ACPI related. Have you tried booting without ACPI? --HPS ___ 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: mfiutil and raid level
Em 04/01/2011 14:37, John Baldwin escreveu: Previous RAID-10 volumes that I've seen MFI BIOSes create used a non-zero secondary raid level (they all used '3', which is what mfiutil uses to create RAID-10 volumes itself). Thank you for the answer, i will use the array created with mfiutil... Just for confirm, i´ve made more tests and more one time the array from bios still stay with secondary raid level = 0 when creates a raid 10. Creating with mfiutil, OK... mfiutil create raid10 e1:s0,e1:s1 e1:s2,e1:s3 mfiutil name mfid1 DADOS noname# mfiutil show volumes mfi0 Volumes: Id SizeLevel Stripe State Cache Name mfid0 ( 465G) RAID-1 64K OPTIMAL Disabled SO mfid1 ( 272G) RAID-10 64K OPTIMAL Writes DADOS noname# ./mfiutil debug mfi0 Configuration (Debug): 3 arrays, 2 volumes, 0 spares array size: 288 volume size: 256 spare size: 40 array 0 of 2 drives: size = 975699968 drive 4 ONLINE raw size: 976773168 non-coerced size: 975724592 coerced size: 975699968 drive 5 ONLINE raw size: 976773168 non-coerced size: 975724592 coerced size: 975699968 array 1 of 2 drives: size = 285474816 drive 0 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 drive 1 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 array 2 of 2 drives: size = 285474816 drive 2 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 drive 3 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 volume mfid0 RAID-1 OPTIMAL SO primary raid level: 1 raid level qualifier: 0 secondary raid level: 0 stripe size: 7 num drives: 2 init state: 0 consistent: 1 no bgi: 0 spans: array 0 @ 0 : 975699968 volume mfid1 RAID-10 OPTIMAL DADOS primary raid level: 1 raid level qualifier: 0 secondary raid level: 3 stripe size: 7 num drives: 2 init state: 0 consistent: 0 no bgi: 0 spans: array 1 @ 0 : 285474816 array 2 @ 0 : 285474816 noname# Creating with BIOS... secondary raid level = 0 noname# mfiutil show volumes mfi0 Volumes: Id SizeLevel Stripe State Cache Name mfid0 ( 465G) RAID-1 64K OPTIMAL Disabled SO mfid1 ( 272G) RAID-1 64K OPTIMAL Disabled NEWDADOS noname# ./mfiutil debug mfi0 Configuration (Debug): 3 arrays, 2 volumes, 0 spares array size: 288 volume size: 256 spare size: 40 array 0 of 2 drives: size = 975699968 drive 4 ONLINE raw size: 976773168 non-coerced size: 975724592 coerced size: 975699968 drive 5 ONLINE raw size: 976773168 non-coerced size: 975724592 coerced size: 975699968 array 1 of 2 drives: size = 285474816 drive 0 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 drive 1 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 array 2 of 2 drives: size = 285474816 drive 2 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 drive 3 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 volume mfid0 RAID-1 OPTIMAL SO primary raid level: 1 raid level qualifier: 0 secondary raid level: 0 stripe size: 7 num drives: 2 init state: 0 consistent: 1 no bgi: 0 spans: array 0 @ 0 : 975699968 volume mfid1 RAID-1 OPTIMAL NEWDADOS primary raid level: 1 raid level qualifier: 0 secondary raid level: 0 stripe size: 7 num drives: 2 init state: 0 consistent: 0 no bgi: 0 spans: array 1 @ 0 : 285474816 array 2 @ 0 : 285474816 noname# Screen from BIOS: http://img808.imageshack.us/i/dellr510h70003lds.jpg/ http://img824.imageshack.us/i/dellr510h70002create.jpg/ http://img338.imageshack.us/i/dellr510h70001noarray.jpg/ Regards. -- Danilo G. Baio (dbaio) ___ 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: [RFC]: unnecessary padding in various kernel structures
On 04/01/2011 19:59, Roman Divacky wrote:
hi,
clang (svn version) has ability to detect unnecessary padding in structures.
I ran this on kernel build on i386 (stripped GENERIC) and amd64 (full GENERIC),
preprocessed this and posted on web.
The lists contain the file of the definition, name of the structure, size of
the unnecessary padding and reason for the alignment. The last field is
how many times this was hit during the build of the kernel.
It looks like padding... to alignment boundary means because of
struct {...} __aligned(CACHE_LINE_SIZE) and such, and we cannot run
away from those - maybe you should filter those results out?
The lists are sorted by the size of the padding.
Examples (i386):
dev/usb/controller/ohci.h:64:8: 2 times
padding size of 'struct ohci_hcca' with 120 bytes to alignment boundary
sys/pcpu.h:156:8: 58 times
padding size of 'struct pcpu' with 108 bytes to alignment boundary
sys/pcpu.h:199:2: 58 times
padding struct 'struct pcpu' with 84 bytes to align 'pc_monitorbuf'
dev/usb/controller/ehci.h:170:8:1 times
padding size of 'struct ehci_qtd' with 58 bytes to alignment boundary
kern/sched_ule.c:206:8: 1 times
padding size of 'struct tdq' with 41 bytes to alignment boundary
Examples(amd64):
net/flowtable.c:179:11: 1 times
padding struct 'struct flowtable' with 124 bytes to align 'ft_udp_idle'
dev/usb/controller/ohci.h:64:8: 2 times
padding size of 'struct ohci_hcca' with 120 bytes to alignment boundary
net/flowtable.c:160:8: 1 times
padding size of 'struct flowtable' with 108 bytes to alignment boundary
vm/uma_int.h:184:8: 6 times
padding size of 'struct uma_cache' with 96 bytes to alignment boundary
vm/uma_int.h:338:19:5 times
padding struct 'struct uma_zone' with 92 bytes to align 'uz_cpu'
net/flowtable.c:149:8: 1 times
padding size of 'struct flowtable_stats' with 64 bytes to alignment
boundary
___
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: CAM related panic on 8.2-PRERELEASE Was: Re: USB related panic on 8.2-PRERELEASE
On Tue, Dec 28, 2010 at 9:49 AM, Oleg Nauman oleg.nau...@gmail.com wrote: On Fri, Dec 10, 2010 at 8:15 PM, Hans Petter Selasky hsela...@c2i.net wrote: Hi, Hello, I think this is a known issue which never got fixed. Please try the attached patch and report back. XXX_SAFE != XXX_REAL_SAFE :-) My laptop experienced a crash again, this time it seems CAM related: Unread portion of the kernel message buffer: umass0: at uhub5, port 3, addr 2 (disconnected) (probe0:umass-sim0:0:0:0): AutoSense failed kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0736482 stack pointer = 0x28:0xc5225bd4 frame pointer = 0x28:0xc5225bec code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 12 (swi2: cambio) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xc072ac57 at kdb_backtrace+0x47 #1 0xc06ffe97 at panic+0x117 #2 0xc09a31f3 at trap_fatal+0x323 #3 0xc09a3602 at trap+0x152 #4 0xc098c87c at calltrap+0x6 #5 0xc06f25e9 at _mtx_unlock_sleep+0x49 #6 0xc06f2669 at _mtx_unlock_flags+0x49 #7 0xc0473bb0 at camisr+0x110 #8 0xc06de98c at intr_event_execute_handlers+0x14c #9 0xc06df77e at ithread_loop+0xbe #10 0xc06dccde at fork_exit+0xee #11 0xc098c8f4 at fork_trampoline+0x8 Uptime: 6m55s Physical memory: 2027 MB Dumping 121 MB: 106 90 74 58 42 26 10 Reading symbols from /boot/modules/bwn_v4_ucode.ko...Reading symbols from /boot/modules/bwn_v4_ucode.ko.symbols...done. done. Loaded symbols for /boot/modules/bwn_v4_ucode.ko Reading symbols from /boot/modules/cuse4bsd.ko...done. Loaded symbols for /boot/modules/cuse4bsd.ko #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc06ffc93 in boot (howto=260) at ../../../kern/kern_shutdown.c:419 #2 0xc06ffed0 in panic (fmt=Variable fmt is not available. ) at ../../../kern/kern_shutdown.c:592 #3 0xc09a31f3 in trap_fatal (frame=0xc5225b94, eva=20) at ../../../i386/i386/trap.c:946 #4 0xc09a3602 in trap (frame=0xc5225b94) at ../../../i386/i386/trap.c:326 #5 0xc098c87c in calltrap () at ../../../i386/i386/exception.s:166 #6 0xc0736482 in turnstile_broadcast (ts=0x0, queue=0) at ../../../kern/subr_turnstile.c:831 #7 0xc06f25e9 in _mtx_unlock_sleep (m=0xc67e170c, opts=0, file=0xc0a04b40 ../../../cam/cam_xpt.c, line=4715) at ../../../kern/kern_mutex.c:675 #8 0xc06f2669 in _mtx_unlock_flags (m=0xc67e170c, opts=0, file=0xc0a04b40 ../../../cam/cam_xpt.c, line=4715) at ../../../kern/kern_mutex.c:227 #9 0xc0473bb0 in camisr (dummy=0x0) at ../../../cam/cam_xpt.c:4715 #10 0xc06de98c in intr_event_execute_handlers (p=0xc556f7f8, ie=0xc56a8800) at ../../../kern/kern_intr.c:1220 #11 0xc06df77e in ithread_loop (arg=0xc556e2b0) at ../../../kern/kern_intr.c:1233 #12 0xc06dccde in fork_exit (callout=0xc06df6c0 ithread_loop, arg=0xc556e2b0, frame=0xc5225d28) at ../../../kern/kern_fork.c:845 #13 0xc098c8f4 in fork_trampoline () at ../../../i386/i386/exception.s:273 (kgdb) Filed PR 153514 for better the things tracking. Is it possible to look into this issue? It happens with device umass enabled in my kernel config file --HPS On Thursday 09 December 2010 12:02:48 Oleg Nauman wrote: On Wed, Dec 8, 2010 at 7:05 PM, Oleg Nauman oleg.nau...@gmail.com wrote: Hello Hans, On Wed, Dec 8, 2010 at 3:33 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Wednesday 08 December 2010 11:41:28 Oleg Nauman wrote: Hello, Unfortunately my notebook experienced the crash during the attempts to attach EVDO modem supplied with builtin MicroSD cardreader. Related core.txt file is attached as well as 'usbconfig dump_all_config_desc' output (all_config.txt) USB subsystem reports endless USB_ERR_STALLED events during attempts to attach umass device, but attaches it finally ( sometimes it attached after two attempts, sometimes it trying to attach during 15-20 minutes ).MicroSD is inserted there, without any effect on attachment attempts though. Hi, Can you reproduce the panic using a kernel built with INVARIANTS options and DEBUG_MEMGUARD . I rebuilt my kernel with options you mentioned ( have added INVARIANT_SUPPORT required by INVARIANTS though ) Waiting on panic.. Got it finally ( core.txt file is attached ) ___ 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: usb-regression (Tyan S3992-E)
On Tuesday, January 04, 2011 6:36:29 pm Arno J. Klaassen wrote: Hallo, definitely my Tyan S3992-E based box I didn't touch since a while, has difficulties with recent code; this time I wanted to cross-install from it on a USB-stick and noticed it didn't work. From dmesg : ohci early: SMM active, request owner change found- vendor=0x1166, dev=0x0223, revid=0x01 domain=0, bus=0, slot=3, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0xf8 (7440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xff6ed000, size 12, enabled map[14]: type I/O Port, range 32, base 0xd800, size 8, enabled pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 10 unknown: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff6ed000 ohci early: SMM active, request owner change Can you get a larger chunk of dmesg? These are just the messages from the PCI bus driver, not from the ohci driver. Are you sure you have ohci in your test kernel? -- John Baldwin ___ 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
FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
Hello folks, Now that I'm fairly confident that the stability issues with your.org's VMs have been resolved, I'd like to point you to the new and improved, semi-weekly analyzer runs at http://scan.freebsd.your.org/freebsd-head/ If you are an HTML/CSS expert and want to help style that page a little more in FreeBSD style, please get in touch with me. Thanks! Uli ___ 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
RFC regarding usage of ISO 8601 throughout the tree
!ACHTUNG BIKESHED ALERT! Hello, With the recent changes to the committer graphs, I again was reminded how much I hate the /MM/DD format (I can't help it ...). Given that this almost looks like ISO 8601, but is an unreadable variant of it, I would like to aggressively change this throughout the tree. I'd like to start with minor stuff like share/misc/*.dot. Then probably src/UPDATING, and ports/UPDATING after I've identified the consumers of these docs. The ultimate goal would be to change syslog's timestamp and ps(1) output, but that goal is far off ... http://en.wikipedia.org/wiki/ISO_8601 Uli ___ 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: RFC regarding usage of ISO 8601 throughout the tree
On Wed, Jan 05, 2011 at 02:21:55PM +0100, Ulrich Sp??rlein wrote: !ACHTUNG BIKESHED ALERT! Hello, With the recent changes to the committer graphs, I again was reminded how much I hate the /MM/DD format (I can't help it ...). Given that this almost looks like ISO 8601, but is an unreadable variant of it, I would like to aggressively change this throughout the tree. I'd like to start with minor stuff like share/misc/*.dot. Then probably src/UPDATING, and ports/UPDATING after I've identified the consumers of these docs. Can we, please, move share/misc/*.dot to doc/ repository, where it belongs and would make a nice addition to the freebsd-contributors article ? The ultimate goal would be to change syslog's timestamp and ps(1) output, but that goal is far off ... http://en.wikipedia.org/wiki/ISO_8601 Uli ___ 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 pgpRFeBQo7jB2.pgp Description: PGP signature
Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
Den 05/01/2011 kl. 14.56 skrev Erik Cederstrand: Ignoring contrib code for the moment, I decided to look at usr.sbin.pw from 2011-01-05. There's one report (http://scan.freebsd.your.org/freebsd-head/usr.sbin.pw/2011-01-05-amd64/report-KkilQ3.html#EndPath) which turns out to be a false positive: * Step 6 calls cmdhelp() on line 168; * cmdhelp() ends with exit(EXIT_FAILURE); on line 432 which I assume is exit(3) from libc * The analyzer doesn't know that this function never returns and continues to flag a null dereference in step 8 The same is true of err(), verr(), errc(), verrc(), errx(), and verrx() which is also causing false positive reports. They ultimately call exit(3). Erik
Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
Den 05/01/2011 kl. 14.14 skrev Ulrich Spörlein: Hello folks, Now that I'm fairly confident that the stability issues with your.org's VMs have been resolved, I'd like to point you to the new and improved, semi-weekly analyzer runs at http://scan.freebsd.your.org/freebsd-head/ I had a look at this again. There are over 9.000 reports so it's a bit overwhelming, but I suspect there's a lot of collateral damage. Ignoring contrib code for the moment, I decided to look at usr.sbin.pw from 2011-01-05. There's one report (http://scan.freebsd.your.org/freebsd-head/usr.sbin.pw/2011-01-05-amd64/report-KkilQ3.html#EndPath) which turns out to be a false positive: * Step 6 calls cmdhelp() on line 168; * cmdhelp() ends with exit(EXIT_FAILURE); on line 432 which I assume is exit(3) from libc * The analyzer doesn't know that this function never returns and continues to flag a null dereference in step 8 What's the fix here? I think the reports are an excellent way to get acquainted with FreeBSD code. Marking and fixing the false positives would make bug-hunting in the remaining reports more motivating :-) Thanks, Erik
Re: Virtio drivers for FreeBSD on KVM
Pete French (petefrench) writes: Actually, it does look like virtio is more than just for networking... http://vbox.innotek.de/pipermail/vbox-dev/2009-November/002053.html Yes indeed. Disk drivers as well. By the way, does anyone whatever happened to the KVM for FreeBSD project ? Nothing since Summer of Code 2007... http://wiki.freebsd.org/FabioChecconi/PortingLinuxKVMToFreeBSD http://retis.sssup.it/~fabio/freebsd/lkvm/ Cheers, Phil ___ 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: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
On Wednesday, January 05, 2011 9:11:50 am Erik Cederstrand wrote: Den 05/01/2011 kl. 14.56 skrev Erik Cederstrand: Ignoring contrib code for the moment, I decided to look at usr.sbin.pw from 2011-01-05. There's one report (http://scan.freebsd.your.org/freebsd-head/usr.sbin.pw/2011-01-05-amd64/report-KkilQ3.html#EndPath) which turns out to be a false positive: * Step 6 calls cmdhelp() on line 168; * cmdhelp() ends with exit(EXIT_FAILURE); on line 432 which I assume is exit(3) from libc * The analyzer doesn't know that this function never returns and continues to flag a null dereference in step 8 The same is true of err(), verr(), errc(), verrc(), errx(), and verrx() which is also causing false positive reports. They ultimately call exit(3). These are all marked as __dead2, so the compiler should know that these do not return. -- John Baldwin ___ 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: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
On Wed, 05.01.2011 at 09:34:49 -0500, John Baldwin wrote: On Wednesday, January 05, 2011 9:11:50 am Erik Cederstrand wrote: Den 05/01/2011 kl. 14.56 skrev Erik Cederstrand: Ignoring contrib code for the moment, I decided to look at usr.sbin.pw from 2011-01-05. There's one report (http://scan.freebsd.your.org/freebsd-head/usr.sbin.pw/2011-01-05-amd64/report-KkilQ3.html#EndPath) which turns out to be a false positive: * Step 6 calls cmdhelp() on line 168; * cmdhelp() ends with exit(EXIT_FAILURE); on line 432 which I assume is exit(3) from libc * The analyzer doesn't know that this function never returns and continues to flag a null dereference in step 8 The same is true of err(), verr(), errc(), verrc(), errx(), and verrx() which is also causing false positive reports. They ultimately call exit(3). These are all marked as __dead2, so the compiler should know that these do not return. And clang did the right thing here in the past. Beware that it does no inter-procedural analysis yet, so it will usually miss that usage() calls exit unconditionally. *But*, it should grok that for err(3) and exit(3). Now there are some possible remedies: - get IPA to work with clang, or at least file a bug - mark functions as __dead2 (please don't do that) - come up with a way to mark the false positives (kinda impossible with the way scan-build currently works) All interested parties with src access are encouraged to take a look at our Coverity Prevent installation (which is down for maintenance, but should be up soon). Regards, Uli ___ 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: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Sp??rlein wrote: On Wed, 05.01.2011 at 09:34:49 -0500, John Baldwin wrote: On Wednesday, January 05, 2011 9:11:50 am Erik Cederstrand wrote: Den 05/01/2011 kl. 14.56 skrev Erik Cederstrand: Ignoring contrib code for the moment, I decided to look at usr.sbin.pw from 2011-01-05. There's one report (http://scan.freebsd.your.org/freebsd-head/usr.sbin.pw/2011-01-05-amd64/report-KkilQ3.html#EndPath) which turns out to be a false positive: * Step 6 calls cmdhelp() on line 168; * cmdhelp() ends with exit(EXIT_FAILURE); on line 432 which I assume is exit(3) from libc * The analyzer doesn't know that this function never returns and continues to flag a null dereference in step 8 The same is true of err(), verr(), errc(), verrc(), errx(), and verrx() which is also causing false positive reports. They ultimately call exit(3). These are all marked as __dead2, so the compiler should know that these do not return. And clang did the right thing here in the past. Beware that it does no inter-procedural analysis yet, so it will usually miss that usage() calls exit unconditionally. *But*, it should grok that for err(3) and exit(3). Now there are some possible remedies: - get IPA to work with clang, or at least file a bug - mark functions as __dead2 (please don't do that) - come up with a way to mark the false positives (kinda impossible with the way scan-build currently works) The problem is that while exit() is __dead2 the actual cmdhelp() is not. At least clang does not see it as such. Thus the static analyzer just sees a call to a normal function (it does not recurse into it) and produces this false positive... I wonder how how hard would it to be to add some trivial IPA that analyzes cases like this.. ___ 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: RFC regarding usage of ISO 8601 throughout the tree
Ulrich =?utf-8?B?U3DDtnJsZWlu?= wrote: !ACHTUNG BIKESHED ALERT! Hello, With the recent changes to the committer graphs, I again was reminded how much I hate the /MM/DD format (I can't help it ...). Given that I guess hope you mean you like linear decreasing order but dislike '/' as a delimeter want to swap from '/' to '-' as in ISO ? this almost looks like ISO 8601, but is an unreadable variant of it, I would like to aggressively change this throughout the tree. I'd like to start with minor stuff like share/misc/*.dot. Then probably src/UPDATING, and ports/UPDATING after I've identified the consumers of these docs. Do you mean you would like to swap eg src/UPDATING 20100720 to eg 2010-07-20 ? That would be more readable. The ultimate goal would be to change syslog's timestamp and ps(1) output, but that goal is far off ... I've long had a mental note to get round to fixing isnd which emits: 05.01.2011 13:15:06 To 2011-01-05 13:15:06 However reading that URL, I see isdnd should have eg: 2011-01-05T13:15:06 2011-01-05T13:15:06+01:00 2011-01-05T12:15:06Z But that 'T' is hard to see, so either space it (allowed by ISO) 2011-01-05 13:15:06 2011-01-05 13:15:06+01:00 2011-01-05 12:15:06Z or lower case the 't' (if ISO allows ?) 2011-01-05t13:15:06 2011-01-05t13:15:06+01:00 2011-01-05t12:15:06Z http://en.wikipedia.org/wiki/ISO_8601 Uli Week numbers in ISO standard can ( should IMO) be ignored: Not much use for week numbers in FreeBSD, Dates when source code is released, /var/logs get stamped etc, best without week numbers, just simplistic linearly progressive continuously decremental digit format (ie Year Month Day Hour Minute Second Week numbers not used much, eg I'm British, lived in Germany 25 years. First I ever saw of week numbers was in Germany, never saw them in Britain. /usr/src/bin/date/ Although default output of date eg Wed Jan 5 17:41:06 CET 2011 is both non linear, also non conformant in timezone (CET should be +01:00) it would open a can of worms to change default output, [unless it hangs on an env var.] ... [at least yet] ... too many shells use it (in user's own code, not just in /usr/src /usr/ports). I don't see anything in `man date` to internaly emit timezone per ISO, this works: echo `date -u +%Y-%m-%dt%H:%M:%S`Z echo `date -u +%Y-%m-%dt%H:%M:%S`+00:00 echo `date -v-1H +%Y-%m-%dt%H:%M:%S`Z # (as my TZ is -01:00) but as that wouldnt do if nested inside more quotes from other shells, we could add to date.c to emit an explicit timezone, 2 flags to add, I suggest: - '-U' to force '-u' also swap output of eg CET 2011 to 2011Z or 2011+00:00( '-U' is not yet used ). - Some flag to specify a numeric string eg [+-][0-5][0-9]:[0-5][0-9] (... maybe tie that in with man environ TZ tzset ? ) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, or HTML or base 64. Avoid top posting, it cripples itemised cumulative responses. ___ 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: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Spörlein wrote: On Wed, 05.01.2011 at 09:34:49 -0500, John Baldwin wrote: These are all marked as __dead2, so the compiler should know that these do not return. And clang did the right thing here in the past. Beware that it does no inter-procedural analysis yet, so it will usually miss that usage() calls exit unconditionally. *But*, it should grok that for err(3) and exit(3). Now there are some possible remedies: - get IPA to work with clang, or at least file a bug - mark functions as __dead2 (please don't do that) Why not? I have done this in some cases because it leads to better code with gcc (the system version in 9-current). See SVN commit r212508 to bin/sh/parser.c. Although synexpect() and synerror() are static, adding __dead2 to both makes the executable 576 bytes smaller on i386 (these functions are called many times). Adding __dead2 to synexpect() only causes a warning noreturn function does return (it calls synerror()). Adding __dead2 to synerror() only also makes the executable smaller but not as much as adding it to both. Reordering the functions in the file does not help to make gcc see that the functions do not return. - come up with a way to mark the false positives (kinda impossible with the way scan-build currently works) -- Jilles Tjoelker ___ 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: RFC regarding usage of ISO 8601 throughout the tree
On Wed, 05.01.2011 at 19:00:31 +0100, Julian H. Stacey wrote: Ulrich =?utf-8?B?U3DDtnJsZWlu?= wrote: !ACHTUNG BIKESHED ALERT! Hello, With the recent changes to the committer graphs, I again was reminded how much I hate the /MM/DD format (I can't help it ...). Given that I guess hope you mean you like linear decreasing order but dislike '/' as a delimeter want to swap from '/' to '-' as in ISO ? Exactly. this almost looks like ISO 8601, but is an unreadable variant of it, I would like to aggressively change this throughout the tree. I'd like to start with minor stuff like share/misc/*.dot. Then probably src/UPDATING, and ports/UPDATING after I've identified the consumers of these docs. Do you mean you would like to swap eg src/UPDATING 20100720 to eg 2010-07-20 ? That would be more readable. Yes, I think for lists of dates like in UPDATING or automatically generated date output like syslogd, the ISO8601 format only has advantages. The ultimate goal would be to change syslog's timestamp and ps(1) output, but that goal is far off ... I've long had a mental note to get round to fixing isnd which emits: 05.01.2011 13:15:06 To 2011-01-05 13:15:06 Hehe, isdnd was written by a German, it seems :) However reading that URL, I see isdnd should have eg: 2011-01-05T13:15:06 2011-01-05T13:15:06+01:00 2011-01-05T12:15:06Z But that 'T' is hard to see, so either space it (allowed by ISO) 2011-01-05 13:15:06 2011-01-05 13:15:06+01:00 2011-01-05 12:15:06Z or lower case the 't' (if ISO allows ?) 2011-01-05t13:15:06 2011-01-05t13:15:06+01:00 2011-01-05t12:15:06Z I'd prefer the space to T or t for easier human parsing (and for machine parsing it doesn't really matter) http://en.wikipedia.org/wiki/ISO_8601 Uli Week numbers in ISO standard can ( should IMO) be ignored: Not much use for week numbers in FreeBSD, Dates when source code is released, /var/logs get stamped etc, best without week numbers, just simplistic linearly progressive continuously decremental digit format (ie Year Month Day Hour Minute Second Week numbers not used much, eg I'm British, lived in Germany 25 years. First I ever saw of week numbers was in Germany, never saw them in Britain. Outside of cal/ncal I don't think we use week numbers anywhere in FreeBSD. /usr/src/bin/date/ Although default output of date eg Wed Jan 5 17:41:06 CET 2011 is both non linear, also non conformant in timezone (CET should be +01:00) it would open a can of worms to change default output, [unless it hangs on an env var.] ... [at least yet] ... too many shells use it (in user's own code, not just in /usr/src /usr/ports). I don't see anything in `man date` to internaly emit timezone per ISO, this works: echo `date -u +%Y-%m-%dt%H:%M:%S`Z echo `date -u +%Y-%m-%dt%H:%M:%S`+00:00 echo `date -v-1H +%Y-%m-%dt%H:%M:%S`Z # (as my TZ is -01:00) but as that wouldnt do if nested inside more quotes from other shells, we could add to date.c to emit an explicit timezone, 2 flags to add, I suggest: - '-U' to force '-u' also swap output of eg CET 2011 to 2011Z or 2011+00:00( '-U' is not yet used ). - Some flag to specify a numeric string eg [+-][0-5][0-9]:[0-5][0-9] (... maybe tie that in with man environ TZ tzset ? ) It's too late to change anything in date(1)'s default output, and it has %F already via strftime(3) so people like me can already use that everywhere. Regards, Uli ___ 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 and
hi all: i set up the freeradius 21.100.1 on freebsd 8.1. it uses local authentication database of /etc/passwd (thanks to the previous discussions alan did with others). the problem is: it only works with the condition of the server id running as root instead of freeradius due to the one way MD5 hash of /etc/passwd file. are there any other better ways to implement this? ___ 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: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
Den 05/01/2011 kl. 17.55 skrev Ulrich Spörlein: And clang did the right thing here in the past. Beware that it does no inter-procedural analysis yet, so it will usually miss that usage() calls exit unconditionally. *But*, it should grok that for err(3) and exit(3). Now there are some possible remedies: - get IPA to work with clang, or at least file a bug I filed a bug with LLVM (http://llvm.org/bugs/show_bug.cgi?id=8914) but it seems IPA bugs filed on the analyzer have been rejected in the past. Erik
Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
On Wed, Jan 05, 2011 at 09:22:42PM +0100, Erik Cederstrand wrote: Den 05/01/2011 kl. 17.55 skrev Ulrich Sp?rlein: And clang did the right thing here in the past. Beware that it does no inter-procedural analysis yet, so it will usually miss that usage() calls exit unconditionally. *But*, it should grok that for err(3) and exit(3). Now there are some possible remedies: - get IPA to work with clang, or at least file a bug I filed a bug with LLVM (http://llvm.org/bugs/show_bug.cgi?id=8914) but it seems IPA bugs filed on the analyzer have been rejected in the past. I have a dumb patch that may help here... can someone test it? http://lev.vlakno.cz/~rdivacky/clang-checker-no-return.patch it may slow down the analysis a lot, if it does please add a recursion limit there... roman ___ 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: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
On Wed, 05.01.2011 at 20:36:53 +0100, Jilles Tjoelker wrote: On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Spörlein wrote: On Wed, 05.01.2011 at 09:34:49 -0500, John Baldwin wrote: These are all marked as __dead2, so the compiler should know that these do not return. And clang did the right thing here in the past. Beware that it does no inter-procedural analysis yet, so it will usually miss that usage() calls exit unconditionally. *But*, it should grok that for err(3) and exit(3). Now there are some possible remedies: - get IPA to work with clang, or at least file a bug - mark functions as __dead2 (please don't do that) Why not? Cause IMHO it adds clutter, is noisy and needs to be maintained manually, when we have these computer things that should deduct this by themselves. I have done this in some cases because it leads to better code with gcc (the system version in 9-current). See SVN commit r212508 to bin/sh/parser.c. Although synexpect() and synerror() are static, adding __dead2 to both makes the executable 576 bytes smaller on i386 (these functions are called many times). Adding __dead2 to synexpect() only causes a warning noreturn function does return (it calls synerror()). Adding __dead2 to synerror() only also makes the executable smaller but not as much as adding it to both. Reordering the functions in the file does not help to make gcc see that the functions do not return. This is too bad and really makes me sad. It shouldn't be necessary to hand-hold the compilers like that. Could you try some tests with gcc 4.5 to confirm this is still required? Uli ___ 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: RFC regarding usage of ISO 8601 throughout the tree
Ulrich Spörlein wrote: On Wed, 05.01.2011 at 19:00:31 +0100, Julian H. Stacey wrote: Ulrich =?utf-8?B?U3DDtnJsZWlu?= wrote: !ACHTUNG BIKESHED ALERT! Hello, With the recent changes to the committer graphs, I again was reminded how much I hate the /MM/DD format (I can't help it ...). Given that I guess hope you mean you like linear decreasing order but dislike '/' as a delimeter want to swap from '/' to '-' as in ISO ? Exactly. this almost looks like ISO 8601, but is an unreadable variant of it, I would like to aggressively change this throughout the tree. I'd like to start with minor stuff like share/misc/*.dot. Then probably src/UPDATING, and ports/UPDATING after I've identified the consumers of these docs. Do you mean you would like to swap eg src/UPDATING 20100720 to eg 2010-07-20 ? That would be more readable. Yes, I think for lists of dates like in UPDATING or automatically generated date output like syslogd, the ISO8601 format only has advantages. I am using ISO8601 date + time format for years in my scripts, logs etc., so it would be nice to have it on all places of FreeBSD as a standard format. I think 2010-07-20 is really readable than 20100720 or 2010/07/20 and 2011-01-06 00:03:50 is better than Jan 6 00:03:50 (in logs) +1 Miroslav Lachman ___ 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
system sleeping
My 9-CURRENT system are sleeping randomly and i can't see any error in logs. There are a related bug with ACPI? And, sleeping include don't answer any tcp/ip connection like ssh or the simple work that i've installed he: a gateway. But, if someone touch the keyboard, everything wake up again. The system are installed over a old AMD Semprom (x86) machine. Thanks ___ 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
Request for testing/comments -- import of new dialog/libdialog
As part of work on a new installer, I would like to update the base system dialog and libdialog to the newer one provided by Thomas Dickey (http://invisible-island.net/dialog/, ports as devel/cdialog). This is a much nicer, fuller featured version of dialog that simplifies the creation of new dialog-using tools (a longstanding impediment to a new versions of sade, sysinstall, etc.), and is under a marginally better license (LGPL2 instead of GPL2). Patches to effect the import can be found at: - http://people.freebsd.org/~nwhitehorn/libdialog-update.diff What the patches do: - Replaces dialog(1) with a new version. All command-line options of the old dialog except --fstree are accepted by the new dialog, and the ports options framework continues to work without modification. - Renames libdialog to libodialog (old dialog). The new dialog library has a much more pleasant API than the old one -- which directly implies that it has a substantially different API. Until sysinstall, sade, and tzsetup are replaced or rewritten, we need to keep the old library around. - Modifies sysinstall, sade, and tzsetup to link to libodialog instead of libdialog. - Deletes all man pages and examples associated with libodialog. This is deprecated code. - Installs new dialog library as libdialog - Bumps __FreeBSD_version to 900030 Layout of new files: - /usr/src/contrib/dialog -- contents of 20100428 release of dialog (the same as the current ports version) - /usr/src/gnu/lib/dialog -- new dialog library - /usr/src/gnu/lib/libodialog -- old dialog library - /usr/src/gnu/usr.bin/dialog -- new dialog binary I would appreciate any comments or adverse test results. If I hear nothing, I plan to commit this on Wednesday, January 12, one week from today. -Nathan ___ 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: Request for testing/comments -- import of new dialog/libdialog
On 01/05/11 18:57, Nathan Whitehorn wrote: - /usr/src/gnu/lib/dialog -- new dialog library This was a typo. It should be /usr/src/gnu/lib/libdialog. Apologies for the noise. -Nathan ___ 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: RFC regarding usage of ISO 8601 throughout the tree
On Wed, Jan 5, 2011 at 05:21, Ulrich Spörlein u...@spoerlein.net wrote: !ACHTUNG BIKESHED ALERT! Hello, With the recent changes to the committer graphs, I again was reminded how much I hate the /MM/DD format (I can't help it ...). Given that this almost looks like ISO 8601, but is an unreadable variant of it, I would like to aggressively change this throughout the tree. The current format is ISO 8601 compliant, because it allows omitting the hyphen for compactness in computer files that may be automatically processed. Also, adding the hyphen is a bit confusing, because many common (non-compliant) date systems use hyphens or slashes with the components in different orders. Omitting it is non-intuitive to everyone and thus least likely to cause confusion due to local assumptions in cases like 2001-01-02. -- Rob Farmer ___ 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
