date:20181020

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

2018-10-20 Thread Mark Millard

[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 not have this issue.)
> 
> But copying over an older /boot/loader from another
> storage device with a FreeBSD head version that has
> not been updated yet got past the problem being
> reported here. (For other reasons, the kernel has
> been moved back to -r338804 --and with that,
> and the older /boot/loader, the 1950X native-boots
> FreeBSD all the way just fine.)

I found one /boot/loader.old that was dated
in the update'd file system as 2018-May 20,
instead of 2018-Apr-03 from the older file
system. May 20 would apparently mean a little
below -r334014 . It native-booted okay, as did
the April one.

[I do not know how to inspect a /boot/loader*
to find out what -r?? it is from.]

Unfortunately, I had done more than one -r339076
install from -r334014 before rebooting and
no -r334014 loaders were still present:
the other *.old files from a few minutes before
the ones I had the boot problem with.

I might be able to extract loaders from various:

https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/base.txz

materials and try substituting them in order to
narrow the range for works -> fails. If I can,
this likely would take a fair amount of time in
my context.

Other notes:

It turns out that only Hyper-V based use needed
a -r334804 kernel: Native booting with the older
loaders and newer kernels works fine.

Windows 10 Pro 64bit also has no problems
booting and operating the machine.

The native-boot problem does seem to be freeBSD
loader-vintage specific.

> For the BTX failure the display ends up with
> (hand transcribed, ". . ." for an omission):
> 
> BTX loader 1.00 BTX version is 1.02
> Console: internal video/keyboard
> BIOS drive C: is disk0
> . . .
> BIOS drive P: is disk13
> -
> int=  err=  efl=00010246  eip=96fd
> eax=74d48000  ebx=74d4e5e0  ecx=0011  edx=
> esi=74d4e380  edi=74d4e5b0  ebp=00091da0  esp=00091d60
> cs=002b  ds=0033  es=0033fs=0033  gs=0033  ss=0033
> cs:eip=66 f7 77 04 0f b7 c0 89-44 24 0c 89 5c 24 04 8b
>   45 08 89 04 24 83 64 24-10 00 c7 44 24 08 01 00
> ss:esp=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
>   00 00 00 00 00 00 00 00-f0 1d 89 00 00 00 00 00
> BTX halted

I've no clue what of that output might be loader vintage
specific. It might not be of use without knowing the
exact build of the loader.

> The board is a GIGABYTE X399 AORUS Gaming 7 (rev 1.0).
> It has 96 GiBytes of ECC RAM, just 6 DIMMs installed.

For reference for the board's BIOS:

Version: F11e
Dated: 2018-Sep-17
Description: Update AGESA 1.1.0.1a

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: Page fault in midi/sequencer.c

2018-10-20 Thread blubee blubeeme

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:952
> stack backtrace:
> #0 0x80bfe263 at witness_debugger+0x73
> #1 0x80bff1b8 at witness_warn+0x448
> #2 0x80bf6a91 at uiomove_faultflag+0x71
> #3 0x809439e6 at mseq_write+0x4c6
> #4 0x80a4f725 at devfs_write_f+0x185
> #5 0x80c02a87 at dofilewrite+0x97
> #6 0x80c0287f at kern_pwritev+0x5f
> #7 0x80c0277d at sys_pwrite+0x8d
> #8 0x81070af7 at amd64_syscall+0x2a7
> #9 0x8104a4ad at fast_syscall_common+0x101
> Kernel page fault 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_debugger+0x73
> #1 0x80bff1b8 at witness_warn+0x448
> #2 0x810700d3 at trap_pfault+0x53
> #3 0x8106f70a at trap+0x2ba
> #4 0x81049bc5 at calltrap+0x8
> #5 0x80bf6b42 at uiomove_faultflag+0x122
> #6 0x809439e6 at mseq_write+0x4c6
> #7 0x80a4f725 at devfs_write_f+0x185
> #8 0x80c02a87 at dofilewrite+0x97
> #9 0x80c0287f at kern_pwritev+0x5f
> #10 0x80c0277d at sys_pwrite+0x8d
> #11 0x81070af7 at amd64_syscall+0x2a7
> #12 0x8104a4ad at fast_syscall_common+0x101
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 4; apic id = 04
> fault virtual address = 0x20ea6b
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x8106d32d
> stack pointer = 0x28:0xfe00a844a660
> frame pointer = 0x28:0xfe00a844a660
> code segment  = base 0x0, limit 0xf, type 0x1b
>= DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process  = 2356 (xxx)
> [ thread pid 2356 tid 100278 ]
> Stopped at  copyin_nosmap_erms+0xdd:movl(%rsi),%edx
> db>
>
> --
> Peter
> ___
> 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"
>
It's a known fault in the oss implementation midi parsing code. The easiest
route is to use something else to parse midi for the time being.

OSS was ported over and many outstanding bugs are still laying around.

Best,
Owen
___
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"

Page fault in midi/sequencer.c

2018-10-20 Thread Peter Holm

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_debugger+0x73
#1 0x80bff1b8 at witness_warn+0x448
#2 0x80bf6a91 at uiomove_faultflag+0x71
#3 0x809439e6 at mseq_write+0x4c6
#4 0x80a4f725 at devfs_write_f+0x185
#5 0x80c02a87 at dofilewrite+0x97
#6 0x80c0287f at kern_pwritev+0x5f
#7 0x80c0277d at sys_pwrite+0x8d
#8 0x81070af7 at amd64_syscall+0x2a7
#9 0x8104a4ad at fast_syscall_common+0x101
Kernel page fault 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_debugger+0x73
#1 0x80bff1b8 at witness_warn+0x448
#2 0x810700d3 at trap_pfault+0x53
#3 0x8106f70a at trap+0x2ba
#4 0x81049bc5 at calltrap+0x8
#5 0x80bf6b42 at uiomove_faultflag+0x122
#6 0x809439e6 at mseq_write+0x4c6
#7 0x80a4f725 at devfs_write_f+0x185
#8 0x80c02a87 at dofilewrite+0x97
#9 0x80c0287f at kern_pwritev+0x5f
#10 0x80c0277d at sys_pwrite+0x8d
#11 0x81070af7 at amd64_syscall+0x2a7
#12 0x8104a4ad at fast_syscall_common+0x101


Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address = 0x20ea6b
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x8106d32d
stack pointer = 0x28:0xfe00a844a660
frame pointer = 0x28:0xfe00a844a660
code segment  = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process  = 2356 (xxx)
[ thread pid 2356 tid 100278 ]
Stopped at  copyin_nosmap_erms+0xdd:movl(%rsi),%edx
db>

-- 
Peter
___
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"

FreeBSD 12.0-BETA1 Now Available

2018-10-20 Thread Glen Barber

-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 powerpcspe MPC85XXSPE
o 12.0-BETA1 sparc64 GENERIC
o 12.0-BETA1 armv6 RPI-B
o 12.0-BETA1 armv7 BANANAPI
o 12.0-BETA1 armv7 BEAGLEBONE
o 12.0-BETA1 armv7 CUBIEBOARD
o 12.0-BETA1 armv7 CUBIEBOARD2
o 12.0-BETA1 armv7 CUBOX-HUMMINGBOARD
o 12.0-BETA1 armv7 RPI2
o 12.0-BETA1 armv7 PANDABOARD
o 12.0-BETA1 armv7 WANDBOARD
o 12.0-BETA1 armv7 GENERICSD
o 12.0-BETA1 aarch64 GENERIC
o 12.0-BETA1 aarch64 RPI3
o 12.0-BETA1 aarch64 PINE64
o 12.0-BETA1 aarch64 PINE64-LTS

Note regarding arm SD card images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -current mailing list.

If you would like to use SVN to do a source based update of an existing
system, use the "stable/12" branch.

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 12.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64 and i386 architectures.
Disk images may be downloaded from the following URL (or any of the
FreeBSD FTP mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/12.0-BETA1/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

 ap-south-1 region: ami-0c8239b63a5166f9f
 eu-west-3 region: ami-054b9592a74acd863
 eu-west-2 region: ami-0e7c28a496ed94202
 eu-west-1 region: ami-054b26b609c4617eb
 ap-northeast-2 region: ami-05fe71556c58cda6c
 ap-northeast-1 region: ami-0ff21c344009b9a0b
 sa-east-1 region: ami-0b659763bae30534f
 ca-central-1 region: ami-06fa2c747afca2b22
 ap-southeast-1 region: ami-0adb26a053af07edf
 ap-southeast-2 region: ami-08f20d18855fa4df4
 eu-central-1 region: ami-07f0b8c2abe96da0d
 us-east-1 region: ami-0f0a80ec326c85b07
 us-east-2 region: ami-0e57dc3fa5955b97d
 us-west-1 region: ami-0b8759ac8a8d49b2e
 us-west-2 region: ami-0c5ed0426315d4dd4

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can
be installed by running:

% vagrant init freebsd/FreeBSD-12.0-BETA1
% vagrant up

=== Upgrading ===

Please note, freebsd-update(8) binary upgrade bits are still in progress
and not yet available.  A followup to this email will be sent when they
are available.

== ISO CHECKSUMS ==

o 12.0-BETA1 amd64 GENERIC:
  SHA512 (FreeBSD-12.0-BETA1-amd64-bootonly.iso) = 
7d2b49ca641f898ff1a110931139b2363ed51cee8a1e26eb718d3022f2e409087a7fa65079f0b7e2b91c1dc4664c3b9d107f6166d8c58f03cc1caf7c9813993f
  SHA512 (FreeBSD-12.0-BETA1-amd64-bootonly.iso.xz) = 
de64b81cd5af7fe27e4daa3f0a377fcb41b8c56c7a9b7099ba3c43fe68e08ba7bc0a69dc4b0fd14dc98af27be20089c19781e3b0651cab2da5fdb62f8b4b0bc0
  SHA512 (FreeBSD-12.0-BETA1-amd64-disc1.iso) = 
e06dcc21aef253e9ff7c52a5245cca945f0116c3bb23917907a7eca9eacf523490a9fe83480d608119748af157459bc977ccc3fdfa0ea317d9fef591180a0667
  SHA512 (FreeBSD-12.0-BETA1-amd64-disc1.iso.xz) = 
12f1fa6504721d40c4822fce92abe0fa5aaf43828e4ef59dfb8cc7a87ffa3d286793ba5814b5f86f88c0626a7b701ceb9c4935745d36ecf8b74e44f3593548b4
  SHA512 (FreeBSD-12.0-BETA1-amd64-dvd1.iso) = 
cbd783171c4621509c0d1f382332849d2a2051d9500cf1199467b92751d8ecdc471061998ad73fbc48ce26b05fe3630510438c86e644d409c

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

2018-10-20 Thread Ali Abdallah

>> 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/fuser.c
> >> index b4225328fc1f..17d06f1c5b13 100644
> >> --- a/usr.bin/fstat/fuser.c
> >>  +++ b/usr.bin/fstat/fuser.c
> >>  @@ -92,7 +92,7 @@ struct consumer {
> >>STAILQ_ENTRY(consumer)  next;
> >> };
> >> struct reqfile {
> >> -   uint32_tfsid;
> >>  +   uint64_tfsid;
> >>uint64_tfileid;
> >>const char  *name;
> >>STAILQ_HEAD(, consumer) consumers;
> >
> > The above patch does not resolve the problem for me.
> >
>
> Are you sure you recompiled and reinstalled the tool with the patch
> applied?
> You can recompile and install like this:
> # make -j 3 clean all install
>
> If this indeed still does not work, can you show output of:
> uname -m
> mount
>
> I tested on zfs, perhaps there is something extra going on on other
> filesystems.
>
> --
> Mateusz Guzik 
>
___
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"

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

2018-10-20 Thread Mark Millard

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 updated yet got past the problem being
reported here. (For other reasons, the kernel has
been moved back to -r338804 --and with that,
and the older /boot/loader, the 1950X native-boots
FreeBSD all the way just fine.)

For the BTX failure the display ends up with
(hand transcribed, ". . ." for an omission):

BTX loader 1.00 BTX version is 1.02
Console: internal video/keyboard
BIOS drive C: is disk0
. . .
BIOS drive P: is disk13
-
int=  err=  efl=00010246  eip=96fd
eax=74d48000  ebx=74d4e5e0  ecx=0011  edx=
esi=74d4e380  edi=74d4e5b0  ebp=00091da0  esp=00091d60
cs=002b  ds=0033  es=0033fs=0033  gs=0033  ss=0033
cs:eip=66 f7 77 04 0f b7 c0 89-44 24 0c 89 5c 24 04 8b
   45 08 89 04 24 83 64 24-10 00 c7 44 24 08 01 00
ss:esp=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
   00 00 00 00 00 00 00 00-f0 1d 89 00 00 00 00 00
BTX halted


The board is a GIGABYTE X399 AORUS Gaming 7 (rev 1.0).
It has 96 GiBytes of ECC RAM, just 6 DIMMs installed.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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"

dmesg submission service -- please submit today

2018-10-20 Thread Edward Sanford Sutton, III

  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 appreciate seeing this as an option or request on installs and
think it could make a good reminder in the output when binary updating
or source rebuilding or in the UPDATING file (I'm more likely to check
there than in the handbook). Adding it to normal dmesg output or a login
message would seem too bloated and likely to be removed or ignored.
  If something is planned for removal, documenting it and mentioning it
in output when it is loaded both could help spread awareness. If needing
feedback from those users, it could make it clear it is considered for
removal so that people who need to speak up about being a user have a
chance to be heard then too.
  freebsd.org hosting it would lead to more trust and easy control of a
command sequence to generate it with options, review contents, then
submit it would get more feedback.
  Anyways, I'm not a regular to this list and I only found out as I was
browsing through release+stable+current mailings, PRs, changes, and
patches under review for my issue of processes getting stuck in the
pfault state (as listed by top) when I get down to about 140M free of
32G until more and more processes lock up. Power button set for shutdown
usually eventually gives one after it begins killing things due to
timeouts being reached. Though I have had some luck with patches
improving how long until I can expect a needed action be taken, I've
decided 11.2 is not stable enough for use so will likely go to 12-stable
with hopes of changes I have not yet tested. I got rid of my last 10M
adapter last year when I ran across it as any reason I may reach for it
would be a painful experience to not just replace it.
Thank you and good luck on a smooth cleanup,
Edward Sanford Sutton, III
___
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"

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

2018-10-20 Thread Graham Perrin

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 jail to stable/12 (and then update the whole system 
to match what's in the jail) but the jail went too far, to 13.0-CURRENT: 


___
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: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

2018-10-20 Thread Mark Millard




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 after seeing
a boot failure native.

Looks like the native failure is even earlier,
before db> is even possible, possibly during
early loader activity.

So this report is really for running under
Hyper-V: -r338804 boots and -r338810 does
not. By contrast -r334804 does not boot native.
(But I've little information for that context.)

Sorry for the confusion. I rushed the report
in hopes of getting to sleep. It was not to be.

> It fails just after the FreeBSD/SMP lines,
> reporting "kernel trap 9 with interrupts disabled".
> 
> It fails in pmap_force_invaldiate_cache_range at
> a clflusl (%rax) instruction that produces a
> "Fatal trap 9: general protection fault while
> in kernel mode". cpudid=0 apic id= 00
> 
> I used kernel.txz files from:
> 
> https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/
> 
> to narrow the range of kernel builds for working -> failing
> and got:
> 
> -r338804 boots fine
> (no amd64 kernel builds between to try)
> -r338810+ fails (any that I tried, anyway)
> 
> In that range is -r338807 :
> 
> QUOTE
> Author: kib
> Date: Wed Sep 19 19:35:02 2018
> New Revision: 338807
> URL: 
> https://svnweb.freebsd.org/changeset/base/338807
> 
> 
> Log:
>  Convert x86 cache invalidation functions to ifuncs.
> 
>  This simplifies the runtime logic and reduces the number of
>  runtime-constant branches.
> 
>  Reviewed by: alc, markj
>  Sponsored by:The FreeBSD Foundation
>  Approved by: re (gjb)
>  Differential revision:   
> https://reviews.freebsd.org/D16736
> 
> Modified:
>  head/sys/amd64/amd64/pmap.c
>  head/sys/amd64/include/pmap.h
>  head/sys/dev/drm2/drm_os_freebsd.c
>  head/sys/dev/drm2/i915/intel_ringbuffer.c
>  head/sys/i386/i386/pmap.c
>  head/sys/i386/i386/vm_machdep.c
>  head/sys/i386/include/pmap.h
>  head/sys/x86/iommu/intel_utils.c
> END QUOTE
> 
> There do seem to be changes associated with
> clflush(...) use. Looking at:
> 
> https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=339432
> 
> it appears that pmap_force_invalidate_cache_range has not
> changed since -r338807.
> 
> It seems that -r338806 and -r3388810 would be unlikely
> contributors.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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"

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

2018-10-20 Thread Mark Millard

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 fails in pmap_force_invaldiate_cache_range at
a clflusl (%rax) instruction that produces a
"Fatal trap 9: general protection fault while
in kernel mode". cpudid=0 apic id= 00

I used kernel.txz files from:

https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/

to narrow the range of kernel builds for working -> failing
and got:

-r338804 boots fine
(no amd64 kernel builds between to try)
-r338810+ fails (any that I tried, anyway)

In that range is -r338807 :

QUOTE
Author: kib
Date: Wed Sep 19 19:35:02 2018
New Revision: 338807
URL: 
https://svnweb.freebsd.org/changeset/base/338807


Log:
  Convert x86 cache invalidation functions to ifuncs.
  
  This simplifies the runtime logic and reduces the number of
  runtime-constant branches.
  
  Reviewed by:  alc, markj
  Sponsored by: The FreeBSD Foundation
  Approved by:  re (gjb)
  Differential revision:
https://reviews.freebsd.org/D16736

Modified:
  head/sys/amd64/amd64/pmap.c
  head/sys/amd64/include/pmap.h
  head/sys/dev/drm2/drm_os_freebsd.c
  head/sys/dev/drm2/i915/intel_ringbuffer.c
  head/sys/i386/i386/pmap.c
  head/sys/i386/i386/vm_machdep.c
  head/sys/i386/include/pmap.h
  head/sys/x86/iommu/intel_utils.c
END QUOTE

There do seem to be changes associated with
clflush(...) use. Looking at:

https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=339432

it appears that pmap_force_invalidate_cache_range has not
changed since -r338807.

It seems that -r338806 and -r3388810 would be unlikely
contributors.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: boot message: sendmsg on igb0: No buffer space available

2018-10-20 Thread Dave Cottlehuber

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 dhclient is trying before the
interface is available for use - is that likely in your case?
A+
Dave








___
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: DRM: radeonkms … can not be unloaded (kernel panic)) …

2018-10-20 Thread Hans Petter Selasky


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 unload the graphics driver so we haven't spent time on 
proper cleanup. Also, the drm module will cause panic if you try load load it 
again after unload.




Is the principle for -next- the same as for -devel-, should I simply _never_ 
attempt to unload the module?

$ date ; uname -v
Sat 20 Oct 2018 02:06:21 BST
FreeBSD 12.0-BETA1 r339438 GENERIC
$ pkg query '%o %v %R' drm-kmod drm-next-kmod gpu-firmware-kmod
graphics/drm-next-kmod 4.11.g20180822 poudriere
graphics/gpu-firmware-kmod g20180825 FreeBSD


I recommend building these modules from source, /usr/src which match you 
currently installed kernel!


--HPS

___
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"

SCSI and dmesg

2018-10-20 Thread Warner Losh

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 the hardware. I'm still working out
the kinks in the dmesg parsing, but this is interesting data.

If you've not recently submitted, please consider doing so. We'll be
finalizing the scsi SIMs that I'm going to propose retiring in 13 here in a
few weeks, and I'm going to base much of what list I come up with based on
what is submitted. The glitches with FreeBSD dmesgs have been cleared up as
well.

http://dmesgd.nycbug.org/index.cgi

or

curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d
"description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) $(kenv
smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@
/var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi
___
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: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works

Re: Page fault in midi/sequencer.c

Page fault in midi/sequencer.c

FreeBSD 12.0-BETA1 Now Available

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

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

dmesg submission service -- please submit today

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

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

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

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

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

SCSI and dmesg

13 matches

Site Navigation

Mail list logo

Footer information