Re: Regarding pciids
On Mon, Oct 18, 2010 at 12:13 PM, Garrett Cooper wrote: > On Mon, Oct 18, 2010 at 11:36 AM, Alexander Best > wrote: > > On Mon Oct 18 10, Garrett Cooper wrote: > >> On Mon, Oct 18, 2010 at 8:28 AM, Alexander Best > wrote: > >> > On Mon Oct 18 10, Alexander Best wrote: > >> >> On Fri Sep 17 10, Alex Dupre wrote: > >> >> > I created hackish scripts to generate pci_vendors file from Boemler > and > >> >> > Mares (pciids.sf.net) lists. I haven't found the Hart list. > >> >> > > >> >> > The results of the scripts are here: > >> >> > >> >> sorry it seems i missed your post back then. > >> >> > >> >> i found two more lists: > >> >> > >> >> http://rh-software.com/downloads/pcidevs.txt > >> >> and > >> >> http://hobbes.nmsu.edu/h-browse.php?dir=/pub/incoming (seems to be > based on the > >> >> Hart list) > >> >> > >> >> the actual Hart list seems to have vanished and the web location is > no longer > >> >> accessible. > >> >> > >> >> personally i don't think it's necessary to combine the data of two > files. the > >> >> mares database seems extremely elaborate. all my pci devices get > described > >> >> properly. also making use of only one databse would make it more easy > to submit > >> >> additional info back to the vendor. > >> >> > >> >> so any objections to switching to the mares list? > >> >> > >> >> cheers. > >> >> alex > >> >> > >> >> > > >> >> > http://www.alexdupre.com/pci_vendors/mares.txt > >> >> > http://www.alexdupre.com/pci_vendors/boemler.txt > >> >> > http://www.alexdupre.com/pci_vendors/mares-boemler.txt > >> >> > http://www.alexdupre.com/pci_vendors/boemler-mares.txt > >> >> > > >> >> > The first two are generated from single lists, the last two are > >> >> > combined, with different preference order. > >> > > >> > oh...and i think it would be a good idea to move from ";" as comment > character > >> > to "#". that way we wouldn't need to run a script, but could include > the vendor > >> > file directly into the src tree. > >> > >> I noted this a while back to Warner and Brooke as I came up with a > >> short script to do this, and they suggested that it be supplemented to > >> the existing list, not replace it. > > > > why? the mares list is obviosly superior, because linux contributes to it > and > > thus has far more people submitting changes than any other list. > > > > is there a case where the old list has an entry the mares list is > missing? > >Most of the values (above 99%) were the same actually between the > 2 lists. I think the point was to avoid churn in the description > fields because a lot of the description fields were different, the > Linux list was produced by questionable sources (IIRC the other list > was produced by vendors, but I could be wrong). Rather than guessing I > would just ask Brookes and Warner directly though, offlist... > Cheers, > -Garrett > Questionable, you mean like Intel? :) I brought this up in the first place asking because our new ID's go direct into the sf list. I understand the desire to avoid churn, but I suspect this would be a change for the longer term good. Just my .02 Jack ___ 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: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps
cd /usr/ports/*/postgres90-server make clean export DTRACE_DEBUG=1 make install Check what dtrace is doing. BTW have you added postgres to the wheel group? 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: geom_sched usage
On Tue, Oct 19, 2010 at 08:07:54AM +0200, David Naylor wrote:
> On Monday 18 October 2010 21:51:25 Luigi Rizzo wrote:
...
> > > - is there anyway to automatically attach gsched to a device on startup
> > > (i.e.
> > >
> > > in rc.conf)?
> >
> > no, you have to build some script yourself.
>
> Would there be any interest in having a rc.d/ script? I would find it
> conveniant to specify a single rc.conf line and get scheduling for all my
> devices. PC-BSD might find such functionality useful.
>
> See attached for my first draft at such a script, I'm willing to hash it into
> shape.
it would surely be useful but try to keep it simple and user-driven
(this is a general comment on rc.d scripts).
Some things i think you should simplify in your script:
- remove support for guessing which devices should get the scheduler.
This is really a user decision and if the user names no devices then
i believe it is better/safer not to install any scheduler.
- use standard names such as gsched_flags or gsched_flags_${dev} to hold
generic and specific flags for the insert command.
It is neither useful nor flexible to have the script insert '-a'
in front of the algorithm;
cheers
luigi
___
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 sparc64/sparc64
TB --- 2010-10-19 01:55:54 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-19 01:55:54 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-10-19 01:55:54 - cleaning the object tree TB --- 2010-10-19 01:58:17 - cvsupping the source tree TB --- 2010-10-19 01:58:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-10-19 02:03:02 - building world TB --- 2010-10-19 02:03:02 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-19 02:03:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-19 02:03:02 - TARGET=sparc64 TB --- 2010-10-19 02:03:02 - TARGET_ARCH=sparc64 TB --- 2010-10-19 02:03:02 - TZ=UTC TB --- 2010-10-19 02:03:02 - __MAKE_CONF=/dev/null TB --- 2010-10-19 02:03:02 - cd /src TB --- 2010-10-19 02:03:02 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 19 02:03:04 UTC 2010 >>> 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 Tue Oct 19 06:51:31 UTC 2010 TB --- 2010-10-19 06:51:31 - generating LINT kernel config TB --- 2010-10-19 06:51:31 - cd /src/sys/sparc64/conf TB --- 2010-10-19 06:51:31 - /usr/bin/make -B LINT TB --- 2010-10-19 06:51:31 - building LINT kernel TB --- 2010-10-19 06:51:31 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-19 06:51:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-19 06:51:31 - TARGET=sparc64 TB --- 2010-10-19 06:51:31 - TARGET_ARCH=sparc64 TB --- 2010-10-19 06:51:31 - TZ=UTC TB --- 2010-10-19 06:51:31 - __MAKE_CONF=/dev/null TB --- 2010-10-19 06:51:31 - cd /src TB --- 2010-10-19 06:51:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Oct 19 06:51:32 UTC 2010 >>> 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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netsmb/smb_subr.c 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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netsmb/smb_trantcp.c 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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netsmb/smb_usr.c 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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/nfs/nfs_common.c 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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/nfs/nfs_lock.c cc1: warnings being treated as errors /src/sys/nfs/nf
Re: sysctl -a is slow
On 2010-09-20, David Xu wrote:
> I redirect all output to a disk file, and it still needs 1 second to
> complete, this machine is dual-core pentium E5500, faster than previous
> one which is a dual-core AMD 5000+ machine, the 5000+ needs 2
> seconds to complete.
>
> $/usr/bin/time sysctl -b kern.geom.confdot > sysctl_geom_confdot.txt
> 1.00 real 0.00 user 0.00 sys
I couldn't reproduce the problem myself but I bet that it's a lost
wakeup in g_waitfor_event(). Can you try this patch?
%%%
Index: sys/geom/geom_event.c
===
--- sys/geom/geom_event.c (revision 214048)
+++ sys/geom/geom_event.c (working copy)
@@ -220,11 +220,12 @@ one_event(void)
mtx_lock(&g_eventlock);
TAILQ_REMOVE(&g_events, ep, events);
ep->flag &= ~EV_INPROGRESS;
- mtx_unlock(&g_eventlock);
if (ep->flag & EV_WAKEUP) {
ep->flag |= EV_DONE;
wakeup(ep);
+ mtx_unlock(&g_eventlock);
} else {
+ mtx_unlock(&g_eventlock);
g_free(ep);
}
g_topology_unlock();
@@ -365,11 +366,14 @@ g_waitfor_event(g_event_t *func, void *a
va_end(ap);
if (error)
return (error);
- do
- tsleep(ep, PRIBIO, "g_waitfor_event", hz);
- while (!(ep->flag & EV_DONE));
+
+ mtx_lock(&g_eventlock);
+ while (!(ep->flag & EV_DONE))
+ msleep(ep, &g_eventlock, PRIBIO, "g_waitfor_event", hz);
if (ep->flag & EV_CANCELED)
error = EAGAIN;
+ mtx_unlock(&g_eventlock);
+
g_free(ep);
return (error);
}
%%%
--
Jaakko
___
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: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps
On 19 Oct 2010, at 10:15, István wrote: > wow, you go the point after couple of emails. better later than never, huh :) You sure are an amusing guy. Rude, but amusing :-) > > you think adding pgsql to wheel might help? cc freebsd-security@ and see > their opinion about the topic. dof needs to inject the probes in /dev/dtrace/helper, so the user needs rw access to the /dev/dtrace/helper. I specifically added write access to the wheel group for this. > > i modified the permission of /dev/dtrace/helper instead but it gives the > following error still: > > dtrace DOF postgres: DTrace ioctl failed for DOF at 0x801c35000: Invalid > argument This error usually means that there were no probes found in dof section of the binary. Somehow they were not inserted correctly during the build stage. > do you mean /usr/ports/databases/postgresql90-server? Yes. > > I was rebuilding it with that switch, what now? Send me the build log, gzipped. 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: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps
On Tue, 19 Oct 2010, Rui Paulo wrote: you think adding pgsql to wheel might help? cc freebsd-security@ and see their opinion about the topic. dof needs to inject the probes in /dev/dtrace/helper, so the user needs rw access to the /dev/dtrace/helper. I specifically added write access to the wheel group for this. In the medium term, part of the solution here will be to finish adding a role-based privilege system. I had this on my todo list for 8.0 but didn't manage to get it finished. With any luck, it will make 9.0 in plenty of time. this would allow specific kernel privileges to be delegated to specific users and groups (among other things). Many of the kernel changes to support this have been done since 7.0 when I added priv(9), but we've not yet selected a specific policy and API to bind to them. Some appliances are already using priv(9) via extensible MAC modules to delegate privilege, but for a role-based privilege system, I think a tighter integration is preferable (especially in light of the risks from composing incorrectly with the root user model). In some sense, however, a privilege system is also exactly the wrong answer. Ideally, you should be able to run dtrace on any process that you have debugging rights on, which is calculated with respect to the credentials of the two processes involved (subject and object). You might also reasonably key certain kernel probes, such as systrace probes, to the same authorization scheme. The remainder of kernel tracing presumably should remain a privilege, as should the use of kernel probes. In general, I would prefer it if the kernel didn't know any more about specific users and groups than it already does -- in practice, this is somewhat unavoidable due to the way we do devfs, but minimizing it would be a good idea. In the past, where we have had special things we need to delegate that bypass some but not all system integrity protections (such as shutdown, reboot, and backup), we've assigned them via the operator group, FYI. Robert ___ 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 powerpc64/powerpc
TB --- 2010-10-19 01:15:02 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-19 01:15:02 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-10-19 01:15:02 - cleaning the object tree TB --- 2010-10-19 01:17:08 - cvsupping the source tree TB --- 2010-10-19 01:17:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-10-19 01:21:43 - building world TB --- 2010-10-19 01:21:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-19 01:21:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-19 01:21:43 - TARGET=powerpc TB --- 2010-10-19 01:21:43 - TARGET_ARCH=powerpc64 TB --- 2010-10-19 01:21:43 - TZ=UTC TB --- 2010-10-19 01:21:43 - __MAKE_CONF=/dev/null TB --- 2010-10-19 01:21:43 - cd /src TB --- 2010-10-19 01:21:43 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 19 01:21:45 UTC 2010 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Oct 19 09:16:13 UTC 2010 TB --- 2010-10-19 09:16:13 - generating LINT kernel config TB --- 2010-10-19 09:16:13 - cd /src/sys/powerpc/conf TB --- 2010-10-19 09:16:13 - /usr/bin/make -B LINT TB --- 2010-10-19 09:16:13 - building LINT kernel TB --- 2010-10-19 09:16:13 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-19 09:16:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-19 09:16:13 - TARGET=powerpc TB --- 2010-10-19 09:16:13 - TARGET_ARCH=powerpc64 TB --- 2010-10-19 09:16:13 - TZ=UTC TB --- 2010-10-19 09:16:13 - __MAKE_CONF=/dev/null TB --- 2010-10-19 09:16:13 - cd /src TB --- 2010-10-19 09:16:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Oct 19 09:16:13 UTC 2010 >>> 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/netsmb/smb_subr.c 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/netsmb/smb_trantcp.c 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/netsmb/smb_usr.c 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/nfs/nfs_common.c 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 -
[head tinderbox] failure on sparc64/sun4v
TB --- 2010-10-19 04:03:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-19 04:03:09 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-10-19 04:03:09 - cleaning the object tree TB --- 2010-10-19 04:04:56 - cvsupping the source tree TB --- 2010-10-19 04:04:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-10-19 04:09:53 - building world TB --- 2010-10-19 04:09:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-19 04:09:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-19 04:09:53 - TARGET=sun4v TB --- 2010-10-19 04:09:53 - TARGET_ARCH=sparc64 TB --- 2010-10-19 04:09:53 - TZ=UTC TB --- 2010-10-19 04:09:53 - __MAKE_CONF=/dev/null TB --- 2010-10-19 04:09:53 - cd /src TB --- 2010-10-19 04:09:53 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 19 04:09:55 UTC 2010 >>> 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 Tue Oct 19 09:35:04 UTC 2010 TB --- 2010-10-19 09:35:04 - generating LINT kernel config TB --- 2010-10-19 09:35:04 - cd /src/sys/sun4v/conf TB --- 2010-10-19 09:35:04 - /usr/bin/make -B LINT TB --- 2010-10-19 09:35:04 - building LINT kernel TB --- 2010-10-19 09:35:04 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-19 09:35:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-19 09:35:04 - TARGET=sun4v TB --- 2010-10-19 09:35:04 - TARGET_ARCH=sparc64 TB --- 2010-10-19 09:35:04 - TZ=UTC TB --- 2010-10-19 09:35:04 - __MAKE_CONF=/dev/null TB --- 2010-10-19 09:35:04 - cd /src TB --- 2010-10-19 09:35:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Oct 19 09:35:05 UTC 2010 >>> 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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netsmb/smb_subr.c 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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netsmb/smb_trantcp.c 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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netsmb/smb_usr.c 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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/nfs/nfs_common.c 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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/nfs/nfs_lock.c cc1: warnings being treated as errors /src/sys/nfs/nfs_lock.c:
Re: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps
wow, you go the point after couple of emails. better later than never, huh :) you think adding pgsql to wheel might help? cc freebsd-security@ and see their opinion about the topic. i modified the permission of /dev/dtrace/helper instead but it gives the following error still: dtrace DOF postgres: DTrace ioctl failed for DOF at 0x801c35000: Invalid argument do you mean /usr/ports/databases/postgresql90-server? I was rebuilding it with that switch, what now? I. On Tue, Oct 19, 2010 at 8:18 AM, Rui Paulo wrote: > cd /usr/ports/*/postgres90-server > make clean > export DTRACE_DEBUG=1 > make install > > Check what dtrace is doing. > > BTW have you added postgres to the wheel group? > > Regards, > -- > Rui Paulo > > > -- the sun shines for all http://blog.l1x.me ___ 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: DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps
On Tue, Oct 19, 2010 at 10:33 AM, Rui Paulo wrote: > > On 19 Oct 2010, at 10:15, István wrote: > > > wow, you go the point after couple of emails. better later than never, > huh :) > > You sure are an amusing guy. Rude, but amusing :-) > > thanks! > > > > you think adding pgsql to wheel might help? cc freebsd-security@ and see > their opinion about the topic. > > dof needs to inject the probes in /dev/dtrace/helper, so the user needs rw > access to the /dev/dtrace/helper. I specifically added write access to the > wheel group for this. > > and you think the only way to do that is to add pgsql to wheel group?!? http://images.memegenerator.net/Troll-Face/ImageMacro/2337177/LOL-U-MAD-BRO.jpg > > > > i modified the permission of /dev/dtrace/helper instead but it gives the > following error still: > > > > dtrace DOF postgres: DTrace ioctl failed for DOF at 0x801c35000: Invalid > argument > > This error usually means that there were no probes found in dof section of > the binary. Somehow they were not inserted correctly during the build stage. > you see, we are slowly getting there :) > > > do you mean /usr/ports/databases/postgresql90-server? > > Yes. > > > > > I was rebuilding it with that switch, what now? > > Send me the build log, gzipped. > yes sir yes! (and you are talking about ppl being rude) what file do you need and which directory ___excatly___ btw. it would be beneficial for you as the DTrace maintainer of FreeBSD to have your own environment and prove me that I am wrong since you are happily tracing on your own box, it is just the lame user who is not able to do that :) your own words: "Tracing and instrumenting userland programs is very important because it allows the understanding of what's going on, especially on highly complex systems such as databases, web servers, and language interpreters. Since DTrace on FreeBSD now has the ability to instrument both the kernel and the userland program, you can get very meaningful data on how your program is behaving and why." So instead of fixing my problem on my box, fix it for everybody and update the wiki with the process if you have a chance. As of now, I consider FreeBSD as a non-supported platform for DTrace since I spent almost 2 days to get it working without success and it is definitely less effort to spin up a (Open)Solaris instance to debug performance issue. Let me know if you get it working in the future. thank you in advance. -- the sun shines for all http://blog.l1x.me ___ 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: CPU report in first line of "vmstat 1" is meaningless
On Monday, October 18, 2010 3:30:11 pm Ed Maste wrote: > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > cp_time value essentially won't roll over (at 1 billion increments per > > second it will roll over in 500 years; we currently increment 133 times per > > second, I think). If the value can be calculated accurately, it should be > > printed. > > Well, it won't roll over, but it's still different from all following > lines (in that it effectively shows user/system/idle CPU usage since > boot on the first line, and a snapshot over the last interval from then > on). I think it's still better to avoid printing it in that case. All of the first line is that way though. To do this "right" you'd need to blank out the entire first line. vm_stat and iostat on OS X have the current FreeBSD behavior (instant first line that summarizes all activity since uptime), so I'd be inclined to just leave the existing behavior. -- 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: mfiutil reports "PSTATE 0x0020" new drive state
On Monday, October 18, 2010 12:55:18 pm Sergey Kandaurov wrote: > On 16 October 2010 02:18, Sergey Kandaurov wrote: > > On 16 October 2010 00:51, Charles Owens wrote: > >> Hmm... the problem appears to have resolved itself. After a few hours the > >> new drive seems to have gone back into the array, and the original hot > >> spare > >> drive put back into hot-spare state. > >> > >> So I'm interpreting state 0x0020 to therefore mean something like "hang on > >> while I use this new drive to automatically put everything back as it was > >> before the failure". Is this correct? > >> > >> Thanks, > >> Charles > >> > >> [r...@bsvr ~]# mfiutil show drives > >> mfi0 Physical Drives: > >> ( 149G) ONLINE SATA enclosure 1, slot 0 > >> ( 149G) ONLINE SATA enclosure 1, slot 1 > >> ( 149G) ONLINE SATA enclosure 1, slot 2 > >> ( 149G) HOT SPARE SATA enclosure 1, > >> slot > >> 3 > >> ( 149G) ONLINE SATA enclosure 1, slot 4 > >> > >> > > >>> > [...] > >>> [r...@svr ~]# mfiutil show drives > >>> mfi0 Physical Drives: > >>> ( 149G) ONLINE SATA enclosure 1, slot > >>> 0 > >>> ( 149G) ONLINE SATA enclosure 1, slot > >>> 1 > >>> ( 149G) ONLINE SATA enclosure 1, slot > >>> 2 > >>> ( 149G) ONLINE SATA enclosure 1, slot > >>> 3 > >>> ( 149G) PSTATE 0x0020 SATA enclosure > >>> 1, slot 4 > >>> > >>> mfi0: port 0x1000-0x10ff mem > >>> ... > >>> > > > > Hi, Charles Owens. > > > > 0x20 is much likely to be the copyback physical state, > > which is missing in enum mfi_pd_state. > > And what you've experienced is copyback feature in action :) > > Your array has been rebuilt with HSP as its ordinal PD, then you > > switched failed drive > > with good one, and HSP came into copyback mode to move all its data back > > to good disk. That prevents reordering of disk numbers in array and > > double rebuilding. > > > > So, it no one objects, I'd like to commit this change. If you have access to the MFI docs (or a reference in the Linux driver, e.g.) then this is fine. The existing pd_state enum lists the values for PD state that were listed in the MFI docs I had access to at the time I wrote mfiutil. -- 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: uma_zfree(NULL) is broken
On Monday, October 18, 2010 4:59:17 pm m...@freebsd.org wrote: > There's explicit protection for free(NULL, M_FOO), but uma_zfree(zone, > NULL) will put NULL in the local bucket and then probably return it > later from a uma_zalloc call. Obviously it's not a good idea to call > uma_zfree(9) on NULL, but in this case it's an easy mistake to make > when e.g. converting a set of malloc(9)/free(9) uses into uma(9). > > So is the "right" thing to allow a uma_zfree(NULL) and silently > succeed, like for free(9)? That would be my guess, but I'm open to > alternatives. Given that free(3) and free(9) both handle NULL, I think it makes sense for uma_zfree() to do so as well. -- 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: geom_sched usage
David Naylor wrote: On Monday 18 October 2010 21:51:25 Luigi Rizzo wrote: [...] - is there anyway to automatically attach gsched to a device on startup (i.e. in rc.conf)? no, you have to build some script yourself. Would there be any interest in having a rc.d/ script? I would find it conveniant to specify a single rc.conf line and get scheduling for all my devices. PC-BSD might find such functionality useful. See attached for my first draft at such a script, I'm willing to hash it into shape. [...] You can use `sysctl kern.disks` to find available disk devices in your rc script. 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"
Re: mfiutil reports "PSTATE 0x0020" new drive state
On 19 October 2010 16:49, John Baldwin wrote: > On Monday, October 18, 2010 12:55:18 pm Sergey Kandaurov wrote: >> On 16 October 2010 02:18, Sergey Kandaurov wrote: >> > On 16 October 2010 00:51, Charles Owens >> > wrote: >> >> Hmm... the problem appears to have resolved itself. After a few hours >> >> the >> >> new drive seems to have gone back into the array, and the original hot >> >> spare >> >> drive put back into hot-spare state. >> >> >> >> So I'm interpreting state 0x0020 to therefore mean something like "hang on >> >> while I use this new drive to automatically put everything back as it was >> >> before the failure". Is this correct? >> >> >> >> Thanks, >> >> Charles >> >> >> >> [r...@bsvr ~]# mfiutil show drives >> >> mfi0 Physical Drives: >> >> ( 149G) ONLINE SATA enclosure 1, slot >> >> 0 >> >> ( 149G) ONLINE SATA enclosure 1, slot >> >> 1 >> >> ( 149G) ONLINE SATA enclosure 1, slot >> >> 2 >> >> ( 149G) HOT SPARE SATA enclosure 1, >> >> slot >> >> 3 >> >> ( 149G) ONLINE SATA enclosure 1, slot >> >> 4 >> >> >> >> >> >> >>> >> [...] >> >>> [r...@svr ~]# mfiutil show drives >> >>> mfi0 Physical Drives: >> >>> ( 149G) ONLINE SATA enclosure 1, slot >> >>> 0 >> >>> ( 149G) ONLINE SATA enclosure 1, slot >> >>> 1 >> >>> ( 149G) ONLINE SATA enclosure 1, slot >> >>> 2 >> >>> ( 149G) ONLINE SATA enclosure 1, slot >> >>> 3 >> >>> ( 149G) PSTATE 0x0020 SATA enclosure >> >>> 1, slot 4 >> >>> >> >>> mfi0: port 0x1000-0x10ff mem >> >>> ... >> >>> >> > >> > Hi, Charles Owens. >> > >> > 0x20 is much likely to be the copyback physical state, >> > which is missing in enum mfi_pd_state. >> > And what you've experienced is copyback feature in action :) >> > Your array has been rebuilt with HSP as its ordinal PD, then you >> > switched failed drive >> > with good one, and HSP came into copyback mode to move all its data back >> > to good disk. That prevents reordering of disk numbers in array and >> > double rebuilding. >> > >> >> So, it no one objects, I'd like to commit this change. > > If you have access to the MFI docs (or a reference in the Linux driver, e.g.) > then this is fine. The existing pd_state enum lists the values for PD state > that were listed in the MFI docs I had access to at the time I wrote mfiutil. > Hi, John. I've no such access unfortunately. As for FreeBSD vendor's driver, it doesn't list PD states at all (and looks like their version lags behind other OS versions). However, they (LSI) are listing COPYBACK entry as 0x20 in its Linux driver, and there: http://lkml.org/lkml/2009/5/5/389 -- wbr, pluknet ___ 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 reports "PSTATE 0x0020" new drive state
On Tuesday, October 19, 2010 10:05:24 am Sergey Kandaurov wrote: > On 19 October 2010 16:49, John Baldwin wrote: > > On Monday, October 18, 2010 12:55:18 pm Sergey Kandaurov wrote: > >> On 16 October 2010 02:18, Sergey Kandaurov wrote: > >> > On 16 October 2010 00:51, Charles Owens > >> > wrote: > >> >> Hmm... the problem appears to have resolved itself. After a few hours > >> >> the > >> >> new drive seems to have gone back into the array, and the original hot > >> >> spare > >> >> drive put back into hot-spare state. > >> >> > >> >> So I'm interpreting state 0x0020 to therefore mean something like "hang > >> >> on > >> >> while I use this new drive to automatically put everything back as it > >> >> was > >> >> before the failure". Is this correct? > >> >> > >> >> Thanks, > >> >> Charles > >> >> > >> >> [r...@bsvr ~]# mfiutil show drives > >> >> mfi0 Physical Drives: > >> >> ( 149G) ONLINE SATA enclosure 1, > >> >> slot 0 > >> >> ( 149G) ONLINE SATA enclosure 1, > >> >> slot 1 > >> >> ( 149G) ONLINE SATA enclosure 1, > >> >> slot 2 > >> >> ( 149G) HOT SPARE SATA enclosure 1, > >> >> slot > >> >> 3 > >> >> ( 149G) ONLINE SATA enclosure 1, > >> >> slot 4 > >> >> > >> >> > >> > >> >>> > >> [...] > >> >>> [r...@svr ~]# mfiutil show drives > >> >>> mfi0 Physical Drives: > >> >>> ( 149G) ONLINE SATA enclosure 1, > >> >>> slot > >> >>> 0 > >> >>> ( 149G) ONLINE SATA enclosure 1, > >> >>> slot > >> >>> 1 > >> >>> ( 149G) ONLINE SATA enclosure 1, > >> >>> slot > >> >>> 2 > >> >>> ( 149G) ONLINE SATA enclosure 1, > >> >>> slot > >> >>> 3 > >> >>> ( 149G) PSTATE 0x0020 SATA > >> >>> enclosure > >> >>> 1, slot 4 > >> >>> > >> >>> mfi0: port 0x1000-0x10ff mem > >> >>> ... > >> >>> > >> > > >> > Hi, Charles Owens. > >> > > >> > 0x20 is much likely to be the copyback physical state, > >> > which is missing in enum mfi_pd_state. > >> > And what you've experienced is copyback feature in action :) > >> > Your array has been rebuilt with HSP as its ordinal PD, then you > >> > switched failed drive > >> > with good one, and HSP came into copyback mode to move all its data back > >> > to good disk. That prevents reordering of disk numbers in array and > >> > double rebuilding. > >> > > >> > >> So, it no one objects, I'd like to commit this change. > > > > If you have access to the MFI docs (or a reference in the Linux driver, > > e.g.) > > then this is fine. The existing pd_state enum lists the values for PD state > > that were listed in the MFI docs I had access to at the time I wrote > > mfiutil. > > > > Hi, John. > > I've no such access unfortunately. > As for FreeBSD vendor's driver, it doesn't list PD states at all > (and looks like their version lags behind other OS versions). > > However, they (LSI) are listing COPYBACK entry as 0x20 in its Linux driver, > and there: http://lkml.org/lkml/2009/5/5/389 Ok. You should add the SYSTEM state too (0x40) while you are at 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: wpa_supplicant and ssid
On Tue, 2010-10-19 at 00:55 +0800, Buganini wrote: > It seems that wpa_supplicant iterate through all scanned ssids and try to > associate with each, > and that cause two problem for me. > > 1) in my school, there are many AP, and connection is not stable, when > disconnect, > it take many time to try and fail to associate with those ssids until the > one I want. This appears to be the same as the bug reported in PR bin/98220. wpa_supplicant is contributed code, so I think the correct answer is to report this upstream. As far as I could tell when I last checked, this hasn't yet been fixed upstream. Gavin -- Gavin Atkinson FreeBSD committer and bugmeister GPG: A093262B (313A A79F 697D 3A5C 216A EDF5 935D EF44 A093 262B) ___ 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 reports "PSTATE 0x0020" new drive state
On Oct 18, 2010, at 11:25 AM, Garrett Cooper wrote: > On Mon, Oct 18, 2010 at 9:55 AM, Sergey Kandaurov wrote: >> On 16 October 2010 02:18, Sergey Kandaurov wrote: >>> > >Check with LSI before you commit that; you might not understand > the overall nuances of that value. In all fairness, we're talking about an information reporting attribute, not an action attribute. And yes, most of us in this discussion have been writing device drivers and working with vendors for years. Scott ___ 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: [zfs] Mounting from (...) failed with error 19
On 19.10.2010 09:03, Andrey V. Elsukov wrote:
>> Mounting from (...) failed with error 19
>>
>> On boot. The system is using pure ZFS setup. It seems that 19 means
>> ENODEV but according to the dmesg the device do exist.
>
> Yes, i have the same problem.
I fixed it with attached patch.
--
WBR, Andrey V. Elsukov
Index: vfs_mountroot.c
===
--- vfs_mountroot.c (revision 214058)
+++ vfs_mountroot.c (working copy)
@@ -713,7 +713,8 @@
goto out;
}
- if (dev[0] != '\0' && !parse_mount_dev_present(dev)) {
+ if (strcmp(fs, "zfs") && dev[0] != '\0' &&
+ !parse_mount_dev_present(dev)) {
printf("mountroot: waiting for device %s ...\n", dev);
delay = hz / 10;
timeout = root_mount_timeout * hz;
signature.asc
Description: OpenPGP digital signature
Re: CPU report in first line of "vmstat 1" is meaningless
On Tue, Oct 19, 2010 at 08:54:38AM -0400, John Baldwin wrote: > On Monday, October 18, 2010 3:30:11 pm Ed Maste wrote: > > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > > > > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > > cp_time value essentially won't roll over (at 1 billion increments per > > > second it will roll over in 500 years; we currently increment 133 times > > > per > > > second, I think). If the value can be calculated accurately, it should be > > > printed. > > > > Well, it won't roll over, but it's still different from all following > > lines (in that it effectively shows user/system/idle CPU usage since > > boot on the first line, and a snapshot over the last interval from then > > on). I think it's still better to avoid printing it in that case. > > All of the first line is that way though. To do this "right" you'd need to > blank out the entire first line. > > vm_stat and iostat on OS X have the current FreeBSD behavior (instant first > line that summarizes all activity since uptime), so I'd be inclined to just > leave the existing behavior. I'd be very happy if all vmstat and iostat would get a command line switch to suppress the "summary since last reboot" line. This information may be useful for some cases but in other cases, like creating performance data for monitoring systems like Icinga / Nagios one has to remove the first line(s) manually. pgpC5OK9NKDHe.pgp Description: PGP signature
Re: [zfs] Mounting from (...) failed with error 19
On Oct 18, 2010, at 10:03 PM, Andrey V. Elsukov wrote: > On 19.10.2010 3:50, Xin LI wrote: >> With latest kernel I got: >> >> Mounting from (...) failed with error 19 >> >> On boot. The system is using pure ZFS setup. It seems that 19 means >> ENODEV but according to the dmesg the device do exist. > > Yes, i have the same problem. Can you both boot verbose and send me the output. Also, please boot with -a and show me the console output, as well as the output of the '?' command. Thanks, -- Marcel Moolenaar xcl...@mac.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: [zfs] Mounting from (...) failed with error 19
On 19.10.2010 19:43, Marcel Moolenaar wrote: >> Yes, i have the same problem. > > Can you both boot verbose and send me the output. > Also, please boot with -a and show me the console > output, as well as the output of the '?' command. It is ZFS-only system and I have this line in /boot/loader.conf: vfs.root.mountfrom="zfs:zroot" With "boot -a -v -s" I got the same result that with "boot -s -v" but when I enter zfs:zroot in mountroot prompt it printed: Trying to mount root from zfs:zroot []... mountroot: waiting for device zroot ... Mounting from zfs:zroot failed with error 19. Trying to mount root from zfs:zroot []... mountroot: waiting for device zroot ... Mounting from zfs:zroot failed with error 19. panic: mountroot: unable to (re-)mount root. So, it seems that waiting for device when we are booting from zfs is not necessary.. -- WBR, Andrey V. Elsukov 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 #8 r214013: Wed Oct 20 00:06:20 MSD 2010 root@:/usr/obj/usr/src/sys/BTR i386 Table 'FACP' at 0x7f7a0200 Table 'APIC' at 0x7f7a0390 Table 'MCFG' at 0x7f7a03f0 Table 'OEMB' at 0x7f7ae040 Table 'HPET' at 0x7f7a5900 Table 'SSDT' at 0x7f7aeb80 ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel/kernel" at 0x83d7c000. Preloaded elf module "/boot/kernel/zfs.ko" at 0x83d7c198. Preloaded elf module "/boot/kernel/opensolaris.ko" at 0x83d7c240. Preloaded elf module "/boot/kernel/linux.ko" at 0x83d7c2f0. Preloaded elf module "/boot/kernel/snd_hda.ko" at 0x83d7c39c. Preloaded elf module "/boot/kernel/sound.ko" at 0x83d7c448. Preloaded elf module "/boot/kernel/coretemp.ko" at 0x83d7c4f4. Preloaded elf module "/boot/kernel/acpi_video.ko" at 0x83d7c5a4. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0x83d7c654. Preloaded elf module "/boot/kernel/drm.ko" at 0x83d7c6ac. Preloaded elf module "/boot/kernel/i915.ko" at 0x83d7c754. Preloaded elf module "/boot/kernel/acpi_asus.ko" at 0x83d7c800. Preloaded elf module "/boot/modules/video4bsd.ko" at 0x83d7c8b0. Preloaded elf module "/boot/kernel/usb.ko" at 0x83d7c960. Preloaded elf module "/boot/kernel/usb_quirk.ko" at 0x83d7ca08. Preloaded elf module "/boot/kernel/ehci.ko" at 0x83d7cab8. Preloaded elf module "/boot/kernel/umass.ko" at 0x83d7cb64. Calibrating TSC clock ... TSC clock: 1596041208 Hz CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.04-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 Features=0xbfe9fbff Features2=0x40c39d AMD Features=0x10 AMD Features2=0x1 TSC: P-state invariant 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 512 kbytes, 16-way associative, 64 bytes/line real memory = 2147483648 (2048 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x01026000 - 0x7d36, 2083823616 bytes (508746 pages) avail memory = 2079625216 (1983 MB) Table 'FACP' at 0x7f7a0200 Table 'APIC' at 0x7f7a0390 APIC: Found table at 0x7f7a0390 MP Configuration Table version 1.4 found at 0x830f1160 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 bios32: Found BIOS32 Service Directory header at 0x830f bios32: Entry = 0xf0010 (830f0010) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0x31 pnpbios: Found PnP BIOS data at 0x830f88b0 pnpbios: Entry = f:996a Rev = 1.0 Other BIOS signatures found: ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xfb9e0 00014 (v00 ACPIAM) ACPI: RSDT 0x7f7a 0003C (v01 A_M_I_ OEMRSDT 03000903 MSFT 0097) ACPI: FACP 0x7f7a0200 00084 (v02 A_M_I_ OEMFACP 03000903 MSFT 0097) ACPI: DSDT 0x7f7a05b0 05342 (v01 A1028 A1028000 INTL 20051117) ACPI: FACS 0x7f7ae000 00040 ACPI: APIC 0x7f7a0390 0005C (v01 A_M_I_ OEMAPIC 03000903 MSFT 0097) ACPI: MCFG 0x7f7a03f0 0003C (v01 A_M_I_ OEMMCFG 03000903 MSFT 0097) ACPI: OEMB 0x7f7ae040 00061 (v01 A_M_I_ AMI_OEM 03000903 MSFT 0097) ACPI: HPET 0x7f7a5900 00038 (v01 A_M_I_ OEMHPET 03000903 MSFT 0097) ACPI: SSDT 0x7f7aeb80 004F0 (v01 PmRefCpuPm 3000 INTL 20051117) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin
Re: [zfs] Mounting from (...) failed with error 19
On Oct 19, 2010, at 7:55 AM, Andrey V. Elsukov wrote: > On 19.10.2010 09:03, Andrey V. Elsukov wrote: >>> Mounting from (...) failed with error 19 >>> >>> On boot. The system is using pure ZFS setup. It seems that 19 means >>> ENODEV but according to the dmesg the device do exist. >> >> Yes, i have the same problem. > > I fixed it with attached patch. Makes sense. "tank" (or its namesake) isn't a real device. Feel free to commit to unbreak things, but we may want to rethink this from a generality point of view. Listing exceptions doesn't scale and we now have 2 (the first was the empty device name as used by nfs, and now also zfs). Good catch, BTW. -- Marcel Moolenaar xcl...@mac.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: CPU report in first line of "vmstat 1" is meaningless
On Tuesday, October 19, 2010 10:40:56 am Lars Engels wrote: > On Tue, Oct 19, 2010 at 08:54:38AM -0400, John Baldwin wrote: > > On Monday, October 18, 2010 3:30:11 pm Ed Maste wrote: > > > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > > > > > > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > > > cp_time value essentially won't roll over (at 1 billion increments per > > > > second it will roll over in 500 years; we currently increment 133 times > > > > per > > > > second, I think). If the value can be calculated accurately, it should > > > > be > > > > printed. > > > > > > Well, it won't roll over, but it's still different from all following > > > lines (in that it effectively shows user/system/idle CPU usage since > > > boot on the first line, and a snapshot over the last interval from then > > > on). I think it's still better to avoid printing it in that case. > > > > All of the first line is that way though. To do this "right" you'd need to > > blank out the entire first line. > > > > vm_stat and iostat on OS X have the current FreeBSD behavior (instant first > > line that summarizes all activity since uptime), so I'd be inclined to just > > leave the existing behavior. > > I'd be very happy if all vmstat and iostat would get a command line > switch to suppress the "summary since last reboot" line. > This information may be useful for some cases but in other cases, like > creating performance data for monitoring systems like Icinga / Nagios > one has to remove the first line(s) manually. I would be fine with that, but I wouldn't alter the format of that line by default. -- 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: [zfs] Mounting from (...) failed with error 19
On my sparc64 system with today kernel I also got this problem. With old kernel system boots properly. boot -sv log attached. -- MATPOCKuH boot-sv.log Description: Binary data ___ 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: panic in uma_startup for many-core amd64 system
On Tue, Oct 19, 2010 at 8:55 AM, Andriy Gapon wrote: > >> Having dynamic slab sizes would allow to have the keg backed on a larger slab >> without going OFFPAGE. > > I agree in principle. > But without seeing code that implements that I can't guess if it would really > be > more efficient or more maintainable, i.e. more useful in general. > Still a very good idea. > I'm going to work on that. Unfortunately I think that could take a long time to me. I hope someone will have some insight to share. -- Giovanni Trematerra ___ 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: [zfs] Mounting from (...) failed with error 19
On 19.10.2010 03:50, Xin LI wrote: Escaping to boot loader prompt, and load old kernel, old opensolaris.ko, old zfs.ko doesn't work. I think you forgot to load zpool.cache: load -t /boot/zfs/zpool.cache /boot/zfs/zpool.cache ___ 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"
ath9k
Recently there were changes made to the ath driver on CURRENT does FreeBSD still need these changes? http://marc.info/?l=linux-wireless&m=128746728412954&w=2 I did notice they went in OpenBSD's Tree today -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.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: [zfs] Mounting from (...) failed with error 19
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/19/10 08:49, Marcel Moolenaar wrote:
>
> On Oct 19, 2010, at 7:55 AM, Andrey V. Elsukov wrote:
>
>> On 19.10.2010 09:03, Andrey V. Elsukov wrote:
Mounting from (...) failed with error 19
On boot. The system is using pure ZFS setup. It seems that 19 means
ENODEV but according to the dmesg the device do exist.
>>>
>>> Yes, i have the same problem.
>>
>> I fixed it with attached patch.
>
> Makes sense. "tank" (or its namesake) isn't a real device.
> Feel free to commit to unbreak things, but we may want to
> rethink this from a generality point of view. Listing
> exceptions doesn't scale and we now have 2 (the first was
> the empty device name as used by nfs, and now also zfs).
>
> Good catch, BTW.
Yes good catch, it fixed the problem for me as well.
What about the attached patch? I'm going to give it a swirl soon. The
difference is that it tests whether dev begins with /dev/.
Note that I'm not quite convinced with this yet as we may want to wait
for the devices from a zpool be ready, which may also need some yielding
during boot. A better way of solving this might be to register a
"watchlist" of devices (so that ZFS can register its vdev devices for
example) and have mountroot wait for that list? Or perhaps a set of
EVENTHANDLER callback?
Cheers,
- --
Xin LI http://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
iQEcBAEBCAAGBQJMvgvkAAoJEATO+BI/yjfBX/gIAIRnS4eQVBe/Zh6RrT8BjI91
J1r7wNz1AYXda2t4/RUVnPZYr97GG1quEewtgcxTxW2nkii1ZkftjMg6Ik4Gio6Y
AxNdjEB35tXqhVUV1oS8JS09ejZij2Y43SHxWxOkhUnFEmuhjK4+euM/+obpJ4Kl
AR61E/DYqwv/8bqhofknylroDsveN3Vhd1n7dK4s+e3YcmANnZxTCWcxroD7C2yb
gCH6TDZPDVKVbfyS73QFoyic2Jml5eK/dkmlLMRubP5qs5aIgy0P1zcjhvRrrgOf
bYLM3IUEbVhPSQnO8d2sDhXytgCI/s6p39rMdKPR3jrf2+UnW6IM46NvVkSaOP8=
=cAxC
-END PGP SIGNATURE-
Index: sys/kern/vfs_mountroot.c
===
--- sys/kern/vfs_mountroot.c(revision 214082)
+++ sys/kern/vfs_mountroot.c(working copy)
@@ -713,8 +713,7 @@ parse_mount(char **conf)
goto out;
}
- if (strcmp(fs, "zfs") != 0 && dev[0] != '\0' &&
- !parse_mount_dev_present(dev)) {
+ if ((strstr(dev, "/dev/") == dev) && !parse_mount_dev_present(dev)) {
printf("mountroot: waiting for device %s ...\n", dev);
delay = hz / 10;
timeout = root_mount_timeout * hz;
___
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: [zfs] Mounting from (...) failed with error 19
On Oct 19, 2010, at 2:21 PM, Xin LI wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 10/19/10 08:49, Marcel Moolenaar wrote: >> >> On Oct 19, 2010, at 7:55 AM, Andrey V. Elsukov wrote: >> >>> On 19.10.2010 09:03, Andrey V. Elsukov wrote: > Mounting from (...) failed with error 19 > > On boot. The system is using pure ZFS setup. It seems that 19 means > ENODEV but according to the dmesg the device do exist. Yes, i have the same problem. >>> >>> I fixed it with attached patch. >> >> Makes sense. "tank" (or its namesake) isn't a real device. >> Feel free to commit to unbreak things, but we may want to >> rethink this from a generality point of view. Listing >> exceptions doesn't scale and we now have 2 (the first was >> the empty device name as used by nfs, and now also zfs). >> >> Good catch, BTW. > > Yes good catch, it fixed the problem for me as well. > > What about the attached patch? I'm going to give it a swirl soon. The > difference is that it tests whether dev begins with /dev/. Interesting. I've been thinking about this too, but isn't exactly fool-proof. When devfs is the root file system, you can use "ufs:da0s1a" to refer to the device special file. It seems inconsistent to have "ufs:da0s1" fail when ufs:/dev/da0s1" works (a real scenario with USB based mass storage devices -- root mount is unheld as soon as umass is created, but before daX exists for it). This patch at least covers the problem cases with a single strstr(), and we may get away with the inconsistency given above by documenting it properly. Andrey: any thoughts? -- Marcel Moolenaar xcl...@mac.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"
Sleep/Lenovo SL410 fails again after csup & clang
My experience with a sleeping freebsd laptop has been shortlived! Today I rebuilt world using clang & this morning's csup current. Clang build went just swimmingly. Unthinkingly, I closed my laptop lid and put it in my case. When I got to my house, it was roasting with fans spinning and sleep light flashing. No damage, thankfully. Low and behold, hw.pci.do_power_resume=0 no longer lets my laptop sleep! I had recently fiddled with powerd, but problem persisted after reverting to previous configuration of associated sysctls etc. Interestingly, sleep bounce now fails with a hard freeze, which it never has in the past. Verbose output shows the wifi then re0 network interfaces going from D0->D3 as last living output. Please note problem persists regardless of user, X running, sleep_delay sysctl, do_power_resume, do_power_nodriver, powerd running/not running. Without sleep bounce, problem is characterized by flashing sleep light and spinning fans (CPU temperature is high). No devices added or removed, was sleeping this morning before buildworld. Is it worth rebuilding with gcc? Or a content change and not a compiler issue? Any major pci changes lately maybe? Matt sendtom...@gmail.com Not sure where to go from here... If it is helpful, I can provide any required logs, verbose dmesg etc. ___ 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: sysctl -a is slow
Jaakko Heinonen wrote:
On 2010-09-20, David Xu wrote:
I redirect all output to a disk file, and it still needs 1 second to
complete, this machine is dual-core pentium E5500, faster than previous
one which is a dual-core AMD 5000+ machine, the 5000+ needs 2
seconds to complete.
$/usr/bin/time sysctl -b kern.geom.confdot > sysctl_geom_confdot.txt
1.00 real 0.00 user 0.00 sys
I couldn't reproduce the problem myself but I bet that it's a lost
wakeup in g_waitfor_event(). Can you try this patch?
%%%
Index: sys/geom/geom_event.c
===
--- sys/geom/geom_event.c (revision 214048)
+++ sys/geom/geom_event.c (working copy)
@@ -220,11 +220,12 @@ one_event(void)
mtx_lock(&g_eventlock);
TAILQ_REMOVE(&g_events, ep, events);
ep->flag &= ~EV_INPROGRESS;
- mtx_unlock(&g_eventlock);
if (ep->flag & EV_WAKEUP) {
ep->flag |= EV_DONE;
wakeup(ep);
+ mtx_unlock(&g_eventlock);
} else {
+ mtx_unlock(&g_eventlock);
g_free(ep);
}
g_topology_unlock();
@@ -365,11 +366,14 @@ g_waitfor_event(g_event_t *func, void *a
va_end(ap);
if (error)
return (error);
- do
- tsleep(ep, PRIBIO, "g_waitfor_event", hz);
- while (!(ep->flag & EV_DONE));
+
+ mtx_lock(&g_eventlock);
+ while (!(ep->flag & EV_DONE))
+ msleep(ep, &g_eventlock, PRIBIO, "g_waitfor_event", hz);
if (ep->flag & EV_CANCELED)
error = EAGAIN;
+ mtx_unlock(&g_eventlock);
+
g_free(ep);
return (error);
}
%%%
Yes, the patch seems fixed the problem, I can not reproduce it.
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"
Re: [zfs] Mounting from (...) failed with error 19
On 20.10.2010 2:33, Marcel Moolenaar wrote: >> What about the attached patch? I'm going to give it a swirl soon. The >> difference is that it tests whether dev begins with /dev/. > > Interesting. I've been thinking about this too, but isn't > exactly fool-proof. When devfs is the root file system, > you can use "ufs:da0s1a" to refer to the device special > file. It seems inconsistent to have "ufs:da0s1" fail when > ufs:/dev/da0s1" works (a real scenario with USB based mass > storage devices -- root mount is unheld as soon as umass > is created, but before daX exists for it). > > This patch at least covers the problem cases with a single > strstr(), and we may get away with the inconsistency given > above by documenting it properly. > > Andrey: any thoughts? Currently usage information in parse_dir_ask() says that device should be specified with "/dev/". But conf0 does not use "/dev/". Also, Marcel, do you have any plans write some documentation with examples about using of new features? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CPU report in first line of "vmstat 1" is meaningless
:> :> > On a related note I'm not sure if it makes sense to have the same :> > behaviour for the first line when an interval is set as when it is :> > invoked with no interval. : :...also vmstat seems to exist in a few other OSes (linux e.g). maybe they've :fixed it already (or the netbsd/openbsd/dragonflybsd folks or apple?). : :cheers. :alex No, we haven't. I think it is meaningless too, and I can't imagine any script that would try to snarf that line. Another problem is that vmstat output in general is blowing out its column formatting. We have made some changes in DFly... sub-second intervals can be specified, and I think we enforce at least one space between fields so the output doesn't become totally unreadable. But the blowouts still remain. -Matt ___ 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: [zfs] Mounting from (...) failed with error 19
Hello!
> I fixed it with attached patch.
Omg... Why You are using strcmp, but not strncmp(fs, "zfs", strlen("zfs"))?
--
MATPOCKuH
___
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"
