Re:freebsd-current Digest, Vol 835, Issue 5
Got an answer via telegram: pkg install os-generic-userland-devtools should work, will try soon. Notebook's on r354240, works, but plasma's broken after deleting the whole config and reinstalled all packages. We had that recently with the "division/zero" bug, but my KDE never did again. Doesn't matter, XFCE is good enough for a 65 year-old grandmother running CPU with 70° Celsius not overclocked. Enough chit-chat, MvB Op za, nov. 2, 2019 om 13:02 schreef freebsd-current-requ...@freebsd.org: Send freebsd-current mailing list submissions to freebsd-current@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.freebsd.org/mailman/listinfo/freebsd-current or, via email, send a message with subject or body 'help' to freebsd-current-requ...@freebsd.org You can reach the person managing the list at freebsd-current-ow...@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-current digest..." Today's Topics: 1. GhostBSD and FreeBSD-sources (Miranda van den Breukelingen) 2. Re: GhostBSD and FreeBSD-sources (Clay Daniels) 3. FreeBSD CI Weekly Report 2019-10-27 (Li-Wen Hsu) -- Message: 1 Date: Fri, 1 Nov 2019 15:23:19 +0100 From: Miranda van den Breukelingen To: freebsd-current@freebsd.org Subject: GhostBSD and FreeBSD-sources Message-ID: <33dd6159-89be-ecc9-175f-4d7764e2a...@gmail.com> Content-Type: text/plain; charset=utf-8 Dear specialists, I've been the one who didn't let Xorg -configure happen successfully on current. I tried a lot on freeBSD/TrueOS based distributions and beeing kept at GhostBSD. There the sfcb-driver works and with mode=3 I can get full 1920x1080 now - but Xrender means no desktop cube, lines and less openGL making great lines into the desktop. OpenGL 20/31 does for 20 mins, then kwin_x11 let shine all windows with black entry, so you have to restart. Other WM produce didn't work. So, after Alt+F2 'kstart5 plasmashell' desktop is fully compatible - so never give up on X matters, AMDGPU and radeon don't work as a firmware bug and coulnd't be initialized - not on FreeBSD nor on GhostBSD or whatever. But modesetting is a way to have at least base grafical function.? Now to the question: the latest development release of GhostBSD is 12.1; I svn up'd the freeBSD sources as the kernel boots quickly and is 100% freeBSD IMO - until openRC starts. We have a networkmgr, btw? Wow! And the Software Center grafically without the Arch octopi-clone? Wow again! Let's see what Solaris means after 2010 to me and there's a hackintosh-project, that runs clearly from virtualization but has physical boot-up-problems. But to BSD: the sources '/base/head' should be compatible but is there a+++meta package with kernel build tools and a makeworld that is bootable? What do I need? clang, gcc, cc, sed and what else? There'd to be a meta-package for kernel development! Please don't fool me because of a non-distro question but it matters freeBSD on the base, too.? And if I just can improve the running 12.1. to CURRENT GENERIC it would be a superb effect for many of us! Thx for answers in advance. Miranda PS: my ubt0 makes progress, although not beeing able to connect; but at least the whole stuff doesn't kill itself anymore. -- Message: 2 Date: Fri, 1 Nov 2019 15:49:21 -0500 From: Clay Daniels To: Miranda van den Breukelingen Cc: "freebsd-current@freebsd.org" Subject: Re: GhostBSD and FreeBSD-sources Message-ID: Content-Type: text/plain; charset="UTF-8" GhostBSD is downstream to FreeBSD. Take a look at DistroWatch: https://distrowatch.com/search.php?ostype=BSD=All=All=FreeBSD¬basedon=None=All=All=All=All=All=All=All=All=Active#simple On Fri, Nov 1, 2019 at 3:28 PM Miranda van den Breukelingen < mms.vanbreukelin...@gmail.com> wrote: > Dear specialists, > > I've been the one who didn't let Xorg -configure happen successfully on > current. I tried a lot on freeBSD/TrueOS based distributions and beeing > kept at GhostBSD. There the sfcb-driver works and with mode=3 I can get > full 1920x1080 now - but Xrender means no desktop cube, lines and less > openGL making great lines into the desktop. OpenGL 20/31 does for 20 > mins, then kwin_x11 let shine all windows with black entry, so you have > to restart. Other WM produce didn't work. So, after Alt+F2 'kstart5 > plasmashell' desktop is fully compatible - so never give up on X > matters, AMDGPU and radeon don't work as a firmware bug and coulnd't be > initialized - not on FreeBSD nor on GhostBSD or whatever. But > modesetting is a way to have at least base grafical function. > > Now to the question: the latest development release of GhostBSD is 12.1; > I svn up'd the freeBSD sources as the kernel boots quickly and is 100% >
Re: Problems with AMDGPU and two grafic cards
Hi Pete, did BIOS update, has been critical. in the meantime with lot o'luck I got the scfb-driver to work but only in 1024x76 (but the bios-logo starting in 1920x1280) and with 'dbus-launch kstart5 plasmashell' I have a root-login to plasmashell. I guess I can add further video-modes to the driver in xorg.conf or set the boot kernel option for 1920x1280 but now, after two days with just 3 hours of sleep, I'm too tired and grateful enough it did graphics at all. The CD-medium has been from february and didn't do 'mode 5' on loaders prompt, the one I have now is setting up /usr/src with 1920x1080 (I just thought on 1280x1024, that's a resolution where you really need an expensive screen. It's a ASUS r7240-o4gd5-L (GB, DVI, HDMI, Active, LP) and the Ryzen 7 has 2700MhZ. X. Building llvm-devel now, tried all kmods, all the same old story. A delete of # before hw. syscons.disable=1 is attached. *g* Now with the new base resolution I will get lightdm or even sddm to run my hopes after 35 hours behind screens. Yours, MMS ___ 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: 2 things; a cool crash log of my grandmother-laptop, that's plasma's now bricked; vmn0 not X -configuring
No, there's no LED flashing of SDD when entering to boot the initial modules. On Thu, 10 Oct 2019 at 7:34, Theron wrote: On 2019-10-09 19:46, Miranda van den Breukelingen wrote: > 2. Radeon R7 240 firmware error: > > did hw.syscons.disable=1 in /boot/loader.conf --- nothing, no boot > with none of the kernels. > Really no boot with that line in loader.conf, whereas it could boot previously? Possibly it is booting, but you can't see because the console is gone? The console should come back once amdgpu is loaded. If not, try debugging over ssh. ___ 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: Troubles with the X-Server on an RADEON GPU 240
On Wed, 2 Oct 2019 at 18:50, mms.vanbreukelin...@gmail.com wrote: Forgotten to tell, I did this aleady. User has been already added to the video group. On Wed, 2 Oct 2019 at 18:42, Pete Wright wrote: On 10/2/19 9:36 AM, Miranda Maria Sophie Van den Breukelingen wrote: > Revision: svn'd but not yet built 353009 on CURRENT GENERIC; > built: xorg-xserver; llvm-devel > > X -configure log tells, can't open dev/io; falling back to scfb > no screens found > > /etc/rc.conf: kld_load="amdgpu". > > sddm: > xauth in sloop... > > kernel rebuilt? I would make sure you've installed the drm-kmod pkg, it is not clear to me that you have done this yet as per above. This should install the appropriate kernel drivers, just make sure you read the pkg message after installing it (esp making sure you are a member of the "video" group). -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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"
Kernel panic after rebuilding CURRENT
Had verbose on and got the following kernel error on 290: taskqgroup_adjust_if_config_tqg: panic: sched_pickcpu: failed to find a cpu Looked for device tqg, isn't available in a slightly changing GENERIC custom. I know what this personally means to me, incompatibility and a lack of social integration, but what's the reason for BSD telling me: "thank you, that's it!" I have LOCK_PROFILING as option for building, but this had nothing to do with that kinda problem. Reversion from this morning, as a lack of Inet at the moment, I had to 'svn up' from within Linux with ufs write enabled and gave root to the rescue CD for fsck'ing the /dev/ada0p7. The hashkey terror stops and when unmounted without flags -fl on arch. They're doing well together simple because if unification purpose against monopoly. Had to rebuild without SMP, so virtualization is problematic. #ing the ule_scheduler shouldn't be "unticked", as this causes severe compile errors. I think she just wants a backward development at this age, nostalgia electronica should be a study tribe on universities like history in school! Anyone able to get 2nd CPU up again? ___ 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: The X11 with amdgpu fault
It's on root permissions, 'make install clean --SUID'? (Or is there a scegliere-menue?) I guess u have 'device io' on, otherwise I would rebuild. Give me some time until Internet works again here (a MAN - project) then I'm ready to work again. THX for helping, I just rebuilt the amdgpu-driver, the xorg-server? I would have been let built llvm-devel in the meantime, also not sure if kmod-drivers-fw will do this! OpenGL's 3.1 still a Problem, mostly forced to Xrender. Cu, soon, Miranda On Sun, 22 Sep 2019 at 17:12, Jan Beich wrote: "mms.vanbreukelin...@gmail.com" writes: > The output of the /var/Xorg.log is: > > xf86EnableIO: failed to open /dev/io for Extended I/O Did you build x11-servers/xorg-server with SUID option enabled? For one, /dev/io cannot be opened by anyone but root even after adjusting file permissions. https://github.com/freebsd/freebsd/blob/releng/12.0/sys/dev/io/iodev.c#L73 ___ 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"
The X11 with amdgpu fault
The output of the /var/Xorg.log is: xf86EnableIO: failed to open /dev/io for Extended I/O And then Falling back to old probe for modesetting. Results in: No devices to configureNo screens to configure System repaired in zfs from rescue CD. Another 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: The X11 error correction went to a non-booting kernel
Mr. Clay, Daniels, Jr.,! Sorry for the typo in the mail. Arch linux is a wonderful System as a long as you KISS, therefore an unreachable target and wait for April, 1st, Judd's making a joke then, where it is likely to be known what to do the upcoming year. My Cheetah correction system on androids custom makes bug like this apperently when you don't need it and your insertion device has been stolen. Have you been this, Ganesha-Daniel? If so, rats stay rats even if they win a flight. A gdb for these kinds of v. keyboards, especially when SDDMing has been one of the greatest project for Plasma Neon in development on armhf. So the problem: why are you trying to delete my kerns. ➕ builtworld on a freshly based upsetting of CURRENT with things like lock profiling and an -v flag? I have a 1 year old homebrewed Ryzen 3700 on an Asus 350 Prime + with 16GBs and my grandmother's a Dell Vostro 3000 series. Being this dmesg fancy leads me to conclusion to turn it off on startup services. @gordon: not bullshit at all, just a desperate crying for help on this amdgpu problem. Sorry, no output of anything, especially dmesg or service status as still no web. Ah Daniel, how about booting single, your ELF binaries are damaged now. Look for y97r /device! Miranda On Sat, 21 Sep 2019 at 21:35, Clay Daniels Jr. wrote: Interesting email. Not sure why it went to the Current email list, but it probably does apply to me. Since July I have been following the 13.0 Current weekly snapshots. I wipe the partition and make a clean install, saving any files I might have created to a thumbdrive. Of course these kernels are not booting anymore. They no longer exist. I've been wondering if someone, human or robot, keeps track of Current builds. Apparently so. I recently built me a new computer and have been been busy installing Current on the newer machine. I went from a 2014 All-in-One HP Pavilion 23 with AMD E2 cpu to an AMD Ryzen 7 3700X. If I could help the Current project in any way, like sending a dmesg or such each week, I would be glad to do so. Let me know,Clay Daniels On Sat, Sep 21, 2019 at 12:14 PM mms.vanbreukelin...@gmail.com wrote: - Forwarded message - From: "mms.vanbreukelin...@gmail.com" To: "freebsd-curr...@gmail.com" Cc: Sent: Sat, 21 Sep 2019 at 15:18 Subject: The X11 error correction went to a non-booting kernel @daniel-clay: None of the three kerns. Boot anymore. Gotta install zfs-utils and zfs-dkms-rc on Arsch linux to edit it back again. This besides only if I-Net will be available at i-node. ___ 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-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
The X11 error correction went to a non-booting kernel
- Forwarded message - From: "mms.vanbreukelin...@gmail.com" To: "freebsd-curr...@gmail.com" Cc: Sent: Sat, 21 Sep 2019 at 15:18 Subject: The X11 error correction went to a non-booting kernel @daniel-clay: None of the three kerns. Boot anymore. Gotta install zfs-utils and zfs-dkms-rc on Arsch linux to edit it back again. This besides only if I-Net will be available at i-node. ___ 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: Kernel-Crash when working with ubt0
On Thu, 29 Aug 2019 at 6:04, Warner Losh
wrote:
On Wed, Aug 28, 2019, 8:57 PM Miranda Maria Sophie Van den Breukelingen
wrote:
On Thu, 29 Aug 2019 at 03:48, Warner Losh wrote:
On Wed, Aug 28, 2019, 4:34 PM mms.vanbreukelin...@gmail.com
wrote:
@Maksim, I first did a "git apply -R bt.diff" and then
root@freeBSD13:/usr/src # git apply --stat --check --ignore-whitespace
ng_btsocket_hci_raw.c.diff.txt
error: patch failed:
head/sys/netgraph/bluetooth/socket/ng_btsocket_hci_raw.c:1156
error: head/sys/netgraph/bluetooth/socket/ng_btsocket_hci_raw.c: patch does not
apply
patch -p1 worked for me to apply it.
And it worked just fine for everything once I rebooted. The patch looked fine
to my eye.
Warner
Rebuilding with MTX_SPIN=y (withouth patch)...On Wed, 28 Aug 2019 at 19:10,
Maksim Yevmenkin wrote:
> > > Hmm... interesting
> > >
> > > I only took a brief look at it. I suppose I can ensure user space address
> > > is wired and then copyout() can be called with mutex held
> >
> > >No, you cannot do this, at least without making the kernel to panic.
> > User might unmap the wired mapping at any time still.
>
> Kostik,
>
> i was thinking along the lines of vslock/vsunlock and copyout_nofault.
> basically similar to the sysctl code. do you think this would not
> work?
actually, i dont think i need to hold lock over copyout. attached is
my version of the patch (untested)
thank
max
oh, didn't patch it with the -p1 option, maybe this is why. I rebuild the
kernel and removed the WITNESS option, option MTX_SPIN
# is an illtusion for not locking yourself out
and it does work. When using the built-in-adapter you not just have to reboot
but to turn it off for at least 10 secs., and then reboot into freeBSD again.
Here's what I'm having right now:
/etc/rc.d/bluetooth start ubt0
/etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0
root@freeBSD13:/usr/home/miranda # /etc/rc.d/bluetooth start ubt0
root@freeBSD13:/usr/home/miranda #
So, you got to tell it at least twice because of dmesg often
calling:ng_hci_process_command_timeout: ubt0hci - unable to complete HCI
command OGF=0x3, OCF=0x3. Timeout
The ubt0 is the Asus stack, I can't setup the internal ubt1 anymore at all.
Maybe I'm gonna patch with the -p1 flag tomorrow.
@warner Is there a way to patch a running kernel and just reboot or is it
always in a new buildkernel environment? I did "patch bt.diff";
@maksim; special way to patch correctly?
bluetooth-config scan
Scanning for new Bluetooth devices (Attempt 1 of 5) ... done.
Found 1 new bluetooth device (now scanning for names):
[ 1] c0:7a:a5:00:c7:11 "Ubittek MagicBox" (Ubittek_MagicBox)
Select device to pair with [1, or 0 to rescan]: 1
Warning: An entry for device c0:7a:a5:00:c7:11 is already present in
/etc/bluetooth/hcsecd.conf.
To modify pairing information, edit this file and run
service hcsecd restart
Continue? [yes]: yes
Entry in /etc/bluetooth/hcsecd.conf:device {
bdaddr c0:7a:a5:00:c7:11;
name "Ubittek MagicBox";
key nokey;
pin nopin;
}
l2ping:l2ping -a c0:7a:a5:00:c7:11
16 bytes from Ubittek_MagicBox seq_no=0 time=2611.842 ms result=0
16 bytes from Ubittek_MagicBox seq_no=1 time=6.274 ms result=0
16 bytes from Ubittek_MagicBox seq_no=2 time=6.862 ms result=0
[not 0 bytes??]
but, and this is the status for now:l2control -a c0:7a:a5:00:c7:11
read_channel_list
l2control: Could not bind socket, bdaddr=c0:7a:a5:00:c7:11: Network is down
I think it is paired correctly but doesn't know how to connect; in linux with
bluethothctl I get normally "device paired" self-connection-trial
"device connected" and 5 secs later "device disconnected". It has to do a
salvating "bip" at the box and then it's connected.
kldstat:Id Refs Address Size Name
1 87 0x8020 2288f58 kernel
2 1 0x824ad000 3170 splash_bmp.ko
3 1 0x824b1000 a468 ng_ubt.ko
4 3 0x824bc000 12d10 ng_hci.ko
5 4 0x824cf000 2dc0 ng_bluetooth.ko
6 7 0x824d2000 18d50 netgraph.ko
7 1 0x824eb000 18c28 ng_l2cap.ko
8 1 0x82504000 68840 if_em_updated.ko
9 1 0x8256d000 96fa0 linux64.ko 10 3 0x82604000
b760 linux_common.ko
11 1 0x8261 b4bf0 linux.ko
12 1 0x826c5000 2a78 ubtbcmfw.ko
13 1 0x82d18000 7b040 i915kms.ko
14 1 0x82d94000 3d9e8 drm2.ko
15 4 0x82dd2000 1f40 iicbus.ko
16 1 0x82dd4000 f70 iic.ko
17 1 0x82dd5000 1570 iicbb.ko
18 1 0x82dd7000 15720 if_iwm.ko
19 1 0x82ded000 e045f iwm3160fw.ko
20 1 0x82ece000 1840 uhi
Re: Kernel-Crash when working with ubt0
@Maksim, I first did a "git apply -R bt.diff" and then root@freeBSD13:/usr/src # git apply --stat --check --ignore-whitespace ng_btsocket_hci_raw.c.diff.txt error: patch failed: head/sys/netgraph/bluetooth/socket/ng_btsocket_hci_raw.c:1156 error: head/sys/netgraph/bluetooth/socket/ng_btsocket_hci_raw.c: patch does not apply Rebuilding with MTX_SPIN=y (withouth patch)...On Wed, 28 Aug 2019 at 19:10, Maksim Yevmenkin wrote: > > > Hmm... interesting > > > > > > I only took a brief look at it. I suppose I can ensure user space address > > > is wired and then copyout() can be called with mutex held > > > > >No, you cannot do this, at least without making the kernel to panic. > > User might unmap the wired mapping at any time still. > > Kostik, > > i was thinking along the lines of vslock/vsunlock and copyout_nofault. > basically similar to the sysctl code. do you think this would not > work? actually, i dont think i need to hold lock over copyout. attached is my version of the patch (untested) thanks, max ___ 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: Kernel-Crash when working with ubt0
On Tue, 27 Aug 2019 at 9:11, Konstantin Belousov wrote: On Mon, Aug 26, 2019 at 02:35:25PM -0700, maksim yevmenkin wrote: > > > > On Aug 26, 2019, at 9:14 AM, Warner Losh wrote: > > > > Is it from read_connection_list? If so I have a 'patch' that I'm using but > > haven't committed because it's just too gross: drop the lock before the > > copyout and pick it up again after... > > > > Hmm... interesting > > I only took a brief look at it. I suppose I can ensure user space address is > wired and then copyout() can be called with mutex held >No, you cannot do this, at least without making the kernel to panic. User might unmap the wired mapping at any time still. Is it a userspace specific issue, I don't think so? It's a page fault because of aquired lock. Well, I try two things this evening: 1. I do the patch manually cut'n paste, as git --diff is a weired thing, especially when you come from Arch - but ok, I give this a try. 2. Recompile with option MTX_SPIN=y at the config at /usr/src/head/sys/x86_64/conf/MIRANDA, make with INSTKERNNAME=XYZ compiles ok, but you just get an M at the reversion#, just the CURRENT appears with "uname -a". Would be a bit arrogant, insulant and egoistic calling our Kernel by your first name and Helling everyone you've coded it, IMO. Btw, you can't just mix up LINT and "stock" together, since I did, I know what the long run of -1 means. Not a cool thing, when compiling 8 hours at a (3rd, to be honest) world and then the kernel built just can't bootstrap. I also built two worlds 28 simultaniously from different sources and compared installation. mergemaster's -Ui (or -p) always's to be done at Single Mode with remounting root rw, system is very vulnerable at the moment masterpwd is constructed and groups are merged (this not in Single Mode as it needs the ELF64 for merging correctly (right?) and dbus missing some users afterwards normally. I had to recreate user not just once and to chown 775 it. It has something from an abortion when turning on after install Kernel and screen remains black. This is what all of US fear. zcat under Linux can be a black cat... > > It’s odd that I’ve never seen this before. I’m traveling at the moment will > take a closer look this later this week > > Thanks > Max > ___ > 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" On Mon, Aug 26, 2019 at 02:35:25PM -0700, maksim yevmenkin wrote: > > > > On Aug 26, 2019, at 9:14 AM, Warner Losh wrote: > > > > Is it from read_connection_list? If so I have a 'patch' that I'm using but > > haven't committed because it's just too gross: drop the lock before the > > copyout and pick it up again after... > > > > Hmm... interesting > > I only took a brief look at it. I suppose I can ensure user space address is > wired and then copyout() can be called with mutex held No, you cannot do this, at least without making the kernel to panic. User might unmap the wired mapping at any time still. > > Itâs odd that Iâve never seen this before. Iâm traveling at the moment > will take a closer look this later this week > > Thanks > Max > ___ > 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-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Kernel-Crash when working with ubt0
I'm not repeating myself here: kernel-crash with ubt0 | | | | || | | | | | kernel-crash with ubt0 I'm trying to setup a bluetooth-box with freeBSD 13. uname -a: FreeBSD freeBSD13 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r351273M: Wed Aug 21 06:50:26 CEST 2019 root@freeBSD13:/usr/obj/usr/src/head/amd64.amd64/sys/GENERIC amd64 loading ng_ubt.ko | | | | I swear it has nothing to do with the kernel, with the stock one it's getting to the same point. Miranda ___ 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"
