I decided that it was better to fix our stdatomic.h, so I have a review
to do that at https://reviews.freebsd.org/D16585
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To
approach might be to fix sys/cdefs.h
and sys/stdatomic.h to actually work with modern GCC by having them not
use the struct for the _GCC_ATOMICS case, only for the _SYNC case.
I think that would fix all of the cases.
--
John Baldwin
___
freebsd-curre
search order for the
> directories for now.
I finally got the approval 2 days ago to remove float.h from amd64-gcc so
you shouldn't need this reverted anymore once the OFED thing is
straightened out.
--
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"
On 7/26/18 10:55 AM, Mark Millard wrote:
>
>
> On 2018-Jul-26, at 10:21 AM, John Baldwin wrote:
>
>> On 7/25/18 6:52 PM, Mark Millard wrote:
>>>
>>>
>>> On 2018-Jul-25, at 2:10 PM, Mark Millard wrote:
>>>
>>>
>>>
>>
On 7/25/18 6:52 PM, Mark Millard wrote:
>
>
> On 2018-Jul-25, at 2:10 PM, Mark Millard wrote:
>
>
>
>> On 2018-Jul-25, at 10:09 AM, Mark Millard wrote:
>>
>>> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote:
>>>
>>>> On 7/24/18 11:
On 7/25/18 10:09 AM, Mark Millard wrote:
>
>
> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote:
>
>> On 7/24/18 11:39 PM, Mark Millard wrote:
>>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote:
>>>
>>>> https://ci.freebsd.org/job/FreeBSD-hea
sts of _Atomic(int) with GCC don't trigger those
failures when using its stdatomic.h, so there is probably something else
going on with kernel includes being used while building the library,
etc. The last time we had this issue with stdarg.h it was because a
header shared between the kernel and userland always used ''
which is correct for the kernel but not for userland.
--
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"
On 7/5/18 12:36 PM, Konstantin Belousov wrote:
> On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky wrote:
>> On 07/05/18 20:59, Hans Petter Selasky wrote:
>>> On 07/05/18 19:48, Pete Wright wrote:
>>>>
>>>>
>>>> On 07/05/2018 10
On 7/3/18 5:10 PM, Pete Wright wrote:
>
>
> On 07/03/2018 15:56, John Baldwin wrote:
>> On 7/3/18 3:34 PM, Pete Wright wrote:
>>>
>>> On 07/03/2018 15:29, John Baldwin wrote:
>>>> That seems like kgdb is looking at the wrong CPU. Can you use
>>
gister operand). You could also try using
just 'r' to always
force the use of a register. It would be less optimal than "er" but should
function correctly.
> On Tue, Jul 3, 2018 at 15:38 Pete Wright <mailto:p...@nomadlogic.org>> wrote:
>
>
>
>
On 7/3/18 3:34 PM, Pete Wright wrote:
>
>
> On 07/03/2018 15:29, John Baldwin wrote:
>> That seems like kgdb is looking at the wrong CPU. Can you use
>> 'info threads' and look for threads not stopped in 'sched_switch'
>> and get their backtraces?
On 7/3/18 3:20 PM, Pete Wright wrote:
>
>
> On 07/03/2018 15:12, Pete Wright wrote:
>>
>>
>> On 07/03/2018 14:17, Pete Wright wrote:
>>>
>>>
>>> On 07/03/2018 12:02, John Baldwin wrote:
>>>> On 7/3/18 11:28 AM, Niclas Zeising wr
1,%0", "ir", v);
-ATOMIC_ASM(set, long, "orq %1,%0", "ir", v);
-ATOMIC_ASM(clear,long, "andq %1,%0", "ir", ~v);
-ATOMIC_ASM(add, long, "addq %1,%0", "ir", v);
-ATOMIC_ASM(subtract, long, "subq %1,%0", "ir", v);
+ATOMIC_ASM(set, long, "orq %1,%0", "er", v);
+ATOMIC_ASM(clear,long, "andq %1,%0", "er", ~v);
+ATOMIC_ASM(add, long, "addq %1,%0", "er", v);
+ATOMIC_ASM(subtract, long, "subq %1,%0", "er", v);
#defineATOMIC_LOADSTORE(TYPE) \
ATOMIC_LOAD(TYPE); \
--
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"
On 6/30/18 10:19 AM, Mark Millard wrote:
>
>
> On 2018-Jun-30, at 10:04 AM, Mark Millard wrote:
>
>> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote:
>>
>>> On 6/30/18 9:17 AM, Mark Millard wrote:
>>>> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote
On 6/30/18 9:17 AM, Mark Millard wrote:
> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote:
>
>> On 6/29/18 2:37 PM, Mark Millard wrote:
>>> [I expect this is more than just amd64-gcc related but that is all
>>> that ci.freebsd.org normally builds via a devel/*-g
ent on
LDBL_MANT_DIG.
--
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"
e
should really be fixing our tree to work with compiler-provided language
headers when at all possible. It's not clear to me if amd64 should be
using the compiler provided values of things like LDBL_MIN/MAX either btw.
--
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"
c: 0.4_1
>> amd64-gcc: 6.4.0
>> mpfr: 4.0.1
>> gmp: 6.1.2
>> mpc: 1.1.0_1
>> amd64-binutils: 2.30_3,1
>
> and amd64-gcc being 6.4.0 (via powerpc64-gcc) is from -r466834
> (via looking up in https://svnweb.freebsd.org/ports/head/devel/ ).
different
> timecounter:
> https://lists.freebsd.org/pipermail/freebsd-cloud/2017-January/80.html
I suspect you are probably right that we should just "trust" TSC frequencies
provided by a hypervisor. We could perhaps choose to whitelist hypervisors
known to provide accurate valu
some sort of driver for the GPU that knows
how to turn the display back on. That isn't a portable thing, it's
GPU-specific.
You could perhaps write smaller drivers that only support resume and not
graphics acceleration, but that doesn't seem trivial.
--
John Baldwin
_
gt; inf = 0x80442de80
> old_chain = 0x804431820
> ti = 0x7fffd550
> kt = 0x0
> nkvm = 0x804363800
> temp = 0x8047f33b0 "/home/eax/crashes/aes_gpault_crash/vmcore.2"
> kernel = 0x8043dec80 "/home/eax/crashes/aes_gpault_crash/kernel/kernel"
> filename
an 256 interrupt pins on I/O
APICs, so IRQ 256 is already reserved for use by one of those
interrupt pins. The real fix is that I need to make FIRST_MSI_INT
dynamic instead of a constant and just define it as the first free IRQ
after the I/O APICs have probed.
--
John Baldwin
___
On Tuesday, April 17, 2018 10:15:53 PM Vitalij Satanivskij wrote:
> Dear John
>
> I'm try patch with no success
>
> http://hell.ukr.net/panic/recorder_patch165.webm
>
> Also I'm enable verbose boot and record boot process (hpet was disabled so
> cra
My laptop running recent head panicked this morning, apparently from hitting
a key to stop the screensaver (at which point xscreensaver prompts for a
password to unlock).
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https
On Tuesday, April 17, 2018 10:01:41 AM John Baldwin wrote:
> My laptop running recent head panicked this morning, apparently from hitting
> a key to stop the screensaver (at which point xscreensaver prompts for a
> password to unlock).
(Sorry, buggy mail client sent this early)
panic
si: 0
>
> If one of this parameters not set as described system not boot ^(
Please try the patch from here https://reviews.freebsd.org/P165
--
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"
am using a patched bhyve that uses cap_ioctls_limit() on a listen
socket (so the caps will be copied to the new socket during accept()).
I'll see if I can't come up with a simpler program to reproduce this.
--
John Baldwin
___
freebsd-curren
yper-V?
That seems like an odd device to have for an AMD machine. I suspect that this
has never
worked and the module started auto-loading due to devmatch.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/
his is probably to have linux_vdso32.c and
linux_vdso64.c that #include linux_vdso.c after setting
ELF_WORD_SIZE similar to how sys/kern/imgact_elf.c works.
Then the COMPAT_LINUX and linux64.ko modules would include
linux_vdso64.c and COMPAT_LINUX32 and linux32.ko modules
(and linux.ko on i386) would
s_timer
4751 kernel`key_timehandler
5286 kernel`nd6_timer
6700 kernel`usb_power_wdog
7341 kernel`pfslowtimo
19607 kernel`tcp_timer_delack
20273 dtrace.ko`dtrace_state_deadman
32262 kernel`sleepq_timeout
You can use this to figure out which timer events are using CPU in the
softclock thread/proc
to run svnlite cleanup /ext/ports until svnlite stops bailing out. When
newfs was written, I passed -t to it to enable trim, which seems to make a
difference on this for deletes but not writes. Can anyone please suggest
anything I can so to speed up disk i/o? And is async being applied
FreeBSD recently introduced an updated Code of Conduct that developers and
members must adhere to. There has been much backlash online about it and
about introducing identity politics into a technical OS project in general.
The Code of Conduct was adopted from the "Geek Feminism" wiki's version,
wh
On Thursday, March 01, 2018 02:02:58 PM Konstantin Belousov wrote:
> On Wed, Feb 28, 2018 at 03:32:43PM -0800, John Baldwin wrote:
> > On Wednesday, February 28, 2018 09:45:47 PM Konstantin Belousov wrote:
> > > On Wed, Feb 28, 2018 at 10:57:53AM -0800, John Baldwin wrote:
On Wednesday, February 28, 2018 09:45:47 PM Konstantin Belousov wrote:
> On Wed, Feb 28, 2018 at 10:57:53AM -0800, John Baldwin wrote:
> > On Tuesday, February 20, 2018 10:19:02 AM Conrad Meyer wrote:
> > > On Mon, Feb 19, 2018 at 2:38 PM, Ronald Klop wrote:
> > > >
e relinking of everything when changes).
This matters for more than just pkg as the kernel also looks at the embedded
__FreeBSD_version in binaries to make decisions about compat shims to enable
(grep for P_OSREL in sys/).
--
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"
2
make[2]: stopped in /storage/usr/src
1 error
make[2]: stopped in /storage/usr/src
*** [_bootstrap-tools] Error code 2
make[1]: stopped in /storage/usr/src
1 error
make[1]: stopped in /storage/usr/src
*** [buildworld] Error code 2
make: stopped in /storage/usr/src
1 error
make: stopped in /storage/usr/src
#
thanks,
--
John
tech-li...@zyxst.net
___
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"
On Monday, February 12, 2018 02:31:46 PM Warner Losh wrote:
> On Mon, Feb 12, 2018 at 10:12 AM, John Baldwin wrote:
>
> > On Monday, February 12, 2018 08:27:27 AM Warner Losh wrote:
> > > Greetings,
> > >
> > > As you may know, the Lua (http://www.l
, and the
second seems a bit fraught with peril as well if the application is
expecting the non-COW'd file to be in sync with other files in the system
since presumably non-COW'd files couldn't be snapshotted, etc.
--
John Baldwin
___
fre
FI case we probably have lots
of room, but for the non-EFI case we are constrained to 0xa - 0xa000
for the text/data/bss and stack (in some cases like PXE booting the top
can be lower than 0xa). I'm not sure if we have any other platforms
with similar memory constraints.
--
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"
> On Feb 7, 2018, at 6:07 AM, Maurizio Vairani wrote:
>
> 2018-02-06 23:02 GMT+01:00 John Nielsen :
> > On Feb 6, 2018, at 11:50 AM, Ian Lepore wrote:
> >
> > On Tue, 2018-02-06 at 11:33 -0700, John Nielsen wrote:
> >>
> >> Apparently sending a
> On Feb 6, 2018, at 11:50 AM, Ian Lepore wrote:
>
> On Tue, 2018-02-06 at 11:33 -0700, John Nielsen wrote:
>>
>> Apparently sending a NULL socket pointer to ifioctl hasn't worked
>> since this commit in 2011:
>> https://svnweb.freebsd.org/base?view=revisi
> On Feb 6, 2018, at 10:54 AM, John Nielsen wrote:
>
>>
>> On Feb 4, 2018, at 2:50 AM, Maurizio Vairani wrote:
>>
>> 2018-01-29 18:38 GMT+01:00 John Nielsen :
>> [ resending from correct email address ]
>>
>>> On Jan 29, 2018, at 6:05 AM,
> On Feb 4, 2018, at 2:50 AM, Maurizio Vairani wrote:
>
> 2018-01-29 18:38 GMT+01:00 John Nielsen :
> [ resending from correct email address ]
>
>> On Jan 29, 2018, at 6:05 AM, Maurizio Vairani wrote:
>>
>> I am running
>> # uname
>> -a
>>
> On Feb 4, 2018, at 2:50 AM, Maurizio Vairani wrote:
>
> 2018-01-29 18:38 GMT+01:00 John Nielsen :
> [ resending from correct email address ]
>
>> On Jan 29, 2018, at 6:05 AM, Maurizio Vairani wrote:
>>
>> I am running
>> # uname
>> -a
>>
/freebsd/freebsd32.h)
--
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"
[ resending from correct email address ]
> On Jan 29, 2018, at 6:05 AM, Maurizio Vairani wrote:
>
> I am running
> # uname
> -a
>
> FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
> UTC 2018
> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> On Jan 27, 2018, at 9:20 AM, Ian Lepore wrote:
>
> On Fri, 2018-01-26 at 23:20 -0700, John Nielsen wrote:
>>>
>>> On Jan 26, 2018, at 9:42 PM, John Nielsen wrote:
>>>
>>>>
>>>> [...]
>>> --- iscsi.o ---
>>> isc
> On Jan 26, 2018, at 9:42 PM, John Nielsen wrote:
>
>> On Jan 26, 2018, at 10:35 AM, Ian Lepore wrote:
>>
>> On Fri, 2018-01-26 at 10:00 -0700, John Nielsen wrote:
>>>>
>>>> On Jan 26, 2018, at 3:37 AM, Maurizio Vairani >>> om&
> On Jan 26, 2018, at 10:35 AM, Ian Lepore wrote:
>
> On Fri, 2018-01-26 at 10:00 -0700, John Nielsen wrote:
>>>
>>> On Jan 26, 2018, at 3:37 AM, Maurizio Vairani >> om> wrote:
>>>
>>> 2018-01-24 17:19 GMT+01:00 Warner Losh :
>>&
> On Jan 26, 2018, at 3:37 AM, Maurizio Vairani wrote:
>
> 2018-01-24 17:19 GMT+01:00 Warner Losh :
>
>
> On Wed, Jan 24, 2018 at 3:12 AM, Maurizio Vairani
> wrote:
> On this CURRENT snapshot
> # uname -a
> FreeBSD freebsd12 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r327788: Wed Jan 10
> 22:55:40
at at most 2048 threads
* will hold LOCK_NCHILDREN locks. We handle failure ok, and we should
* probably be safe for the most part, but it's still a SWAG.
*/
#define LOCK_NCHILDREN 5
#define LOCK_CHILDCOUNT 2048
Probably the '2048' (max number of concurren
gt; cause they are wrapping in vlan tags thus the bridge
> never learns all the mac addresses, but this is just a
> guess.
I finally figured this out w/ tcpdump, as tcpdump was showing the
packets going out em0.14 (in my case), but the reply was never making
it back to em0.14. I was seein
with patch, if I set LINK0, it should work
w/ original configuration), I'll test and commit the patch.
Otherwise, please submit another fix.
Thanks.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do,
ng
forever. I could fix the tests to check for the status in the kinfo_proc.
I've no idea if there are other programs aside from tests that depend on
this behavior that are also broken though. I feel like I copied that
approach from some other bit of code when writing t
t; kernel structures are changing, which means NVIDIA needs to recompile
> their binary blob aswell!
The blob does not generally use FreeBSD-specific structures. Part of
the driver is source and that interfaces with FreeBSD's APIs to implement
shim
On Wednesday, October 18, 2017 04:40:22 PM Glen Barber wrote:
> On Wed, Oct 18, 2017 at 09:28:40AM -0700, John Baldwin wrote:
> > On Wednesday, October 18, 2017 03:01:55 PM Glen Barber wrote:
> > > On Wed, Oct 18, 2017 at 07:49:00AM -0700, John Baldwin wrote:
> > > >
On Wednesday, October 18, 2017 03:01:55 PM Glen Barber wrote:
> On Wed, Oct 18, 2017 at 07:49:00AM -0700, John Baldwin wrote:
> > On Tuesday, October 17, 2017 11:57:44 AM David Boyd wrote:
> > > The FreeBSD-12.0-CURRENT-amd64-20171012-r324542.vmdk image displays
> > > ma
reating the snapshot images wasn't updated to generate
cg checksums when creating the initial filesystem. Glen, do you know which
tool (makefs or something else?) is used to generate the UFS filesystem
in VM images for snapshots? (In this case it appears to be a .vmdk image)
--
John Baldwin
_
for a panic we really
need the panic message in addition to the stack trace.
--
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"
ed by
> >>> clang,
> >>> > but not super well. For FreeBSD 12, we're getting close for everything
> >>> > except sparc64 (whose fate has not yet been finally decided).
> >>> >
> >>> > So for the popular ar
.0 [GDB v8.0 for FreeBSD]
> Copyright (C) 2017 Free Software Foundation, Inc.
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug...done.
> ABI doesn't support a vmcore tar
/lib/libthr/thread/thr_create.c:289
> #9 0x7fffdddf7000 in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7fffddff7000
Your backtrace shows it crashed during thread exit inside of libthr, not in
lldb itself. Also, it seems you are using libgcc_s from external gcc rather
On Thursday, September 14, 2017 03:19:29 PM Stephen Hurd wrote:
> John Baldwin wrote:
> > igb0: port 0xe020-0xe03f mem
> > 0xfb22-0xfb23,0xfb244000-0xfb247fff irq 43 at device 0.0 on pci6
> > igb0: attach_pre capping queues at 8
> > igb0: using 1024 tx descript
igb0: trying 4 rx queues 4 tx queues
igb0: Using MSIX interrupts with 9 vectors
igb0: allocated for 4 tx_queues
igb0: allocated for 4 rx_
b50
> > mi_startup() at mi_startup+0x9c/frame 0x82193b70
> > btext() at btext+0x2c
> > Uptime: 1s
>
> I bisected revisions, and the last working is r322988.
> This machine is E5-2660 v4@ based.
If you just revert r322988 on a newer tree does it work ok?
--
John
y: 255
> container lock: sched lock 0 (0x81c39800)
> db> show lock 0x81c39800
> class: spin mutex
> name: sched lock 0
> flags: {SPIN, RECURSE}
> state: {OWNED}
> owner: 0xf80128cdb560 (tid 100028, pid 11, "idle: cpu25")
>
> Regards,
> Kevin
--
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"
down.
Note that once memory is placed in swap, it won't be pulled back in until
some thread or process actually needs it. If nothing needs the memory it
doesn't hurt to just leave it out on swap. It might also mean that the
memory freed up by your temporary memory pressure from your g
sue with the bhyve capsicum work. I've cc'd Allan
and Peter who might be able to help track that down. It might be useful
if you can run bhyve under ktrace, e.g.:
sudo ktrace -i -t p sh /usr/share/examples/bhyve/vmrun.sh -d .raw vm-
And then post the output of 'sudo kdump'
--
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"
On Thursday, August 03, 2017 09:57:15 AM Andriy Gapon wrote:
> On 02/08/2017 18:49, John Baldwin wrote:
> > sysctl nodes are created explicitly via linker_file_register_sysctls, not
> > via
> > SYSINITs, so you can't order them with respect to other init functions.
On Wednesday, August 02, 2017 06:53:54 PM Hans Petter Selasky wrote:
> On 08/02/17 17:49, John Baldwin wrote:
> > On Wednesday, August 02, 2017 12:39:36 PM Hans Petter Selasky wrote:
> >> On 08/02/17 12:13, Andriy Gapon wrote:
> >>>
> >>> As far as I und
On Wednesday, August 02, 2017 10:14:01 AM Andriy Gapon wrote:
> On 02/08/2017 04:00, Ngie Cooper (yaneurabeya) wrote:
> >
> >> On Aug 1, 2017, at 09:21, John Baldwin wrote:
> >>
> >> On Tuesday, August 01, 2017 09:47:41 AM Andriy Gapon wrote:
> >
ted explicitly via linker_file_register_sysctls, not via
SYSINITs, so you can't order them with respect to other init functions.
I think Andriy's suggestion of doing sysctls "inside" sysinits (so they are
registered last and unregistered first) is probably better than the current
s
the like. I forgot to
send this to Andriy earlier, but here is the fix I'm using:
https://github.com/freebsd/freebsd/commit/574dc95cf8272e16f6d44aff6cb4e08dede08886
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.o
clue. nlm_syscall is dying with EFAULT. The last
argument is a pointer to an array of char * pointers, and the only way
I can see it dying is if it fails to copyin() one of the strings pointed
to by those pointers. You could try running rpc.lockd under gdb from
ports and setting a breakpoint o
elevant HAL modules before you load if_ath /
> if_ath_pci otherwise it won't find your hardware.
>
> I realise this is a bit of a POLA change, but I'd like to get it into
> -HEAD before FreeBSD-12 is cut.
Why not have if_ath
blocks like boot2,
> just that we can not use those blocks for more universal cases and eventually
> those special cases will diminish.
Yes, the BSD label stuff is stuck with a smaller size, but GPT should support
unified bootstraps.
--
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"
On Sunday, April 30, 2017 09:02:30 AM Sepherosa Ziehau wrote:
> On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin wrote:
> > On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
> >> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin wrote:
> >> > On Wednesd
On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin wrote:
> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin wrote:
> >> > On Thursd
On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin wrote:
> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> >> > From: John Baldwin [mailto:j...@freebsd.org]
> >> > Sent: Thursday, April 2
On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> > From: John Baldwin [mailto:j...@freebsd.org]
> > Sent: Thursday, April 20, 2017 02:34
> > > Can we add the support of "ACPI0004" with the below one-line change?
> > >
> > > acpi_sysr
in the ACPI
6.1 spec it's not quite clear that ACPI0004 is like that? In particular, it
seems that 004 should only allow direct children to suballocate? This change
might work, but it will allow more devices to allocate the ranges in _CRS
than otherwise.
Do you have an acpidump from a guest
; ffs_vnops.c:280
> vfs_bio.c:3500
> ufs_dirhash.c:281
> vfs_syscalls.c:3364
>
> [some above also in dmesg, most in /var/log/messages...
There are several known LORs in the VFS/UFS code that are either false
positives or ones that have effectively been harmless.
--
John Baldwin
___
; have_ia_ref =
> ifp =
> ia =
> isbroadcast =
> ---Type to continue, or q to quit---
> gw =
The panic is in the LLE_FREE() here:
/*
* If there is a cached route,
kdbg for a few
> months anyway...
Do you have a core.txt.0 file? If so it should contain a stack trace from
kgdb which is the first thing that would be useful to obtain.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freeb
I enlarge the terminal to 86 columns the output is correct again.
> This happens in urxvt (my default), rxvt and in xterm.
>
> Some regression?
I've noticed this same "feature" after the upgrade to 1.10. If possible
please let it fit in 80 cols again. :)
--
John Baldwin
hy its
> none0.
I think this device is supported by the intpm(4) driver?
--
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"
these
> two are being updated together, so I don't really see by the code why
> they might differ. Could someone please take a look at it, with more
> experience in the NFS code? -czg
Can you print out the two mtimes? I wonder if what's happening is that
your server uses differe
ng" and then
> "running" states.
>
> I would like to fix that, but not sure how to do that best.
> One idea is to move the mi_switch() trace closer to the cpu_switch() call
> similarly to DTrace sched:cpu-off and sched:cpu-on probes.
I think this is the
SC_tc() got called timecounter is not yet tsc_timecounter.
> >> > inittimecounter() later will do the work calling tc_windup().
> >> >
> >>
> >> You mean, just this
> >> - if (cpu_deepest_sleep >= 2 && cpu_vendor_id == CPU_V
st moving order of init_TSC_tc() would not help, since tsc checks smp
> > consistency, which requires started APs. Try this for now, but might
> > be John has better idea how to handle the issue. You might need to add
> > some extern declarations for the patch to compile.
> &
On Tuesday, January 17, 2017 01:46:31 PM Jakob Alvermark wrote:
> On Fri, January 13, 2017 22:46, Jakob Alvermark wrote:
> > On Fri, January 13, 2017 19:44, John Baldwin wrote:
> >
> >> On Friday, January 13, 2017 09:58:01 AM Jakob Alvermark wrote:
> >>
> >
On Wednesday, January 18, 2017 09:00:52 AM Hans Petter Selasky wrote:
> On 01/18/17 02:18, John Baldwin wrote:
> > You might still want to adjust 'nextevent' to schedule the next interrupt
> > to be sooner than 'timerperiod' though. You could just set 'next
On Tuesday, January 17, 2017 05:08:58 PM Cy Schubert wrote:
> In message <1492450.xzfnz8z...@ralph.baldwin.cx>, John Baldwin writes:
> > On Tuesday, January 17, 2017 12:53:19 PM Cy Schubert wrote:
> > > In message , Hans
> > > Petter
> > > Sela
> >
update of these fields? Can they be
> written simultaneously by configtimer() and cpu_new_callout()?
Both functions do ET_HW_LOCK() of DPCPU_PTR(timerstate).
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailm
+*/
> + state->nextcall = SBT_MAX;
> + state->nextcallopt = now + 1;
> hardclock_sync(cpu);
> }
> busy = 0;
>
>
> Then there is no proble
eatedly at:
>
> Jan 17 11:55:16 slippy kernel: cd0: Attempt to query device size failed:
> NOT READY, Medium not present - tray closed
So it panics and reboots after this?
--
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"
On Tuesday, January 17, 2017 08:31:28 PM Hans Petter Selasky wrote:
> Hi,
>
> On 01/17/17 20:00, John Baldwin wrote:
> >>
> >> Does this matter for the first tick? How often is configtimer() called?
> >
> > As I said, it is called at runtime when profcloc
On Tuesday, January 17, 2017 07:04:15 PM Hans Petter Selasky wrote:
> On 01/17/17 16:50, John Baldwin wrote:
> > On Monday, January 16, 2017 10:10:16 PM Hans Petter Selasky wrote:
> >> On 01/16/17 20:31, John Baldwin wrote:
> >>> On Monday, January 16, 2017 04:51:4
On Monday, January 16, 2017 10:10:16 PM Hans Petter Selasky wrote:
> On 01/16/17 20:31, John Baldwin wrote:
> > On Monday, January 16, 2017 04:51:42 PM Hans Petter Selasky wrote:
> >> Hi,
> >>
> >> When booting I observe an additional 30-second delay after this
301 - 400 of 4747 matches
Mail list logo
