Re: problem after installkernel going from 9.0 to CURRENT

2013-01-03 Thread Kevin Oberman
On Thu, Jan 3, 2013 at 7:24 PM, Warren Block  wrote:
> On Thu, 3 Jan 2013, Kevin Oberman wrote:
>
>>> One possibility: I believe I labeled each of the partitions
>>> during
>>> the gpt creation process.  Can I use those labels to (hopefully) by-pass
>>> this issue?
>>
>>
>> Yes! This is the current recommended way of doing it.
>>>
>>> cat /etc/fstab
>>
>> # DeviceMountpoint  FStype  Options Dump
>> Pass#
>> /dev/gpt/swap   noneswapsw  0   0
>> /dev/gpt/root   /   ufs rw  1   1
>> /dev/gpt/tmp/tmpufs rw  2   2
>> /dev/gpt/usr/usrufs rw  2   2
>> /dev/gpt/var/varufs rw  2   2
>
>
> To avoid collisions, I recommend people use unique labels on each system.  I
> sometimes pick a couple of letters from the system name or drive: xfswap,
> xfrootfs, xftmpfs, xfusrfs, xfvarfs.

Good point (as usual).

The example was from my laptop where this is not an issue, but in
larger environments it is an excellent suggestion.

I would put the unique ID at the end of the label as the eye tends to
read from left to right (at least in most language so you can
recognize whether it is usr or swap or home pretty much instantly.
Sticking letters at the start make the most fundamental information
harder to see.
swaprxf xfswap
usrfsxf  xfusrfs

Still, this is a nit and I appreciate the suggestion!..
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


SOLVED: problem after installkernel going from 9.0 to CURRENT

2013-01-03 Thread Robert Huff

   Using the GPT labels is a winning solution.

   Thanks to all those who helped,


 Robert Huff


___
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 ia64/ia64

2013-01-03 Thread FreeBSD Tinderbox
TB --- 2013-01-04 02:04:44 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-01-04 02:04:44 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-01-04 02:04:44 - starting HEAD tinderbox run for ia64/ia64
TB --- 2013-01-04 02:04:44 - cleaning the object tree
TB --- 2013-01-04 02:04:44 - /usr/local/bin/svn stat /src
TB --- 2013-01-04 02:04:48 - At svn revision 245019
TB --- 2013-01-04 02:04:49 - building world
TB --- 2013-01-04 02:04:49 - CROSS_BUILD_TESTING=YES
TB --- 2013-01-04 02:04:49 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-01-04 02:04:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-01-04 02:04:49 - SRCCONF=/dev/null
TB --- 2013-01-04 02:04:49 - TARGET=ia64
TB --- 2013-01-04 02:04:49 - TARGET_ARCH=ia64
TB --- 2013-01-04 02:04:49 - TZ=UTC
TB --- 2013-01-04 02:04:49 - __MAKE_CONF=/dev/null
TB --- 2013-01-04 02:04:49 - cd /src
TB --- 2013-01-04 02:04:49 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jan  4 02:04:54 UTC 2013
>>> 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 Fri Jan  4 03:40:35 UTC 2013
TB --- 2013-01-04 03:40:35 - generating LINT kernel config
TB --- 2013-01-04 03:40:35 - cd /src/sys/ia64/conf
TB --- 2013-01-04 03:40:35 - /usr/bin/make -B LINT
TB --- 2013-01-04 03:40:35 - cd /src/sys/ia64/conf
TB --- 2013-01-04 03:40:35 - /usr/sbin/config -m LINT
TB --- 2013-01-04 03:40:35 - building LINT kernel
TB --- 2013-01-04 03:40:35 - CROSS_BUILD_TESTING=YES
TB --- 2013-01-04 03:40:35 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-01-04 03:40:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-01-04 03:40:35 - SRCCONF=/dev/null
TB --- 2013-01-04 03:40:35 - TARGET=ia64
TB --- 2013-01-04 03:40:35 - TARGET_ARCH=ia64
TB --- 2013-01-04 03:40:35 - TZ=UTC
TB --- 2013-01-04 03:40:35 - __MAKE_CONF=/dev/null
TB --- 2013-01-04 03:40:35 - cd /src
TB --- 2013-01-04 03:40:35 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Fri Jan  4 03:40:35 UTC 2013
>>> 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
>>> Kernel build for LINT completed on Fri Jan  4 04:15:09 UTC 2013
TB --- 2013-01-04 04:15:09 - cd /src/sys/ia64/conf
TB --- 2013-01-04 04:15:09 - /usr/sbin/config -m GENERIC
TB --- 2013-01-04 04:15:09 - building GENERIC kernel
TB --- 2013-01-04 04:15:09 - CROSS_BUILD_TESTING=YES
TB --- 2013-01-04 04:15:09 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-01-04 04:15:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-01-04 04:15:09 - SRCCONF=/dev/null
TB --- 2013-01-04 04:15:09 - TARGET=ia64
TB --- 2013-01-04 04:15:09 - TARGET_ARCH=ia64
TB --- 2013-01-04 04:15:09 - TZ=UTC
TB --- 2013-01-04 04:15:09 - __MAKE_CONF=/dev/null
TB --- 2013-01-04 04:15:09 - cd /src
TB --- 2013-01-04 04:15:09 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Fri Jan  4 04:15:09 UTC 2013
>>> 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
[...]
/src/sys/dev/firewire/if_fwip.c:499: undefined reference to 
`crom_add_simple_text'
/src/sys/dev/firewire/if_fwip.c:500: undefined reference to `crom_add_entry'
/src/sys/dev/firewire/if_fwip.c:501: undefined reference to 
`crom_add_simple_text'
if_fwip.o: In function `fwip_stream_input':
/src/sys/dev/firewire/if_fwip.c:840: undefined reference to 
`fw_noderesolve_nodeid'
if_fwip.o: In function `fwip_unicast_input':
/src/sys/dev/firewire/if_fwip.c:939: undefined reference to 
`fw_noderesolve_nodeid'
if_fwip.o:(.data.rel+0x80): undefined reference to 
`sysctl__hw_firewire_children'
*** [kernel.debug] Error code 1

Stop in /obj/ia64.ia64/src/sys/GENERIC.
*** [buildkernel] Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2013-01-04 04:23:26 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-01-04 04:23:26 - ERROR: failed to build GENERIC kernel
TB --- 2013-01-04 04:23:26 - 6534.29 user 1389.55 system 8321.70 real


http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: problem after installkernel going from 9.0 to CURRENT

2013-01-03 Thread Warren Block

On Thu, 3 Jan 2013, Kevin Oberman wrote:


One possibility: I believe I labeled each of the partitions during
the gpt creation process.  Can I use those labels to (hopefully) by-pass
this issue?


Yes! This is the current recommended way of doing it.

cat /etc/fstab

# DeviceMountpoint  FStype  Options DumpPass#
/dev/gpt/swap   noneswapsw  0   0
/dev/gpt/root   /   ufs rw  1   1
/dev/gpt/tmp/tmpufs rw  2   2
/dev/gpt/usr/usrufs rw  2   2
/dev/gpt/var/varufs rw  2   2


To avoid collisions, I recommend people use unique labels on each 
system.  I sometimes pick a couple of letters from the system name or 
drive: xfswap, xfrootfs, xftmpfs, xfusrfs, xfvarfs.

___
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: problem after installkernel going from 9.0 to CURRENT

2013-01-03 Thread Kevin Oberman
On Thu, Jan 3, 2013 at 3:23 PM, Robert Huff  wrote:
> On 1/3/2013 11:40 AM, Warren Block wrote:
>>
>> On Wed, 2 Jan 2013, Robert Huff wrote:
>>
>>> (While this may not be a strictly CURRENT issue, I asked on
>>> questions@, but have not found a solution.)
>>>
>>> Situation:
>>> One of my boxes failed, and for various reasons it became easier
>>> to just scrub and rebuild it. Like its predecessor it will run CURRENT
>>> 1) Using BSDinstall, I flushed then created the first disk:
>>>
>>> ada2p1freebsd-boot128k
>>> ada2p2freebsd-swap4g
>>> ada2p3freebsd-ufs25g
>>>
>>> 5) On rebooting, the loader(??) claims to not be able to find a
>>> bootable partition - i.e. I get a screen that ends in "mountroot > ".
>>> Providing the presumptive value by hand returns "error 19".
>>
>>
>> It really does not sound like a GPT problem, because 9.0 booted.
>
>
> I don't (at the moment) think it's GPT caused; but I do think it may
> be GPT related.
>
>
>
>>   The
>> -current kernel can't find/detect the device.  Scrolling back in the
>> console buffer might find a problem.  buildworld/kernel/installworld do
>> not affect the disk partitioning, but can change the code that looks for
>> those partitions.
>
>
> Exactly.  I'm looking for help figuring out how the hand-off from
> loader to kernel got broken and what I have to do to fix it.
> One possibility: I believe I labeled each of the partitions during
> the gpt creation process.  Can I use those labels to (hopefully) by-pass
> this issue?

Yes! This is the current recommended way of doing it.
> cat /etc/fstab
# DeviceMountpoint  FStype  Options DumpPass#
/dev/gpt/swap   noneswapsw  0   0
/dev/gpt/root   /   ufs rw  1   1
/dev/gpt/tmp/tmpufs rw  2   2
/dev/gpt/usr/usrufs rw  2   2
/dev/gpt/var/varufs rw  2   2
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: problem after installkernel going from 9.0 to CURRENT

2013-01-03 Thread Kevin Oberman
On Wed, Jan 2, 2013 at 12:03 PM, Robert Huff  wrote:
> On 1/2/2013 1:57 PM, Benjamin Kaduk wrote:
>>
>> On Wed, 2 Jan 2013, Robert Huff wrote:
>
>
>> For a full clean install, I believe that bsdinstall should prompt about
>> installing bootcode around here.  I don't really understand from your
>> procedure how bsdinstall was used; there might be some edge case where
>> there is no prompt about bootcode.
>>
>>> 2) Installed off the 9.0 CD, got it up and running, everything was
>>> good.
>
>
> Let me elaborate on this:
>
> 2) Installed off the 9.0 CD, had a fully bootable system connected
> to the Internet, everything was good.
>
>
>> I think you should investigate the 'bootcode' subcommand of gpart(8).
>
>
> Does the above change things?
> It was my expectation "installkernel" would Do The Right Thing with
> respect to new bootcode, and I am surprised it did not.

installkernel does absolutely nothing to the boot partition. You need
to use bsdinstall or gpart to write the new image to disk.

That said, I know of no reason that the boot code written by the 9.0
install would fail to boot head. I am running 9.1 on a GPT disk and it
works fine, but I that disk is ada1 and I have booteasy installed on
the MBR of ada0. It has no problems booting the 9.1 system. (Windows 7
in on ada0.) Then again, I am hardly an expert on the subject.
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: problem after installkernel going from 9.0 to CURRENT

2013-01-03 Thread Robert Huff

On 1/3/2013 11:40 AM, Warren Block wrote:

On Wed, 2 Jan 2013, Robert Huff wrote:


(While this may not be a strictly CURRENT issue, I asked on
questions@, but have not found a solution.)

Situation:
One of my boxes failed, and for various reasons it became easier
to just scrub and rebuild it. Like its predecessor it will run CURRENT
1) Using BSDinstall, I flushed then created the first disk:

ada2p1freebsd-boot128k
ada2p2freebsd-swap4g
ada2p3freebsd-ufs25g

5) On rebooting, the loader(??) claims to not be able to find a
bootable partition - i.e. I get a screen that ends in "mountroot > ".
Providing the presumptive value by hand returns "error 19".


It really does not sound like a GPT problem, because 9.0 booted.


	I don't (at the moment) think it's GPT caused; but I do think it may be 
GPT related.




  The
-current kernel can't find/detect the device.  Scrolling back in the
console buffer might find a problem.  buildworld/kernel/installworld do
not affect the disk partitioning, but can change the code that looks for
those partitions.


	Exactly.  I'm looking for help figuring out how the hand-off from 
loader to kernel got broken and what I have to do to fix it.
	One possibility: I believe I labeled each of the partitions during the 
gpt creation process.  Can I use those labels to (hopefully) by-pass 
this issue?



Robert Huff
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [RFC/RFT] calloutng

2013-01-03 Thread Bruce Evans

On Thu, 3 Jan 2013, Alexander Motin wrote:


On 03.01.2013 16:45, Bruce Evans wrote:

On Wed, 2 Jan 2013, Alexander Motin wrote:

More important for scheduling fairness thread's CPU percentage is also
based on hardclock() and hiding from it was trivial before, since all
sleep primitives were strictly aligned to hardclock(). Now it is
slightly less trivial, since this alignment was removed and user-level
APIs provide no easy way to enforce it.


%cpu is actually based on statclock(), and not even used for scheduling.


May be for SCHED_4BSD, but not for SCHED_ULE.  In SCHED_ULE both %cpu and 
thread priority based on the same ts_ticks counter, that is based on 
hardclock() as time source. Interactivity calculation uses alike logic and 
uses the same time source.


Hmm.  I missed this because it hacks on the 'ticks' global.  It is clearer
in intermediate versions which use the scheduler API sched_tick(), which
is the hardclock analogue of sched_clock() for statclock.  sched_tick() is
now bogus since it is null for all schedulers.

Bruce
___
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: problem after installkernel going from 9.0 to CURRENT

2013-01-03 Thread Warren Block

On Wed, 2 Jan 2013, Robert Huff wrote:

	(While this may not be a strictly CURRENT issue, I asked on 
questions@, but have not found a solution.)


Situation:
	One of my boxes failed, and for various reasons it became easier to 
just scrub and rebuild it. Like its predecessor it will run CURRENT

1) Using BSDinstall, I flushed then created the first disk:

ada2p1  freebsd-boot128k
ada2p2  freebsd-swap4g
ada2p3  freebsd-ufs 25g

(There are non-bootable disks at ada0, -1, and -3.)

	2) Installed off the 9.0 CD, got it up and running, everything was 
good.

3) Used csup (tag=.) to update the source tree as of 00:01 on 12/30.
4a) Built world - OK.
4b) Build kernel - OK.
4c) Ran mergemaster - OK.
4d) Installed kernel - OK.
5) On rebooting, the loader(??) claims to not be able to find a
bootable partition - i.e. I get a screen that ends in "mountroot > ".
Providing the presumptive value by hand returns "error 19".
	6) Boot using installation CD and use "gpart show" to double check 
device names and partitions; everything looks good.

7) Try normal booting again, no go.

	This is my first time installing to a completely GPT partitioned 
system, and I have (obviously) failed to grok something.  I checked 
src/UPDATING and found nothing which covered this.

What have I bungled, and how do I fix it?


It really does not sound like a GPT problem, because 9.0 booted.  The 
-current kernel can't find/detect the device.  Scrolling back in the 
console buffer might find a problem.  buildworld/kernel/installworld do 
not affect the disk partitioning, but can change the code that looks for 
those partitions.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [RFC/RFT] calloutng

2013-01-03 Thread Alexander Motin

On 03.01.2013 16:45, Bruce Evans wrote:

On Wed, 2 Jan 2013, Alexander Motin wrote:

More important for scheduling fairness thread's CPU percentage is also
based on hardclock() and hiding from it was trivial before, since all
sleep primitives were strictly aligned to hardclock(). Now it is
slightly less trivial, since this alignment was removed and user-level
APIs provide no easy way to enforce it.


%cpu is actually based on statclock(), and not even used for scheduling.


May be for SCHED_4BSD, but not for SCHED_ULE.  In SCHED_ULE both %cpu 
and thread priority based on the same ts_ticks counter, that is based on 
hardclock() as time source. Interactivity calculation uses alike logic 
and uses the same time source.


--
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: installworld failure due to cross-device links

2013-01-03 Thread Stefan Esser
Am 02.01.2013 14:26, schrieb Nathan Whitehorn:
> On 01/02/13 07:04, Stefan Esser wrote:
>> I'd be interested in the general policy on LINKS vs. SYMLINKS
>> between directories that might end up on different file systems.
>>
>> There seems to be an assumption that system directories in /usr
>> (e.g. /usr/bin, /usr/sbin, /usr/libexec) are on the same file
>> system, but I do not think that this assumption is documented.
>>
>> I'm using a ZFS only installation of -CURRENT and have separate file
>> systems for several of the directories in / and /usr, that usually
>> share a file system (e.g. /bin, /sbin, but also /usr/bin/, /usr/sbin
>> and /usr/libexec are independent file systems).
>>
>> An older case is the link from /usr/bin/chgrp to /usr/sbin/chown
>> (see usr.sbin/chown/Makefile), which is easily fixed by using a
>> SMYLINK instead of a LINK.
>>
>> And now there is usr.sbin/bsdinstall/partedit/Makefile, which as of
>> r244859 creates a link from /usr/libexec/bsdinstall to /usr/sbin/sade.
>>
>> This breaks with /usr/bin and /usr/sbin on different file systems,
>> while it should not according to the commit message:
>>
> 
> Thanks for the patch! I've committed it (slightly modified) as r244958.
> I haven't taken any action on the chgrp/chown issue, though.

Thanks for the fix. Seems I had a wrong idea of the semantics of the
(SYM)LINKS macro, as I had assumed that the build target would be
linked to the list of names (instead of pairs of source/dest).

I did not expect you to do anything with chown/chgrp, but I still
think there should be a policy on whether hard links may be used to
connect files in different directories (which might be in different
file systems).

Regards, STefan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [RFC/RFT] calloutng

2013-01-03 Thread Bruce Evans

On Wed, 2 Jan 2013, Alexander Motin wrote:


On 02.01.2013 19:09, Konstantin Belousov wrote:

On Wed, Jan 02, 2013 at 05:22:06PM +0100, Luigi Rizzo wrote:

Probably one way to close this discussion would be to provide
a sysctl so the sysadmin can decide which point in the interval
to pick when there is no suitable callout already scheduled.

Isn't trying to synchronize to the external events in this way unsafe ?
I remember, but cannot find the reference right now, a scheduler
exploit(s) which completely hide malicious thread from the time
accounting, by making it voluntary yielding right before statclock
should fire. If statistic gathering could be piggy-backed on the
external interrupt, and attacker can control the source of the external
events, wouldn't this give her a handle ?


Fine-grained timeouts complete fully opening this security hole.
Synchronization without fine-grained timeouts might allow the same,
but is harder to exploit since you can't control the yielding points
directly.  With fine-grained timeouts, you just have to predict the
statclock firing points.  Use one timeout to arrange to yield just
before statclock fires and another to regain control just after it has
fired.  If the timeout resolution is say 50 usec, then this can hope
to run for all except 100 usec out of every 1/stathz seconds.  With
stathz = 128, 1/stathz is 7812 usec, so this gives 7712/7812 of the
CPU with 0 statclock ticks.  Since the scheduler never sees you running,
your priority remains minimal, so the scheduler should prefer to run
you whenever a timeout expires, with only round-robin with other
minimal-priority threads preventing you getting 7712/7812 of the (user
non-rtprio) CPU.

The previous stage of fully opening this security hole was changing
(the default) HZ from 100 to 1000.  HZ must not be much smaller than
stathz, else the security hole is almost fully open.  With HZ = 100
being less than stathz and timeout granularity limiting the fine control
to 2/HZ = 20 msec (except you can use a periodic itimer to get a 1/HZ
granularity at a minor cost of getting more SIGALRMs), it is impossible
to get near 100% of the CPU with 0 statclock ticks.  After yielding,
you can't get control for another 100 or 200 msec.  Since this exceeds
1/stathz = 78.12 usec, you can only hide from statclock ticks by not
running very often or for very long.  Limited hiding is possible by
wasting even more CPU to determine when to hide: since the timeout
granularity is large, it is also ineffective for determining when to
yield.  So when running, you must poll the current time a lot to
determine when to yield.  Yield just before statclock fires, as above.
(Do it 50 usec early, as above, to avoid most races involving polling
the time.)  This actually has good chances of not limiting the hiding
too much, depending on the details of the scheduling.  It yields just
before a statclock tick.  After this tick fires, if the scheduler
reschedules for any reason, then the hiding process would most likely
be run again, since its priority is minimal.  But at least the old
4BSD scheduler doesn't reschedule after _every_ statclock tick.  This
depends on the bugfeature that the priority is not checked on _every_
return to user mode (sched_clock() does change the priority, but this
is not acted on until much later).  Without this bugfeature, there
would be excessive context switches.  OTOH, with timeouts, at least
old non-fine-grained ones, you can force a rescheduling that is acted
on soon enough simply by using timeouts (since timeouts give a context
switch to the softclock thread, the scheduler has no option to skip
checking the priority on return to user mode).

After the previous stage of changing HZ to 1000, the granuarity is fine
enough for using timeouts to hide from the scheduler.  Using a periodic
itimer to get a granularity of 1000 usec, start hiding 50-1000 usec
before each statclock tick and regain control 1000 usec later.  With
stathz = 128, 6812/7812 of the CPU with 0 statclock ticks.  Not much
worse (for the hider) than 7712/7812.

Statclock was supposed to be aperiodic to avoid hiding (see
statclk-usenix93.ps), but this was never implemented in FreeBSD.  With
fine-grained timeouts, it would have to be very aperiodic, to the point
of giving large inaccuracies, to limit the hiding very much.  For
example, suppose that it has an average period of 7812 usec with +-50%
jitter.  You would try to hide from it most of the time by running for
a bit less than 7812/2 usec before yielding in most cases.  If too
much scheduling is done on each statclock tick, then you are likely
to regain control after each one (as above) and then know that there
is almost a full minimal period until the next one.  Otherwise, it
seems to be necessary to determine when the previous statclock tick
occurred, so as to determine the minimum time until the next one.

There are many different kinds of accounting with different characteristics. 
Run time for each thread cal

steady stream of ath errors

2013-01-03 Thread Mike Tancsa
Experimenting with ath under RELENG8,9 and HEAD at home on my wifi
router, I found that with current from today (r244989) gives a steady
stream of errors.  How can I debug the issue in my setup ?

   input(Total)   output
   packets  errs idrops  bytespackets  errs  bytes colls
72 7 0  38865 78 0  76117 0
57 4 0989 32 0   2062 0
47 0 0   3369 29 0   5724 0
  162511 01394179   2214 02779765 0
  314620 02369588   3955 04723911 0
  326914 02499654   4130 04984206 0
  357019 02549189   4330 05082261 0
  339915 02485682   4201 04956613 0
  353022 02612967   4375 05207076 0
  334016 02371278   4040 04728272 0
  328114 02321800   3947 04628010 0
  309215 02263990   3826 04514317 0
  2905 8 02124069   3572 04235585 0
  301718 02229250   3722 0773 0
  270111 01709542   3064 03407885 0
  224511 01918413   3038 03824605 0
  342812 02508519   4251 05001890 0
  342814 02473616   4180 04931945 0
  322711 02264217   3886 04514416 0
  322314 02403237   4016 04792172 0
  331317 02402811   4048 04791158 0

ath0@pci0:2:0:0:class=0x028000 card=0x2c371a3b chip=0x002b168c
rev=0x01 hdr=0x00
vendor = 'Atheros Communications Inc.'
device = 'AR9285 Wireless Network Adapter (PCI-Express)'
class  = network
bar   [10] = type Memory, range 64, base 0xfe9f, size 65536, enabled
cap 01[40] = powerspec 3  supports D0 D1 D3  current D0
cap 05[50] = MSI supports 1 message
cap 10[60] = PCI-Express 2 legacy endpoint max data 128(128) link x1(x1)
 speed 2.5(2.5)
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0002[140] = VC 1 max VC0
ecap 0003[160] = Serial 1 
ecap 0004[170] = Power Budgeting 1



stats etc attached.

---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
0{zotac}# ifconfig ath0
ath0: flags=8843 metric 0 mtu 2290
ether 74:2f:68:af:b9:47
nd6 options=29
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng 
status: running
0{zotac}# ifconfig wlan0
wlan0: flags=8843 metric 0 mtu 1500
ether 74:2f:68:af:b9:47
inet6 fe80::762f:68ff:feaf:b947%wlan0 prefixlen 64 tentative scopeid 
0x5 
inet 192.168.241.129 netmask 0xff00 broadcast 192.168.241.255 
nd6 options=29
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng 
status: running
ssid policevan2 channel 6 (2437 MHz 11g ht/20) bssid 74:2f:68:af:b9:47
regdomain 96 indoor ecm authmode WPA privacy MIXED deftxkey 2
TKIP 2:128-bit TKIP 3:128-bit txpower 20 scanvalid 60 protmode CTS
ampdulimit 64k ampdudensity 8 shortgi wme burst dtimperiod 1 -dfs
0{zotac}# 
0{zotac}# sysctl -a dev.ath
dev.ath.0.%desc: Atheros 9285
dev.ath.0.%driver: ath
dev.ath.0.%location: slot=0 function=0 handle=\_SB_.PCI0.NBP1.NP1S
dev.ath.0.%pnpinfo: vendor=0x168c device=0x002b subvendor=0x1a3b 
subdevice=0x2c37 class=0x028000
dev.ath.0.%parent: pci2
dev.ath.0.smoothing_rate: 75
dev.ath.0.sample_rate: 10
dev.ath.0.sample_stats: 0
dev.ath.0.countrycode: 0
dev.ath.0.regdomain: 96
dev.ath.0.slottime: 9
dev.ath.0.acktimeout: 64
dev.ath.0.ctstimeout: 48
dev.ath.0.softled: 0
dev.ath.0.ledpin: 0
dev.ath.0.ledon: 0
dev.ath.0.ledidle: 2700
dev.ath.0.hardled: 0
dev.ath.0.led_net_pin: -1
dev.ath.0.led_pwr_pin: -1
dev.ath.0.txantenna: 0
dev.ath.0.rxantenna: 1
dev.ath.0.txintrperiod: 5
dev.ath.0.diag: 0
dev.ath.0.tpscale: 0
dev.ath.0.tpc: 0
dev.ath.0.tpack: 63
dev.ath.0.tpcts: 63
dev.ath.0.txagg: 0
dev.ath.0.forcebstuck: 0
dev.ath.0.intmit: 1
dev.ath.0.monpass: 24
dev.ath.0.hwq_limit: 2
dev.ath.0.tid_hwq_lo: 2
dev.ath.0.tid_hwq_hi: 4
dev.ath.0.txq_data_minfree: 10
dev.ath.0.txq_mcastq_maxdepth: 512
dev.ath.0.clear_stats: 0
dev.ath.0.stats.ast_watchdog: 0
dev.ath.0.stats.ast_hardware: 0
dev.ath.0.stats.ast_bmiss: 0
dev.ath.0.stats.ast_bmiss_phantom: 0
dev.ath.0.stats.ast_bstuck: 0
dev.ath.0.stats.ast_rxorn: 0
dev.ath.0.stats.ast_rxeol: 0
dev.ath.0.stats.ast_txurn: 0
dev.ath.0.stats.ast_mib: 0
dev.ath.0.stats.ast_intrcoal: 0
dev.ath.0.stats.ast_tx_packets: 0
dev.ath.0.stats.ast_tx_mgmt: 0
dev.ath.0.stats.ast_tx_disc

Re: loopback interface broken on current

2013-01-03 Thread KAHO Toshikazu
  Hello,

> If I comment out :
> ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0"
> Network doesn't work.

  Yes, you should not commnet out it,
you cannot connect from/to outside.

  network_interfaces="auto" is same as /etc/default/rc.conf,
so that you can remove it safely from /etc/rc.conf.

  I cannot identify the problematic line caused the problem.

-- 
vi...@elam.kais.kyoto-u.ac.jp
___
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: loopback interface broken on current

2013-01-03 Thread Manfred Antar
At 03:30 AM 1/3/2013, KAHO Toshikazu wrote:
>  Hello, 
>
>> There is still >ifa_del_loopback_route: deletion failed: 3
>> that wasn't there before,but the 127.0.0.1 seems to be configured now:
>
>  Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf?
>If you have it, try to remove it.
>
>  I think something broken, but people using automatic configuration
>don't notice the breakage.
>
>-- 
>k...@elam.kais.kyoto-u.ac.jp
>
>-- 
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.

Hi
If I comment out :
ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0"
Network doesn't work.


||  n...@pozo.com   ||
||  Ph. (415) 681-6235  ||
 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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: loopback interface broken on current

2013-01-03 Thread Manfred Antar
At 03:30 AM 1/3/2013, KAHO Toshikazu wrote:
>  Hello, 
>
>> There is still >ifa_del_loopback_route: deletion failed: 3
>> that wasn't there before,but the 127.0.0.1 seems to be configured now:
>
>  Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf?
>If you have it, try to remove it.
>
>  I think something broken, but people using automatic configuration
>don't notice the breakage.
>
>-- 
>k...@elam.kais.kyoto-u.ac.jp
>
>-- 
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.

I have :
network_interfaces="auto"
ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0"
I will try to comment out the above line and see what happens.
But I think it might screw up my routing


||  n...@pozo.com   ||
||  Ph. (415) 681-6235  ||
 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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: loopback interface broken on current

2013-01-03 Thread KAHO Toshikazu
  Hello, 

> There is still >ifa_del_loopback_route: deletion failed: 3
> that wasn't there before,but the 127.0.0.1 seems to be configured now:

  Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf?
If you have it, try to remove it.

  I think something broken, but people using automatic configuration
don't notice the breakage.

-- 
k...@elam.kais.kyoto-u.ac.jp
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [RFC/RFT] calloutng

2013-01-03 Thread Luigi Rizzo
On Wed, Jan 02, 2013 at 09:52:37PM -0800, Kevin Oberman wrote:
> On Wed, Jan 2, 2013 at 2:06 PM, Alexander Motin  wrote:
> > On 02.01.2013 18:08, Adrian Chadd wrote:
> >>
> >> .. I'm pretty damned sure we're going to need to enforce a "never
> >> earlier than X" latency.
> >
> >
> > Do you mean here that we should never wake up before specified time (just as
> > specified by the most of existing APIs), or that we should not allow sleep
> > shorter then some value to avoid DoS? At least on x86 nanosleep(0) doesn't
> > allow to block the system. Also there is already present mechanism for
> > specifying minimum timer programming interval in eventtimers(9) KPI.
> 
> I can see serious performance issues with some hardware (wireless
> comes to mind) if things happen too quickly. Intuition is that it
> could also play hob with VMs.
> 
> I believe that the proper way is to wake between  T_X and T_X + D.
> This assumes that D is max_wake_delay, not deviation, which leaves us
> at the original of (T_X) =< event_time =< (T_X + D).

i think "max delay" was the intended meaning of the D parameter.
We picked bad names (tolerance, deviation,...) for it.

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"