Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
Den 05/01/2011 kl. 20.36 skrev Jilles Tjoelker: > 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? Because the analyzer is supposed to find bugs. Only the function that really doesn't return should be marked as such. If we begin spewing __dead2's everywhere, it's bound to silence a valid bug somewhere down the line when e.g. a conditional in a print_help() function is changed subtly so it doesn't always reach exit(). Erik
[head tinderbox] failure on powerpc/powerpc
TB --- 2011-01-06 08:29:16 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-06 08:29:16 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-01-06 08:29:16 - cleaning the object tree TB --- 2011-01-06 08:29:29 - cvsupping the source tree TB --- 2011-01-06 08:29:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-01-06 08:30:04 - building world TB --- 2011-01-06 08:30:04 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-06 08:30:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-06 08:30:04 - TARGET=powerpc TB --- 2011-01-06 08:30:04 - TARGET_ARCH=powerpc TB --- 2011-01-06 08:30:04 - TZ=UTC TB --- 2011-01-06 08:30:04 - __MAKE_CONF=/dev/null TB --- 2011-01-06 08:30:04 - cd /src TB --- 2011-01-06 08:30:04 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 6 08:30:05 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 6 10:06:32 UTC 2011 TB --- 2011-01-06 10:06:32 - generating LINT kernel config TB --- 2011-01-06 10:06:32 - cd /src/sys/powerpc/conf TB --- 2011-01-06 10:06:32 - /usr/bin/make -B LINT TB --- 2011-01-06 10:06:33 - building LINT kernel TB --- 2011-01-06 10:06:33 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-06 10:06:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-06 10:06:33 - TARGET=powerpc TB --- 2011-01-06 10:06:33 - TARGET_ARCH=powerpc TB --- 2011-01-06 10:06:33 - TZ=UTC TB --- 2011-01-06 10:06:33 - __MAKE_CONF=/dev/null TB --- 2011-01-06 10:06:33 - cd /src TB --- 2011-01-06 10:06:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 6 10:06:33 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/ps3/if_glc.c cc1: warnings being treated as errors /src/sys/powerpc/ps3/if_glc.c: In function 'glc_intr_filter': /src/sys/powerpc/ps3/if_glc.c:837: warning: implicit declaration of function 'atomic_set_64' /src/sys/powerpc/ps3/if_glc.c:837: warning: nested extern declaration of 'atomic_set_64' /src/sys/powerpc/ps3/if_glc.c: In function 'glc_intr': /src/sys/powerpc/ps3/if_glc.c:849: warning: implicit declaration of function 'atomic_readandclear_64' /src/sys/powerpc/ps3/if_glc.c:849: warning: nested extern declaration of 'atomic_readandclear_64' *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-06 10:19:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-06 10:19:15 - ERROR: failed to build lint kernel TB --- 2011-01-06 10:19:15 - 5317.34 user 842.23 system 6598.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ 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 Wed, Jan 05, 2011 at 06:57:14PM -0600, Nathan Whitehorn wrote: > 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 Are there any ports which link to the old version of libdialog, and if so, what will happen to them? Why not keep the old version as libdialog and instead use a new name for the new library (libndialog or whatever) ? (I am not saying you should do this - it is a real question.) -- Erik Trulsson ertr1...@student.uu.se ___ 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 Thu, 6 Jan 2011 12:09:27 +0100 Erik Trulsson wrote: > Why not keep the old version as libdialog and instead use a new name > for the new library (libndialog or whatever) ? > (I am not saying you should do this - it is a real question.) Because then we can never upgrade to a newer version of libdialog. -- Bruce Cran ___ 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/06/11 05:09, Erik Trulsson wrote: On Wed, Jan 05, 2011 at 06:57:14PM -0600, Nathan Whitehorn wrote: 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 Are there any ports which link to the old version of libdialog, and if so, what will happen to them? I could not find any, but the search was not amazingly thorough. The libdialog we had was entirely peculiar to FreeBSD, basically only for the use of sysinstall. Most external dialog-using things use dialog(1), which is compatible, and those that don't require the newer version I propose to import. Why not keep the old version as libdialog and instead use a new name for the new library (libndialog or whatever) ? (I am not saying you should do this - it is a real question. Since I plan to immediately replace dialog(1), and libodialog is immediately deprecated, renaming the old library seemed to simplify things substantially. Having libdialog under its standard name reducing the need for patching it, patching dependent ports, and confusion. -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 Thursday, January 06, 2011 6:09:27 am Erik Trulsson wrote: > On Wed, Jan 05, 2011 at 06:57:14PM -0600, Nathan Whitehorn wrote: > > 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 > > Are there any ports which link to the old version of libdialog, and if > so, what will happen to them? I think we should probably work on porting the existing libdialog consumers in the tree to the new version and then retire libodialog completely. We could then have a port of the old library for any ports that need it. -- 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: RFC regarding usage of ISO 8601 throughout the tree
On Wednesday, January 05, 2011 6:40:09 pm Miroslav Lachman wrote:
> 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)
Changing the format of syslog messages is guaranteed to break ${INFINITY}
scripts and other log parsing tools. I think that is too large of a POLA
violation to justify.
I also don't find the format used in UPDATING that hard to read as I use it on
an almost daily basis myself. Given that the format in UPDATING is already
compliant, this mostly seems to be a gratuitous change.
--
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"
[head tinderbox] failure on powerpc/powerpc
TB --- 2011-01-06 13:44:16 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-06 13:44:16 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-01-06 13:44:16 - cleaning the object tree TB --- 2011-01-06 13:44:24 - cvsupping the source tree TB --- 2011-01-06 13:44:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-01-06 13:45:23 - building world TB --- 2011-01-06 13:45:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-06 13:45:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-06 13:45:23 - TARGET=powerpc TB --- 2011-01-06 13:45:23 - TARGET_ARCH=powerpc TB --- 2011-01-06 13:45:23 - TZ=UTC TB --- 2011-01-06 13:45:23 - __MAKE_CONF=/dev/null TB --- 2011-01-06 13:45:23 - cd /src TB --- 2011-01-06 13:45:23 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 6 13:45:24 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 6 15:21:36 UTC 2011 TB --- 2011-01-06 15:21:36 - generating LINT kernel config TB --- 2011-01-06 15:21:36 - cd /src/sys/powerpc/conf TB --- 2011-01-06 15:21:36 - /usr/bin/make -B LINT TB --- 2011-01-06 15:21:36 - building LINT kernel TB --- 2011-01-06 15:21:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-06 15:21:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-06 15:21:36 - TARGET=powerpc TB --- 2011-01-06 15:21:36 - TARGET_ARCH=powerpc TB --- 2011-01-06 15:21:36 - TZ=UTC TB --- 2011-01-06 15:21:36 - __MAKE_CONF=/dev/null TB --- 2011-01-06 15:21:36 - cd /src TB --- 2011-01-06 15:21:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 6 15:21:36 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/ps3/if_glc.c cc1: warnings being treated as errors /src/sys/powerpc/ps3/if_glc.c: In function 'glc_intr_filter': /src/sys/powerpc/ps3/if_glc.c:837: warning: implicit declaration of function 'atomic_set_64' /src/sys/powerpc/ps3/if_glc.c:837: warning: nested extern declaration of 'atomic_set_64' /src/sys/powerpc/ps3/if_glc.c: In function 'glc_intr': /src/sys/powerpc/ps3/if_glc.c:849: warning: implicit declaration of function 'atomic_readandclear_64' /src/sys/powerpc/ps3/if_glc.c:849: warning: nested extern declaration of 'atomic_readandclear_64' *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-06 15:34:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-06 15:34:15 - ERROR: failed to build lint kernel TB --- 2011-01-06 15:34:15 - 5317.41 user 834.84 system 6599.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ 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 01/06/11 13:52, John Baldwin wrote:
>> 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.
> Changing the format of syslog messages is guaranteed to break ${INFINITY}
> scripts and other log parsing tools. I think that is too large of a POLA
> violation to justify.
On the other ahnd there is also a new syslog RFC which uses ISO8601
timestamps (http://tools.ietf.org/html/rfc5424) and is implemented by
syslog-ng, rsyslog and NetBSD-current.
As with most major changes the format should be configurable and use the
old format as default. But in the long term I would expect the new
format to spread (maybe just because I use it on my logserver and
already changed my parsing tools).
--
Martin
___
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, 5 Jan 2011 20:47:49 +0100 Ulrich Spörlein wrote: > > 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 :) > How quickly the world forgets :( isdnd was developed by h...@. -- Gary Jennejohn ___ 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
Gary Jennejohn wrote: > On Wed, 5 Jan 2011 20:47:49 +0100 > Ulrich Spörlein wrote: > > > > 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 :) > > How quickly the world forgets :( isdnd was developed by h...@. How quickly the world spins ;-) Hellmuth'shttp://kts.org --> http://people.freebsd.org/~hm/i4b-home/ Last edit-date: Nov 2001 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 Thursday 06 January 2011 09:01:09 Erik Cederstrand wrote: > Den 05/01/2011 kl. 20.36 skrev Jilles Tjoelker: >> 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? > > Because the analyzer is supposed to find bugs. Only the function that > really doesn't return should be marked as such. If we begin spewing > __dead2's everywhere, it's bound to silence a valid bug somewhere > down the line when e.g. a conditional in a print_help() function is > changed subtly so it doesn't always reach exit(). On the other hand you can't really expect the compiler/analyser to know what a procedure in another file does, so in that case you need __dead2 anyway. For procedures in the same file it would be nice if the compiler automatically optimised non-returning calls, but I'm not sure the analyser should do that. If the code relies on the fact that a procedure doesn't return, which is the case here, it's a good thing to declare it as such exactly to prevent bugs from creeping in. You can't add a return statement to a non-returning procedure without the compiler complaining about it and I'm sure the analyser would complain about it as well. So you won't be hiding other bugs by adding __dead2 here and there. signature.asc Description: This is a digitally signed message part.
Re: ahci timeout
I'm having these problems either. I'm running 8.2-PRERELEASE #0 r216555: Sun Dec 19 12:10:37. With only one disk connected: [FreeBSD:~] # camcontrol devlist at scbus0 target 0 lun 0 (pass1,ada0) Everything is fine. Sometimes after reconnecting drive to other Marvell bus and using: camcontrol reset/rescan I'm getting ahci timeouts. But after that system runs fine. I had problems connecting my 4xraidz1 zpool to Asus Hummingbird motherboard: ahci0: on atapci0 ahci1: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41f mem 0xfbcfbc00-0xfbcfbfff irq 21 at device 31.2 on pci0 Two disk are connected to Intel controller and another two to Marvell. I never had done anything more than importing pool and list files. After while I see ahci timeouts on Marvell controller. On Wed, Dec 29, 2010 at 5:09 PM, Nikolay Denev wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > On 27 Dec, 2010, at 21:20 , Barbara wrote: > >> >> As my old PATA hard disk was failing, I had to replace it with a new SATA >> drive where I moved my FreeBSDs installations, as PATA drives are not easy to >> find these days. >> So I had to move one of my data drive from a VIA8237A SATA controller to the >> last free SATA slot on a Marvell 88SX6121 to make room for the new hd. >> The hd I moved was working perfectly when connected to the VIA controller. >> Now, with the Marvell I'm getting messages like the following twos while >> using >> the disk: >> ahcich0: Timeout on slot 10 >> ahcich0: is cs 3800 ss 3c00 rs 3c00 tfd 50010040 serr >> >> >> ahcich0: Timeout on slot 5 >> ahcich0: is cs 0180 ss 01e0 rs 01e0 tfd 50040040 serr >> >> >> This doesn't happen regularly. For example downloading from a slow website on >> it, so few kb/s, is ok. >> But if I copy files from the disk attacked to the Marvell controller to >> another another disk, or for example run md5 on some files, it's very likely >> to >> happen. >> The process accessing the disk can not be killed even with -9, ^C does >> nothing, and umount doesn't exit. >> If I'm copying files on it from another disk it can't be unmounted too as the >> unkillable process has it in use. >> On shutdown many disk doesn't get unmounted, so there are a lot of fsck on >> boot, and on CURRENT (last built yesterday), FreeBSD enter debugger as it >> fail >> flushing disk caches. >> >> Relevant part from dmesg: >> >> atapci0: port 0xdc00-0xdc07,0xd880- >> 0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfbdffc00-0xfbdf >> irq >> 28 at device 0.0 on pci6 >> ahci0: on atapci0 >> ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported >> ahcich0: at channel 0 on ahci0 >> ahcich1: at channel 1 on ahci0 >> ata2: on atapci0 >> atapci1: port 0xbc00-0xbc07,0xb880-0xb883, >> 0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f,0xb000-0xb0ff irq 21 at device 15.0 >> on pci0 >> ata3: on atapci1 >> ata4: on atapci1 >> atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177, >> 0x376,0xfc00-0xfc0f at device 15.1 on pci0 >> ata0: on atapci2 >> ata1: on atapci2 >> >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-8 SATA 2.x device >> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada0: Command Queueing enabled >> ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) >> ada1 at ata3 bus 0 scbus3 target 0 lun 0 >> ada1: ATA-7 SATA 2.x device >> ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) >> ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) >> ada2 at ata4 bus 0 scbus4 target 0 lun 0 >> ada2: ATA-8 SATA 1.x device >> ada2: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) >> ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >> ada3 at ata0 bus 0 scbus5 target 0 lun 0 >> ada3: ATA-7 device >> ada3: 100.000MB/s transfers (UDMA5, PIO 8192bytes) >> ada3: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) >> >> ___ >> 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" > > Just to add a "me too". > > I'm running -STABLE but have the same problems with Marvell 88SX6121 giving > "ahci timeout" messages. > > Regards, > Nikolay > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.16 (Darwin) > > iEYEARECAAYFAk0bXUwACgkQHNAJ/fLbfrnWbQCdHQtnxDHkv0GXV5+gL3/qo46e > Q1YAn3eQkCbQ95WRiWG1+ELMEzKXRFT9 > =zG6+ > -END PGP SIGNATURE- > ___ > 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-cur
[ANNOUNCE] Playstation 3 support now in HEAD
Yesterday, I imported support for the Sony Playstation 3 into our 64-bit
PowerPC port, expanding our game console support into the current
generation. There are still a few rough edges due to missing hardware
support, but the machine boots and runs FreeBSD stably. These rough
edges should be smoothed out in time for the 9.0 release. Thanks to
Peter Grehan for donating the hardware that made this port possible.
-Nathan
Supported hardware:
- Sony Playstation 3 Fat, firmware version< 3.21
- Netbooting only
- 480i/480p only
Instructions:
The PS3 must be netbooted. First, acquire and install a copy of Petitboot
from http://ozlabs.org/~jk/projects/petitboot/
Next, set up a second machine with DHCP, NFS, and TFTP. Setup DHCP to netboot
loader.ps3 over TFTP, with the root path pointing to an NFS directory.
DHCP Setup:
host ps3 {
hardware ethernet XX:XX:XX:XX:XX:XX;
filename "/loader.ps3";
option host-name "ps3";
next-server 10.0.1.37;
option root-path "10.0.1.37:/usr/netboot-ps3";
}
NFS setup:
mkdir /usr/netboot-ps3
cd /usr/src
make buildworld installworld distribution TARGET=powerpc TARGET_ARCH=powerpc64
DESTDIR=/usr/netboot-ps3
Then share /usr/netboot-ps3 read/write over NFS with the PS3.
Connect a monitor set to 480i or 480p to the video output, and boot!
___
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 06/01/2011 kl. 20.56 skrev Tijl Coosemans: > On Thursday 06 January 2011 09:01:09 Erik Cederstrand wrote: >> Den 05/01/2011 kl. 20.36 skrev Jilles Tjoelker: >>> On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Spörlein wrote: - get IPA to work with clang, or at least file a bug - mark functions as __dead2 (please don't do that) >>> >>> Why not? >> >> Because the analyzer is supposed to find bugs. Only the function that >> really doesn't return should be marked as such. If we begin spewing >> __dead2's everywhere, it's bound to silence a valid bug somewhere >> down the line when e.g. a conditional in a print_help() function is >> changed subtly so it doesn't always reach exit(). > > On the other hand you can't really expect the compiler/analyser to know > what a procedure in another file does, so in that case you need __dead2 > anyway. [...] I have high expectations of LLVM :-) LLVM already has some knowledge of what's going on in other files (see LTO) so why shouldn't it be able to detect the __noreturn__ ? All the necessary information should be readily available. Erik
nfssvc not available or version mismatch (nfsv4 client)
Hi all, I am trying to run NFSv4 client on 64bit FreeBSD 9.0-Current. I have inserted into /etc/rc.conf following lines: nfsuserd_enable="YES" nfscbd_enable="YES" and after restart, during boot there is a meesage: Jan 6 23:50:56 vm-salwerom root: /etc/rc: WARNING: failed to start nfsuserd Jan 6 23:50:56 vm-salwerom kernel: KLD nfscommon.ko: depends on nfssvc - not available or version mismatch Jan 6 23:50:56 vm-salwerom kernel: linker_load_file: Unsupported file type Jan 6 23:50:59 vm-salwerom root: /etc/rc: WARNING: failed to start nfscbd Jan 6 23:50:59 vm-salwerom kernel: KLD nfscl.ko: depends on nfssvc - not available or version mismatch Jan 6 23:50:59 vm-salwerom kernel: linker_load_file: Unsupported file type the file nfssvc exists: vm-salwerom% ls /boot/kernel/nfss* /boot/kernel/nfsserver.ko /boot/kernel/nfssvc.ko Is there a problem with kernel modules or something else? -- Marek Salwerowicz ___ 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: xterm -C and TIOCCONS vs. PRIV_TTY_CONSOLE
On Thu, Jan 6, 2011 at 8:49 PM, Craig Leres wrote:
> On 01/06/11 20:05, Garrett Cooper wrote:
>> Just to make sure we're both on the same page:
>>
>> $ grep xterm /etc/ttys
>> ttyv0 "/usr/libexec/getty Pc" xterm on secure
>> ttyv1 "/usr/libexec/getty Pc" xterm on secure
>> ttyv2 "/usr/libexec/getty Pc" xterm on secure
>> ttyv3 "/usr/libexec/getty Pc" xterm on secure
>> ttyv4 "/usr/libexec/getty Pc" xterm on secure
>> ttyv5 "/usr/libexec/getty Pc" xterm on secure
>> ttyv6 "/usr/libexec/getty Pc" xterm on secure
>> ttyv7 "/usr/libexec/getty Pc" xterm on secure
>> ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure
>
> No, that's not what mine looks like. I changed it to match and rebooted
> but it doesn't help with the TIOCCONS issue.
>
> When I run xinit, it starts up the xterm -C which does a TIOCCONS. The
> 8.1 kernel checks for PRIV_TTY_CONSOLE which isn't set and denies the
> request:
>
> case TIOCCONS:
> /* Set terminal as console TTY. */
> if (*(int *)data) {
> error = priv_check(td, PRIV_TTY_CONSOLE);
> if (error)
> return (error);
>
> /*
> * XXX: constty should really need to be locked!
> * XXX: allow disconnected constty's to be stolen!
> */
>
> if (constty == tp)
> return (0);
> if (constty != NULL)
> return (EBUSY);
>
> tty_unlock(tp);
> constty_set(tp);
> tty_lock(tp);
> } else if (constty == tp) {
> constty_clear();
> }
> return (0);
>
>
> There's nothing I see in all of /usr/src that turns on PRIV_TTY_CONSOLE
> in any case. You could rewrite the above like this:
>
> case TIOCCONS:
> /* Set terminal as console TTY. */
> if (*(int *)data) {
> return (EPERM)
> } else if (constty == tp) {
> constty_clear();
> }
> return (0);
>
> and it won't change any behavior.
Ok -- figured I would ask about the obvious. I wish I could help
you further right now, but unfortunately I have a lot on my plate.
I've CCed ed@ and the list again so that someone else might be able to
chime in and help you further.
Cheers,
-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: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
On Thu, Jan 06, 2011 at 11:59:07PM +0100, Erik Cederstrand wrote: > > Den 06/01/2011 kl. 20.56 skrev Tijl Coosemans: > > > On Thursday 06 January 2011 09:01:09 Erik Cederstrand wrote: > >> Den 05/01/2011 kl. 20.36 skrev Jilles Tjoelker: > >>> On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Sp?rlein wrote: > - get IPA to work with clang, or at least file a bug > - mark functions as __dead2 (please don't do that) > >>> > >>> Why not? > >> > >> Because the analyzer is supposed to find bugs. Only the function that > >> really doesn't return should be marked as such. If we begin spewing > >> __dead2's everywhere, it's bound to silence a valid bug somewhere > >> down the line when e.g. a conditional in a print_help() function is > >> changed subtly so it doesn't always reach exit(). > > > > On the other hand you can't really expect the compiler/analyser to know > > what a procedure in another file does, so in that case you need __dead2 > > anyway. [...] > > I have high expectations of LLVM :-) LLVM already has some knowledge of > what's going on in other files (see LTO) so why shouldn't it be able to > detect the __noreturn__ ? All the necessary information should be readily > available. the static analyzer has nothing to do with LLVM. it's a clang component and uses only the info that clang knows. and clang (ie. the C frontend) does not perform any analysis of this kind, thus it does not know that stuff is dead. fwiw - my trivial (but working) patch brought down the number of reports by mere 5% so the bulk is probably somewhere else... ___ 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"
