What does not work very good on FreeBSD

One thing I had specific trouble with recently is bluetooth, which is a shame. Ive got some nice stereo bt speakers and wanted to use them with the thinkpad, which has a bt adapter. I tried the handbook, reading forum, etc, but couldn't get it to work. The bt stack seems to be broken.
 
Suspend, Hibernation, Resume

… I changed from Release to Stable. I just realized that hw.acpi.lid_switch_state=S3 stopped working and now I'm using S5 in the mean time. It is good enough for now.

Sleep and wake (suspend and resume) should be good for the vast majority of users of kernel modesetting drivers.

BobSlacker S3 suspend to RAM (and resume) should be close to perfect. Please post details to a separate topic, ping me from there and I'll help you. Thanks.
 
piizog
This is of no use without naming the type of the Thinkpad. Will you please donate us the missing bits?

Ah, apologies, I wasn't really thinking anybody would be that interested XD

It's X280 type 20KE-SAC100 with i5-8350U and integrated graphics. Seems to have the Intel 8265NGW as the wireless chip. I don't know how to see what driver it's running since I'm still getting used to this FreeBSD thing and lspci doesn’t seem to be a thing.
 
I don't know how to see what driver it's running since I'm still getting used to this FreeBSD thing and lspci doesn’t seem to be a thing.
Code:
# pciconf -lv | grep -b3 network
# kldstat | grep iwn

Intel 8265 is what I have, and I can confirm for you that it works under FreeBSD, and uses the iwn driver.

lspci is a Linux thing, which is different from FreeBSD.
 
… assumed, with all that that implies, that lspci was Linux and pciconf -lv is what I should use on FreeBSD. I learned something.

Linux' lspci and lsusb are feature-rich and have readable output. I am thankful to whoever ported them to FreeBSD. It also makes it easier to write scripts that need that information.

I habitually install sysutils/pciutils and sysutils/usbutils as companions to sysutils/hw-probe. Runtime context for the latter, <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252282#c4>:

sysutils/pciutils and sysutils/usbutils are not recommended because we have pciconf and usbconfig instead in the system by default.
 
What's not listed yet would be smbfs, out of the box.
At least, I need the patch proposed at PR 90815.
And more, if Windows completely drops smb1.x support, anyone who want to mount shares on Windows would lose it on FreeBSD clients. Latest (at least smb/cifs2) support is needed. There seems to be a plan, but its priority looks low.
 
  • Thanks
Reactions: _al
What's not listed yet would be smbfs, out of the box.
At least, I need the patch proposed at PR 90815.
And more, if Windows completely drops smb1.x support, anyone who want to mount shares on Windows would lose it on FreeBSD clients. Latest (at least smb/cifs2) support is needed. There seems to be a plan, but its priority looks low.
Something wrong with having a net/samba413 port?

Not to mention that OpenZFS (which is what FreeBSD has in base) is quite capable of doing remote datasets. Also, OpenSSH is in base, so you can do scp in a pinch. You can't keep everybody happy. FreeBSD is meant to be a pretty minimalistic DIY. Some things do need ironing out, like DHCP...
 
Something wrong with having a net/samba413 port?

Not to mention that OpenZFS (which is what FreeBSD has in base) is quite capable of doing remote datasets. Also, OpenSSH is in base, so you can do scp in a pinch. You can't keep everybody happy. FreeBSD is meant to be a pretty minimalistic DIY. Some things do need ironing out, like DHCP...

This was about the client, not the server.
 
Something wrong with having a net/samba413 port?
Unfortunately, as far as I know, it had no alternative which just works as mount_smbfs to mount remote share onto some local mount point.
And when I tried sysutils/fusefs-smbnetfs at past, it could mount remote share, but automatically unmounted even when reads from the share was ongoing. So I fear to even test writing with it, thus stopped evaluating at the moment.
 
Unfortunately, as far as I know, it had no alternative which just works as mount_smbfs to mount remote share onto some local mount point.
And when I tried sysutils/fusefs-smbnetfs at past, it could mount remote share, but automatically unmounted even when reads from the share was ongoing. So I fear to even test writing with it, thus stopped evaluating at the moment.
Isn't there some kind of .conf directive that prevents the auto-unmounting or something similar? I'd probably want to do some feature research and see if existing features can be used to accomplish that result.
 
Back
Top