Re: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works

[Adding some vintage information for a loader that allowed a native boot.] On 2018-Oct-20, at 4:00 AM, Mark Millard wrote: > I attempted to jump from head -r334014 to -r339076 > on a threadripper 1950X board and the native > FreeBSD boot failed very early. (Hyper-V use of > the same media did no

Re: Page fault in midi/sequencer.c

On Sun, Oct 21, 2018 at 12:59 AM Peter Holm wrote: > I can trigger this on 13.0-CURRENT r339445 with a non-root test program: > > Calling uiomove() with the following non-sleepable locks held: > exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @ > dev/sound/midi/sequencer.c

Page fault in midi/sequencer.c

I can trigger this on 13.0-CURRENT r339445 with a non-root test program: Calling uiomove() with the following non-sleepable locks held: exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @ dev/sound/midi/sequencer.c:952 stack backtrace: #0 0x80bfe263 at witness_debugg

FreeBSD 12.0-BETA1 Now Available

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The first BETA build of the 12.0-RELEASE release cycle is now available. Installation images are available for: o 12.0-BETA1 amd64 GENERIC o 12.0-BETA1 i386 GENERIC o 12.0-BETA1 powerpc GENERIC o 12.0-BETA1 powerpc64 GENERIC64 o 12.0-BETA1 powerpcs

Re: fuser does not list id of processes that have a file

>> I tested on zfs, perhaps there is something extra going on on other filesystems. I tested on UFS2, and I get nothing out of the patched fuser.c. On Thu, Oct 18, 2018 at 11:24 PM Mateusz Guzik wrote: > On 10/17/18, Ali Abdallah wrote: > >> diff --git a/usr.bin/fstat/fuser.c b/usr.bin/fstat/f

head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works

I attempted to jump from head -r334014 to -r339076 on a threadripper 1950X board and the native FreeBSD boot failed very early. (Hyper-V use of the same media did not have this issue.) But copying over an older /boot/loader from another storage device with a FreeBSD head version that has not been

dmesg submission service -- please submit today

Thank you for asking; I used the one-liner in hopes that it helps. I presume the same areas can be used from a release/stable/current boot media to gather it from another machine not running FreeBSD presently but will be a likely future goal so will try to get it submitted too. I would apprecia

DRM: radeonkms no longer usable following a switch to stable, FreeBSD 12.0-BETA1 r339438

On 20/10/2018 08:51, Hans Petter Selasky wrote: > I recommend building these modules from source, /usr/src which match you > currently installed kernel! Thanks, I did build from source, and the poudriere jail was just a _little_ behind. Not ideal, I know :-) OT, I aimed to update the jai

Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

On 2018-Oct-20, at 1:39 AM, Mark Millard wrote: > I attempted to jump from head -r334014 to -r339076 > on a threadripper 1950X board and the boot fails. > This is both native booting and under Hyper-V, > same machine and root file system in both cases. I did my investigation under Hyper-V aft

head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

I attempted to jump from head -r334014 to -r339076 on a threadripper 1950X board and the boot fails. This is both native booting and under Hyper-V, same machine and root file system in both cases. It fails just after the FreeBSD/SMP lines, reporting "kernel trap 9 with interrupts disabled". It fa

Re: boot message: sendmsg on igb0: No buffer space available

On Fri, 19 Oct 2018, at 19:46, Mike Tancsa wrote: > Feeding entropy: . > lo0: link state changed to UP > sendmsg on igb0: No buffer space available > igb0: link state changed to UP > cxl1: link state changed to UP > Starting Network: lo0 igb0 cxl0 cxl1. I’m reasonably sure that this occurs when dh

Re: DRM: radeonkms … can not be unloaded (kernel panic)) …

On 10/20/18 3:10 AM, Graham Perrin wrote: On 20/10/2018 00:01, Graham Perrin wrote: kldunload radeonkms – results in a kernel panic. Found, at under 'drm-devel-kmod g20180822 screen freeze': … normally you never

SCSI and dmesg

Greetings a few weeks ago I pointed people to the nycbug dmesg service. I said I was looking at data to drive SCSI retirement. I've gatherd some preliminary data, which I've uploaded to https://github.com/bsdimp/device-data/blob/master/cam.md along with some preliminary notions of disposition for