Is it possible to get fleshed out, human-readable argument lists from ktrace -t c ?

rwp: yah i was just now looking at getting the atheros working

The AR9271 is a single-chip USB 2.0 802.11n solution. It operates in

the 2GHz spectrum and supports a single stream (1T1R).

it looks like the chipset is supported by athn but i couldn't figure out how to get it working out the box and i was having issues getting the ethernet working because i have vlans set up on ports of the wifi router in my living room that i use to do quick work where i need to plug in an ethernet cable

it's too bad the installer doesn't help you go through the wifi motions .. and i'm guessing either my wifi module isn't supported or it just doesn't detect it during install. i bet maybe firmware tomfoolery or who knows what heh

vlans on wifi? i didn't know that was a thing

rtprio: 802.11 allows a VLAN tag in a wireless frame, but i'm not sure that's what OP meant, "ports" probably refers to wired Ethernet ports

so is there no way at all to get drm-510 working on recent 14-STABLE?

515 and 61 are both broken in different ways for me

got a pf question. i don't have "log" in any of my rules, but still when i run tcpdump -e -i pflog0 -l -n -t i still see rules 2 and 6 doing a "pass out ..."

why am i seeing anything if "log" isn't in any of the rules? the default rule is block all, fwiw

515 causes random kernel panics in the LinuxKPI rcu subsystem (iirc), and 61 is at least better than that but I get GPU resets that leave my laptop in an unusable state if I try opening up mpv while I've simultaneously got firefox running

61 seems to have some performance issues as well. I think I'm running into this problem, except FF never triggers it on its own: freebsd/drm-kmod #366

I'd hop on over to current to try out drm-66, but all of the officially published binaries for 15 still have performance degrading debug flags applied, right?

the performance I've been getting out of 14-STABLE lately has basically been making this laptop from 2019 feel like the better part of a decade older than it actually is

I'm wondering at what point the snapshots for 15 will have the full performance of the snapshots for 14. is it when stable/15 gets branched from current in the near future? or is it not until releng/15.0, or later?

Hi

Fixed my internet

let's fix the pkgs now..

good to hear. Good luck

rtprio: what ivy said. Also. Yes. Multiple WiFi networks on different subnets using vlans is why. But I also assign ports to tag because I have iot things attached to it.

I should get a small managed switch for it and keep the ports on the wifi router u tagged. It’s really just a WiFi bridge and since it is in the living room I attach appliances to the Ethernet ports with one leading to the switch in the basement.

guys should I run "pkg upgrade -f".. notice that all pkgs are already for 13.5

It wouldn't hurt

divlamir: but not necessary.. right?

hi, all

Retrofan: No, freebsd-update would have told you if it was necessary. But I would do it to be safe if I make a big jump

it didn't tell me..

Do some testing then, usage will tell if everything is working

yeah

Installed the missing drivers

and I will reboot with x11

I updated the loader

But..

the drivers still have problem..

I already installed drm-kmod

Alver: just curious, what is the output of procstat -k for one of your processes that is uninterruptible sleep on the tun operation?

jmnbtslsQE: mi_switch _cv_wait_unlock tun_destroy tun_clone_destroy if_clone_destroyif_flags if_clone_destroy ifioctl kern_ioctl sys_ioctl amd64_syscall fast_syscall_common

er

why are you spreading this tunfd quite so far and wide, anyways?

kevans: hercules emulator. Not my code (un?)fortunately

tuns are generally expected to be driven by just one process

kevans: that is the stack for the one process.

so presumably it's just forking and still holding the file open in other threads?

Possible. It's way beyond my capabilities for now. :/

got a link to the thing you're working on specifically?

kevans: github.com/SDL-Hercules-390/hyperio…aa6e3fcb72aaf7572dfd4bae91/tuntap.c . But that does not have any of my changes in

... and it doesn't work the least bit out of the box. Looks like no one ever bothered trying to run hercules with QETH on FreeBSD before.

I've written the code for pretty much everything else, but closing a tun created by (my code in) the app is a huge pain.

I can close the file descriptor I get passed, but then the tun just gets dismantled - it remains visible in ifconfig.

Hence my attempt at SIOCIFDESTROY but that's six (seven?) times now that I've screwed over my jail host server with an uninterruptable wait. :°)

If I read the code correctly, on Linux, just closing the last fd to a tun device will automatically tear down and destroy the device too.

yeah, I have a thing to allow ours to do similar

Oooh. That would be *very* convenient.

should probably get that in for 15.0 now that you mention it

Alver: oh, you might also be interested in reviews.freebsd.org/D39740

I was already reading it :D

that at least lets you ^C ifconfig

or whatever's trying to destroy it

Useful indeed. The chicken-egg situation I have is not very handy

Well, hercules has the capability to create a tun device itself for the duration of its emulation, and you can specify the parameters - tun or tap, ips, netmask, mtu, etc etc.

I can already make it do all that (which in itself was already a kludge due to differences in Linux and FreeBSD ioctls). But the cleanup not yet.

Since it's an emulator I also have very little control over what happens on the tun so I can't even properly reproduce the problems I have. It will segfault, hang, or succeed.

I linked in ASan but that didn't show anything overly obvious. Built with -O2, segfault. Built with -O0, hang. But is it related? Who can tell.

Alver: i don't really have time to help there i'm afraid, but i at least pushed those two tuntap patches for 15.0. I think both are reasonable MFC candidates for 14.4, though transient tunnels may be a little trickier

14.4 might just get interruptible destroy

kevans: thanks for the pointers already. I'll keep an eye out

Hi

My PC is finally working!!!

using chatzilla now

Thank you everyone for help.. FreeBSD community is the best :)

so is the OS

Sure!

Upgrading fixed most of my problems and bugs

and with Linux compatibility layer bugs fixed

But.. some problems with AMD radeon drivers :(

Next.. will be fixing my old ports, fixing drivers, building SeaMonkey native; bec. I really need to leave chrome

it's fast.. but doing nothing of my needs

No Plugins, FTP, Gopher, Usenet, IRC, etc..

Congratulations Retrofan

lots of good has been happening the last few days

I'm sure you'll manage to fix the rest, too

I am really want to bring seamonkey to ports tree again..

I loved seamonkey as well

autumnblue: thank you :)

are still user of it

:)

My CRT is making some strange signals

those signals make me fell blind..

haha, some magnet next to it or something perhaps

don't forget to press the degauss button

No magnets

I remember degauss button

this CRT was not powered up for nearly 20 year.. until I begin to use it

Done.

I had a Dell CRT back in the day, using it for nearly 12 years with no need for degaussing

yeah

good times

CRT stuff is so dangerous..

20kv at the rear of the tube, and that's often where the adjustment rheostats are...

yeah

yeah pretty jolty

I remember someone got a shock from that high voltage transformer

but he is fine now..

took them a couple decades to be fine?

oh yeah transformer not CRT I see

he got a burn on his hand

20k shock will surly kill someone..

yeah it's better to be safe

depends on the amps, but yeah, plastic tools ;]

As I know CRT has high amp voltage..

Oh.. gimp is working again

that remember me when I ported it to Atari sparemint

er.. chrome removed support for ublock, hate it more than ever..

then they continued the rest..

I use Qubes OS on my workstation, it's easier to keep things separate

Re: my question last night:

but you buy the price with no DMA forwarding and no hyper threading, but it's all for security

Ah, solved. I thought I had to specify -t options and in doing so zapped the defaults, which included "n trace namei(9) translations"

both are enableable options but messes with security

Wait..

Ghidra is removed from pkgs..?

that's not really how I would characterize it

the port still exists and the license terms don't prevent packaging, there just isn't a package at the moment for whatever reason

yeah understand

it will be a pain to compile a huge software like that :(

I was using on 13.2

pkg search returns ghidra-11.3.1

mine nothing..

I am on 14.3

is 13.5 more updated than 14.3 ?

I may use the pkg files, I still have them

*old

the ports tree is shared across all releases, but it or one of its dependencies could be failing to build on yours for some reason or another

I faced that alot on old ports

look like time to go..

And again thanks for help :)

ghidra can just be run from a directory I think, with whatever tarball the nsa provides or equally

last time I saw, it was basically jre -run ghidra.jar or something.

which of course is ages ago