Re: current now panics when starting VBox VM

[Greg V via freebsd-current]

On November 2, 2021 5:16:35 PM GMT+03:00, Michael Butler via freebsd-current 
 wrote:
>On current as of this morning (I haven't tried to bisect yet) ..
>
>  .. with either graphics/drm-devel-kmod or graphics/drm-current-kmod, 
>trying to start a VirtualBox VM triggers this panic ..
>

>#16 0x80c81fc8 at calltrap+0x8
>#17 0x808b4d69 at sysctl_kern_proc_pathname+0xc9

something something https://reviews.freebsd.org/D32738 ? 
sysctl_kern_proc_pathname was touched recently there.

(Also can someone commit https://reviews.freebsd.org/D30174 ? These 
warning-filled reports are unreadable >_<)

Re: FYI for aarch64 main [14] running a mid March version: I ended up with [usb{usbus2}] stuck at (near) 100% cpu

[Greg V]

On May 14, 2021 5:59:48 AM UTC, Mark Millard via freebsd-current 
 wrote:
>The [usb{usbus2}] process eventually got stuck-busy, no
>more I/O:
>
>
>The system was a MACCHIATObin Double Shot.

I've noticed USB issues on the mcbin too.
In my experience uaudio was the most likely thing to freeze: sometimes when 
playing audio the whole USB stack would hang, IIRC only unplugging and 
reconnecting the hub would let USB I/O continue.

Looks like the XHCI hardware might not be fully stable here?? but I do wonder 
if we could possibly lack some recovery mechanisms for this situation that 
other OSes have.
___
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: panic in drm or vt or deadlock on mutex or ...

[Greg V]

On Mon, Feb 8, 2021 at 04:53, Alastair Hogge  wrote:

On 2021-02-04 17:50, Emmanuel Vadot wrote:

[...]


  Only happens with drm when you do what ?


Boot to multi-user; login (getty):
$ doas kldload /boot/modules/amdgpu.ko
$ sysctl
[panic]

..is a guaranteed way to panic my system.



https://github.com/freebsd/drm-kmod/issues/15 → 
https://github.com/freebsd/drm-kmod/pull/37 ?



___
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: Name of touchpad changed in latest rev

[Greg V]

On Mon, Jan 18, 2021 at 08:01, Malcolm Matalka  
wrote:

I just installed the below revision, and looks like the name the mouse
shows up as has changed.  Not sure if this is intended or not.  What 
was

"SynPS/2 Synaptics TouchPad" and now it is "DELL07E6:00 06CB:76AF
TouchPad".


Congratulations, you are now using the touchpad over I2C instead of 
PS/2 :)
The iichid code has finally landed in current so we have much better 
HID support now.



___
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: Current kernel build broken with linuxkpi?

[Greg V]

On Thu, Jan 14, 2021 at 08:36, Robert Huff  wrote:


Hello:


   > I am trying to upgrade a system running:
   >
   > FreeBSD 13.0-CURRENT #0 r365372: Sun Sep  6 10:51:26 EDT 2020 
amd64

   >
   > Per this discussion, I cannot compile the kernel because
   > drm-current-kmod is out-of-date.
   > When I try to upgrade drm-current-kmod (r561457) I get:
   >
   > ===>  drm-current-kmod-5.4.62.g20210113 not supported on older
   > CURRENT, no
   > kernel support.
   > *** Error code 1
   >
   > Stop.
   > make: stopped in /usr/ports/graphics/drm-current-kmod
   >
   > Huh?
   > 	What is my path forward? (That does not involve reinstalling 
the

   > OS.)

   Either

   upgrade the kernel without the drm PORTS_ whatever thing h
   upgrade drm-current-kmod h add back the PORTS_thing if you
   really want it upgrade kernel again


If I understand things correctly: things in the PORTS_MODULES
list are upgraded _after_ the kernel is completely rebuilt.
I am hitting this _during_ the rebuild.


I'm not sure if they will be upgraded after it's installed..

also, did you upgrade the world?
The version stuff that ports checks comes from /usr/include.


So the question becomes: _will_ removing the IGNORE line work?


Why wouldn't it?


___
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: Current kernel build broken with linuxkpi?

[Greg V]

On Thu, Jan 14, 2021 at 08:05, Robert Huff  wrote:


"Houston ... we have a problem."
Scenario: Chicken, meet egg?
I am trying to upgrade a system running:

FreeBSD 13.0-CURRENT #0 r365372: Sun Sep  6 10:51:26 EDT 2020 amd64

Per this discussion, I cannot compile the kernel because
drm-current-kmod is out-of-date.
When I try to upgrade drm-current-kmod (r561457) I get:

===>  drm-current-kmod-5.4.62.g20210113 not supported on older 
CURRENT, no

kernel support.
*** Error code 1

Stop.
make: stopped in /usr/ports/graphics/drm-current-kmod

Huh?
What is my path forward? (That does not involve reinstalling the
OS.)


Either

upgrade the kernel without the drm PORTS_ whatever thing → upgrade 
drm-current-kmod → add back the PORTS_thing if you really want it → 
upgrade kernel again


or

remove the IGNORE line in the port's Makefile → upgrade 
drm-current-kmod → upgrade the kernel.


You have discovered precisely why this (building kmods from ports when 
building the kernel itself) is not a very good feature :)



___
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: AMD Secure Encrypted Virtualization - FreeBSD Status?

[Greg V]

Hey everyone,

On October 5, 2019 4:49:39 AM GMT+03:00, "Clay Daniels Jr." 
 wrote:
>Grarpamp,Tomasz, and all:
>
>https://wiki.freebsd.org/SecureBoot
>A work in progress.

please keep in mind that the wiki is, as usual, very outdated. You can see that 
the last edit on this page was in 2017.

A lot more work has been happening e.g. https://reviews.freebsd.org/D19093 
https://reviews.freebsd.org/D20952 etc.

___
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: Firefox – GtkFileChooserNative – file selection dialogues

[Greg V]

On September 19, 2019 8:02:35 PM GMT+03:00, Graham Perrin 
 wrote:
>Firefox does not use xdg-desktop-portal for file selection dialogs
>
>
> > This patch makes Firefox's GTK3 platform support use
> > GtkFileChooserNative when available. GtkFileChooserNative
> > transparently uses the desktop portals interface, which
> > enables Firefox to use native Qt file dialogs on KDE, or
> > sandboxed file dialogs in Flatpak.
>
>– RESOLVED FIXED, mozilla64
>
>Can I benefit from this patch on FreeBSD?
>
>(What am I missing?)

The dbus portal implementation itself, most likely.

___
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: "amdgpu and radeonkms are known to fail with EFI Boot"

[Greg V]

On August 24, 2019 10:15:22 AM GMT+03:00, "Clay Daniels Jr." 
 wrote:
>From the kmod ports, dated 20190814
>
>
>/usr/ports/graphics/drm-current-kmod/pkg-descr
>
>"amdgpu and radeonkms are known to fail with EFI Boot"
>
>
>/usr/ports/graphics/drm-current-kmod/pkg-message
>
>"some positive reports if EFI is not enabled"
>
>
>Any practical suggestions on getting drm-current-kmod to work on an AMD
>machine, including how to NOT enable EFI? I did not see that option on
>the
>install menu.

"Not enabling" EFI means booting the installer in legacy more (CSM). Installer 
images are universal, so you'd have to instruct the firmware to ignore the EFI 
loader on there. Deleting the EFI partition might work I guess. rEFInd can 
force CSM boot a USB drive.

I do not recommend this. Instead, there is a workaround for the EFI framebuffer 
conflict. If you have it (i.e. amdgpu fails to load, or hangs when starting 
GUI), boot with hw.syscons.disable=1. You won't see anything on the screen 
after the boot loader and before loading the driver :) but that's not a big 
deal when the driver autoloads successfully.
___
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: acpi issues on FreeBSD-current_r350103 on Thinkpad A485

[Greg V]

On July 20, 2019 1:54:47 AM GMT+03:00, Evilham  wrote:

> it even suspends and resumes back to X

Wow, that's great news! Desktop Ryzen+Vega doesn't (not that I need suspend 
very much on desktop haha)

>- xbacklight doesn't work, neither does intel-backlight because 
>  it's AMD

Since it's a Thinkpad, do the brightness keys work anyway? Does acpi_ibm work?

>Serious issue:
>I was just debugging this right now, more infos with a proper bug 
>report will come, but I think the system encounters a deadlock 
>sometimes with the drm-kmod / amdgpu which results in a kernel 
>panic.

If you're on the packaged drm-kmod v4.16, it's amazing that Raven GPU works at 
all. You should try drm-v5.0 from git.

>kld_list="amdgpu"

It even works when loaded this early? Interesting. Do you also not have the EFI 
framebuffer conflict? i.e. without disabling vt.syscons, everything just works 
reliably?
___
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: Enabling synaptics and elantech touchpads by default

[Greg V]

On June 3, 2019 11:31:21 PM GMT+03:00, Niclas Zeising  
wrote:
>Hi!
>I've created a reveiew, https://reviews.freebsd.org/D20507, to enable 
>synaptics and elantech touchpads by default.
>
>Today, these tunables needs to be set on boot for users to get full use
>
>of their touchpads, even when using X.  By enabling this, things like 
>two finger scroll will work in X by default, meaning we get a more user
>
>friendly appearance.
>
>Is there any reason not to do this?

Probably buggy hardware, as usual?

But the ONLY system I ever saw a problem on is the ASUS Eee PC 900 (where 
elantech support breaks all mouse movement). Which is an extremely irrelevant 
joke of a machine. I only booted it for the nostalgia/laughs/dmesgd.nycbug 
posts.

Definitely +1 to enabling by default. Reducing the amount of tunables required 
for modern desktop use is very good.
___
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: FreeBSD Core Team Response to Controversial Social Media Posts

[Greg V]

On Sun, May 12, 2019 at 03:16, Miroslav Lachman <000.f...@quip.cz> 
wrote:

FreeBSD Core Team Secretary wrote on 2019/05/10 03:24:
The FreeBSD Core Team is aware of recent controversial statements 
made

on social media by a FreeBSD developer.  We, along with the Code of
Conduct review committee, are investigating the matter and will 
decide

what action to take.  Both the Core Team and the FreeBSD Foundation
would like to make it clear that views shared by individuals 
represent

neither the Project nor the Foundation.



This is incredibly stupid and I am really sad to read things like 
this in the mailinglist of my favourite operating system (again).
What will be next? Checking if developers do not smoke weed, drink 
alcohol or have sex without condom?


https://yourlogicalfallacyis.com/slippery-slope

Speaking freely does not mean you are entitled to having your speech 
published by any forum or mailing list. Having rules and enforcing them 
is good, every project has the right to enforce their rules in their 
spaces.


The only problem here is that the "report" was posted by a known troll, 
so hopefully the outcome of the investigation is


a) nothing, and

b) mail from known anonymous email domains no longer gets accepted into 
mailing lists.



___
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: Danish FreeBSD Developer hates jews collectively

[Greg V]

On May 9, 2019 10:16:35 PM GMT+03:00, Enji Cooper  wrote:
>
>> On May 9, 2019, at 11:03 AM, ossobser...@redchan.it wrote:
>
>This is the only reply I’m going to give to this thread that seems like
>obvious troll bait.

Oh yeah, if you see anything mentioning "GPL revocation", it's most likely the 
work of That Guy:

https://redd.it/b8wwhk https://redd.it/antkt3

Looks like low-effort spamming of Reddit was so unsatisfying that he went back 
to high-effort trolling.
___
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: Switching fb backend back to default

[Greg V]

On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg  
wrote:

Hi

I'm working on making i915kms unload properly. I've come to what I 
think

is the last issue. The drm driver unloads ok, the "efifb" backend is
restored (according to logs) and vt_efifb_init() is being called but 
the

screen (laptop built in display) stays black. The system seems
operational otherwise. If I load i915kms again in this state I get 
back

a visible (i915kms) framebuffer.

Did we ever have this working so it's known to work?


Recently on the linux kernel mailing list:

http://lkml.iu.edu/hypermail/linux/kernel/1903.1/01162.html

> Of course, once native drivers like i915 or radeon take over, such a 
framebuffer is toast... [6]


> [6] 
linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb()

> linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe()

So it seems like efifb is not supposed to work after a driver has been 
loaded at least once.



___
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: emac g4 1.25 GHz retail model won't boot FreeBSD 12 at all.

[Greg V]

On Mon, Nov 12, 2018 at 11:54 PM, Alex McKeever 
 wrote:
The CD or DVD show up fine in the device selection screen, but it 
won’t even boot the disc. What changed from 11.2 to 12.0 in regards 
to PowerPC Macs that are 32 bit?


I've been able to boot various 12-CURRENT builds on my iBook G4 just 
fine.


What exactly do you mean by "won't even boot"? Do you see the loader 
prompt when selecting the disc?


___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Greg V]

On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen  
wrote:

Greetings,

I'm trying to track down a couple of things.  amdtemp doesn't
report any temperature sensors, and acpi seems to have some
errors.  Not sure if they are related.

These are the ACPI-related warnings and errors during boot.

   Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has 
valid Length but zero Address: 0x/0x1 
(20181031/tbfadt-796)


I see this one on my R7 1700 / X370 system, seems harmless.


   acpi0:  on motherboard
   Firmware Error (ACPI): Failure creating [\134_SB.SMIC], 
AE_ALREADY_EXISTS (20181031/dswload2-477)
   ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20181031/psobject-372)
   Firmware Error (ACPI): Failure creating [\134_SB.SMIB], 
AE_ALREADY_EXISTS (20181031/dsfield-803)


Looks like people see these on Linux:

https://forum.manjaro.org/t/unstable-behaviour-not-always-completely-booting/55823/5

Are you on the latest firmware ("BIOS") revision for your board?

___
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: Graphics open-source-friendliness, AMD Ryzen vs. Intel

[Greg V]

On Sun, Nov 11, 2018 at 3:42 PM, Thomas Mueller  
wrote:
I may need to buy parts for a new computer because of malfunctions on 
current motherboard and CPU (Intel Sandy Bridge dating to May 2011).


Question is whether I am better off, regarding 
open-source-friendliness of graphics chips for running Xorg, with AMD 
Ryzen or the newer Intel chipsets.  I know to avoid NVIDIA.


Both are great for open source friendliness in general.

Onboard Vega GPUs on the Ryzen APUs should work fine on FreeBSD with 
kms-drm 4.16.


If you're looking for high performance though, don't get an APU, get an 
8-core (R7 2700X/2700/1700X/1700) and a discrete GPU (Radeon RX 
550/560/570/580 depending on how much you care about graphics 
performance).


I am inclined to run FreeBSD-current and build Xorg from FreeBSD 
ports.


When I boot into UEFI setup, I see the CPU temperature is or quickly 
goes to 97 C and stays there.


I tried replacing the thermal paste and installing a new case fan to 
replace one that had quit, but CPU temperature still shows and stays 
at 97 C.


Now I have a replacement Arctic Cooler heatsink and fan on order to 
replace the original Intel heatsink and fan whose connectors were 
damaged in taking out and struggling to get back in.


Currently, I boot into UEFI Setup, but after a couple minutes, the 
computer powers off and then tries to power back on, then off again a 
few seconds later, until I end the loop by turning off the power 
supply switch.  I can guess CPU overheating.


Yeah, a new CPU cooler should help.

I could transplant the current hard drive (Seagate NAS 4 TB) to get a 
quicker start software-wise.


An SSD might provide a quicker start too ;)

___
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: Current status of Ryzen (non-)support

[Greg V]

On Sun, Oct 21, 2018 at 7:09 PM, Hannes Hauswedell 
 wrote:

Hi everyone,

I wanted to ask what the current status of Ryzen support is and/or
whether any new changes are planned.

My situation:
* second generation Ryzen: 2600X
* running -CURRENT
* I have done the things described here:
https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069799.html
* no full system freezes, but under load, e.g. building with 12 
threads,

programs start to segfault.
* memtest86 ran through without issues
* on a Linux dual boot I haven't had any issues

Is this a known problem? Anythings I can do about it? I thought the
Ryzen problem were only supposed to happen with first generation 
CPUs...


First gen (R7 1700) here, overclocked to 3.9GHz, also running CURRENT 
— never had any unexpected segfaults, even when building with 16 
threads.


The only bug is that the bottom (chipset) PCIe slot breaks when an NVMe 
SSD is installed / chipset USB3 ports don't work:

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

___
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: Good motherboard for Ryzen (first-gen)

[Greg V]

On Thu, Oct 11, 2018 at 11:40 PM, Eric van Gyzen  
wrote:

On 9/21/18 9:53 PM, Eric van Gyzen wrote:
I would like to build a Ryzen desktop.  Can anyone recommend a good 
motherboard?


I'm planning on a first-gen, because the second-gen has similar 
stability problems as the first-gen had, and AMD hasn't released 
errata for the second-gen yet (as far as I know...I would love to 
be wrong).


I would like to be a cool kid with a Threadripper, but I can't 
justify the cost, so I'm thinking maybe a Ryzen 7 with /only/ 8 
cores.  :)


Ideally, I want an Intel NIC, ECC memory support, and a 3-year 
warranty.


Thanks for all the responses.  They were very helpful.  Here is what 
I ended up building:


Mobo:  ASUS Prime X470-Pro
CPU:   Ryzen 7 2700X 3.7GHz 8-Core
RAM:   Corsair Vengeance LPX 2 x 16GB DDR4-2666 PC4-21300 C16
Video: ASUS GeForce GTX 1060 6GB
Disk:  Samsung 970 EVO 500GB TLC NAND M.2 2280 PCIe NVMe 3.0 x4
PSU:   EVGA SuperNOVA G3 750 Watt 80 Plus Gold ATX
Fan:   Cooler Master Hyper 212 EVO Universal CPU Cooler

It's running FreeBSD head.  BIOS version is 4018 (2018-07-12).  So 
far, it has been perfectly stable.  No crashes, no lockups.  It has 
been my work-from-home desktop for just over a week now.  I'm 
overclocking the memory a little, but nothing else.  The NIC works.  
The sound works, though I've only tested the rear analog output.  The 
video card works with the nvidia-driver, currently 390.87.  It's 
driving two 2560x1440 monitors over HDMI.


The only problem so far:  I can't get NUMA enabled.  I've set Memory 
Interleave to "off", but the BIOS still doesn't generate an ACPI SRAT 
table.  I'm still working on this.


You won't ever get NUMA enabled.

Because Ryzen 7 2700X is not a NUMA processor! :)

Only Threadripper and EPYC are.

Desktop Ryzen has a "slightly NUMA-like" thing going on, it's 
recognized as 'cache groups' in the line:
FreeBSD/SMP: 1 package(s) x 2 cache groups x 4 core(s) x 2 hardware 
threads


But it's not actual NUMA.

___
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: Problem compiling rust

[Greg V]

On Sat, Oct 6, 2018 at 3:26 PM, Filippo Moretti  
wrote:
  extracting 
cargo-0.29.0-x86_64-unknown-freebsd/cargo/share/doc/cargo/README.md  
extracting cargo-0.29.0-x86_64-unknown-freebsd/cargo/manifest.in  
extracting 
cargo-0.29.0-x86_64-unknown-freebsd/cargo/etc/bash_completion.d/cargo 
 extracting cargo-0.29.0-x86_64-unknown-freebsd/cargo/bin/cargo  
extracting 
cargo-0.29.0-x86_64-unknown-freebsd/cargo/share/zsh/site-functions/_cargorunning: 
/usr/ports/lang/rust/work/rustc-1.29.1-src/build/x86_64-unknown-freebsd/stage0/bin/cargo 
build --manifest-path 
/usr/ports/lang/rust/work/rustc-1.29.1-src/src/bootstrap/Cargo.toml 
--frozenTraceback (most recent call last):  File 
"/usr/ports/lang/rust/work/rustc-1.29.1-src/x.py", line 20, in 
bootstrap.main()  File 
"/usr/ports/lang/rust/work/rustc-1.29.1-src/src/bootstrap/bootstrap.py", 
line 843, in mainbootstrap(help_triggered)  File 
"/usr/ports/lang/rust/work/rustc-1.29.1-src/src/bootstrap/bootstrap.py", 
line 819, in bootstrapbuild.build_bootstrap()  File 
"/usr/ports/lang/rust/work/rustc-1.29.1-src/src/bootstrap/bootstrap.py", 
line 646, in build_bootstraprun(args, env=env, 
verbose=self.verbose)  File 
"/usr/ports/lang/rust/work/rustc-1.29.1-src/src/bootstrap/bootstrap.py", 
line 148, in runraise RuntimeError(err)RuntimeError: failed to 
run: 
/usr/ports/lang/rust/work/rustc-1.29.1-src/build/x86_64-unknown-freebsd/stage0/bin/cargo 
build --manifest-path 
/usr/ports/lang/rust/work/rustc-1.29.1-src/src/bootstrap/Cargo.toml 
--frozen*** Error code 1

Stop.make[1]: stopped in /usr/ports/lang/rust*** Error code 1
Stop.make: stopped in /usr/ports/lang/rust[root@sting 
/usr/ports/lang/rust]# I always had this problem trying to compiling 
rust (amd64 alpha3),as I only need it to compile firefox I wonder if 
it is possible to disable its building.Thanks Filippo


You don't need to compile Rust from source to compile Firefox.
You can just 'pkg install rust' to get Rust from a binary package.

BTW, this error message doesn't say much, but if cargo fails, you might 
be out of memory.


___
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: linux-c7 and opengl apps?

[Greg V]

On Fri, Oct 5, 2018 at 11:21 PM, Theron  wrote:

% /compat/linux/opt/VirtualGL/bin/glxinfo | grep OpenGL
libGL error: MESA-LOADER: failed to retrieve device information


Do you have linsysfs mounted?

Try reading /compat/linux/sys/class/drm/card0/device/uevent.

Mesa won't retrieve device information without linsysfs.
I wrote the linsysfs patch that exposed the info there so that recent 
Mesa would work :)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222375
(Wow, that was a year ago… interesting note from there: you might 
need to set LIBGL_DRI3_DISABLE=1 for Linux apps)


Also, what's with the "/opt/VirtualGL"? Are you using mesa from 
linux-c7 or something… weird?


This problem has existed forever.  I am not sure it is actually a 
fault in Linux emulation, as these very same symptoms ("failed to 
retrieve device information" message, console freeze) existed back in 
FreeBSDDesktop/freebsd-base-graphics days when attempting to run 
purely FreeBSD OpenGL apps.  At the time the workaround was a patch 
to Mesa's GPU detection; the underlying kernel problem wasn't 
addressed.


There was a somewhat related issue (but not the same one, FreeBSD and 
Linux versions of mesa/libdrm use different mechanisms to get device 
info).
Mostly affected Wayland-EGL clients — they would try to access 
/dev/dri/card408 instead of /dev/dri/card0, fail to get info and fall 
back to software rendering.
I fixed it a while ago: 
https://gitlab.freedesktop.org/mesa/mesa/commit/db8519a369261cdedda50852facc45616d4eba28


But I never saw console freezes when Mesa couldn't properly detect the 
GPU o_0


___
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: linux-c7 and opengl apps?

[Greg V]

On Wed, Oct 3, 2018 at 12:36 PM, Johannes Lundberg  
wrote:

Hi

Have anyone successfully run opengl apps with linux-c7?

Linux opengl apps works great with linux-c6 on gpu < kabylake but
linux-c6-dri does not include support for kabylake gpus.
Linux glxinfo in c7 show support for hardware rendering on kabylake 
but any

attempt to run an opengl app results in application seg fault or other
crash (I believe this is also the case with skylake gpus on linux-c7).


On AMD Polaris: everything used to work in an ubuntu 16.04 chroot 
(currently having "can't open display :0" with that, probably 
forgetting something).


Trying Unigine Heaven with c7, segfaults right now. glxinfo shows 
everything correctly though.



Is there any way to run gdb on linux apps/core dumps?


There was a BSDCan talk that mentioned some gdb solutions:

https://www.youtube.com/watch?v=9N3NrPeCJpk
https://www.bsdcan.org/2018/schedule/attachments/473_linuxulator-notes-bsdcan2018.txt

___
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: best linux emulation for 12-current

[Greg V]

On Thu, Oct 4, 2018 at 7:31 PM, tech-lists  wrote:

Hi,

Which is the better package for linux emulation on 12-alpha8 - c6 or 
c7? Or something else?


Emulation is for boinc_client to take linux work


c7 is newer, of course it's better, c6 is very old stuff. But you can 
also just extract any Linux distro (that's not *too* new — Ubuntu 
16.04 cloud image works) into a directory and chroot into it.


___
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: Good motherboard for Ryzen (first-gen)

[Greg V]

On Sat, Sep 22, 2018 at 5:53 AM, Eric van Gyzen  
wrote:
I would like to build a Ryzen desktop.  Can anyone recommend a good 
motherboard?


I'm planning on a first-gen, because the second-gen has similar 
stability problems as the first-gen had, and AMD hasn't released 
errata for the second-gen yet (as far as I know...I would love to be 
wrong).


IIRC the weird freeze/segfault bugs were only in the early batches of 
1st gen. If you get 2nd gen, you're *definitely* getting a stable chip. 
My R7 1700 is from Aug 2017, never had any issues. So a 1st gen bought 
today should be fine too of course, unless *somehow* you get very very 
very old stock.


I would like to be a cool kid with a Threadripper, but I can't 
justify the cost, so I'm thinking maybe a Ryzen 7 with /only/ 8 
cores.  :)
Yeah, yeah. Good discounts on 1st gen Threadripper can be found these 
days though… but still there's board cost + RAM cost (you have to 
fill up 4 memory channels on TR if you want performance to not suck).


Ideally, I want an Intel NIC, ECC memory support, and a 3-year 
warranty.


For ECC, you can google board name + ecc ram. You can often find 
reports on forums/subreddits/whatever.


Since you care about warranty, you probably don't care about 
overclocking, so do not watch the following videos: B450 boards — 
https://youtu.be/yWAwOH-egFs X470 — https://youtu.be/L8T2gzIkw78 :)


But still, good power delivery is important for an 8-core even at stock 
settings, so avoid the latest ASUS TUF board, and super cheap boards in 
general.


I have an MSI X370 SLI PLUS. The firmware is good, RGB lighting support 
is good (most important thing! lol. controllable under FreeBSD with 
https://github.com/nagisa/msi-rgb), the VRM is okay but not super great 
(8-core @ 1.39V 3.95GHz → ~100 ℃ without any direct airflow over 
the VRM heatsink). NIC is Realtek, recognized by re(4), I never tried 
it (I use a Mellanox card). Audio is Realtek, works fine 99% of the 
time (very occasionally sound stops working, sysctl 
dev.hdac.0.polling=1 brings it back). There is a pin header for the SPI 
flash chip  to recover a failed firmware update (I actually did this 
once :D), but the pins are tiny (2mm instead of the usual 2.54).


___
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: FreeBSD EFI projects

[Greg V]

On Thu, Sep 20, 2018 at 12:24 AM, Rebecca Cran  
wrote:

On 9/19/18 3:53 AM, Greg V wrote:



Yes, of course it was 64-bit.

I don't think I ever downloaded the 32-bit one...



And are you sure it was booted via EFI and not the BIOS emulation CSM 
(Compatibility Support Module)? I'm fairly sure we _don't_ support 
booting a 64-bit kernel from 32-bit EFI yet.


Well, I said I built a 32-bit-EFI version of GRUB 2, and told *that* to 
boot 64-bit FreeBSD kernel :)


Our loader.efi wasn't used.

___
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: FreeBSD EFI projects

[Greg V]

On Wed, Sep 19, 2018 at 6:31 PM, Rodney W. Grimes 
 wrote:

 On Wed, Sep 19, 2018 at 6:06 PM, Rodney W. Grimes
  wrote:
 >>  On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
 >>   wrote:
 >>  >>  On 9/18/18 4:11 AM, Greg V wrote:
 >>  >>
 >>  >>  >
 >>  >>  > I can confirm that the kernel already worked fine when 
booted

 >> from
 >>  >>  > 32-bit EFI.
 >>  >>  >
 >>  >>  > I booted an old Mac into HardenedBSD using a 32-bit-EFI 
build

 >> of
 >>  >> GRUB2 :)
 >>  >>
 >>  >>
 >>  >>  Was that a 64-bit version of FreeBSD? My understanding is 
the

 >> 32-bit
 >>  >>  FreeBSD boots fine, but 64-bit needs work.
 >>  >
 >>  > You would be hard pressed to find a system with a 64 bit CPU 
that

 >>  > could run 64 bit FreeBSD that had a 32 bit EFI implementation.
 >>
 >>  Mac mini 2006 with a Core2Duo instead of the stock CoreDuo (and 
the

 >>  2007 model's firmware flashed, but I don't think that impacts
 >> FreeBSD).
 >
 > Yes, that is one of the catagories of rare, a EFI-32 bit system 
that
 > was originally shipped with a 32 bit only CPU, that later got 
upgraded

 > in the field with a 64 bit CPU, that still runs a EFI-32 bios.
 > Are you sure the 2007 firmware is EFI32?  I would of thought
 > since they upgraded the base system to a 64 bit CPU they would
 > of shipped it with a EFI-64 bios.

 The EFI firmware is technically 64 bit? but it only boots 32-bit
 binaries.

 
https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html
 'Furthermore, it appears that although subsequently released 
MacBook,
 MacBook Air, and pre-"Mid-2010" Mac mini models all are equipped 
with
 "Core 2 Duo" 64-bit processors and 64-bit EFIs, Apple has blocked 
these
 "consumer-targeted" Macs from booting in 64-bit mode. iMac and 
MacBook
 Pro models released in 2007 with 64-bit EFIs seem to have been 
blocked

 as well.'


That is not EFI32, so that is not a test case for how FreeBSD boots
on EFI32 systems.  That is a restriction apple artificially placed
in the implementation.


Yeah, maybe not the best test case, but probably the most common one.
What matters to users is that a 32-bit loader (bootia32.efi) is 
required, whether artificially or not.



 >>  And probably just the 2007 model as well :)
 >>
 >>  Also, IIRC there were some Intel Atom tablets with 32-bit EFI.
 >
 > Atom N2xx and Z5xx series Atom models cannot run x86-64

 Atom Z3740 ? "Instruction Set: 64-bit"
 
https://ark.intel.com/products/76759/Intel-Atom-Processor-Z3740-2M-Cache-up-to-1_86-GHz


The above does not say Atom Z3xxx.  If you find a Atom
N2xx or Z5xx based system it most certainly has a EFI32.



 The tablet in question: ASUS VivoTab Note 8 (M80TA)
 https://www.asus.com/us/Tablets/ASUS_VivoTab_Note_8_M80TA/


I can not find enough detail to know for certain that tablet
actually has which version of EFI.
You are saying it has EFI32?  And if so based on what information?


Heard from someone that it only took 32-bit efi binaries.

Other Z3xxx users report the same:
https://askubuntu.com/questions/775498/ubuntu-on-32-bit-uefi-only-based-tablet-pc



___
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: FreeBSD EFI projects

[Greg V]

On Wed, Sep 19, 2018 at 6:06 PM, Rodney W. Grimes 
 wrote:

 On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
  wrote:
 >>  On 9/18/18 4:11 AM, Greg V wrote:
 >>
 >>  >
 >>  > I can confirm that the kernel already worked fine when booted 
from

 >>  > 32-bit EFI.
 >>  >
 >>  > I booted an old Mac into HardenedBSD using a 32-bit-EFI build 
of

 >> GRUB2 :)
 >>
 >>
 >>  Was that a 64-bit version of FreeBSD? My understanding is the 
32-bit

 >>  FreeBSD boots fine, but 64-bit needs work.
 >
 > You would be hard pressed to find a system with a 64 bit CPU that
 > could run 64 bit FreeBSD that had a 32 bit EFI implementation.

 Mac mini 2006 with a Core2Duo instead of the stock CoreDuo (and the
 2007 model's firmware flashed, but I don't think that impacts 
FreeBSD).


Yes, that is one of the catagories of rare, a EFI-32 bit system that
was originally shipped with a 32 bit only CPU, that later got upgraded
in the field with a 64 bit CPU, that still runs a EFI-32 bios.
Are you sure the 2007 firmware is EFI32?  I would of thought
since they upgraded the base system to a 64 bit CPU they would
of shipped it with a EFI-64 bios.


The EFI firmware is technically 64 bit… but it only boots 32-bit 
binaries.


https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html

'Furthermore, it appears that although subsequently released MacBook, 
MacBook Air, and pre-"Mid-2010" Mac mini models all are equipped with 
"Core 2 Duo" 64-bit processors and 64-bit EFIs, Apple has blocked these 
"consumer-targeted" Macs from booting in 64-bit mode. iMac and MacBook 
Pro models released in 2007 with 64-bit EFIs seem to have been blocked 
as well.'



 And probably just the 2007 model as well :)

 Also, IIRC there were some Intel Atom tablets with 32-bit EFI.


Atom N2xx and Z5xx series Atom models cannot run x86-64


Atom Z3740 — "Instruction Set: 64-bit"
https://ark.intel.com/products/76759/Intel-Atom-Processor-Z3740-2M-Cache-up-to-1_86-GHz

The tablet in question: ASUS VivoTab Note 8 (M80TA)
https://www.asus.com/us/Tablets/ASUS_VivoTab_Note_8_M80TA/

___
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: FreeBSD EFI projects

[Greg V]

On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes 
 wrote:

 On 9/18/18 4:11 AM, Greg V wrote:

 >
 > I can confirm that the kernel already worked fine when booted from
 > 32-bit EFI.
 >
 > I booted an old Mac into HardenedBSD using a 32-bit-EFI build of 
GRUB2 :)



 Was that a 64-bit version of FreeBSD? My understanding is the 32-bit
 FreeBSD boots fine, but 64-bit needs work.


You would be hard pressed to find a system with a 64 bit CPU that
could run 64 bit FreeBSD that had a 32 bit EFI implementation.


Mac mini 2006 with a Core2Duo instead of the stock CoreDuo (and the 
2007 model's firmware flashed, but I don't think that impacts FreeBSD).


And probably just the 2007 model as well :)

Also, IIRC there were some Intel Atom tablets with 32-bit EFI.

___
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: FreeBSD EFI projects

[Greg V]

On 09/18, Rebecca Cran wrote:

On 9/18/18 4:11 AM, Greg V wrote:



I can confirm that the kernel already worked fine when booted from
32-bit EFI.

I booted an old Mac into HardenedBSD using a 32-bit-EFI build of GRUB2 :)



Was that a 64-bit version of FreeBSD? My understanding is the 32-bit
FreeBSD boots fine, but 64-bit needs work.


Yes, of course it was 64-bit.

I don't think I ever downloaded the 32-bit one...
___
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: FreeBSD EFI projects

[Greg V]

On Mon, Sep 17, 2018 at 11:09 PM, Konstantin Belousov 
 wrote:

That said, making only the loader->kernel transition from EFI 32bit to
64bit kernel should be not too hard, and even significantly simpler 
than

to make 32bit EFI load 32bit kernel. amd64 kernels already aware that
there might be no BIOS and they do not try to make vm86 calls into 
real

code, and only read memory map from the loader metadata etc.

Besides old Macs, this should also benefit newer Intel embedded-like
boards.


Hi,

I can confirm that the kernel already worked fine when booted from 
32-bit EFI.


I booted an old Mac into HardenedBSD using a 32-bit-EFI build of GRUB2 
:)


___
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: dmesg output I don't understand

[Greg V]

On Wed, Aug 22, 2018 at 7:20 PM, Per Gunnarsson 
 wrote:

Hello!

What do these lines in my dmesg mean?

I am on amd64.

/usr/src Revision: 338177

/usr/ports Revision: 43

P.S

I got Fatal trap 12 with this revision after installing several fusefs
modules from ports.

After removing fuse from my loader.conf, things booted again.

Regards,

Per Gunnarsson

lock order reversal:
 1st 0xfee82d80 bufwait (bufwait) @ 
/usr/src/sys/kern/vfs_bio.c:3916

 2nd 0xf80005787000 dirhash (dirhash) @
/usr/src/sys/ufs/ufs/ufs_dirhash.c:289


Hi,

this is debugging output you're seeing because your kernel is built 
with the WITNESS option.

(e.g. the default GENERIC kernel in -CURRENT)

lock order reversal is a very common message, you can ignore it.

Switch to GENERIC-NODEBUG to get rid of the messages and get a 
performance boost (these safety checks impact syscall performance)


___
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: Elantech Touchpad Woes - Support for Elantech touchpads over i2c/SMBus still possibly missing

[Greg V]

On Sat, Jun 2, 2018 at 3:14 AM, Albert  wrote:

Hi all,


I'd like to start out by saying that I'm a newcomer to FreeBSD, but 
I've been running Linux for years now and I'm still having a few 
issues transitioning. Despite that. I've been having a blast setting 
things up for myself, and I'm hopeful I can get this resolved soon 
enough.


I'm trying to get FreeBSD running on my laptop, an "Acer Chromebook 
14" (EDGAR), and although I've managed to overcome most of the 
problems I've faced along the way (needing to upgrade to a UEFI, 
misnamed wireless modules, video drivers not working on RELEASE nor 
STABLE), I just can't seem to get the touchpad on this thing to work.


For reference, EDGAR is an Intel Celeron N3160 SoC. Pretty much the 
only thing in it that isn't Intel are the case, the keyboard, the 
webcam and the touchpad. On Linux, the touchpad appears in _/proc_ as

[...]
and it can be seen from _lsmod_ as *elan_i2c*. The source for the 
corresponding driver can be found here: Google ChromeOS Git. 



Now on FreeBSD, it's as though it didn't even exist. Without applying 
any of the changes I've tried to get it working, here's the (verbose) 
output to _dmesg_ on FreeBSD: (vdmesg-nochanges 
). 
With the knowledge I have so far, this is to be expected, as it seems 
FreeBSD requires the *ig4* module to work with *i2c* devices. Loading 
it at boot does seem to make the buses visible, but the touchpad 
still doesn't appear (or not properly, I don't know all these codes): 
(vdmesg-ig4 
). 
The obvious solution is to enable support for elantech devices with 
_hw.psm.elantech_support_, but nada: (vdmesg-elantech 
). 
The only difference is _sysctl_ shows that option is enabled. Aside 
from that, it seems I'm not the only one who's had this sort of issue 
before, so support has been worked on and is claimed to be working. 
Loading the recommended cyapa and chromebook_platform modules at boot 
does not fix this issue: (vdmesg-chromebook 
). 
The reason appears, at least to me, to be that the cyapa driver isn't 
a proper elan driver. These are /different/ devices.


I'm determined to get this working /somehow/, so any help would be 
appreciated. It feels like there's a solution here somewhere and I'm 
either too dumb to find it or it's just not there quite yet. If it's 
the latter, I'm willing to put some work into porting the right 
driver with a little guidance. (I have plenty of experience with C 
but none of this driver stuff.)


Hi! hw.psm.elantech_support is not the solution. hw.psm... psm means 
PS/2 Mouse. This is for PS/2 Elantech touchpads.


cyapa is indeed not the right driver either. The "cy" is for Cypress. 
That's the touchpad found in e.g. the Acer C720.


So there's no support for your touchpad right now.

OpenBSD has HID over i2c support: https://man.openbsd.org/imt -- you 
could try porting that...


Also, should be possible to add i2c support to webcamd I guess, that 
would get the Linux driver running in userspace.

___
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: zfskern{txg_thread_enter} thread using 100% or more CPU

[Greg V]

On Wed, Apr 25, 2018 at 2:30 AM, Steve Wills  wrote:

Hi,

Recently on multiple systems running CURRENT, I've been seeing the 
system become unresponsive. Leaving top(1) running has lead me to 
notice that when this happens, the system is still responding to ping 
and top over ssh is still working, but no new processes can start and 
switching to other tasks doesn't work. In top, I do see pid 17, 
[zfskern{txg_thread_enter}] monopolizing both CPU usage and disk IO. 
Any ideas how to troubleshoot this? It doesn't appear to be a 
hardware issue.

Hi,

Do you have something writing to a gzip compressed dataset? You can use 
the vfssnoop DTrace script from 
https://forums.freebsd.org/threads/sharing-of-dtrace-scripts.32855/#post-181816 
to see who's writing what.


I don't remember if it was exactly txg_thread_enter or whatever, but 
both CPU and disk sounds a lot like heavily compressed writes.


In my case, the Epiphany browser was downloading a large malware 
database to ~/.config/epiphany/gsb-threats.db :D

___
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: Compilation failure of the kernel for drm-next

[Greg V]

On 2/27/2018 5:03 AM, Pete Wright wrote:



On 02/26/2018 17:17, Mylan Connolly wrote:

Hello all,

I'm not sure if this is the best place to send this, but it looks 
like the issue tracker in Github is a bit dead.


there may not be much traffic on it recently, but people are def still 
actively working on the repository and will see when new issues are 
reported.


as of now your best to to use or test out the drm-next bits is to run 
a recent 12-CURRENT with no patches applied.  then you can build the 
port or package via the ports tree under graphics/drm-next-kmod.  it 
currently runs on my end under 12-CURRENT and 11-STABLE.

Yeah, and the issue tracker for drm-next-kmod is

https://github.com/FreeBSDDesktop/kms-drm/issues

NOT https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues
___
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: mlx4 weird error "Failed to map EQ context memory" after update

[Greg V]

On 01/20/2018 12:18, Hans Petter Selasky wrote:

On 01/20/18 00:17, Greg V via freebsd-net wrote:


On 01/19/2018 12:54, Hans Petter Selasky wrote:

On 01/18/18 14:11, Greg V wrote:
Hi. I've upgraded CURRENT from December 19 
(https://github.com/freebsd/freebsd/commit/fd53ccf393f4f8ac1948e97eca108) 
to today 
(https://github.com/freebsd/freebsd/commit/391a83c86bb91ae3840cf37b7de478f42cc97e2a) 
and my Mellanox ConnectX-2 network card stopped working:


mlx4_core0:  mem 
0xfe10-0xfe1f,0xf080-0xf0ff irq 32 at device 0.0 on 
pci7

mlx4_core: Mellanox ConnectX core driver v3.4.1 (October 2017)
mlx4_core: Initializing mlx4_core
mlx4_core0: command 0xffa failed: fw status = 0x1
mlx4_core0: Failed to map EQ context memory, aborting
device_attach: mlx4_core0 attach returned 12


Loading the OLD mlx4.ko and mlx4en.ko on the NEW kernel actually 
does work fine!


Reverting all mlx4 changes between then and now (no big changes, 
mostly just the 1 << 31 thing from D13858) and rebuilding the mlx4 
module with CC=clang50 does not help.


What happened?!

Upgraded CURRENT again today, the problem went away :)
___
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: Broadcom 802.11ac WDI SDIO Adapter (Version 1.605.1.0) not configured

[Greg V]

On 01/24/2018 02:03, KIRIYAMA Kazuhiko wrote:

HI,

Broadcom 802.11ac WDI SDIO Adapter works in Windows but does
not recognaized in my machne[1]. Actually both ifconfig and
pciconf show nothing wifi drives found:

Hi.

SDIO support is not there yet.

Some development is going on:
https://wiki.freebsd.org/SDIO?action=AttachFile=view=sdio_bsdcam.pdf

But seems like it's quite far from actually working with Wi-Fi cards.
___
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: mlx4 weird error "Failed to map EQ context memory" after update

[Greg V]

On 01/19/2018 12:54, Hans Petter Selasky wrote:

On 01/18/18 14:11, Greg V wrote:
Hi. I've upgraded CURRENT from December 19 
(https://github.com/freebsd/freebsd/commit/fd53ccf393f4f8ac1948e97eca108) 
to today 
(https://github.com/freebsd/freebsd/commit/391a83c86bb91ae3840cf37b7de478f42cc97e2a) 
and my Mellanox ConnectX-2 network card stopped working:


mlx4_core0:  mem 
0xfe10-0xfe1f,0xf080-0xf0ff irq 32 at device 0.0 on pci7

mlx4_core: Mellanox ConnectX core driver v3.4.1 (October 2017)
mlx4_core: Initializing mlx4_core
mlx4_core0: command 0xffa failed: fw status = 0x1
mlx4_core0: Failed to map EQ context memory, aborting
device_attach: mlx4_core0 attach returned 12


Loading the OLD mlx4.ko and mlx4en.ko on the NEW kernel actually does 
work fine!


Reverting all mlx4 changes between then and now (no big changes, 
mostly just the 1 << 31 thing from D13858) and rebuilding the mlx4 
module with CC=clang50 does not help.


What happened?!


Hi,

Can you do:

objdump -Dx /boot/kernel/mlx4.ko > mlx4.ko.txt
objdump -Dx /boot/kernel/mlx4en.ko > mlx4en.ko.txt

And diff the text result between working and non-working ko's.
That results in 180883 lines (9.2 megabytes) of diff for mlx4.ko. The 
CC=clang50 one is only a bit better at 7.6 MB :(
Can you also make sure that /boot/modules does not contain anything 
*mlx4* ?

Yeah, it did not contain that.
___
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"

mlx4 weird error "Failed to map EQ context memory" after update

[Greg V]

Hi. I've upgraded CURRENT from December 19 
(https://github.com/freebsd/freebsd/commit/fd53ccf393f4f8ac1948e97eca108) 
to today 
(https://github.com/freebsd/freebsd/commit/391a83c86bb91ae3840cf37b7de478f42cc97e2a) 
and my Mellanox ConnectX-2 network card stopped working:


mlx4_core0:  mem 0xfe10-0xfe1f,0xf080-0xf0ff 
irq 32 at device 0.0 on pci7

mlx4_core: Mellanox ConnectX core driver v3.4.1 (October 2017)
mlx4_core: Initializing mlx4_core
mlx4_core0: command 0xffa failed: fw status = 0x1
mlx4_core0: Failed to map EQ context memory, aborting
device_attach: mlx4_core0 attach returned 12


Loading the OLD mlx4.ko and mlx4en.ko on the NEW kernel actually does 
work fine!


Reverting all mlx4 changes between then and now (no big changes, mostly 
just the 1 << 31 thing from D13858) and rebuilding the mlx4 module with 
CC=clang50 does not help.


What happened?!

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