Re: vt(4) odd scrolling behavior

[Poul-Henning Kamp]

In message 
, Kyle Evans writes:

>I've had this odd behavior [1] on one of my machines with vt(4)
>misbehaving in graphics mode following the beastie loader's screen.
>
>Any ideas what might cause something like this, 

I've seen it too.  I think beastie sets a scrolling region and
doesn't clear it.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

vt(4) odd scrolling behavior

[Kyle Evans]

Hello!

I've had this odd behavior [1] on one of my machines with vt(4)
misbehaving in graphics mode following the beastie loader's screen.

Any ideas what might cause something like this, or if it's just
something unsupported? I have a PR open at [2] with pciconf -lv
output.

Thanks,

Kyle Evans

[1] http://files.kyle-evans.net/vt_scrolling.mp4
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211876
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Revision 309657 to stack_machdep.c renders unbootable system

[Steven G. Kargl]

On Fri, Dec 16, 2016 at 03:19:09PM -0800, John Baldwin wrote:
> 
> So the hack in pause() is probably not as necessary now.  In particular, I
> think we only need it for thread0, not for other threads.  The patch below
> worked for me with SPEW's config:
> 
> Index: kern_synch.c
> ===
> --- kern_synch.c  (revision 310128)
> +++ kern_synch.c  (working copy)
> @@ -321,7 +321,8 @@ pause_sbt(const char *wmesg, sbintime_t sbt, sbint
>   if (sbt == 0)
>   sbt = tick_sbt;
>  
> - if (cold || kdb_active || SCHEDULER_STOPPED()) {
> + if ((cold && curthread == ) || kdb_active ||
> + SCHEDULER_STOPPED()) {
>   /*
>* We delay one second at a time to avoid overflowing the
>* system specific DELAY() function(s):
> 

I'll give your patch a try on Monday.  I'm heading out the door
for the weekend, and the system that has problems sits in my office.
System is currently rebuilding firefox-50, which seems to have
a penchant for becoming wedged.  An unkillable program consuming
~1 GB of memory. :(

-- 
Steve
http://troutmask.apl.washington.edu/~kargl/
 2. https://www.youtube.com/watch?v=Py6d6o2jbaE
 1. https://www.youtube.com/watch?v=6hwgPfCcpyQ
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Revision 309657 to stack_machdep.c renders unbootable system

[John Baldwin]

On Wednesday, December 14, 2016 04:50:21 PM Mark Johnston wrote:
> On Wed, Dec 14, 2016 at 03:48:04PM -0800, Steven G. Kargl wrote:
> > On Wed, Dec 14, 2016 at 02:10:48PM -0800, Mark Johnston wrote:
> > > On Wed, Dec 14, 2016 at 12:14:16PM -0800, Mark Johnston wrote:
> > > > On Wed, Dec 14, 2016 at 11:49:26AM -0800, Steven G. Kargl wrote:
> > > > > Well, after 3 days of bisection, I finally found the commit
> > > > > that renders my system unbootable.  The system does not panic.
> > > > > It simply gets stuck in some state.  Nonfunctional keyboard,
> > > > > so can't break into debugger.  No serial console available.
> > > > > The verbose dmesg.boot for a working kernel from revision
> > > > > 309656 is at
> > > > > 
> > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/dmesg.309656.txt
> > > > > 
> > > > > The kernel config file is at
> > > > > 
> > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/SPEW.txt
> > > > > 
> > > > > In looking at /usr/src/UPDATING, there is no warning that one
> > > > > can create a boat anchor by upgrading to 309657.  If compiling
> > > > > a kernel with 'options DDB' is no longer supported, this should
> > > > > be stated in UPDATING.  Or, UPDATING should state that 'options
> > > > > DDB' requires 'options STACK'.  Or, 'options DDB' should simply
> > > > > to the right thing and pull in whatever 'option STACK' does. 
> > > > 
> > > > It is supported though - the point of that change was to fix a problem
> > > > that occurred when DDB is configured but STACK isn't. While testing I
> > > > tried every combination of the two options, and I just tried and
> > > > successfully booted a kernel with DDB and !STACK.
> > > > 
> > > > Does the kernel boot successfully if STACK is added to your
> > > > configuration?
> > > 
> > > I tried your config (plus virtio drivers) and was able to reproduce the
> > > hang in bhyve. Adding STACK "fixed" the hang, as did reverting part of
> > > my change to re-add dead code into the kernel. My VM was always hanging
> > > after printing
> > > 
> > > 000.50 [ 426] vtnet_netmap_attach   virtio attached txq=1, 
> > > txd=1024 rxq=1, rxd=1024
> > > 
> > > Sure enough, removing "device netmap" from your config also fixes the
> > > hang. When the hang occurs, I can see with "bhyvectl --get-rip" that
> > > we're stuck in DELAY(), but I can't get a stack at that point. I think
> > > my change is an innocent bystander - it just happened to expose a latent
> > > issue elsewhere.
> > > 
> > > I don't have much more time to look at this right now, but I'll look
> > > into it more tonight.
> > 
> > Yes, adding STACK got me to a booting kernel.  I can't remember
> > why I added netmap to my config file.  Re-adding dead code seems to
> > point to some memory corruption issue or a rogue pointer. :(
> 
> It's not quite that bad, as it turns out. The key is that
> adding/removing the dead code changes the ordering of the items in the
> sysinit linker set. I discovered that if the ctl(4) module is
> initialized before the vtnet driver attaches, the hang occurs, and
> reverting my commit results in a sysinit order where vtnet comes
> _before_ ctl(4). So my change triggers the problem just because it
> happens to perturb something in the compile-time linker.
> 
> > 
> > BTW, I think it would be prudent to add something like 
> > 
> >   20161206:
> >  At revision 309657, 'options STACK' was introduced into
> >  sys/x86/x86/mstack_machdep.c.  Old kernel configuration files
> >  that included 'options DDB' are now required to include also
> >  'options STACK'.
> > 
> > to UPDATING or some such wording.  I was jumping from circ Oct 10th world
> > to top of tree, and got caught by ~3000 commits.
> 
> The issue actually seems to be in 4BSD, and more specifically in r308564
> and r308565. Switching to ULE or reverting either of those two commits
> fixes the hang. Here's what happens:
> 
> 1. ctl_init() runs and creates ctl_thresh_thread. This thread's main
>loop cause pause(9) when it has no work to do. During boot, pause(9)
>just calls DELAY() and does not yield the CPU.
> 2. thread0 attaches the vtnet driver. As part of this, it creates and
>starts some high-priority taskqueue threads in
>_taskqueue_thread_start(). They're added to the scheduler with:
> 
>thread_lock();
>sched_pri(...);
>sched_add(...);
>thread_unlock();
> 
>4BSD's sched_add() will call maybe_preempt() in this case, which as
>of r308564 will unconditionally set td_owepreempt in the current
>thread.
> 3. thread_unlock() will release the critical section held by the current
>thread and because td_owepreempt is set, we'll yield the CPU. The
>taskqueue threads have nothing to do, but ctl_thresh_thread runs
>and ends up busy-waiting in pause() forever.
> 
> r308565 removes a check in maybe_preempt() that would have stopped
> td_owepreempt from being set. Before r308564, maybe_preempt() would have
> switched directly to 

Re: Help

[scrat]

On 12/12/16 23:08, Lewis ingraham wrote:

Hi FreeBSD Current Team, I need help with a few things:


1. I tried getting help from all kinds of irc chats but still no dice.
2. I cannot get my soundcard to work on FreeBSD. It is the Soundblaster
Z(SB1500, SB1502) with the CA0132 codec.

I really LOVE FreeBSD i use it for workstation applications and
professional use as well. Is there any way i could be referred to someone
to can code the drivers needed to work with my hardware?? And possibly
someone who could help me with my software problems.


https://www.freebsd.org/releases/11.0R/hardware.html#sound

Looks like it is not supported
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: best approximation of getcpu() ?

[John Baldwin]

On Friday, December 16, 2016 12:10:01 PM Adrian Chadd wrote:
> On 16 December 2016 at 11:45, Luigi Rizzo  wrote:
> > On Fri, Dec 16, 2016 at 09:29:15AM +, David Chisnall wrote:
> >> On 16 Dec 2016, at 03:10, Alan Somers  wrote:
> >> >
> >> > What about pthread_setaffinity(3) and friends?  You can use it to pin
> >> > a thread to a single CPU, and know that it will never migrate.
> >>
> >> This is not a useable solution for anything that needs to live in a 
> >> library and also doesn???t solve the problem.
> >>
> >> The Linux get_cpu call() is used for caches that are somewhere between 
> >> global and thread-local.  Accessing them still requires a lock, but it???s 
> >> very likely to be uncontended (contention only happens when you???re 
> >> context switched at exactly the wrong time, or if a thread is migrated 
> >> between cores in between the get_cpu() call and usage) and so you can use 
> >> the userspace fast path for the lock and not suffer from cache contention 
> >> effects.
> >>
> >> One x86, you can use cpuid from userspace and get the current core ID.  I 
> >> have some code that does this and re-checks every few hundred accesses, 
> >> storing the current CPU ID in a thread-local variable.  Using the per-CPU 
> >> caches is a lot faster than using the global cache (and reduces contention 
> >> on the global cache).  It would be great if we could have a syscall to do 
> >> this on FreeBSD (it would be even better if we could have specify a TLS 
> >> variable that the kernel automatically updates for the userspace thread 
> >> when the scheduler migrates the thread between cores).
> >
> > indeed the following line seems to do the job for x86
> > asm volatile("cpuid" : "=d"(curcpu), "=a"(tmp), "=b"(tmp), 
> > "=c"(tmp) : "a"(0xb) );
> > (there must be a better way to tell the compiler that eax, ebx, ecx, edx are
> > all clobbered).
> >
> > 0xb is the CPUID function that returns the current APIC id for the
> > core (not necessarily matching the OS core-id)
> >
> > The only problem is that this instruction is serialising and slow,
> > seems to take some 70-100ns on several of my machines so you
> > cannot afford to call it at all times but need the value cached
> > somewhere. Exposing it as thread local storage, or a VDSO syscall,
> > would be nicer because the kernel knows when it is actually changing
> > value.
> 
> The problem is your CPU ID can change in the middle of packet handling.
> 
> So if you want it to be accurate, you need to bind your worker thread to a 
> CPU.

Well, it seems the goal is to have something much lighter weight akin to
critical_enter/exit or sched_pin/unpin in the kernel.  It's not that you
care about a specific CPU, you just want to not migrate.  (UMA uses
critical sections when accessing the per-CPU buckets for the same reasons.)
The problem with using cli/sti in userland is that you might page fault and
context switch during the fault handler (or get preempted in the fault
handler which will run with interrupts enabled) and migrate.  You could
prevent this if you are able to mlock() all of the pages holding any code
you will execute or data you will access to prevent faults, but you have to
ensure you can do this for every potential page.

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

Re: Enabling NUMA in BIOS stop booting FreeBSD

[John Baldwin]

On Thursday, December 15, 2016 03:57:58 PM Adrian Chadd wrote:
> heh, an updated BIOS that solves the problem will solve the problem. :)
> 
> I think you have enough information to provide to supermicro. Ie,
> "SMAP says X, when physical memory pages at addresses X are accessed,
> they don't behave like memory, maybe something is wrong".
> 
> All I can think of is some hack to add a blacklist for that region so
> you can boot the unit. But it makes me wonder what else is going on.

We have the blacklist: it is the memory test.  That is the way to workaround
this type of BIOS breakage.  This is just the first time in over a decade that
test has been relevant.

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

Re: best approximation of getcpu() ?

[Adrian Chadd]

On 16 December 2016 at 11:45, Luigi Rizzo  wrote:
> On Fri, Dec 16, 2016 at 09:29:15AM +, David Chisnall wrote:
>> On 16 Dec 2016, at 03:10, Alan Somers  wrote:
>> >
>> > What about pthread_setaffinity(3) and friends?  You can use it to pin
>> > a thread to a single CPU, and know that it will never migrate.
>>
>> This is not a useable solution for anything that needs to live in a library 
>> and also doesn???t solve the problem.
>>
>> The Linux get_cpu call() is used for caches that are somewhere between 
>> global and thread-local.  Accessing them still requires a lock, but it???s 
>> very likely to be uncontended (contention only happens when you???re context 
>> switched at exactly the wrong time, or if a thread is migrated between cores 
>> in between the get_cpu() call and usage) and so you can use the userspace 
>> fast path for the lock and not suffer from cache contention effects.
>>
>> One x86, you can use cpuid from userspace and get the current core ID.  I 
>> have some code that does this and re-checks every few hundred accesses, 
>> storing the current CPU ID in a thread-local variable.  Using the per-CPU 
>> caches is a lot faster than using the global cache (and reduces contention 
>> on the global cache).  It would be great if we could have a syscall to do 
>> this on FreeBSD (it would be even better if we could have specify a TLS 
>> variable that the kernel automatically updates for the userspace thread when 
>> the scheduler migrates the thread between cores).
>
> indeed the following line seems to do the job for x86
> asm volatile("cpuid" : "=d"(curcpu), "=a"(tmp), "=b"(tmp), "=c"(tmp) 
> : "a"(0xb) );
> (there must be a better way to tell the compiler that eax, ebx, ecx, edx are
> all clobbered).
>
> 0xb is the CPUID function that returns the current APIC id for the
> core (not necessarily matching the OS core-id)
>
> The only problem is that this instruction is serialising and slow,
> seems to take some 70-100ns on several of my machines so you
> cannot afford to call it at all times but need the value cached
> somewhere. Exposing it as thread local storage, or a VDSO syscall,
> would be nicer because the kernel knows when it is actually changing
> value.

The problem is your CPU ID can change in the middle of packet handling.

So if you want it to be accurate, you need to bind your worker thread to a CPU.



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

Re: best approximation of getcpu() ?

[Luigi Rizzo]

On Fri, Dec 16, 2016 at 09:29:15AM +, David Chisnall wrote:
> On 16 Dec 2016, at 03:10, Alan Somers  wrote:
> > 
> > What about pthread_setaffinity(3) and friends?  You can use it to pin
> > a thread to a single CPU, and know that it will never migrate.
> 
> This is not a useable solution for anything that needs to live in a library 
> and also doesn???t solve the problem.
> 
> The Linux get_cpu call() is used for caches that are somewhere between global 
> and thread-local.  Accessing them still requires a lock, but it???s very 
> likely to be uncontended (contention only happens when you???re context 
> switched at exactly the wrong time, or if a thread is migrated between cores 
> in between the get_cpu() call and usage) and so you can use the userspace 
> fast path for the lock and not suffer from cache contention effects.  
> 
> One x86, you can use cpuid from userspace and get the current core ID.  I 
> have some code that does this and re-checks every few hundred accesses, 
> storing the current CPU ID in a thread-local variable.  Using the per-CPU 
> caches is a lot faster than using the global cache (and reduces contention on 
> the global cache).  It would be great if we could have a syscall to do this 
> on FreeBSD (it would be even better if we could have specify a TLS variable 
> that the kernel automatically updates for the userspace thread when the 
> scheduler migrates the thread between cores).

indeed the following line seems to do the job for x86
asm volatile("cpuid" : "=d"(curcpu), "=a"(tmp), "=b"(tmp), "=c"(tmp) : 
"a"(0xb) );
(there must be a better way to tell the compiler that eax, ebx, ecx, edx are
all clobbered).

0xb is the CPUID function that returns the current APIC id for the
core (not necessarily matching the OS core-id)

The only problem is that this instruction is serialising and slow,
seems to take some 70-100ns on several of my machines so you
cannot afford to call it at all times but need the value cached
somewhere. Exposing it as thread local storage, or a VDSO syscall,
would be nicer because the kernel knows when it is actually changing
value.

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

Re: /usr/share/man/man4/cc.4.gz obsolete?

[Nikolai Lifanov]

On 12/16/2016 04:31, Trond Endrestøl wrote:
> /usr/share/man/man4/cc.4.gz shows up as obsolete whenever I run 
> make -C /usr/src check-old.
> 
> make -C /usr/src delete-old removes the file, but 
> make -C /usr/src installworld adds it.
> 
> System is base/head r309889.
> 
> Please make up your mind.
> 

This is installed by cxgbe module directory for if_cc (T6 cards) and
previously removed as an old congestion control page. I put up a review
to fix this: https://reviews.freebsd.org/D8816

- Nikolai




signature.asc
Description: OpenPGP digital signature

Install tools in src/Makefile.inc1 might need to be augmented

[David Wolfskill]

I found the attached patch (which augments ITOOLS in src/Makefile.inc1
with "env" and "mktemp") necessary to complete "make installworkd"
when updtaing from:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #197  
r310104M/310111:1200018: Thu Dec 15 04:20:23 PST 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

to:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #198  
r310154M/310154:1200019: Fri Dec 16 05:31:10 PST 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Epistemology for post-truthers: How do we select parts of reality to ignore?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
Index: Makefile.inc1
===
--- Makefile.inc1	(revision 310154)
+++ Makefile.inc1	(working copy)
@@ -915,8 +915,8 @@
 .endif
 
 ITOOLS=	[ awk cap_mkdb cat chflags chmod chown cmp cp \
-	date echo egrep find grep id install ${_install-info} \
-	ln make mkdir mtree mv pwd_mkdb \
+	date echo egrep env find grep id install ${_install-info} \
+	ln make mkdir mktemp mtree mv pwd_mkdb \
 	rm sed services_mkdb sh strip sysctl test true uname wc ${_zoneinfo} \
 	${LOCAL_ITOOLS}
 


signature.asc
Description: PGP signature

Re: best approximation of getcpu() ?

[Slawa Olhovchenkov]

On Fri, Dec 16, 2016 at 03:17:19AM +0100, Luigi Rizzo wrote:

> TL;DR; is there any way a userspace thread in FreeBSD can tell
> on which CPU it is (was) running ? I know the thread can migrate
> at any time but as long as the event is rare I can live with
> the occasionally wrong information.
> Linux has getcpu(2) which is exposed by glibc as sched_getcpu(3),
> but the linuxulator in FreeBSD only has a dummy (uniplemented)
> function for that syscall.
> 
> FULL DESCRIPTION
> It is common practice, when building scalable systems, to use per-cpu
> resources that can be accessed without contention by just protecting
> them with a CLI; STI; pair. Multiqueue NICs typically do this to
> build a lock-free transmit path. In [1] we show an in-kernel
> scheduler that maps a large number of clients to a (much smaller)
> number of lock-free mailboxes, one per core.
> 
> In the kernel we can do CLI and STI and access curcpu.
> In userspace a suitably privileged process can indeed open /dev/io
> to acquire the right to use CLI and STI, though I am not sure
> wether curcpu is available in some way.
> 
> Of course running userspace code with interrupts disabled is risky,
> but we can use the per-cpu trick with a small tweak, namely,
> protect each resouce with a lock. If the thread does not migrate
> imediately after getcpu(), we will access the lock (and the resource)
> almost always from the same cpu hence very efficiently.
> Occasional migration may cause contention but should not
> alter too much the good performance of this scheme.
> 
> So, any idea before I add a syscall/ioctl (or extend one)
> to export this information ?

Most hard task is discover what irq handle specific NIC tx/rx queue
(assume irq already have affinity).
After this discover (by some magic shit) no problem to start pthread
and execute some like

CPU_ZERO();
CPU_SET(i, );
pthread_attr_init();
pthread_attr_setaffinity_np(, sizeof(mask), );
pthread_create([i].tid, , balancer_thread, [i]);
pthread_set_name_np(balancer[i].tid, name);

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

/usr/share/man/man4/cc.4.gz obsolete?

[Trond Endrestøl]

/usr/share/man/man4/cc.4.gz shows up as obsolete whenever I run 
make -C /usr/src check-old.

make -C /usr/src delete-old removes the file, but 
make -C /usr/src installworld adds it.

System is base/head r309889.

Please make up your mind.

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"