Re: jail related inconsistencies in FreeBSD tools parameters

[Miroslav Lachman]

James Gritton wrote on 2018/06/26 20:42:

On 2018-06-23 12:58, Eitan Adler wrote:


[...]


I was thinking of a more generic one that does id or name. Now that I
think about it a bit more, C makes this kind of thing impossible to do
usefully.

That said, I'll still review and commit any patches to existing tools
to make them behave consistently.


Yes, jail_getid(3) works with either a numeric ID or a name.

I've added a patch to 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229266 for the four 
programs I've found that need help.  I've tested the easy ones (cpuset 
and sockstat).


Thank you very much. I really appreciate your neverending work on jails!
I hope it will be committed soon.

Kind regards
Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: jail related inconsistencies in FreeBSD tools parameters

[James Gritton]

On 2018-06-23 12:58, Eitan Adler wrote:

On 23 June 2018 at 08:50, James Gritton  wrote:

On 2018-06-23 09:45, Eitan Adler wrote:


On 23 June 2018 at 08:30, James Gritton  wrote:


On 2018-06-22 16:03, Miroslav Lachman wrote:



Chris H wrote on 2018/06/22 23:46:



On Fri, 22 Jun 2018 23:13:17 +0200 "Miroslav Lachman"
<000.f...@quip.cz>
said

I don't know if it is better to discuss it in jail@ or stable@ 
list so

a
do cross-post.

FreeBSD has many jail aware utilities but they are inconsistent 
in

taking JID as parameter.

For example "sockstat" takes -j JID "Show only sockets belonging 
to

the
specified jail ID" and it means numeric ID only.
On the other hand "ps" takes -J JID "This may be either the jid 
or

name
of the jail.  Use -J 0 to display only host processes."
The same apply for "top", it understands jid as a number or name 
of

the
jail too.
Then again "cpuset" takes only numerical ID of the jail...

Shouldn't it be consistent across all FreeBSD base utilities so 
all of

them can use numerical ID and name?



Good idea! Are you offering to create a patch? ;-)
It'd be my guess that given they weren't all created at the same 
time,

nor
the same individual; that (quite probably?) the "jail" additions 
were

also
added at different times, and by different people. So I'd imagine 
that
unless someone with a commit bit decides one day they'd like to 
take

that
on. Someone(tm) maybe you? will need to propose a patch. :-)




If I can understand C sources I will create the patch by myself
instead of just posting here. Unfortunately I am able to code in 
sh,

php and a bit of javascript and perl but no C. :)

Miroslav Lachman




Sure, a PR would be handy for this - it's a pretty simple thing to 
add,

and
consistency would indeed be a good move.



Agreed. I'll review and commit such patches. I'd like to see a single
function for taking a "id or name". Ideally it would live in a
library, perhaps libjail?



It already lives there: jail_getid(3)


I was thinking of a more generic one that does id or name. Now that I
think about it a bit more, C makes this kind of thing impossible to do
usefully.

That said, I'll still review and commit any patches to existing tools
to make them behave consistently.


Yes, jail_getid(3) works with either a numeric ID or a name.

I've added a patch to 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229266 for the four 
programs I've found that need help.  I've tested the easy ones (cpuset 
and sockstat).


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

Pós-Graduação SENAI | FATEC - MBA em Gestão de Projetos

[SENAI | FATEC - Faculdade SENAI]

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

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Pete French]

Gah! I my memory said it was /var/boot - so close :-) Thanks!

On 26/06/2018 15:22, Freddie Cash wrote:



On Tue, Jun 26, 2018, 5:33 AM Pete French, > wrote:



 > Also, please show the 100 first lines of the verbose boot dmesg
on this
 > machine.

the dmesg wraps around if I boot verbosely, but heres the contnets of
/var/log/messages from the time it starts to where it stops
talking about CPU specific stuff... if you need something else then
let me know - this is an easy machine to reboot and play about with.


/var/run/dmesg.boot is there for this various reason (dmesg buffer 
rolling over). :) It's the dmesg output for the current boot.


Cheers,
Freddie


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

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Freddie Cash]

On Tue, Jun 26, 2018, 5:33 AM Pete French, 
wrote:

>
> > Also, please show the 100 first lines of the verbose boot dmesg on this
> > machine.
>
> the dmesg wraps around if I boot verbosely, but heres the contnets of
> /var/log/messages from the time it starts to where it stops
> talking about CPU specific stuff... if you need something else then
> let me know - this is an easy machine to reboot and play about with.
>

/var/run/dmesg.boot is there for this various reason (dmesg buffer rolling
over). :) It's the dmesg output for the current boot.

Cheers,
Freddie

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

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Pete French]

> If you run without the script, with the same settings, do you experience
> problems ?

I have not tried this since the last BIOPS update which brought with it
the latest AEGSA version. Previously the machine would lock uop
if I enabled SMT though which is why looking at those settings
and cross referencing them to the erata was very interesting.

I just rebooted the machine to get you the log, and am going to
run without applyingthose fixes for the rest of the week to see how 
it goes though. Will let you know one way or the other on Friday,
and will do my best to lock it up before then.

> Also, please show the 100 first lines of the verbose boot dmesg on this
> machine.

the dmesg wraps around if I boot verbosely, but heres the contnets of
/var/log/messages from the time it starts to where it stops
talking about CPU specific stuff... if you need something else then
let me know - this is an easy machine to reboot and play about with.

-pete.

Jun 26 13:13:26 dilbert kernel: Table 'FACP' at 0xdd0fb6b8
Jun 26 13:13:26 dilbert kernel: Table 'APIC' at 0xdd0fb7d0
Jun 26 13:13:26 dilbert kernel: APIC: Found table at 0xdd0fb7d0
Jun 26 13:13:26 dilbert kernel: APIC: Using the MADT enumerator.
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 0 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 1 ACPI ID 2: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 1 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 2 ACPI ID 3: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 2 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 3 ACPI ID 4: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 3 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 4 ACPI ID 5: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 4 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 5 ACPI ID 6: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 5 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 6 ACPI ID 7: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 6 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 7 ACPI ID 8: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 7 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 8 ACPI ID 9: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 8 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 9 ACPI ID 10: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 9 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 10 ACPI ID 11: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 10 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 11 ACPI ID 12: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 11 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 12 ACPI ID 13: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 12 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 13 ACPI ID 14: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 13 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 14 ACPI ID 15: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 14 (AP)
Jun 26 13:13:26 dilbert kernel: MADT: Found CPU APIC ID 15 ACPI ID 16: enabled
Jun 26 13:13:26 dilbert kernel: SMP: Added CPU 15 (AP)
Jun 26 13:13:26 dilbert kernel: Copyright (c) 1992-2018 The FreeBSD Project.
Jun 26 13:13:26 dilbert kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 
1989, 1991, 1992, 1993, 1994
Jun 26 13:13:26 dilbert kernel: The Regents of the University of 
California. All rights reserved.
Jun 26 13:13:26 dilbert kernel: FreeBSD is a registered trademark of The 
FreeBSD Foundation.
Jun 26 13:13:26 dilbert kernel: FreeBSD 11.2-STABLE #0 r335659: Tue Jun 26 
10:47:47 BST 2018
Jun 26 13:13:26 dilbert kernel: 
petefre...@dilbert.london-internal.ingresso.co.uk:/usr/obj/usr/src/sys/GENERIC 
amd64
Jun 26 13:13:26 dilbert kernel: FreeBSD clang version 6.0.0 
(tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
Jun 26 13:13:26 dilbert kernel: Table 'FACP' at 0xdd0fb6b8
Jun 26 13:13:26 dilbert kernel: Table 'APIC' at 0xdd0fb7d0
Jun 26 13:13:26 dilbert kernel: Table 'FPDT' at 0xdd0fb8b0
Jun 26 13:13:26 dilbert kernel: Table 'FIDT' at 0xdd0fb8f8
Jun 26 13:13:26 dilbert kernel: Table 'SSDT' at 0xdd0fb998
Jun 26 13:13:26 dilbert kernel: Table 'SSDT' at 0xdd104630
Jun 26 13:13:26 dilbert kernel: Table 'CRAT' at 0xdd106948
Jun 26 13:13:26 dilbert kernel: Table 'CDIT' at 0xdd107898
Jun 26 13:13:26 dilbert kernel: Table 'SSDT' at 0xdd1078c8
Jun 26 13:13:26 dilbert kernel: Table 'MCFG' at 0xdd10a660
Jun 26 13:13:26 dilbert kernel: Table 'HPET' at 0xdd10a6a0
Jun 26 13:13:26 dilbert kernel: Table 'SSDT' at 0xdd10a6d8
Jun 26 13:13:26 dilbert kernel: Table 'UEFI' at 0xdd10a700
Jun 26 13:13:26 dilbert kernel: Table 'IVRS' at 0xdd10a748
Jun 26 13:13:26 dilbert kernel: Table 'SSDT' at 0xdd10a818
Jun 26 13:13:26 dilbert kernel: Table 'SSDT' at 0xdd10a910
Jun 26 13:13:26 

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Konstantin Belousov]

On Tue, Jun 26, 2018 at 11:31:26AM +0100, Pete French wrote:
> > On 06/18/2018 09:34, Pete French wrote:
> > > Preseumably in the slightly longer term these workarounds go into the
> > > actual kernel if it detects Ryzen ?
> >
> > Yes, Kostik said he would code this into the kernel after he gets enough
> > feedback.
> 
> So, I've been running with the sysctl and cputl fixes from
> https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069799.html
> for a couple of weeks now, with all the default settings back on (including
> SMT) and it now completely stable, so consider this one more point of feedback

If you run without the script, with the same settings, do you experience
problems ?

Also, please show the 100 first lines of the verbose boot dmesg on this
machine.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Pete French]

> On 06/18/2018 09:34, Pete French wrote:
> > Preseumably in the slightly longer term these workarounds go into the
> > actual kernel if it detects Ryzen ?
>
> Yes, Kostik said he would code this into the kernel after he gets enough
> feedback.

So, I've been running with the sysctl and cputl fixes from
https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069799.html
for a couple of weeks now, with all the default settings back on (including
SMT) and it now completely stable, so consider this one more point of feedback
for incorporating thois in the the kernel :-)

cheers,

-pete.

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

[Bug 228535] emulators/virtualbox-ose-kmod: 11.2-BETA3 - kldload vboxdrv leads to panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228535

m...@janh.de changed:

   What|Removed |Added

 CC||m...@janh.de

--- Comment #9 from m...@janh.de ---
I have hit this problem, too.

For me, it is different than previous problems with kernel modules from ports
after minor FreeBSD version updates: There were modules that would not load,
but very rarely an old module would lead to a panic.

I have vboxdrv_load="YES" in /boot/loader.conf and I could not immediately tell
what caused the panic. Obviously, single user mode would not work, either, but
loading the old kernel did.

Having freebsd-update print a warning in the end to update ports with kernel
modules would not help in this case, either: The panic already happens after
installing the kernel and rebooting and you cannot even install the userland.
If there was such a warning, it would have to be with the first prompt for a
reboot. Rebuilding ports at that time would not be the best idea, either, since
the userland is still old. The message would have to tell you to disable
everything from ports in /boot/loader.conf, /etc/rc.conf|kld_list, and similar
places.

Besides emulators/virtualbox-ose-kmod, I also had to rebuild x11/nvidia-driver,
but it was nicer: There was no crash, xorg simply would not start.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"