Re: Why is /usr/obj/lib32 where it is?
On 2011-04-25 21:53, Doug Barton wrote: In my /usr/obj (on amd64) I have 2 directories; lib32, and the root of the fs where the sources are. It seems odd to me that lib32 is not under the same root as everything else, so I'm asking why. :) If you look under /usr/obj/lib32, you will see the same root of the fs where the sources are, and approximately the same directory structure. The lib32 dir is used for building the 32-bit compatibility libraries on amd64, and needs to be separate from the 'native' obj directory. ___ 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"
responsiveness during IO tasks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I've noticed lately that when doing heavy IO, my 9-CURRENT system (Fri Apr 15 23:33:46 EDT 2011) is quite unresponsive. I have two ZFS mirrors setup and run KDE4. The system has 12GB of RAM. When I, for example, copy an ISO image from one mirror to the other, the whole desktop becomes really slow during the copy. It takes a good 15 seconds to open a new tab in Konsole, switching windows takes a while, etc. Once the copy is finished, things are fine. It wasn't like this back before I upgraded from 8.2-RC1 to 9-CURRENT. Has anyone else noticed something similar, or is it just me? Is there any other info I can provide or something I should look for? Thanks, Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJNtiDLAAoJEPXPYrMgexuh2hgIAK4a33NtKUNP5bDy9nCumjNM Y+0WYxio72kDEUR0KPGJKB8TT3qV4DAknvydEvOTvXNQq2GZUX5WvJKu0cNwbg7g qQt7xawaQq9NkE4dGJLMgDRDrkGVzHEFFHKegmFl8l9WnUxC8ffAjEvtW63Lcefe xLzo9s3SbfmKS5p6dm/EXx49rSrtZv3uENnPBErXDY4Vd6LtNRBV2umk2GzU0Jgr HdOcZVv+MOSEbIMavJidRtYE5Ous0XYRBYFF+ZHhRVkLQ4yIj2OXmQiB0IjYh11O gX0NcHSBA8Pe6WbRRpcUbS0Evr4ur/n1VWgwZB/Bfbrtt0RnFbRDNCnBfOLAhuw= =ZgkD -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"
newnfs NFS client testing
Hi, I believe that the new/experimental NFS client in head is now compatible with the old/regular NFS client. If you run current and do NFS mounts, testing of the new NFS client would be appreciated. All you need to do is: - replace the fstype of "nfs" with "newnfs" in the appropriate lines in /etc/fstab If you are using a diskless NFS root fs, you need to change the line for "/" in etc/fstab on the root fs on the NFS server plus add a line like this to boot/loader.conf on the root fs on the server: vfs.root.mountfrom="newnfs:" Thanks in advance for any testing, rick ps: The plan is to switch "newnfs" --> "nfs" soon if problems aren't reported. ___ 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 termcape :ti@:te@:
On Tue, Apr 26, 2011 at 07:41:38AM +0900, Randy Bush wrote: > > I overlooked asking whether Randy had regen'd the termcap.db file > > which is presumably used for the updated termcap. > > i did I sort of assumed you did, but am still puzzled where the problem lies. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpDgSKhqJlJr.pgp Description: PGP signature
Re: xterm termcape :ti@:te@:
On Tue, Apr 26, 2011 at 01:10:58AM +0300, Kostik Belousov wrote: > On Mon, Apr 25, 2011 at 05:38:26PM -0400, Thomas Dickey wrote: > > On Mon, Apr 25, 2011 at 01:12:54PM +0200, Gary Jennejohn wrote: > > > Mine sets it to rxvt. > > > > > > I tried setting TERM to rxvt in xterm, but of course it didn't work. > > > > I overlooked asking whether Randy had regen'd the termcap.db file > > which is presumably used for the updated termcap. A truss/ktrace > > would show the particular file opened, but not the content. If > > we were talking about terminfo, I'd look for the output of infocmp > > to verify the change, but don't have a convenient way to verify > > that the termcap data seen by "less" is as expected. > > There is also $TERMCAP env var that adds a level of inconvenience > when debugging such issues. yes (I don't recall if FreeBSD's system configuration for ncurses uses this feature - but then again, truss/ktrace would tell that part of the story). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp1hznYVLC81.pgp Description: PGP signature
Re: xterm termcape :ti@:te@:
i gave up and am using xterm-clear, which is working for me. randy ___ 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 termcape :ti@:te@:
> I overlooked asking whether Randy had regen'd the termcap.db file > which is presumably used for the updated termcap. i did ___ 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 termcape :ti@:te@:
On Mon, Apr 25, 2011 at 05:38:26PM -0400, Thomas Dickey wrote: > On Mon, Apr 25, 2011 at 01:12:54PM +0200, Gary Jennejohn wrote: > > Mine sets it to rxvt. > > > > I tried setting TERM to rxvt in xterm, but of course it didn't work. > > I overlooked asking whether Randy had regen'd the termcap.db file > which is presumably used for the updated termcap. A truss/ktrace > would show the particular file opened, but not the content. If > we were talking about terminfo, I'd look for the output of infocmp > to verify the change, but don't have a convenient way to verify > that the termcap data seen by "less" is as expected. There is also $TERMCAP env var that adds a level of inconvenience when debugging such issues. pgpIk2nMWIoaO.pgp Description: PGP signature
Re: xterm termcape :ti@:te@:
On Mon, Apr 25, 2011 at 01:12:54PM +0200, Gary Jennejohn wrote: > Mine sets it to rxvt. > > I tried setting TERM to rxvt in xterm, but of course it didn't work. I overlooked asking whether Randy had regen'd the termcap.db file which is presumably used for the updated termcap. A truss/ktrace would show the particular file opened, but not the content. If we were talking about terminfo, I'd look for the output of infocmp to verify the change, but don't have a convenient way to verify that the termcap data seen by "less" is as expected. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp83J5KbLgzo.pgp Description: PGP signature
Re: Why is /usr/obj/lib32 where it is?
On 04/25/2011 13:07, Steve Kargl wrote: On Mon, Apr 25, 2011 at 12:53:44PM -0700, Doug Barton wrote: Howdy, In my /usr/obj (on amd64) I have 2 directories; lib32, and the root of the fs where the sources are. It seems odd to me that lib32 is not under the same root as everything else, so I'm asking why. :) troutmask:kargl[214] find /usr/obj/usr/src/lib32 -type f | wc -l 2412 It seems that a portion of lib32 is found were you appear to want it to be. I don't understand your answer. Let me add a few more details. My /usr/src is a symlink to /home/svn/head. For that matter, my /usr/obj is actually a symlink to /usr/local/obj. Meanwhile, I have the following in /usr/obj: ls /usr/obj/ home/ lib32/ hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: Why is /usr/obj/lib32 where it is?
On Mon, Apr 25, 2011 at 12:53:44PM -0700, Doug Barton wrote: > Howdy, > > In my /usr/obj (on amd64) I have 2 directories; lib32, and the root of > the fs where the sources are. It seems odd to me that lib32 is not under > the same root as everything else, so I'm asking why. :) > troutmask:kargl[214] find /usr/obj/usr/src/lib32 -type f | wc -l 2412 It seems that a portion of lib32 is found were you appear to want it to be. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Why is /usr/obj/lib32 where it is?
Howdy, In my /usr/obj (on amd64) I have 2 directories; lib32, and the root of the fs where the sources are. It seems odd to me that lib32 is not under the same root as everything else, so I'm asking why. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: sched_4bsd startup crash trying to run a bound thread on an AP that hasn't started
On Wednesday, April 20, 2011 6:02:42 pm Ryan Stone wrote:
> On Wed, Apr 6, 2011 at 2:29 PM, John Baldwin wrote:
> > I guess one other option would be something like this:
> >
> >if (smp_started && (td->td_pinned != 0 || td->td_flags &
> > TDF_BOUND ||
> >ts->ts_flags & TSF_AFFINITY)) {
> >if (td->td_pinned != 0)
> >cpu = td->td_lastcpu;
> >else if (td->td_flags & TDF_BOUND) {
> >/* Find CPU from bound runq. */
> >KASSERT(...);
> >cpu = ts->ts_runq - &runq_pcpu[0];
> >} else
> >/* Find a valid CPU for our cpuset. */
> >cpu = sched_pickcpu(td);
> >ts->ts_runq = &runq_pcpu[cpu];
> >single_cpu = 1;
> >CTR3(KTR_RUNQ, ...);
> >} else {
> >/* Global runq case. */
> >}
> >
> > This also avoids duplicating some common code to all the single_cpu cases.
> >
> > --
> > John Baldwin
> >
>
> I went with this option. Does this look right?
Yes, I would perhaps tweak the comment to reflect the full if statement
though. Maybe something like:
/*
* If SMP is started and the thread is pinned or otherwise limited to
* a specific set of CPUs, queue the thread to a per-CPU run queue.
* Otherwise, queue the thread to the global run queue.
*/
>
> Index: sys/kern/sched_4bsd.c
> ===
> --- sys/kern/sched_4bsd.c (revision 220603)
> +++ sys/kern/sched_4bsd.c (working copy)
> @@ -1246,30 +1246,28 @@
> }
> TD_SET_RUNQ(td);
>
> - if (td->td_pinned != 0) {
> - cpu = td->td_lastcpu;
> + /*
> +* If SMP is not started, don't obey any requested CPU pinning as that
> +* CPU has either not yet started or it is curcpu. Trying to run a
> +* thread on a CPU that has not yet started will panic the system.
> +*/
> + if (smp_started && (td->td_pinned != 0 || td->td_flags & TDF_BOUND ||
> + ts->ts_flags & TSF_AFFINITY)) {
> + if (td->td_pinned != 0)
> + cpu = td->td_lastcpu;
> + else if (td->td_flags & TDF_BOUND) {
> + /* Find CPU from bound runq. */
> + KASSERT(SKE_RUNQ_PCPU(ts),
> + ("sched_add: bound td_sched not on cpu runq"));
> + cpu = ts->ts_runq - &runq_pcpu[0];
> + } else
> + /* Find a valid CPU for our cpuset */
> + cpu = sched_pickcpu(td);
> ts->ts_runq = &runq_pcpu[cpu];
> single_cpu = 1;
> CTR3(KTR_RUNQ,
> "sched_add: Put td_sched:%p(td:%p) on cpu%d runq", ts, td,
> cpu);
> - } else if (td->td_flags & TDF_BOUND) {
> - /* Find CPU from bound runq. */
> - KASSERT(SKE_RUNQ_PCPU(ts),
> - ("sched_add: bound td_sched not on cpu runq"));
> - cpu = ts->ts_runq - &runq_pcpu[0];
> - single_cpu = 1;
> - CTR3(KTR_RUNQ,
> - "sched_add: Put td_sched:%p(td:%p) on cpu%d runq", ts, td,
> - cpu);
> - } else if (ts->ts_flags & TSF_AFFINITY) {
> - /* Find a valid CPU for our cpuset */
> - cpu = sched_pickcpu(td);
> - ts->ts_runq = &runq_pcpu[cpu];
> - single_cpu = 1;
> - CTR3(KTR_RUNQ,
> - "sched_add: Put td_sched:%p(td:%p) on cpu%d runq", ts, td,
> - cpu);
> } else {
> CTR2(KTR_RUNQ,
> "sched_add: adding td_sched:%p (td:%p) to gbl runq", ts,
>
--
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: `hw.acpi.thermal.tz0.temperature' disappeared
On Wednesday, April 20, 2011 2:22:39 am Romain Garbage wrote: > 2011/4/18 : > > I don't seem to have a hw.acpi.thermal sysctl node on my box. Can > > someone please try this patch? > > Works for me too. > > $> sysctl -a | grep temp > [...] > hw.acpi.thermal.tz0.temperature: 62.0C > dev.cpu.0.temperature: 55.0C > dev.cpu.1.temperature: 56.0C > [...] > > By the way, why the temperature from coretemp is different of the one > from acpi? Are they two different hardware? Yes, tz0 is probably some other sensor. -- 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: Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA]
Kostik Belousov wrote: > [Cc: list trimmed] > > On Mon, Apr 25, 2011 at 05:38:11PM +0300, Alexander Motin wrote: >> Kostik Belousov wrote: >>> On Mon, Apr 25, 2011 at 03:26:02PM +0300, Alexander Motin wrote: Andrey V. Elsukov wrote: > On 25.04.2011 14:23, Alexander Motin wrote: >> What will not work: >> - old device names won't be seen inside GEOM, so users who hardcoded >> provider names in gmirror/gstripe/... metadata (not the default >> behavior) are still in trouble. >> - patch mimics ATA_STATIC_ID behavior, if user had custom kernel >> without it, he should update device names manually. >> - it won't work for users with hot-unplugging ATA controllers (not >> devices), but I believe it is really rare case. >> - low-level tools, such as smartmontools, won't be able to work with >> alias devices, as background ada driver doesn't implements legacy >> ioctls. May be I could partially fix this. >> >> Except those, I think this patch should work for the most of users. >> >> Any more objections/ideas? Is this an acceptable solution? > what about new GEOM class? You can create new class instance after > disk_alloc(), attach it to the new disk and create provider with old-style > name. It seems this class will be very simple. It sounds like less dirty option. I'll try it. Thank you. Won't re-providing exactly the same device into GEOM create some problems? glabel and co will connect to each of them (original and legacy) and report two equal sets of labels. >> I have implemented it by adding one more specialized glabel submodule: >> http://people.freebsd.org/~mav/legacy_aliases_geom.patch >> >> But when I already done it, I understood where will be the problem: if >> somebody open any partition on the device with the new name, all legacy >> names will become inaccessible (busy), and vice versa. It could be not a >> big problem if it would only be user's choice -- we could say just: "use >> one or another, not both". But provider could be chosen blindly by some >> GEOM class, such as glabel, and then it turns into pure lottery. >> >> So while from the code side and for point of supporting hardcoded >> provider names it looks much better, it probably won't work so. > If ad4 is an alias for ada0, carry UFS on s1a, for instance, and both > ad4s1a and ada0s1a are mounted rw, user will get (probably unrepairable) > fs corruption. Not sure about double-import of ZFS pools. This is not a problem, GEOM will not allow double open in that case and that is actually where problem I mentioned grows. I was talking about the other case: if ada0s1a opened by glabel during root mounting using UFS ID, swapon for swap mentioned in fstab as /dev/ad4s1b will fail. >>> Can you limit the real functionality of this new class to the calls >>> to make_dev_alias(9) ? Ideally, I would think about some extension of >>> the core GEOM, which would take some parameter, lets call it alias >>> name, and will acompany the existing make_dev() calls with parallel >>> make_dev_alias(). >> Adding one more alias name field to the struct g_geom probably is not a >> problem. And the result probably would not have downsides of two >> previous approaches. And from the code side it would probably looked >> better then textual parsing in a first patch. But supporting alias in >> every place where names used in GEOM (that is required to make it >> usable) will probably require quite a massive set of changes though GEOM >> core and many classes. I am not sure I want to go there. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA]
[Cc: list trimmed] On Mon, Apr 25, 2011 at 05:38:11PM +0300, Alexander Motin wrote: > Kostik Belousov wrote: > > On Mon, Apr 25, 2011 at 03:26:02PM +0300, Alexander Motin wrote: > >> Andrey V. Elsukov wrote: > >>> On 25.04.2011 14:23, Alexander Motin wrote: > What will not work: > - old device names won't be seen inside GEOM, so users who hardcoded > provider names in gmirror/gstripe/... metadata (not the default > behavior) are still in trouble. > - patch mimics ATA_STATIC_ID behavior, if user had custom kernel > without it, he should update device names manually. > - it won't work for users with hot-unplugging ATA controllers (not > devices), but I believe it is really rare case. > - low-level tools, such as smartmontools, won't be able to work with > alias devices, as background ada driver doesn't implements legacy > ioctls. May be I could partially fix this. > > Except those, I think this patch should work for the most of users. > > Any more objections/ideas? Is this an acceptable solution? > >>> what about new GEOM class? You can create new class instance after > >>> disk_alloc(), attach it to the new disk and create provider with old-style > >>> name. It seems this class will be very simple. > >> It sounds like less dirty option. I'll try it. Thank you. Won't > >> re-providing exactly the same device into GEOM create some problems? > >> glabel and co will connect to each of them (original and legacy) and > >> report two equal sets of labels. > > I have implemented it by adding one more specialized glabel submodule: > http://people.freebsd.org/~mav/legacy_aliases_geom.patch > > But when I already done it, I understood where will be the problem: if > somebody open any partition on the device with the new name, all legacy > names will become inaccessible (busy), and vice versa. It could be not a > big problem if it would only be user's choice -- we could say just: "use > one or another, not both". But provider could be chosen blindly by some > GEOM class, such as glabel, and then it turns into pure lottery. > > So while from the code side and for point of supporting hardcoded > provider names it looks much better, it probably won't work so. If ad4 is an alias for ada0, carry UFS on s1a, for instance, and both ad4s1a and ada0s1a are mounted rw, user will get (probably unrepairable) fs corruption. Not sure about double-import of ZFS pools. > > > Can you limit the real functionality of this new class to the calls > > to make_dev_alias(9) ? Ideally, I would think about some extension of > > the core GEOM, which would take some parameter, lets call it alias > > name, and will acompany the existing make_dev() calls with parallel > > make_dev_alias(). > > Adding one more alias name field to the struct g_geom probably is not a > problem. And the result probably would not have downsides of two > previous approaches. And from the code side it would probably looked > better then textual parsing in a first patch. But supporting alias in > every place where names used in GEOM (that is required to make it > usable) will probably require quite a massive set of changes though GEOM > core and many classes. I am not sure I want to go there. > > -- > Alexander Motin pgpnNWD5KjVl7.pgp Description: PGP signature
Re: Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA]
Kostik Belousov wrote: > On Mon, Apr 25, 2011 at 03:26:02PM +0300, Alexander Motin wrote: >> Andrey V. Elsukov wrote: >>> On 25.04.2011 14:23, Alexander Motin wrote: What will not work: - old device names won't be seen inside GEOM, so users who hardcoded provider names in gmirror/gstripe/... metadata (not the default behavior) are still in trouble. - patch mimics ATA_STATIC_ID behavior, if user had custom kernel without it, he should update device names manually. - it won't work for users with hot-unplugging ATA controllers (not devices), but I believe it is really rare case. - low-level tools, such as smartmontools, won't be able to work with alias devices, as background ada driver doesn't implements legacy ioctls. May be I could partially fix this. Except those, I think this patch should work for the most of users. Any more objections/ideas? Is this an acceptable solution? >>> what about new GEOM class? You can create new class instance after >>> disk_alloc(), attach it to the new disk and create provider with old-style >>> name. It seems this class will be very simple. >> It sounds like less dirty option. I'll try it. Thank you. Won't >> re-providing exactly the same device into GEOM create some problems? >> glabel and co will connect to each of them (original and legacy) and >> report two equal sets of labels. I have implemented it by adding one more specialized glabel submodule: http://people.freebsd.org/~mav/legacy_aliases_geom.patch But when I already done it, I understood where will be the problem: if somebody open any partition on the device with the new name, all legacy names will become inaccessible (busy), and vice versa. It could be not a big problem if it would only be user's choice -- we could say just: "use one or another, not both". But provider could be chosen blindly by some GEOM class, such as glabel, and then it turns into pure lottery. So while from the code side and for point of supporting hardcoded provider names it looks much better, it probably won't work so. > Can you limit the real functionality of this new class to the calls > to make_dev_alias(9) ? Ideally, I would think about some extension of > the core GEOM, which would take some parameter, lets call it alias > name, and will acompany the existing make_dev() calls with parallel > make_dev_alias(). Adding one more alias name field to the struct g_geom probably is not a problem. And the result probably would not have downsides of two previous approaches. And from the code side it would probably looked better then textual parsing in a first patch. But supporting alias in every place where names used in GEOM (that is required to make it usable) will probably require quite a massive set of changes though GEOM core and many classes. I am not sure I want to go there. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA]
On Mon, Apr 25, 2011 at 03:26:02PM +0300, Alexander Motin wrote: > Andrey V. Elsukov wrote: > > On 25.04.2011 14:23, Alexander Motin wrote: > >> What will not work: > >> - old device names won't be seen inside GEOM, so users who hardcoded > >> provider names in gmirror/gstripe/... metadata (not the default > >> behavior) are still in trouble. > >> - patch mimics ATA_STATIC_ID behavior, if user had custom kernel > >> without it, he should update device names manually. > >> - it won't work for users with hot-unplugging ATA controllers (not > >> devices), but I believe it is really rare case. > >> - low-level tools, such as smartmontools, won't be able to work with > >> alias devices, as background ada driver doesn't implements legacy > >> ioctls. May be I could partially fix this. > >> > >> Except those, I think this patch should work for the most of users. > >> > >> Any more objections/ideas? Is this an acceptable solution? > > > > what about new GEOM class? You can create new class instance after > > disk_alloc(), attach it to the new disk and create provider with old-style > > name. It seems this class will be very simple. > > It sounds like less dirty option. I'll try it. Thank you. Won't > re-providing exactly the same device into GEOM create some problems? > glabel and co will connect to each of them (original and legacy) and > report two equal sets of labels. Can you limit the real functionality of this new class to the calls to make_dev_alias(9) ? Ideally, I would think about some extension of the core GEOM, which would take some parameter, lets call it alias name, and will acompany the existing make_dev() calls with parallel make_dev_alias(). pgpB5cgDvUM87.pgp Description: PGP signature
NX stacks on amd64 and powerpc
I added a support for non-executable stacks on amd64 and PowerPC architectures some time ago, but did not enabled it. Passed time allowed to fix some bugs in the implementation, and I consider it would be good to have NX stacks enabled for architectures that support it. I plan to commit the following knob twiddle in approximately a week. Some ports, if any, that erronously handle PT_GNU_STACK phdr may break. Anybody interested should and could test the change before the commit, by setting sysctl kern.elf64.nxstack and kern.elf32.nxstack to 1. diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index b41741a..7358e40 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -116,7 +115,12 @@ static int elf_legacy_coredump = 0; SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, &elf_legacy_coredump, 0, ""); -static int __elfN(nxstack) = 0; +static int __elfN(nxstack) = +#if defined(__amd64__) || defined(__powerpc__) /* both 64 and 32 bit */ + 1; +#else + 0; +#endif SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO, nxstack, CTLFLAG_RW, &__elfN(nxstack), 0, __XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) ": enable non-executable stack"); pgpCznmDaUoGZ.pgp Description: PGP signature
Re: geli on r221012
On Mon, 25 Apr 2011 13:31:55 + (UTC), Anton Yuzhaninov wrote: AY> Geli no longer works for me after upgrade to r221012. AY> r220286 works for me. -- WBR, Anton Yuzhaninov ___ 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"
geli on r221012
Geli no longer works for me after upgrade to r221012. # geli attach -k ~citrin/private.key /dev/label/spool2 Enter passphrase: # from dmesg: GEOM_ELI: Device label/spool2.eli created. GEOM_ELI: Encryption: Blowfish-CBC 128 GEOM_ELI: Integrity: HMAC/MD5 GEOM_ELI: Crypto: software # dd if=/dev/label/spool2.eli of=/dev/null dd: /dev/label/spool2.eli: Invalid argument 0+0 records in 0+0 records out 0 bytes transferred in 0.000669 secs (0 bytes/sec) # geli status Name Status Components label/spool2.eli ACTIVE label/spool # geli list Geom name: label/spool2.eli State: ACTIVE EncryptionAlgorithm: Blowfish-CBC KeyLength: 128 AuthenticationAlgorithm: HMAC/MD5 Crypto: software UsedKey: 0 Flags: AUTH KeysAllocated: 125 KeysTotal: 125 Providers: 1. Name: label/spool2.eli Mediasize: 59545088000 (55G) Sectorsize: 4096 Mode: r0w0e0 Consumers: 1. Name: label/spool2 Mediasize: 66988228096 (62G) Sectorsize: 512 Mode: r1w1e1 -- WBR, Anton Yuzhaninov ___ 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: "No such file or directory" in daily setuid checks
On 4/25/11 4:51 AM, J. Hellenthal wrote: > On Sun, Apr 24, 2011 at 07:24:03AM -0400, Glen Barber wrote: >> Hi, >> >> Files/directories do exist, however: >> >> kaos % ll /usr/backup/hourly.14/orion/usr/ >> total 4 >> drwxr-xr-x 5 root wheel 5 Apr 23 17:01 home >> drwxr-xr-x 4 root wheel 5 Apr 23 17:01 local >> > By chance do you have these properties set on the pool or datasets: > listsnaps (zpool property) > snapdir (zfs property) Nope, in fact the cause is much simpler than that. Shortly after periodic starts, rsnapshot begins, which moves the hourly.? directories out from under find(1), which became more obvious after my Monday morning coffee. Sorry for the noise. -- Glen Barber ___ 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"
Heads up: nfsclient .h dependencies changing
Hi, I will be making a commit to head/sys that will change the .h file dependencies for the experimental NFS client. You probably want to do a fresh: make cleandepend make depend when building a kernel after updating to r221014. rick ___ 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: Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA]
Marius Strobl wrote: > On Mon, Apr 25, 2011 at 01:23:37PM +0300, Alexander Motin wrote: >> I've implemented following patch to keep basic compatibility for the >> migrating users. I don't like such hacky things, but at least I tried to >> make it less invasive. >> >> The idea: >> - New xpt_path_legacy_ata_id() function in CAM tries to predict bus >> unit number and then device unit number for specified path, as if it was >> with legacy ATA with ATA_STATIC_ID option. >> - on attach, ada driver fetches that number (if not disabled using >> tunable kern.cam.ada.legacy_aliases), prints to console something like: >> ada0: Previously was known as ad12 >> , and sets kernel environment variable like: >> kern.devalias.ada0="ad12" >> - when geom_dev tastes new geom and creates device node for it, it also >> tries to match prefix of the device name with present kern.devalias.* >> enviromnent variables, and, if some match found, creates alias with >> substituted name (ada0 -> ad12, ada0s1 -> ad12s1, etc.). >> >> The patch is here: http://people.freebsd.org/~mav/legacy_aliases.patch >> >> I did few tests and it seems like working -- two sets of device nodes >> appeared for each device, I can successfully label and mount any of them. >> >> What will not work: >> - old device names won't be seen inside GEOM, so users who hardcoded >> provider names in gmirror/gstripe/... metadata (not the default >> behavior) are still in trouble. >> - patch mimics ATA_STATIC_ID behavior, if user had custom kernel >> without it, he should update device names manually. >> - it won't work for users with hot-unplugging ATA controllers (not >> devices), but I believe it is really rare case. >> - low-level tools, such as smartmontools, won't be able to work with >> alias devices, as background ada driver doesn't implements legacy >> ioctls. May be I could partially fix this. >> >> Except those, I think this patch should work for the most of users. >> >> Any more objections/ideas? Is this an acceptable solution? > > given that only the amd64, i386 and pc98 GENERIC kernel configuration > files had ATA_STATIC_ID enabled by default it would be highly desireable > that your compatibility shim also only mimics that behavior on these > archs or probably better actually check for ATA_STATIC_ID and put that > option back into the respective kernel configuration files. You are right. I have also thought about restoring that option, but haven't related it with architectures. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Switch from legacy ata(4) to CAM-based ATA
On Wed, 20 Apr 2011 12:57:47 +0300, Alexander Motin wrote: AM> If somebody has any problems with new ATA stack, please repeat your AM> tests with latest HEAD code and contact me if problem is still there. AM> Next three weeks before BSDCan I am going to dedicate to fixing possibly AM> remaining issues. On motherboard MSI MS-7210 no HDD detected with new GENERIC (r221012). In dmesg I see line like: device_attach: ahci0 attach returned 6 (I have no serial console cable and can't capture full dmesg). >From pciconf -vlbc (when I boot with old ata) atapci1@pci0:0:31:2:class=0x01018f card=0x72101462 chip=0x27c08086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0xe880, size 8, enabled bar [14] = type I/O Port, range 32, base 0xe800, size 4, enabled bar [18] = type I/O Port, range 32, base 0xe480, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xe400, size 4, enabled bar [20] = type I/O Port, range 32, base 0xe080, size 16, enabled cap 01[70] = powerspec 2 supports D0 D3 current D0 -- WBR, Anton Yuzhaninov ___ 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: Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA]
Andrey V. Elsukov wrote: > On 25.04.2011 14:23, Alexander Motin wrote: >> What will not work: >> - old device names won't be seen inside GEOM, so users who hardcoded >> provider names in gmirror/gstripe/... metadata (not the default >> behavior) are still in trouble. >> - patch mimics ATA_STATIC_ID behavior, if user had custom kernel >> without it, he should update device names manually. >> - it won't work for users with hot-unplugging ATA controllers (not >> devices), but I believe it is really rare case. >> - low-level tools, such as smartmontools, won't be able to work with >> alias devices, as background ada driver doesn't implements legacy >> ioctls. May be I could partially fix this. >> >> Except those, I think this patch should work for the most of users. >> >> Any more objections/ideas? Is this an acceptable solution? > > what about new GEOM class? You can create new class instance after > disk_alloc(), attach it to the new disk and create provider with old-style > name. It seems this class will be very simple. It sounds like less dirty option. I'll try it. Thank you. Won't re-providing exactly the same device into GEOM create some problems? glabel and co will connect to each of them (original and legacy) and report two equal sets of labels. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA]
On Mon, Apr 25, 2011 at 01:23:37PM +0300, Alexander Motin wrote: > Hi. > > I've implemented following patch to keep basic compatibility for the > migrating users. I don't like such hacky things, but at least I tried to > make it less invasive. > > The idea: > - New xpt_path_legacy_ata_id() function in CAM tries to predict bus > unit number and then device unit number for specified path, as if it was > with legacy ATA with ATA_STATIC_ID option. > - on attach, ada driver fetches that number (if not disabled using > tunable kern.cam.ada.legacy_aliases), prints to console something like: > ada0: Previously was known as ad12 > , and sets kernel environment variable like: > kern.devalias.ada0="ad12" > - when geom_dev tastes new geom and creates device node for it, it also > tries to match prefix of the device name with present kern.devalias.* > enviromnent variables, and, if some match found, creates alias with > substituted name (ada0 -> ad12, ada0s1 -> ad12s1, etc.). > > The patch is here: http://people.freebsd.org/~mav/legacy_aliases.patch > > I did few tests and it seems like working -- two sets of device nodes > appeared for each device, I can successfully label and mount any of them. > > What will not work: > - old device names won't be seen inside GEOM, so users who hardcoded > provider names in gmirror/gstripe/... metadata (not the default > behavior) are still in trouble. > - patch mimics ATA_STATIC_ID behavior, if user had custom kernel > without it, he should update device names manually. > - it won't work for users with hot-unplugging ATA controllers (not > devices), but I believe it is really rare case. > - low-level tools, such as smartmontools, won't be able to work with > alias devices, as background ada driver doesn't implements legacy > ioctls. May be I could partially fix this. > > Except those, I think this patch should work for the most of users. > > Any more objections/ideas? Is this an acceptable solution? > Hi, given that only the amd64, i386 and pc98 GENERIC kernel configuration files had ATA_STATIC_ID enabled by default it would be highly desireable that your compatibility shim also only mimics that behavior on these archs or probably better actually check for ATA_STATIC_ID and put that option back into the respective kernel configuration files. Marius ___ 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: Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA]
On 25.04.2011 14:23, Alexander Motin wrote: > What will not work: > - old device names won't be seen inside GEOM, so users who hardcoded > provider names in gmirror/gstripe/... metadata (not the default > behavior) are still in trouble. > - patch mimics ATA_STATIC_ID behavior, if user had custom kernel > without it, he should update device names manually. > - it won't work for users with hot-unplugging ATA controllers (not > devices), but I believe it is really rare case. > - low-level tools, such as smartmontools, won't be able to work with > alias devices, as background ada driver doesn't implements legacy > ioctls. May be I could partially fix this. > > Except those, I think this patch should work for the most of users. > > Any more objections/ideas? Is this an acceptable solution? Hi, what about new GEOM class? You can create new class instance after disk_alloc(), attach it to the new disk and create provider with old-style name. It seems this class will be very simple. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: xterm termcape :ti@:te@:
On Mon, 25 Apr 2011 07:00:39 -0400 Thomas Dickey wrote: > On Mon, Apr 25, 2011 at 09:52:24AM +0200, Gary Jennejohn wrote: > > On Sun, 24 Apr 2011 20:23:14 -0400 > > Thomas Dickey wrote: > > > > > On Mon, Apr 25, 2011 at 08:37:05AM +0900, Randy Bush wrote: > > > > no help from the following: > > > > > > > > *** termcap~Fri Mar 18 14:34:01 2011 > > > > --- termcap Sun Apr 24 23:33:52 2011 > > > > *** > > > > *** 3131,3136 > > > > --- 3131,3137 > > > > # > > > > # Customization begins here. > > > > xterm-xfree86|xterm terminal emulator (XFree86):\ > > > > + :te=\E[?1049l:ti=\E[?1049h:\ > > > > :tc=xterm-new: > > > > > > At this point, I'd check if less is using that entry > > > (ktrace or truss should be able to show the open's on the termcap > > > database, > > > for instance). > > > > > > Also, I seem to recall some discussion about less' -X (--no-init) > > > option. It's possible that someone's patched "less" for FreeBSD > > > to make that -X option more or less permanent. That would be > > > consistent with omitting ti/te from the termcap. > > > > > > > This may not be too helpful, but it works with rxvt and less, i.e. the > > old screen contents are preserved and appear again after leaving less. > > Well, that would address the issue with "less" (if it used the same > behavior in either terminal). rxvt should be setting $TERM to some > "rxvt" name though, since its function-keys differ from xterm's. > That's why I mentioned it, although I didn't compare the termcap entries for xterm and rxvt. > (I seem to recall that some packages for it used to set TERM to "xterm", > under the supposition that a poor match was better than none). > Mine sets it to rxvt. I tried setting TERM to rxvt in xterm, but of course it didn't work. -- 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: xterm termcape :ti@:te@:
On Mon, Apr 25, 2011 at 09:52:24AM +0200, Gary Jennejohn wrote: > On Sun, 24 Apr 2011 20:23:14 -0400 > Thomas Dickey wrote: > > > On Mon, Apr 25, 2011 at 08:37:05AM +0900, Randy Bush wrote: > > > no help from the following: > > > > > > *** termcap~Fri Mar 18 14:34:01 2011 > > > --- termcap Sun Apr 24 23:33:52 2011 > > > *** > > > *** 3131,3136 > > > --- 3131,3137 > > > # > > > # Customization begins here. > > > xterm-xfree86|xterm terminal emulator (XFree86):\ > > > + :te=\E[?1049l:ti=\E[?1049h:\ > > > :tc=xterm-new: > > > > At this point, I'd check if less is using that entry > > (ktrace or truss should be able to show the open's on the termcap database, > > for instance). > > > > Also, I seem to recall some discussion about less' -X (--no-init) > > option. It's possible that someone's patched "less" for FreeBSD > > to make that -X option more or less permanent. That would be > > consistent with omitting ti/te from the termcap. > > > > This may not be too helpful, but it works with rxvt and less, i.e. the > old screen contents are preserved and appear again after leaving less. Well, that would address the issue with "less" (if it used the same behavior in either terminal). rxvt should be setting $TERM to some "rxvt" name though, since its function-keys differ from xterm's. (I seem to recall that some packages for it used to set TERM to "xterm", under the supposition that a poor match was better than none). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpmNFK0VWg68.pgp Description: PGP signature
Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA]
Hi. I've implemented following patch to keep basic compatibility for the migrating users. I don't like such hacky things, but at least I tried to make it less invasive. The idea: - New xpt_path_legacy_ata_id() function in CAM tries to predict bus unit number and then device unit number for specified path, as if it was with legacy ATA with ATA_STATIC_ID option. - on attach, ada driver fetches that number (if not disabled using tunable kern.cam.ada.legacy_aliases), prints to console something like: ada0: Previously was known as ad12 , and sets kernel environment variable like: kern.devalias.ada0="ad12" - when geom_dev tastes new geom and creates device node for it, it also tries to match prefix of the device name with present kern.devalias.* enviromnent variables, and, if some match found, creates alias with substituted name (ada0 -> ad12, ada0s1 -> ad12s1, etc.). The patch is here: http://people.freebsd.org/~mav/legacy_aliases.patch I did few tests and it seems like working -- two sets of device nodes appeared for each device, I can successfully label and mount any of them. What will not work: - old device names won't be seen inside GEOM, so users who hardcoded provider names in gmirror/gstripe/... metadata (not the default behavior) are still in trouble. - patch mimics ATA_STATIC_ID behavior, if user had custom kernel without it, he should update device names manually. - it won't work for users with hot-unplugging ATA controllers (not devices), but I believe it is really rare case. - low-level tools, such as smartmontools, won't be able to work with alias devices, as background ada driver doesn't implements legacy ioctls. May be I could partially fix this. Except those, I think this patch should work for the most of users. Any more objections/ideas? Is this an acceptable solution? -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "No such file or directory" in daily setuid checks
On Sun, Apr 24, 2011 at 07:24:03AM -0400, Glen Barber wrote: >Hi, > >Files/directories do exist, however: > >kaos % ll /usr/backup/hourly.14/orion/usr/ >total 4 >drwxr-xr-x 5 root wheel 5 Apr 23 17:01 home >drwxr-xr-x 4 root wheel 5 Apr 23 17:01 local > Hi Glen, ;) By chance do you have these properties set on the pool or datasets: listsnaps (zpool property) snapdir (zfs property) A ( ls -A ) in the offending directory should verify this by showing a hidden snapdir that would normally not be shown. It might be wise to update the script to just not take those special directories into consideration unless some rc_var is turned on. Recommended naming convention for the var: ? daily_status_security_chksetuid_snapdir_recursive="NO" If so can you flip these off and test it again by running the same commands that are run in the 100.chksetuid script ? Actually I just looked over the script, "That syntax is just fuggin crazy" ( find /path/to/offending/directory ) should do it. -- Regards, J. Hellenthal WWJD pgpEXDJbbmQIW.pgp Description: PGP signature
Re: xterm termcape :ti@:te@:
On Sun, 24 Apr 2011 20:23:14 -0400 Thomas Dickey wrote: > On Mon, Apr 25, 2011 at 08:37:05AM +0900, Randy Bush wrote: > > no help from the following: > > > > *** termcap~Fri Mar 18 14:34:01 2011 > > --- termcap Sun Apr 24 23:33:52 2011 > > *** > > *** 3131,3136 > > --- 3131,3137 > > # > > # Customization begins here. > > xterm-xfree86|xterm terminal emulator (XFree86):\ > > + :te=\E[?1049l:ti=\E[?1049h:\ > > :tc=xterm-new: > > At this point, I'd check if less is using that entry > (ktrace or truss should be able to show the open's on the termcap database, > for instance). > > Also, I seem to recall some discussion about less' -X (--no-init) > option. It's possible that someone's patched "less" for FreeBSD > to make that -X option more or less permanent. That would be > consistent with omitting ti/te from the termcap. > This may not be too helpful, but it works with rxvt and less, i.e. the old screen contents are preserved and appear again after leaving less. -- 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"
