https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227138
--- Comment #2 from willsz...@gmail.com ---
OK,
CMIIW, for terminal columns width:
root:~# tput co
110
for terminal deep colors:
root:~# tput Co
256
root:~# grep -A1 -w 'xterm-256color|xterm alias 3:' /etc/termcap
xterm-256color|xterm ali
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
Gleb Smirnoff changed:
What|Removed |Added
Status|New |In Progress
Assignee|fre
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #23 from Daniel Kolesa ---
(In reply to Gleb Smirnoff from comment #22)
Alright. Let me know when you have a patch so I can test; without being
familiar with the source, this is not something I can patch myself here, and
blindl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #22 from Gleb Smirnoff ---
I see the problem. The size of zone before alignment fits into single slab, but
after alignment it doesn't. However, since we have only 1 item per slab, we
don't need alignment correction at all. I'm w
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #21 from Daniel Kolesa ---
Created attachment 192015
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192015&action=edit
different panic after patch
I rebuilt the kernel once again with my patch this time (the updated
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #20 from Daniel Kolesa ---
(In reply to Daniel Kolesa from comment #19)
Maybe, shouldn't the condition be
if (roundup2(zsize, UMA_BOOT_ALIGN) > UMA_SLAB_SPACE)
instead?
--
You are receiving this mail because:
You are the as
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #19 from Daniel Kolesa ---
Which now that I'm looking at it is actually pretty obvious, because
UMA_SLAB_SIZE is 4096 (i.e. pagesize), and roundup2(zsize, UMA_BOOT_ALIGN) is
4000, which is bigger than zsize (3984) but still smal
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #18 from Daniel Kolesa ---
Created attachment 192014
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192014&action=edit
patched kernel
I built the kernel on my server and replaced it in the installer image, but it
sti
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #17 from Daniel Kolesa ---
(In reply to Gleb Smirnoff from comment #15)
I can try, but if you could perhaps upload a kernel binary somewhere, that'd be
great - otherwise I'll have to build on my HardenedBSD server, which has sl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227138
--- Comment #1 from Andriy Gapon ---
(In reply to willsznet from comment #0)
Right, there is no (termcap) attribute 'colors'. Or 'cols'. There is attribute
'co', columns. When tput sees that prefix it ignores the rest.
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #16 from Shawn Webb ---
(In reply to Gleb Smirnoff from comment #15)
Daniel is relying on me to do custom builds for him to test. I'll perform a
build this evening (US Eastern) for him to test with the patch.
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #15 from Gleb Smirnoff ---
Can you please confirm that patch works for you?
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mai
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227138
Bug ID: 227138
Summary: Tput wrong output
Product: Base System
Version: 10.4-STABLE
Hardware: i386
OS: Any
Status: New
Severity: Affects Only Me
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #14 from Daniel Kolesa ---
(In reply to Gleb Smirnoff from comment #12)
That's great. Looks like we've come to a conclusion pretty quickly after all :)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #13 from Daniel Kolesa ---
(In reply to Konstantin Belousov from comment #11)
That's amusing, I just came to the same conclusion by isolating the code into a
standalone .c program with stubbed out variables.
---
/* Memory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #12 from Gleb Smirnoff ---
Thanks Kostik. I was just preparing a patch to print out all variables.
So, the fix should be:
Index: uma_core.c
===
--- uma_core.c (r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #11 from Konstantin Belousov ---
(In reply to Konstantin Belousov from comment #8)
In fact it is clear where the things get broken:
UMA_SLAB_SPACE is UMA_SLAB_SIZE - sizeof(struct uma_slab) == 3984.
You have 2 14-core CPUs, hy
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #10 from Daniel Kolesa ---
The incorrect lines seem to be coming from the 11-STABLE kernel running on the
server, I guess this makes sense. But the 1827 line should still be correct...
--
You are receiving this mail because:
Y
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #9 from Daniel Kolesa ---
Actually, I managed to obtain a kernel-dbg.txz of the same snapshot and kgdb it
on my server, which runs HardenedBSD 11-STABLE.
This is the output:
(kgdb) list *uma_startup_count+0xe6
0x80e132
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #8 from Konstantin Belousov ---
(In reply to Daniel Kolesa from comment #7)
You do not need the crash dump to get the information I asked about. I suspect
that you can even use linux gdb.
--
You are receiving this mail becaus
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #7 from Daniel Kolesa ---
(In reply to Konstantin Belousov from comment #6)
The problem really is that I have no working FreeBSD setup on this hardware,
only an installer image; the filesystem in the image is read-only and ther
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227116
--- Comment #6 from Konstantin Belousov ---
(In reply to Daniel Kolesa from comment #5)
Yes, cluster on die creates two numa domains per socket, then multiplied by the
number of sockets.
Load the failing kernel into kgdb, then do 'list *um
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211713
--- Comment #58 from stan ---
following my comment #57, here more debug info in another context with same
hardware :
I am able to boot TrueOS-Desktop-201803131015 with
`hw.nvme.per_cpi_io_queues="0"` set in /boot/loader.conf. Everything wo
23 matches
Mail list logo
