Re: filemon
On 30 July 2024 5:38:57 pm AWST, Miroslav Lachman <000.f...@quip.cz> wrote:
>On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
>> Gary Jennejohn writes:
>
>[..]
>
>>> I also load it from /boot/loader.conf using filemon_load="YES"
>>
>> This does cause the module to be loaded at boot time, but it's slower
>> than loading it later, and it increases memory fragmentation. A better
>> option is to include "filemon" in the kld_list variable in /etc/rc.conf
>> or /etc/rc.conf.d/kld. For instance,
>>
>> % cat /etc/rc.conf.d/kld/filemon
>> kld_list="${kld_list} filemon"
>
>Does this also apply today? I recently read from someone on a mailing list
>that the kld_list in rc.conf is no longer needed, that any problems it used to
>solve are solved, and that the preferred way is to load everything from
>loader.conf.
Was it the following mail from Warner on a relates commit?
https://lists.freebsd.org/archives/dev-commits-src-main/2024-May/024029.html
--
Sent from a device with a tiny bloody screen and no hard keyboard; please
excuse my brevity.
Re: RES: i made a mess (forgot the buildworld and installworld)
On 2024-07-14 09:54, Ivan Quitschal wrote: > One idea > Cant say it that would help , but ive checked here and 2 things are working > > mount command > usb is all good > > and the filesystem is fine too. > So does anybody knows where I could literally get the entire 15-CURRENT > containing the entire /usr/src in tar.gz or something? Will this help: https://download.freebsd.org/snapshots/amd64/15.0-CURRENT/ I am sure I have done the same in the past. I recall going down the same path as you now, to restore the system. > I could download it from one machine here and stick it and mount in my messed > up freebsd . > and I just checked that tar command still uses libcrypto and would work, > unless I untar it already inside the pendrive and let it ready for copying > over my actual corrupt /usr/src > > of could someone just please send me I don't know those two libs and ill see > what happens? > Are they > > libcrypto.so.111 > libssl.so.111 (git is only complaining about it when I try to fetch pull > (connection and stuff, so who knows) > > thanks a lot whoever could help me out here , > > thank you again > > Ivan > > > > De: owner-freebsd-curr...@freebsd.org Em > nome de Ivan Quitschal > Enviada em: sábado, 13 de julho de 2024 22:05 > Para: freebsd-current@freebsd.org > Assunto: i made a mess (forgot the buildworld and installworld) > > Hi all > > I made a big mess here. Please lets see if you guys have any idea > > I did a > > make buildkernel > make installkernel > Then forgot the buildworld > > And went straight to > make delete-old > make delete-old-libs > > now not even git command, or ports or nothing because everything is missing > on libraries, libssl to download any code with even wget for example > libcrypto.so. for everything else obviously > but the OS is booting and I do have a shell god knows why > > so im not able so far to do any git pull or fetch to do the buildworld and > then the installworld > > > any ideas please: will save my life > > thank you > > tzk
Re: sysutils/pam_xdg: Cancelled on -CURRENT
On 2024-03-19 16:02, Emmanuel Vadot wrote:
> On Tue, 19 Mar 2024 07:55:15 +
> Alastair Hogge wrote:
>
>> On 2024-03-19 15:23, Emmanuel Vadot wrote:
>> > Hi,
>>
>> Hey Emmanuel,
>>
>> > On Tue, 19 Mar 2024 06:54:27 +
>> > Alastair Hogge wrote:
>> >
>> >> Hello,
>> >>
>> >> Recently a similar module (PAM) mentioned in the subject was committed
>> >> to base[1]. The module in base masks the currently installed Port, the
>> >> man page can be accessed with man -M /usr/local/share/man 8 pam_xdg,
>> >> however, I can now no longer build the Port. I noticed that the base
>> >> module has no WITHOUT_ option, tho, that might be extreme for one
>> >> module, but then again, the base module masks a more feature full
>> >> module. What is the practice to enable use of the Port again? At the
>> >> moment I am updating my host, and testing the following:
>> >>
>> >> diff --git a/lib/libpam/modules/modules.inc
>> >> b/lib/libpam/modules/modules.inc
>> >> index f3ab65333f4f..ddbb326f0312 100644
>> >> --- a/lib/libpam/modules/modules.inc
>> >> +++ b/lib/libpam/modules/modules.inc
>> >> @@ -30,4 +30,3 @@ MODULES += pam_ssh
>> >> .endif
>> >> MODULES+= pam_tacplus
>> >> MODULES+= pam_unix
>> >> -MODULES+= pam_xdg
>> >> \ No newline at end of file
>> >>
>> >> 1:
>> >> https://cgit.freebsd.org/src/commit/?id=6e69612d5df1c1d5bd86990ea4d9a170c030b292
>> >>
>> >> Thanks.
>> >>
>> >
>> > I don't see why you can't build the ports.
>>
>> From sysutils/pam_xdg[2]:
>>
>> if exists(/usr/lib/pam_xdg.so)
>> IGNORE= module name conflict with a different implementation in
>> base system
>> endif
>
> Ah yes, I've missed this :)
>
>> > Using would be a problem but why do you want to use it now that we
>> > have one in base ?
>> > Do you have any problems with the one in base ?
>>
>> I would like to continue using sysutils/pam_xdg because it handles all
>> ${XDG_*_HOME}, and local name spaces.
>
> XDG_*_HOME variables aren't needed, all applications must have a
> fallback to the base directories in the spec and sysutils/pam_xdg
> doesn't offer to use other directories so that's why I didn't implement
> those in the base one.
> What do you mean by "local name spaces" ?
I meant all the other ${XDG_FU} excluding ${XDG_*_HOME}.
Anyways, turns out incredibly mistaken. I deployed another corporate
craptop from the dumpster today, and the User's homedir was not
populated with XDG dirs. I was sure I was using sysutils/pam_xdg for
that, but will now have to find my older scripts that predate using
sysutils/pam_xdg, to achieve that. Sorry for the noise.
Thanks,
Alastair
Re: sysutils/pam_xdg: Cancelled on -CURRENT
On 2024-03-19 15:23, Emmanuel Vadot wrote:
> Hi,
Hey Emmanuel,
> On Tue, 19 Mar 2024 06:54:27 +0000
> Alastair Hogge wrote:
>
>> Hello,
>>
>> Recently a similar module (PAM) mentioned in the subject was committed
>> to base[1]. The module in base masks the currently installed Port, the
>> man page can be accessed with man -M /usr/local/share/man 8 pam_xdg,
>> however, I can now no longer build the Port. I noticed that the base
>> module has no WITHOUT_ option, tho, that might be extreme for one
>> module, but then again, the base module masks a more feature full
>> module. What is the practice to enable use of the Port again? At the
>> moment I am updating my host, and testing the following:
>>
>> diff --git a/lib/libpam/modules/modules.inc
>> b/lib/libpam/modules/modules.inc
>> index f3ab65333f4f..ddbb326f0312 100644
>> --- a/lib/libpam/modules/modules.inc
>> +++ b/lib/libpam/modules/modules.inc
>> @@ -30,4 +30,3 @@ MODULES += pam_ssh
>> .endif
>> MODULES+= pam_tacplus
>> MODULES+= pam_unix
>> -MODULES+= pam_xdg
>> \ No newline at end of file
>>
>> 1:
>> https://cgit.freebsd.org/src/commit/?id=6e69612d5df1c1d5bd86990ea4d9a170c030b292
>>
>> Thanks.
>>
>
> I don't see why you can't build the ports.
>From sysutils/pam_xdg[2]:
if exists(/usr/lib/pam_xdg.so)
IGNORE= module name conflict with a different implementation in
base system
endif
> Using would be a problem but why do you want to use it now that we
> have one in base ?
> Do you have any problems with the one in base ?
I would like to continue using sysutils/pam_xdg because it handles all
${XDG_*_HOME}, and local name spaces.
2: https://cgit.freebsd.org/ports/tree/sysutils/pam_xdg/Makefile#n16
Thanks.
sysutils/pam_xdg: Cancelled on -CURRENT
Hello, Recently a similar module (PAM) mentioned in the subject was committed to base[1]. The module in base masks the currently installed Port, the man page can be accessed with man -M /usr/local/share/man 8 pam_xdg, however, I can now no longer build the Port. I noticed that the base module has no WITHOUT_ option, tho, that might be extreme for one module, but then again, the base module masks a more feature full module. What is the practice to enable use of the Port again? At the moment I am updating my host, and testing the following: diff --git a/lib/libpam/modules/modules.inc b/lib/libpam/modules/modules.inc index f3ab65333f4f..ddbb326f0312 100644 --- a/lib/libpam/modules/modules.inc +++ b/lib/libpam/modules/modules.inc @@ -30,4 +30,3 @@ MODULES += pam_ssh .endif MODULES+= pam_tacplus MODULES+= pam_unix -MODULES+= pam_xdg \ No newline at end of file 1: https://cgit.freebsd.org/src/commit/?id=6e69612d5df1c1d5bd86990ea4d9a170c030b292 Thanks.
Re: RFC: NFS over TLS stats
On 2023-10-25 10:50, Rick Macklem wrote: > Garrett Wollman asked me via email how a server > admin could tell what usage NFS over TLS was > happening. > > I admitted that there was nothing. I have come up > with a patch that generates the following: > kern.rpctls.snd_tls_msgbytes: 21508 > kern.rpctls.snd_msgbytes: 20828 > kern.rpctls.snd_tls_msgcnt: 57 > kern.rpctls.snd_msgcnt: 58 > kern.rpctls.rcv_tls_msgbytes: 12336 > kern.rpctls.rcv_msgbytes: 12072 > kern.rpctls.rcv_tls_msgcnt: 57 > kern.rpctls.rcv_msgcnt: 58 > > Basically counts of number of RPC messages > and total number of bytes those messages > result in. (Both with/without TLS.) This is very cool. > Does this seem reasonable or are there better > statistics that could be generated? Obviously > any other suggestion might or might not be > practical to implement. Is there a preference of snd, and rcv, over rx, and tx? snd is also used by sound(4), tho not for statistics.
Re: Fwd: [Bug 270041] www/qt5-webengine: Poudriere build fails for 5.15.8
On 2023-08-13 23:22, Matthias Apitz wrote: > fwd to freebsd-current@ because I don't know if kde@ is read by someone; > > matthias > > - Forwarded message from bugzilla-nore...@freebsd.org - > > Date: Sun, 13 Aug 2023 15:08:04 + > From: bugzilla-nore...@freebsd.org > To: k...@freebsd.org > Subject: [Bug 270041] www/qt5-webengine: Poudriere build fails for 5.15.8 > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270041 Oh nice! How I have missed this BZ report, this will get my 14-CURRENT hosts up to date, thanks for sharing.
Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere
On 2023-08-10 17:38, Matthias Apitz wrote: > El día Wednesday, August 09, 2023 a las 06:04:16PM +0200, Moin Rahman > escribió: > >> This perfectly builds on the latest HEAD without any problem as shared in my >> build log. I am not sure what is wrong at your end. Neither can I see any >> fallout on the clusters. >> > > I've cc'ed freebsd-current@ > > I did two times the building of lang/python27 within poudriere on > 14.0-CURRENT: > > =>> Building lang/python27 > build started at Tue Aug 8 04:05:20 CEST 2023 > port directory: /usr/ports/lang/python27=>> Building lang/python27 > > =>> Building lang/python27 > build started at Thu Aug 10 06:33:53 CEST 2023 > port directory: /usr/ports/lang/python27 > > The first failed, the one of today went fine. The main difference in the > building log is: > > failing job: > --MAKE_ENV-- > OPENSSLBASE=/usr/local OPENSSLDIR=/usr/local/openssl > OPENSSLINC=/usr/local/include OPENSSLLIB=/usr/local/lib > OPENSSLRPATH=/usr/local/lib > > fine job: > --MAKE_ENV-- > OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include > OPENSSLLIB=/usr/lib > ... > > I didn't changed anything in the poudriere config or port's options. The > only thing I did between was yesterday evening a 'git pull' in > /usr/ports. > > What could have triggered this change of the used SSL version? Do you have the error from the failed build? I have the following patch in my tree to get Python-2.7 to build, tho I have not tested recently if it is still required: diff --git a/lang/python27/pkg-plist b/lang/python27/pkg-plist index 4d8dc5b06c81..a92192e6c9d6 100644 --- a/lang/python27/pkg-plist +++ b/lang/python27/pkg-plist @@ -1908,7 +1908,6 @@ lib/python2.7/lib-dynload/_curses.so lib/python2.7/lib-dynload/_curses_panel.so lib/python2.7/lib-dynload/_elementtree.so lib/python2.7/lib-dynload/_functools.so -lib/python2.7/lib-dynload/_hashlib.so lib/python2.7/lib-dynload/_heapq.so lib/python2.7/lib-dynload/_hotshot.so lib/python2.7/lib-dynload/_io.so There was some heavy OpenSSL work recently, and it maybe possible there is some fallout still from that? -- To health and anarchy, Alastair
Re: Lost glabel provider for GELI consumer/storage
Recreating the glabel manually easily sorted that unnecessary panic out. Sorry for the noise, tho another GEOM gem for the records.
Lost glabel provider for GELI consumer/storage
Hello, I have a NFS host that exports one GELI UFS from a stripe of some number of mirrored disks, all GEOM. While replacing a disk in this RAID—far too tired and late one night—I was playing with gcache, adding/removing one gcache device starting at a time to the gmirrors, and then the gstripe. When I was adding a gcache device to the gstripe I accidentally used 'label' (hardcoded metadata on the storage) instead of 'create' on the gstrip: # gcache label -v -b128K -s 1024 cache-test strip/fafnir_graid10 Now unfortunately, the glabel that sits on top of the gstripe, has disappeared. This now results in GELI unable to locate the glabel, and attach. Removing gcache make no difference: # gcache stop -fv cache-test The boot log: /dev/label/fafnir_encfs: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/label/fafnir_encfs: clean, 24114894 free (10902 frags, 3012999 blocks, 0.0% fragmentation) Can't stat /dev/label/fafnir_exportfs.eli: No such file or directory THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: ufs: /dev/label/fafnir_exportfs.eli (/exports) Unknown error 3; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)! Is it possible to restore the glabel for consumption by GELI? I have some backups, going by the filename they might be relevant, tho, I am unsure how to proceed, or if this is possible. To health and anarchy, Alastair
Re: PinePhone Pro Boots On CURRENT
On 2023-05-29 03:24, Pete Wright wrote: > i've had this pinephone pro for a few months now and finally got > around to attempting to boot FreeBSD on it. Here's the phone: > https://wiki.pine64.org/wiki/PinePhone_Pro > > I needed to get this serial console adapter which works flawlessly > with "cu" > (USB TTL Serial Adapter Converter Cable 3.3v/3v3 3.5mm Stereo Jack > Cable): > https://www.amazon.com/dp/B00XSPECIA?psc=1&ref=ppx_yo2ov_dt_b_product_details > > then i just downloaded the latest CURRENT snapshot and put it on a > microsd card and it booted into multi-user mode. here's the dmesg: > https://www.nomadlogic.org/ppro-dmesg.txt My gosh, this is fantastically amazing! Great work, thanking you very muchly, and looking forward to the updates :-) To anarchy and health, Alastair
Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head
Hello Guido, On 2023-05-28 12:44, Guido Falsi wrote: > On 28/05/23 00:42, Alastair Hogge wrote: >> Hello, >> >> Is there some way to test your X session with minimum components, and slowly >> adding whatever XFCE does? > > Maybe I was not perfectly clear. Xorg works fine, I already tested with > another window manager. Perfection is an unhealthy Neo-liberal ideology, I avoid it at all cost. I missed the gitlab link earlier, tho thank you so much for taking the time to explain that again to me, sorry if I have caused an inconvenience here. My sympathies in your struggle, from another AMD GPU FreeBSD struggler.
Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head
Hello, Is there some way to test your X session with minimum components, and slowly adding whatever XFCE does? I would switch from using a X Display Manager, and launch X from the login vty using startx (if not already ), with a minimum .xinitrc. I would find out what is needed to get a minimal XFCE going, for example, maybe just the Window Manager, no Compositor, or nothing at all to see if X handles the display mode setting at all. Also, where are your X logs? It is is normally at /var/log/X.something. It this log empty after the crash? To anarchy and health On 28 May 2023 2:03:51 am AWST, Guido Falsi wrote: >On 27/05/23 10:31, Guido Falsi wrote: >> Hi, >> >> I'm seeing a strange issue with xfwm4 on my laptop running head (commit >> 5804b7ab378d6207130bd1685c931da6a4e76e55), using pkgbase, everything build >> on poudriere. >> >> I have filed an issue upstream with a description and some finding: >> >> https://gitlab.xfce.org/xfce/xfwm4/-/issues/722 >> >> I'm testing changing some things but I get the same exact error 100% >> repeatable. >> > >A friend of mine suggested trying to disable DRI 3 and this indeed allowed >xfwm4 to not crash. > >This is a workaround, not a fix, and does not explain what is causing the >behavior. > >Not sure where I should be looking, I'll also check changes in kernel that >could be related. > >Again if anyone has some insight please share! > >-- >Guido Falsi > > -- Sent from a device with a tiny bloody screen and no hard keyboard; please excuse my brevity.
Re: photo/video on tty console with the new VT/framebuffer
On 2023-05-19 12:51, Ivan Quitschal wrote: > hi Alastair Hey Ivan, > could you please tell us how did you do to make mpv working ? > > when i try to run it, i get something like this: > > $ mpv --vo=drm video.mp4 > (+) Video --vid=1 (*) (h264 424x240 30.000fps) > (+) Audio --aid=1 (*) (aac 2ch 44100Hz) > [vo/drm] No primary DRM device could be picked! > [vo/drm] Failed to find a usable DRM primary node! > [vo/drm] Failed to create KMS. > Error opening/initializing the selected video_out (--vo) device. > Video: no video > > Exiting... (Errors when loading file) > > > thats what i should use correct ? --vo=drm ? What video card are you using? Have you loaded the kernel driver for it? To health and anarchy, Alastair
Re: photo/video on tty console with the new VT/framebuffer
On 2023-05-19 11:30, Tomek CEDRO wrote: > On Fri, May 19, 2023 at 1:28 PM Alastair Hogge wrote: >> As long as those packages support DRMKMS and does your GPU, you can to a >> degree. I noticed video works for mpv and games/sdl, tho, I cannot get >> input working. I tried the Doom 3 port, and watched movies with mpv all >> from the vty just a couple of months ago. > > Yeah, I have input problem too, maybe worth investigating as this is > really neat feature to have gfx with no Xorg :-) It is worth investigating! In a long dead ago project, the input, events, and displays were all integrated into the vty and mux'd from there. The kernel provides evdev devices now, and there is a library, tho I do not know how to get vt(4) to integrate with evdev, or if the library is the way to do it? Any other ideas?
Re: photo/video on tty console with the new VT/framebuffer
On 2023-05-19 11:04, Ivan Quitschal wrote: > Hi all > > i have a question. searched everywhere and found nothing about. > > Is it possible to visualize photos on tty console like we used to on old > SYSCONS by using zgv or something? > > Or watching videos with mpv/mplayer + sdl 2.0/openGL or something? As long as those packages support DRMKMS and does your GPU, you can to a degree. I noticed video works for mpv and games/sdl, tho, I cannot get input working. I tried the Doom 3 port, and watched movies with mpv all from the vty just a couple of months ago. To health and anarchy, Alastair
Re: ns8250: UART FCR is broken
On 2022-10-27 20:57, Matteo Riondato wrote:
> On 2022-10-26 at 17:15 EDT, Colin Percival wrote:
>
>>On 10/26/22 13:48, Ed Maste wrote:
>>>On Mon, 24 Oct 2022 at 22:11, void wrote:
this started appearing in dmesg
ns8250: UART FCR is broken
ns8250: UART FCR is broken
>>>
>>>This message was added as part of Colin's work to support FreeBSD in the
>>>Firecracker VMM
>>>https://cgit.freebsd.org/src/commit/?id=c4b68e7e53bb352be3fa16995b99764c03097e66
>>>
>>>In this case it indicates that bhyve has the same bug/missing functionality
>>>as Firecracker -- it doesn't implement the FCR_XMT_RST or FCR_RCV_RST bits.
>>>You can safely ignore the message, and it will disappear once someone adds
>>>the required support to bhyve. We should probably also have the kernel emit
>>>the message only once. I've CC'd Colin for comment.
>>
>>Indeed, looking at usr.sbin/bhyve/uart_emul.c it looks like FCR_XMT_RST is
>>not emulated. This is different from Firecracker, which doesn't emulate
>>either anything from the FCR and where I was seeing the receive side not
>>being flushed, but I'm glad my warning was able to flag a bug. :-)
>>
>>If "void" is comfortable with kernel hacking, it would be great to confirm
>>>that the warning is indeed coming from the transmit side not being flushed;
>>a printf("drain = %d\n", drain); would be sufficient.
>>
>>And yes, only emitting this warning once per device (or once per boot?) would
>>probably be good.
>
> I got the same message on real hardware, no virtualization involved as
> either host or guest. Is that expected at all?
>
> Relevant lines from /var/run/dmesg.boot:
>
> ns8250: UART FCR is broken
> ns8250: UART FCR is broken
> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> uart0: console (115200,n,8,1)
> ns8250: UART FCR is broken
> ns8250: UART FCR is broken
> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
> ns8250: UART FCR is broken
On 3 × bare metal 14-CURRENT hosts at
017367c1146a69baca6a1a0bea10b0cb02c72d85:
$ dmesg -a | egrep '(ns8250|uart)'
ns8250: UART FCR is broken
ns8250: UART FCR is broken
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
ns8250: UART FCR is broken
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
On Sun, 28 Aug 2022 11:37:16 +0200 Michael Gmelin wrote: > > On 28. Aug 2022, at 10:42, free...@oldach.net wrote: > > > > Cy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200 (CEST): > >> As stated before in this thread, replacing /var/run with tmpfs is > >> not a supported configuration. > > > > Not supported? What is the purpose of /etc/rc.d/var then? That > > creates a tmpfs backed /var, populates it through mtree, and makes > > a proper /var/run available. > > > > However it doesn't (yet) create /var/run/clamav of course. > > > > It would be fairly easy to extend /etc/rc.d/var by a logic that > > walks through /usr/local/etc/mtree/* and runs mtree on each of the > > files found as needed. All that the security/clamav port would need > > to do then is to drop an appropriate small mtree file as > > /usr/local/etc/mtree/clamav. From a port's perspective that is the > > same logic as dropping service scripts as > > /usr/local/etc/rc.d/clamav-*. > > From a user's perspective, it would be preferable to have this happen > at service start though, as (unlike in the setup described) reboots > don't happen that frequently, but files in /var/run might get deleted > manually. Maybe some rc framework based solution would make sense, > e.g., a variable `mtree_files`, which, if set, is applied in the > default start_precmd. Besides being more resilient, this would also > have the advantage that all required file systems should be available > at that point and the separation between system and ports would be > more clear. Another advantage would be that directories are only > created for services that are actually enabled/started. Yes, something in the RC framework would be nice.
Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c
On 30 May 2022 8:38:27 pm AWST, David Wolfskill wrote: >On Mon, May 30, 2022 at 05:16:57AM -0700, Alastair Hogge wrote: >> ... >> I have not been able to use a new /boot/loader.efi (following -CURRENT) >> since >> mid to late 2021, and your symptoms look the same; fortunately, I found >> bug >> report 264282[0] last night, which I think is related. Yamagi has >> already done >> the investigation, and found a possible cause. For the time being, in >> the case >> of a GELI backed UFS mount, after GELI decrypts the mount, one has to >> manually >> set currdev back to the correct disk. >> >> 0: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264282 >> > >I (just) checked; after switching back to the Lua loader, the currdev >variable is set to "disk0s4a:", which is correct for my case. > >Trying loader's "lsdev" command shows the expected disks, slices, and >partitions, correctly identified as FreeBSD UFS, swap, or ZFS. > >Trying to (e.g.) "ls disk0s4a:" fails, saying that it can't find /. Thanks for having a look into that mate. -- Sent from a device with a tiny bloody screen and no hard keyboard; please excuse my brevity.
Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c
On 2022-05-30 07:10, David Wolfskill wrote:
> -- but only on one machine (of the 3 that I use for daily tracking head
> (and stable/12 & stable/13) -- the build machine ("freebeast").
>
> Each is amd64, using ... venerable ... BIOS/MBR & UFS -- stuff that has
> generally been functionally stable for the last couple of decades.
>
> So for yesterday and today, I've moved the new loader aside and copied
> the one from Friday, which works just fine.
>
> The build machine ("freebeast") uses a GENERIC kernel; the other 2 are
> laptops, and use a kernel that includes GENERIC, then tweaks things a
> bit (e.g., dropping support for tape drives; adding IPFIREWALL and
> explicitly NOT setting IPFIREWALL_DEFAULT_TO_ACCEPT; adding sound stuff).
>
> Info on the update history & copies of stuff like most recent
> (verbosely-booted) dmesg.boot should be available at
> https://www.catwhisker.org/~david/FreeBSD/history/ (and if you can't get
> through, please send a note to d...@freebsd.org and I'll do what I can to
> fix it).
>
> (Of the 2 laptops, I only have the one that I actuaqlly use in
> day-to-day work represented.)
>
> (I note that to recover, I boot from one the stable/* slices, move the
> "head" slice's files around, then reboot from the "head" slice.)
>
> AFAICT, there were no changes to stand/* since main-n255828-18054d0220c,
> though yesterday (main-n255828-18054d0220c -> main-n255840-9cb70cb4769),
> there were some changes to sys/ufs/ffs/ffs_subr.c (from
> main-n255835-076002f24d35:
Hey David,
I have not been able to use a new /boot/loader.efi (following -CURRENT)
since
mid to late 2021, and your symptoms look the same; fortunately, I found
bug
report 264282[0] last night, which I think is related. Yamagi has
already done
the investigation, and found a possible cause. For the time being, in
the case
of a GELI backed UFS mount, after GELI decrypts the mount, one has to
manually
set currdev back to the correct disk.
0: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264282
--
To health and anarchy.
Alastair
Re: WITHOUT_PF breaks buildworld
On Sunday, 19 December 2021 6:47:23 PM AWST Gary Jennejohn wrote: > Some recent change, probably in a .mk file, breaks builworld on HEAD > when WITHOUT_PF is enabled in src.conf. I have had to disable WITHOUT_PF since 2020-07-27, but probably earlier. > Disabling WITHOUT_PF results in a successful buildworld. > > The reported error is that netpfil/pf/pf.h can't be found. Some ports depend on that too. -- To health and anarchy Alastair
Re: freebsd 13 ryzen micro stutter
On 2021-03-28 16:09, Hans Petter Selasky wrote: > On 3/27/21 11:54 AM, Santiago Martinez wrote: >> Hi, i have the same output as @Nils B. If i run with steal =2 and dtrace the >> micro stutter doesn't happen but as soon as i stop the dtrace script it the >> stutters come back again. >> > > Here is a patch which you can try. Not sure if it helps. > https://reviews.freebsd.org/D29467 Thanks Hans, this reduces jitter somewhat, but it still noticeable in Quake2. I left kern.sched.steal_thresh at 1. To good health, Alastair. ___ 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 13 ryzen micro stutter
On 2021-03-23 17:34, myfreeweb wrote: > On March 23, 2021 9:11:46 AM UTC, Michael Gmelin wrote: >> >> >>On Mon, 22 Mar 2021 23:50:52 -0400 >>monochrome wrote: >> >>> After about 8 months of struggling to narrow this down I did another >>> search and saw this: >>> >>> https://www.reddit.com/r/freebsd/comments/lc8fwo/freebsd_13_vega_64_micro_stutter_in_x/ >>> >>> I haven't seen this come up here so I thought I would bring it up. >>> >>> My story started sometime before around August last year when synergy >>> started getting really annoying with stuttering. Pretty sure it >>> wasn't like that when I first started tracking 13-current in around >>> May 2020 (I was on 12 with scfb for a long time before that with no >>> issues), but since then I have tried to eliminate as many variables >>> as possible. First I switched to barrier instead of synergy. Shortly >>> after that I realized it was happening all the time and not just a >>> network problem, I started using foobillard to verify during tests. I >>> tried different RAM combinations, different network cards, a variety >>> of RAM timings, stripping rc.conf etc, powerd settings, also scfb, >>> with no effect. It is observable with ping -f, a dot or two appears >>> every time it glitches. It seemed much better with RC2, but now with >>> RC3 it seems to be back with a vengeance, and since its my main >>> workstation and barrier/synergy server host for several machines, it >>> is unbearable to use. Both Win10 and devuan3 on the same machine are >>> smooth with no issues. Any feedback or info would be appreciated. >>> >>> Hardware: >>> ASRock B450M Pro4 >>> Ryzen 2400G, no OC >>> 32M DDR4-2933 >>> Onboard Vega GPU, drm-fbsd13-kmod >>> ___ >> >>Without knowing much about the issue at hand, just a few ideas: >> >>Sysctls I would look at: >>- raising *.cx_lowest >>- different kern.eventtimer.timer > > None of these should be an issue, but: > > sysctl kern.sched.steal_thresh=1 > > For some reason with the default value of 2, I'm seeing weird > stuttering in youtube videos, games, etc. on a 5950X system. 1 (or 0, > IIRC) works fine. I have noticed this too, firefox exhibits the issue frequently, however I have found it most noticeable in games/dhewm3[0] or Yamagi Quake 2[1]. There is a distinct pause every 3 or 4 seconds where the simulation advances significantly. Thanks for the kern.sched.steal_thresh pointer that has sorted the issue out for now. $ dmesg | egrep '(CPU:|avail memory)' CPU: AMD Ryzen 9 3950X 16-Core Processor (3500.02-MHz K8-class CPU) avail memory = 66779394048 (63685 MB) With an AMD NAVI 8GiB GPU, the host should be able to play either game well enuf, Quake 2 came out in 1997 and Doom 3 2004. I am sure Quake 2 used to play without issues on my old AMD bulldozer. 0: https://www.freshports.org/games/dhewm3/ 1: https://github.com/yquake2/yquake2 ___ 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: On 14-CURRENT: no ports options anymore?
On 2021-03-18 18:07, Jamie Landeg-Jones wrote:
> "Hartmann, O." wrote:
>
>> On Sat, 13 Mar 2021 15:13:15 -0500
>> Michael Butler via freebsd-current wrote:
>>
>> > On 3/13/21 3:00 PM, Hartmann, O. wrote:
>> > > On Sat, 13 Mar 2021 19:52:47 + (UTC)
>> > > Filippo Moretti via freebsd-current wrote:
>> > >
>> > >>
>> > >> I had the same problem in console modeFiippo
>> > >> On Saturday, March 13, 2021, 8:33:57 PM GMT+1, Stefan Esser
>> > >>
>> > >> wrote:
>> > >>
>> > >> Am 13.03.21 um 20:17 schrieb Hartmann, O.:
>> > >>> Since I moved on to 14-CURRENT, I face a very strange behaviour when
>> > >>> trying to set
>> > >>> options via "make config" or via poudriere accordingly. I always get
>> > >>> "===> Options
>> > >>> unchanged" (when options has been already set and I'd expect a dialog
>> > >>> menu).
>> > >>> This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is
>> > >>> at FreeBSD
>> > >>> 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET
>> > >>> 2021 amd64).
>> >
>> > I ran into something similar where dialog4ports would dump core after an
>> > upgrade. Rebuilding the port (ports-mgmt/dialog4ports) solved it for me,
>> >
>> >imb
>>
>> Thanks, recompilig ports-mgmt/dialog4ports solved the problem! I was sure
>> that after some
>> ncurses changes in 14-CURRENT I've rebuilt every single port on all
>> 14-CURRENT systems
>> after that incident, bad luck.
>
> This bit me a few years ago - in my case, the terminal type wasn't
> recognised. If dialog4ports
> doesn't run successfully, the error is ignored by the ports scripts.
> This was on a new
> install (hence the reason I hadn't yet installed my termcap), and it
> meant that before I
> noticed, quite a number of ports got installed without the options I wanted.
>
> Since then, I've patched bsd.port.mk with:
>
> --- bsd.port.mk.orig2017-06-06 17:38:00.0 +0100
> +++ bsd.port.mk 2017-06-08 01:31:36.320294000 +0100
> @@ -4729,8 +4729,8 @@
> trap "${RM} $${TMPOPTIONSFILE}; exit 1" 1 2 3 5 10 13 15; \
> ${SETENV} ${D4P_ENV} ${SH} ${SCRIPTSDIR}/dialog4ports.sh
> $${TMPOPTIONSFILE} || { \
> ${RM} $${TMPOPTIONSFILE}; \
> - ${ECHO_MSG} "===> Options unchanged"; \
> - exit 0; \
> + ${ECHO_MSG} "===> ERROR: Options unchanged"; \
> + exit 1; \
> }; \
> ${ECHO_CMD}; \
> if [ ! -e $${TMPOPTIONSFILE} ]; then \
>
> I never submitted this patch, because the way it was written seemed
> intentional. Maybe this should be reviewed?
Something like that would be great, please can we get a more informative
message? I was bitten by this a few times recently.
___
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: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited)
Tested on main-n245400-e75eac2cb81 ___ 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: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited)
On 2021-03-12 12:04, David Wolfskill wrote: > On Thu, Mar 11, 2021 at 07:57:36PM -0800, Alastair Hogge wrote: >> Turns out, EFI boot stopped working. The following boots but fails with >> ... >> umass0: SCSI over Bulk-Only; quirks = 0x4001 >> umass0:6:0: Attached to scbus6 >> Root mount waiting for: usbus5 CAM >> panic: malloc(M_WAITOK) with sleeping prohibited >> cpuid = 0 >> time = 4 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfe0081dcf5f0 >> vpanic() at vpanic+0x181/frame 0xfe0081dcf640 >> panic() at panic+0x43/frame 0xfe0081dcf6a0 >> malloc_dbg() at malloc_dbg+0xd4/frame 0xfe0081dcf6c0 >> malloc() at malloc+0x34/frame 0xfe0081dcf720 >> disk_alloc() at disk_alloc+0x1c/frame 0xfe0081dcf740 >> daregister() at daregister+0x3f4/frame 0xfe0081dcf9c0 >> cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfe0081dcfa90 >> daasync() at daasync+0x2c2/frame 0xfe0081dcfb00 >> xpt_async_process_dev() at xpt_async_process_dev+0x152/frame >> 0xfe0081dcfb50 >> xpt_async_process() at xpt_async_process+0x334/frame 0xfe0081dcfc60 >> xpt_done_process() at xpt_done_process+0x3a3/frame 0xfe0081dcfca0 >> xpt_done_td() at xpt_done_td+0xf5/frame 0xfe0081dcfcf0 >> fork_exit() at fork_exit+0x80/frame 0xfe0081dcfd30 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0081dcfd30 >> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >> > > You may find the change that's in https://reviews.freebsd.org/D29210 > helps -- the trace looks similar to what I saw, and it has worked for > me. > > Note that I only saw the panic while running a kernel with INVARIANTS. Patch works; tested with INVARIANTS only. Thanks all. To good health, Alastair ___ 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: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited)
On 2021-03-12 12:04, David Wolfskill wrote: > On Thu, Mar 11, 2021 at 07:57:36PM -0800, Alastair Hogge wrote: >> Turns out, EFI boot stopped working. The following boots but fails with >> ... >> umass0: SCSI over Bulk-Only; quirks = 0x4001 >> umass0:6:0: Attached to scbus6 >> Root mount waiting for: usbus5 CAM >> panic: malloc(M_WAITOK) with sleeping prohibited >> cpuid = 0 >> time = 4 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfe0081dcf5f0 >> vpanic() at vpanic+0x181/frame 0xfe0081dcf640 >> panic() at panic+0x43/frame 0xfe0081dcf6a0 >> malloc_dbg() at malloc_dbg+0xd4/frame 0xfe0081dcf6c0 >> malloc() at malloc+0x34/frame 0xfe0081dcf720 >> disk_alloc() at disk_alloc+0x1c/frame 0xfe0081dcf740 >> daregister() at daregister+0x3f4/frame 0xfe0081dcf9c0 >> cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfe0081dcfa90 >> daasync() at daasync+0x2c2/frame 0xfe0081dcfb00 >> xpt_async_process_dev() at xpt_async_process_dev+0x152/frame >> 0xfe0081dcfb50 >> xpt_async_process() at xpt_async_process+0x334/frame 0xfe0081dcfc60 >> xpt_done_process() at xpt_done_process+0x3a3/frame 0xfe0081dcfca0 >> xpt_done_td() at xpt_done_td+0xf5/frame 0xfe0081dcfcf0 >> fork_exit() at fork_exit+0x80/frame 0xfe0081dcfd30 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0081dcfd30 >> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >> > > You may find the change that's in https://reviews.freebsd.org/D29210 > helps -- the trace looks similar to what I saw, and it has worked for > me. > > Note that I only saw the panic while running a kernel with INVARIANTS. Fantastic! Thanks for those pointers, I will try imp's fix after the current build finishes. To health, Alastair ___ 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: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited)
Turns out, EFI boot stopped working. The following boots but fails with umass0:6:0: Attached to scbus6 Root mount waiting for: usbus5 CAM panic: malloc(M_WAITOK) with sleeping prohibited Tested with FreeBSD-14.0-CURRENT-amd64-20210311-15565e0a217-257277-mini-memstick.img OK boot [176/1976] Loading kernel... /boot/kernel/kernel text=0x17f580 text=0xe09440 text=0x6a7ae4 data=0x140 data=0x1c2648+0x43c9b8 syms=[0x8+0x187d28+0x8+0x1a8351] Loading configured modules... can't find '/boot/entropy' can't find '/etc/hostid' GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb ---<>--- Copyright (c) 1992-2021 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 14.0-CURRENT #0 main-n245383-15565e0a217: Thu Mar 11 06:32:09 UTC 2021 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 CPU: AMD E-450 APU with Radeon(tm) HD Graphics (1649.98-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x500f20 Family=0x14 Model=0x2 Stepping=0 Features=0x178bfbff Features2=0x802209 AMD Features=0x2e500800 AMD Features2=0x35ff SVM: NP,NRIP,NAsids=8 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 7845748736 (7482 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) arc4random: WARNING: initial seeding bypassed the cryptographic random device because it was not yet seeded and the knob 'bypass_before_seeding' was enabled. Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x/0x1 (20210105/tbfadt-796) ioapic0: MADT APIC ID 0 != hw id 3 ioapic0 irqs 0-23 Launching APs: 1 Timecounter "TSC" frequency 1649980197 Hz quality 800 random: entropy device external interface WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 14.0. kbd1 at kbdmux0 mlx5en: Mellanox Ethernet driver 3.6.0 (December 2020) vtvga0: smbios0: at iomem 0xf0460-0xf047e smbios0: Version: 2.6, BCD Revision: 2.6 aesni0: No AES or SHA support. acpi0: acpi0: Power Button (fixed) cpu0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf0ff mem 0xd000-0xdfff,0xfeb0-0xfeb3 irq 18 at device 1.0 on pci0 vgapci0: Boot video device hdac0: mem 0xfeb44000-0xfeb47fff irq 19 at device 1.1 on pci0 pcib1: irq 16 at device 4.0 on pci0 pci1: on pcib1 igb0: mem 0xfe60-0xfe6f,0xfe784000-0xfe787fff irq 16 at device 0.0 on pci1 igb0: Using 1024 TX descriptors and 1024 RX descriptors igb0: Using 2 RX queues 2 TX queues igb0: Using MSI-X interrupts with 3 vectors igb0: Ethernet address: a0:36:9f:07:d9:58 [103/1976] igb0: netmap queues/slots: TX 2/1024, RX 2/1024 igb1: mem 0xfe50-0xfe5f,0xfe78-0xfe783fff irq 17 at device 0.1 on pci1 igb1: Using 1024 TX descriptors and 1024 RX descriptors igb1: Using 2 RX queues 2 TX queues igb1: Using MSI-X interrupts with 3 vectors igb1: Ethernet address: a0:36:9f:07:d9:59 igb1: netmap queues/slots: TX 2/1024, RX 2/1024 ahci0: port 0xf140-0xf147,0xf130-0xf133,0xf120-0xf127,0xf110-0xf113,0xf100-0xf10f mem 0xfeb4f000-0xfeb4f3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.20 with 6 6Gbps ports, Port Multiplier supported ahci0: quirks=0x22000 ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ohci0: mem 0xfeb4e000-0xfeb4efff irq 18 at device 18.0 on pci
Re: panic in drm or vt or deadlock on mutex or ...
On 2021-02-09 02:20, Emmanuel Vadot wrote: > Alastair: Can you report a bug there : > https://github.com/freebsd/drm-kmod/issues https://github.com/freebsd/drm-kmod/issues/64 ___ 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 ...
On 2021-02-08 21:01, Hans Petter Selasky wrote: > On 2/8/21 1:53 PM, Alastair Hogge wrote: >> Boot to multi-user; login (getty): >> $ doas kldload /boot/modules/amdgpu.ko >> $ sysctl >> [panic] >> >> ..is a guaranteed way to panic my system. > > Hi, > > Maybe you could do a hack and edit the sysctl source code: > > 1) print the sysctl before it is queried. > 2) sleep 1 second between print and query. > > Should be easy to nail this down! Always panics at: $ /tmp/sysctl-with-delay -a [...] p1003_1b.mapped_files: 200112 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.message_passing: 0 p1003_1b.prioritized_io: 0 p1003_1b.priority_scheduling: 200112 p1003_1b.realtime_signals: 200112 p1003_1b.semaphores: 0 p1003_1b.fsync: 200112 p1003_1b.shared_memory_objects: 200112 p1003_1b.synchronized_io: 0 p1003_1b.timers: 200112 p1003_1b.aio_listio_max: 256 p1003_1b.aio_max: 1024 p1003_1b.aio_prio_delta_max: 0 p1003_1b.delaytimer_max: 2147483647 p1003_1b.mq_open_max: 0 p1003_1b.pagesize: 4096 p1003_1b.rtsig_max: 62 p1003_1b.sem_nsems_max: 0 p1003_1b.sem_value_max: 0 p1003_1b.sigqueue_max: 128 p1003_1b.timer_max: 32 ___ 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"
Asus E45M1-M PRO no longer booting since BIOS update
Hello, Recently I wanted to resurrect and old AMD Bobcat (14h) for use with kgdb over dconschat. The system booted a FreeBSD-13.0-ALPHA2-amd64-20210122 without a problem. I noticed the BIOS was ~9 years old, so I updated the to most recent version, which is ~5 years old. After the BIOS update, Any FreeBSD boot image I have tried as far back as 11, no longer boots past the printed EFI framebuffer information. NetBSD-9 and Kunubtu-20.10 all boot OK. I am not having success with remote debugging via Firewire (I recall it used to be far easier), even WITH_LOADER_FIREWIRE, I can still not attach a remote gdb process. My other host which is connected to the E45M1 via Firewire reports when the E45M1 is booting: fwohci0: fwohci_intr_core: BUS reset fwohci0: PhysicalUpperBound register is not implemented. Physical memory access is limited to the first 4GB fwohci0: PhysicalUpperBound = 0x fwohci0: fwohci_intr_core: node_id=0x0001, SelfID Count=2, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) (me) firewire0: bus manager 1 fwohci0: fwohci_intr_core: BUS reset fwohci0: PhysicalUpperBound register is not implemented. Physical memory access is limited to the first 4GB fwohci0: PhysicalUpperBound = 0x fwohci0: fwohci_intr_core: node_id=0x0001, SelfID Count=3, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) (me) firewire0: bus manager 1 firewire0: split transaction timeout: tl=0x14 flag=0x04 send: dst=0x00 tl=0x14 rt=0 tcode=0x4 pri=0x0 src=0x000 $ fwcontrol 2 devices (info_len=2) node EUI64 statushostname 1 00-0f-2e-01-00-00-67-4b 0 -1 00-0f-2e-01-00-00-67-42 0 $ dmesg -a | grep -A3 Tex fwohci0: mem 0xfc904000-0xfc9047ff,0xfc90-0xfc903fff at device 4.0 on pci10 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:0f:2e:01:00:00:67:4b Any ideas on how I can restore FreeBSD on the hardware? To good health, Alastair ___ 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 ...
Sorry, please ignore previous reply, the modified sysctl is still running, the output earlier, was from the stock binary. On 2021-02-09 14:25, Alastair Hogge wrote: > On 2021-02-08 21:01, Hans Petter Selasky wrote: >> On 2/8/21 1:53 PM, Alastair Hogge wrote: >>> Boot to multi-user; login (getty): >>> $ doas kldload /boot/modules/amdgpu.ko >>> $ sysctl >>> [panic] >>> >>> ..is a guaranteed way to panic my system. >> >> Hi, >> >> Maybe you could do a hack and edit the sysctl source code: >> >> 1) print the sysctl before it is queried. >> 2) sleep 1 second between print and query. >> >> Should be easy to nail this down! > > This is all I am able to catch via the ssh session: > vm.uma.sackhole.size: 32 > vm.uma.hostcache.stats.xdomain: 0 > vm.uma.hostcache.stats.fails: 0 > vm.uma.hostcache.stats.frees: 0 > vm.uma.hostcache.stats.allocs: 0 > vm.uma.hostcache.stats.current: 0 > vm.uma.hostcache.domain.0.wss: 0 > vm.uma.hostcache.domain.0.imin: 0 > vm.uma.hostcache.domain.0.imax: 0 > vm.uma.hostcache.domain.0.nitems: 0 > vm.uma.hostcache.limit.bucket_max: 7680 > vm.uma.hostcache.limit.sleeps: 0 > vm.uma.hostcache.limit.sleepers: 0 > vm.uma.hostcache.limit.max_items: 15360 > vm.uma.hostcache.limit.items: 0 > vm.uma.hostcache.keg.domain.0.free_items: 0 > vm.uma.hostcache.keg.domain.0.pages: 0 > vm.uma.hostcache.keg.efficiency: 98 > vm.uma.hostcache.keg.reserve: 0 > vm.uma.hostcache.keg.align: 7 > vm.uma.hostcache.keg.ipers: 42 > vm.uma.hostcache.keg.ppera: 1 > vm.uma.hostcache.keg.rsize: 96 > vm.uma.hostcache.keg.name: hostcache > vm.uma.hostcache.bucket_size_max: 120 > vm.uma.hostcache.bucket_size: 120 > vm.uma.hostcache.flags: 0x4301 > vm.uma.hostcache.size: 96 > vm.uma.syncache.stats.xdomain: 0 > vm.uma.syncache.stats.fails: 0 > vm.uma.syncache.stats.frees: 1 > vm.uma.syncache.stats.allocs: 1 > vm.uma.syncache.stats.current: 0 > vm.uma.syncache.domain.0.wss: 3 > vm.uma.syncache.domain.0.imin: 0 > vm.uma.syncache.domain.0.imax: 0 > vm.uma.syncache.domain.0.nitems: 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: panic in drm or vt or deadlock on mutex or ...
On 2021-02-08 21:01, Hans Petter Selasky wrote: > On 2/8/21 1:53 PM, Alastair Hogge wrote: >> Boot to multi-user; login (getty): >> $ doas kldload /boot/modules/amdgpu.ko >> $ sysctl >> [panic] >> >> ..is a guaranteed way to panic my system. > > Hi, > > Maybe you could do a hack and edit the sysctl source code: > > 1) print the sysctl before it is queried. > 2) sleep 1 second between print and query. > > Should be easy to nail this down! This is all I am able to catch via the ssh session: vm.uma.sackhole.size: 32 vm.uma.hostcache.stats.xdomain: 0 vm.uma.hostcache.stats.fails: 0 vm.uma.hostcache.stats.frees: 0 vm.uma.hostcache.stats.allocs: 0 vm.uma.hostcache.stats.current: 0 vm.uma.hostcache.domain.0.wss: 0 vm.uma.hostcache.domain.0.imin: 0 vm.uma.hostcache.domain.0.imax: 0 vm.uma.hostcache.domain.0.nitems: 0 vm.uma.hostcache.limit.bucket_max: 7680 vm.uma.hostcache.limit.sleeps: 0 vm.uma.hostcache.limit.sleepers: 0 vm.uma.hostcache.limit.max_items: 15360 vm.uma.hostcache.limit.items: 0 vm.uma.hostcache.keg.domain.0.free_items: 0 vm.uma.hostcache.keg.domain.0.pages: 0 vm.uma.hostcache.keg.efficiency: 98 vm.uma.hostcache.keg.reserve: 0 vm.uma.hostcache.keg.align: 7 vm.uma.hostcache.keg.ipers: 42 vm.uma.hostcache.keg.ppera: 1 vm.uma.hostcache.keg.rsize: 96 vm.uma.hostcache.keg.name: hostcache vm.uma.hostcache.bucket_size_max: 120 vm.uma.hostcache.bucket_size: 120 vm.uma.hostcache.flags: 0x4301 vm.uma.hostcache.size: 96 vm.uma.syncache.stats.xdomain: 0 vm.uma.syncache.stats.fails: 0 vm.uma.syncache.stats.frees: 1 vm.uma.syncache.stats.allocs: 1 vm.uma.syncache.stats.current: 0 vm.uma.syncache.domain.0.wss: 3 vm.uma.syncache.domain.0.imin: 0 vm.uma.syncache.domain.0.imax: 0 vm.uma.syncache.domain.0.nitems: 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: panic in drm or vt or deadlock on mutex or ...
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. ___ 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: sleeping thread on r352386
On Monday, 16 September 2019 7:55:32 PM AWST Masachika ISHIZUKA wrote: > Hi. > > This panic happens on 1300047 (both r352239 and r352386) with core > i5-7500 as follows. This panic dose not happen on r351728 (1300044). > (The following lines were typed by hand so they might have some miss > typed letters.) > > == > Sleeping thread (tid 100177, pid 1814) owns a non-sleepable lock > KDB: stack backtrace of thread 100177: [removed backtrace] https://svnweb.freebsd.org/base?view=revision&revision=352393 ___ 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 r338641 with poudriere-devel: seg fault on building x11/kde-workspace-kde4
On Friday, 21 September 2018 11:36:27 PM AWST Matthias Apitz wrote: > El día Friday, September 21, 2018 a las 11:17:59AM +0200, Matthias Apitz escribió: > > === > > ===> kde-workspace-kde4-4.11.22_26 depends on file: /usr/local/sbin/pkg > > - not found ===> Installing existing package > > /packages/All/pkg-1.10.5_3.txz > > [freebsd-r338641-ports-20180920-job-03] Installing pkg-1.10.5_3... > > [freebsd-r338641-ports-20180920-job-03] Extracting pkg-1.10.5_3: > > .. done > > > > I will remove this pkg /packages/All/pkg-1.10.5_3.txz again and will > > poudriere ask to build ports-mgmt/pkg-devel instead of this, because > > this is already on level 1.10.99. > > I found no way that poudriere uses ports-mgmt/pkg-devel, it always > compiles again ports-mgmt/pkg before kde-workspace-kde4-4.11.22_26, > which crashes :-( > > Any hints? What is the contents of make.conf used for the build? On my build host: $ grep WITH_PKG /etc/make.conf WITH_PKG=devel -- To health and anarchy signature.asc Description: This is a digitally signed message part.
Re: Host CPUTYPE?=bdver2 unable to build release target for CPUTYPE?=slm
On Mon, 30 Oct 2017-10-30 15:38:02 Alastair Hogge wrote:
> On Fri, 27 Oct 2017-10-27 12:59:30 Alastair Hogge wrote:
> > Hi,
> >
> > I am attempting to build a release ${SRC}/release/release.sh -c
>
> > ${custom_release.conf}, however, the build fails with:
> Updated log from a host r325110:
>
> [...]
> --- installconfig_subdir_usr.bin/vtfontcvt ---
> [29/2032]
> ===> usr.bin/vtfontcvt (installconfig)
> --- installconfig_subdir_usr.bin/usbhidaction ---
> ===> usr.bin/usbhidaction (installconfig)
> --- installconfig_subdir_usr.bin/usbhidctl ---
> ===> usr.bin/usbhidctl (installconfig)
> --- installconfig_subdir_usr.bin/last ---
> ===> usr.bin/last (installconfig)
> --- installconfig_subdir_usr.bin/users ---
> ===> usr.bin/users (installconfig)
> --- installconfig_subdir_usr.bin/who ---
> ===> usr.bin/who (installconfig)
> --- installconfig_subdir_usr.bin/vi ---
> --- installconfig_subdir_usr.bin/vi/catalog ---
> ===> usr.bin/vi/catalog (installconfig)
> ELF ldconfig path: /lib /usr/lib /usr/lib/compat
> 32-bit compatibility ldconfig path:
> make: "/usr/src/Makefile" line 335: warning: "LC_ALL=C date" exited on a
> signal --- buildworld ---
> make[1]: "/usr/src/Makefile.inc1" line 162: SYSTEM_COMPILER: Determined that
> CC=cc matches the source tree. Not bootstrapping a cross-compiler.
> make[2]: "/usr/src/release/Makefile.ec2" line 9: warning: "date +-%Y-%m-%d"
> exited on a signal
> make[2]: "/usr/src/release/Makefile.azure" line 20: warning: "date
> +-%Y-%m-%d" exited on a signal
> make[2]: "/usr/src/release/Makefile.gce" line 22: warning: "date +-%Y-%m-%d"
> exited on a signal
> make[2]: "/usr/src/release/Makefile.vagrant" line 32: warning: "date
> +-%Y%m%d" exited on a signal
> make[2]: "/usr/src/release/Makefile.vagrant" line 35: warning: "date
> +%Y.%m.%d" exited on a signal
> make[2]: "/usr/src/release/Makefile.ec2" line 9: warning: "date +-%Y-%m-%d"
> exited on a signal
> make[2]: "/usr/src/release/Makefile.azure" line 20: warning: "date
> +-%Y-%m-%d" exited on a signal
> make[2]: "/usr/src/release/Makefile.gce" line 22: warning: "date +-%Y-%m-%d"
> exited on a signal
> make[2]: "/usr/src/release/Makefile.vagrant" line 32: warning: "date
> +-%Y%m%d" exited on a signal
> make[2]: "/usr/src/release/Makefile.vagrant" line 35: warning: "date
> +%Y.%m.%d" exited on a signal
> --- buildworld_prologue ---
> --
>
> >>> World build started on
>
> --
> --- _worldtmp ---
>
> --
>
> >>> Rebuilding the temporary build tree
>
> --
> rm -rf /usr/obj/usr/src/tmp
> mkdir -p /usr/obj/usr/src/tmp/lib
> mkdir -p /usr/obj/usr/src/tmp/lib/casper
> mkdir -p /usr/obj/usr/src/tmp/usr
> mkdir -p /usr/obj/usr/src/tmp/legacy/bin
> mkdir -p /usr/obj/usr/src/tmp/legacy/usr
> mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p
> /usr/obj/usr/src/tmp/legacy/usr >/dev/null
> Illegal instruction (core dumped)
> *** [_worldtmp] Error code 132
>
> make[1]: stopped in /usr/src
> 1 error
>
> make[1]: stopped in /usr/src
> *** [buildworld] Error code 2
>
> make: stopped in /usr/src
> 1 error
>
> make: stopped in /usr/src
>
> # cd /scratch/fafnir/usr/obj/usr/src/tmp/legacy/
> # gdb
> GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html> This is free software: you are free to
> change and redistribute it. There is NO WARRANTY, to the extent permitted
> by law. Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-portbld-freebsd12.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> (gdb) core mtree.core
> [New LWP 101468]
> warning: Unexpected size of section `.reg-xstate/101468' in core file.
> Core was generated by `mtree -deU -f /us
Re: Host CPUTYPE?=bdver2 unable to build release target for CPUTYPE?=slm
On Fri, 27 Oct 2017-10-27 12:59:30 Alastair Hogge wrote:
> Hi,
>
> I am attempting to build a release ${SRC}/release/release.sh -c
> ${custom_release.conf}, however, the build fails with:
Updated log from a host r325110:
[...]
--- installconfig_subdir_usr.bin/vtfontcvt ---
[29/2032]
===> usr.bin/vtfontcvt (installconfig)
--- installconfig_subdir_usr.bin/usbhidaction ---
===> usr.bin/usbhidaction (installconfig)
--- installconfig_subdir_usr.bin/usbhidctl ---
===> usr.bin/usbhidctl (installconfig)
--- installconfig_subdir_usr.bin/last ---
===> usr.bin/last (installconfig)
--- installconfig_subdir_usr.bin/users ---
===> usr.bin/users (installconfig)
--- installconfig_subdir_usr.bin/who ---
===> usr.bin/who (installconfig)
--- installconfig_subdir_usr.bin/vi ---
--- installconfig_subdir_usr.bin/vi/catalog ---
===> usr.bin/vi/catalog (installconfig)
ELF ldconfig path: /lib /usr/lib /usr/lib/compat
32-bit compatibility ldconfig path:
make: "/usr/src/Makefile" line 335: warning: "LC_ALL=C date" exited on a signal
--- buildworld ---
make[1]: "/usr/src/Makefile.inc1" line 162: SYSTEM_COMPILER: Determined that
CC=cc matches the source tree. Not bootstrapping a cross-compiler.
make[2]: "/usr/src/release/Makefile.ec2" line 9: warning: "date +-%Y-%m-%d"
exited on a signal
make[2]: "/usr/src/release/Makefile.azure" line 20: warning: "date +-%Y-%m-%d"
exited on a signal
make[2]: "/usr/src/release/Makefile.gce" line 22: warning: "date +-%Y-%m-%d"
exited on a signal
make[2]: "/usr/src/release/Makefile.vagrant" line 32: warning: "date +-%Y%m%d"
exited on a signal
make[2]: "/usr/src/release/Makefile.vagrant" line 35: warning: "date +%Y.%m.%d"
exited on a signal
make[2]: "/usr/src/release/Makefile.ec2" line 9: warning: "date +-%Y-%m-%d"
exited on a signal
make[2]: "/usr/src/release/Makefile.azure" line 20: warning: "date +-%Y-%m-%d"
exited on a signal
make[2]: "/usr/src/release/Makefile.gce" line 22: warning: "date +-%Y-%m-%d"
exited on a signal
make[2]: "/usr/src/release/Makefile.vagrant" line 32: warning: "date +-%Y%m%d"
exited on a signal
make[2]: "/usr/src/release/Makefile.vagrant" line 35: warning: "date +%Y.%m.%d"
exited on a signal
--- buildworld_prologue ---
--
>>> World build started on
--
--- _worldtmp ---
--
>>> Rebuilding the temporary build tree
--
rm -rf /usr/obj/usr/src/tmp
mkdir -p /usr/obj/usr/src/tmp/lib
mkdir -p /usr/obj/usr/src/tmp/lib/casper
mkdir -p /usr/obj/usr/src/tmp/usr
mkdir -p /usr/obj/usr/src/tmp/legacy/bin
mkdir -p /usr/obj/usr/src/tmp/legacy/usr
mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p
/usr/obj/usr/src/tmp/legacy/usr >/dev/null
Illegal instruction (core dumped)
*** [_worldtmp] Error code 132
make[1]: stopped in /usr/src
1 error
make[1]: stopped in /usr/src
*** [buildworld] Error code 2
make: stopped in /usr/src
1 error
make: stopped in /usr/src
# cd /scratch/fafnir/usr/obj/usr/src/tmp/legacy/
# gdb
Re: Host CPUTYPE?=bdver2 unable to build release target for CPUTYPE?=slm
Source tree is at r325004
On Fri, 27 Oct 2017-10-27 12:59:30 Alastair Hogge wrote:
> Hi,
>
> I am attempting to build a release ${SRC}/release/release.sh -c
> ${custom_release.conf}, however, the build fails with:
>
> make[1]: "/scratch/fafnir/usr/src/Makefile.inc1" line 162: SYSTEM_COMPILER:
> Determined that CC=cc matches the source tree. Not bootstrapping a cross-
> compiler.
> --
>
> >>> World build started on Fri Oct 27 00:41:56 UTC 2017
>
> --
>
> --
>
> >>> Rebuilding the temporary build tree
>
> --
>
> --
>
> >>> stage 1.1: legacy release compatibility shims
>
> --
> ===> tools/build (obj,includes,all,install)
>
> --
>
> >>> stage 1.2: bootstrap tools
>
> --
> ===> lib/clang/libllvmminimal (obj,all,install)
> ===> usr.bin/clang/llvm-tblgen (obj,all,install)
> ===> usr.bin/clang/clang-tblgen (obj,all,install)
> ===> kerberos5/tools/make-roken (obj,all,install)
> ===> kerberos5/lib/libroken (obj,all,install)
> ===> kerberos5/lib/libvers (obj,all,install)
> ===> kerberos5/tools/asn1_compile (obj,all,install)
> yacc: 4 shift/reduce conflicts.
> ===> kerberos5/tools/slc (obj,all,install)
> ===> usr.bin/compile_et (obj,all,install)
> ===> usr.bin/fortune/strfile (obj,all,install)
> ===> usr.bin/dtc (obj,all,install)
> ===> usr.bin/lorder (obj,all,install)
> ===> lib/libopenbsd (obj,all,install)
> ===> usr.bin/mandoc (obj,all,install)
> ===> usr.bin/rpcgen (obj,all,install)
> ===> lib/liby (obj,all,install)
> ===> usr.bin/yacc (obj,all,install)
> ===> usr.bin/xinstall (obj,all,install)
> ===> usr.sbin/config (obj,all,install)
> ===> usr.bin/vtfontcvt (obj,all,install)
> ===> usr.bin/localedef (obj,all,install)
> In file included from
> /scratch/fafnir/usr/src/usr.bin/localedef/collate.c:50: In file included
> from /scratch/fafnir/usr/src/lib/libc/locale/collate.h:42:
> /scratch/fafnir/usr/src/lib/libc/locale/xlocale_private.h:168:18: warning:
> passing 'long *' to parameter of type 'volatile u_long *' (aka 'volatile
> unsigned long *') converts between pointers to integer types with different
> sign [-Wpointer-sign]
> atomic_add_long(&(obj->retain_count), 1);
>
> [log trimmed]
>
> ===> usr.sbin/crunch (installconfig)
> ===> usr.sbin/crunch/crunchgen (installconfig)
> ===> usr.sbin/crunch/crunchide (installconfig)
> ===> usr.sbin/unbound (installconfig)
> ===> usr.sbin/unbound/daemon (installconfig)
> ===> usr.sbin/unbound/anchor (installconfig)
> ===> usr.sbin/unbound/checkconf (installconfig)
> ===> usr.sbin/unbound/control (installconfig)
> ===> usr.sbin/unbound/local-setup (installconfig)
> ===> usr.sbin/uathload (installconfig)
> ===> usr.sbin/uhsoctl (installconfig)
> ===> usr.sbin/usbconfig (installconfig)
> ===> usr.sbin/usbdump (installconfig)
> ===> usr.sbin/ac (installconfig)
> ===> usr.sbin/lastlogin (installconfig)
> ===> usr.sbin/utx (installconfig)
> ===> etc (installconfig)
> ELF ldconfig path: /lib /usr/lib /usr/lib/compat
> 32-bit compatibility ldconfig path: /usr/lib32
> make: "/usr/src/Makefile" line 313: warning: "LC_ALL=C date" exited on a
> signal make[1]: "/usr/src/Makefile.inc1" line 162: SYSTEM_COMPILER:
> Determined that CC=cc matches the source tree. Not bootstrapping a
> cross-compiler. make[2]: "/usr/src/release/Makefile.ec2" line 9: warning:
> "date +-%Y-%m-%d" exited on a signal
> make[2]: "/usr/src/release/Makefile.azure" line 20: warning: "date
> +-%Y-%m-%d" exited on a signal
> make[2]: "/usr/src/release/Makefile.gce" line 22: warning: "date +-%Y-%m-%d"
> exited on a signal
> make[2]: "/usr/src/release/Makefile.vagrant" line 32: warning: "date
> +-%Y%m%d" exited on a signal
> make[2]: "/usr/src/release/Makefile.vagrant" line 35: warning: "date
> +%Y.%m.%d" exited on a signal
> make[2]: "/usr/src/release/Makefile.ec2" line 9: warning: "date +-%Y-%m-%d"
> exited on a signal
> make[2]: "/usr/src/release/
Host CPUTYPE?=bdver2 unable to build release target for CPUTYPE?=slm
Hi,
I am attempting to build a release ${SRC}/release/release.sh -c
${custom_release.conf}, however, the build fails with:
make[1]: "/scratch/fafnir/usr/src/Makefile.inc1" line 162: SYSTEM_COMPILER:
Determined that CC=cc matches the source tree. Not bootstrapping a cross-
compiler.
--
>>> World build started on Fri Oct 27 00:41:56 UTC 2017
--
--
>>> Rebuilding the temporary build tree
--
--
>>> stage 1.1: legacy release compatibility shims
--
===> tools/build (obj,includes,all,install)
--
>>> stage 1.2: bootstrap tools
--
===> lib/clang/libllvmminimal (obj,all,install)
===> usr.bin/clang/llvm-tblgen (obj,all,install)
===> usr.bin/clang/clang-tblgen (obj,all,install)
===> kerberos5/tools/make-roken (obj,all,install)
===> kerberos5/lib/libroken (obj,all,install)
===> kerberos5/lib/libvers (obj,all,install)
===> kerberos5/tools/asn1_compile (obj,all,install)
yacc: 4 shift/reduce conflicts.
===> kerberos5/tools/slc (obj,all,install)
===> usr.bin/compile_et (obj,all,install)
===> usr.bin/fortune/strfile (obj,all,install)
===> usr.bin/dtc (obj,all,install)
===> usr.bin/lorder (obj,all,install)
===> lib/libopenbsd (obj,all,install)
===> usr.bin/mandoc (obj,all,install)
===> usr.bin/rpcgen (obj,all,install)
===> lib/liby (obj,all,install)
===> usr.bin/yacc (obj,all,install)
===> usr.bin/xinstall (obj,all,install)
===> usr.sbin/config (obj,all,install)
===> usr.bin/vtfontcvt (obj,all,install)
===> usr.bin/localedef (obj,all,install)
In file included from /scratch/fafnir/usr/src/usr.bin/localedef/collate.c:50:
In file included from /scratch/fafnir/usr/src/lib/libc/locale/collate.h:42:
/scratch/fafnir/usr/src/lib/libc/locale/xlocale_private.h:168:18: warning:
passing 'long *' to parameter of type 'volatile u_long *' (aka 'volatile
unsigned long *') converts between pointers to integer types with different
sign [-Wpointer-sign]
atomic_add_long(&(obj->retain_count), 1);
[log trimmed]
===> usr.sbin/crunch (installconfig)
===> usr.sbin/crunch/crunchgen (installconfig)
===> usr.sbin/crunch/crunchide (installconfig)
===> usr.sbin/unbound (installconfig)
===> usr.sbin/unbound/daemon (installconfig)
===> usr.sbin/unbound/anchor (installconfig)
===> usr.sbin/unbound/checkconf (installconfig)
===> usr.sbin/unbound/control (installconfig)
===> usr.sbin/unbound/local-setup (installconfig)
===> usr.sbin/uathload (installconfig)
===> usr.sbin/uhsoctl (installconfig)
===> usr.sbin/usbconfig (installconfig)
===> usr.sbin/usbdump (installconfig)
===> usr.sbin/ac (installconfig)
===> usr.sbin/lastlogin (installconfig)
===> usr.sbin/utx (installconfig)
===> etc (installconfig)
ELF ldconfig path: /lib /usr/lib /usr/lib/compat
32-bit compatibility ldconfig path: /usr/lib32
make: "/usr/src/Makefile" line 313: warning: "LC_ALL=C date" exited on a signal
make[1]: "/usr/src/Makefile.inc1" line 162: SYSTEM_COMPILER: Determined that
CC=cc matches the source tree. Not bootstrapping a cross-compiler.
make[2]: "/usr/src/release/Makefile.ec2" line 9: warning: "date +-%Y-%m-%d"
exited on a signal
make[2]: "/usr/src/release/Makefile.azure" line 20: warning: "date +-%Y-%m-%d"
exited on a signal
make[2]: "/usr/src/rel
Re: release.sh: sh: head: not found \n Unable to determine linker type from LD=ld
On Fri, Jun 23, 2017, at 21:00, Guy Yur wrote:
> On 23 June 2017 at 15:36, Alastair Hogge wrote:
> > Hi,
> >
> > My 12.0-CURRENT r320259 host is unable to complete a release.sh build of
> > a generic world:
> >
> > [...]
> > =/tmp/install.hb5C6cay PATH_LOCALE=/tmp/install.hb5C6cay/locale rm -rf
> > /tmp/install.hb5C6cay
> > sh: head: not found
> > make[4]: "/usr/src/share/mk/bsd.linker.mk" line 42: Unable to determine
> > linker type from LD=ld
> > *** Error code 1
> >
> > ...
> >
> > To good health,
> > Alastair
> > ___
> > 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"
>
> Hi,
>
> I got the same error with r320258.
> Is it because "head" is not part of the bootstrap tools?
>
> I was able to continue by replacing "| head 1" with "| sed -n 1p" in
> _ld_version!= ${${ld}} --version 2>/dev/null | head -n 1 || echo none
>
> head is not in /tmp/install.RANDOMVALUES but sed is.
Great, that worked, thanks :-)
___
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"
release.sh: sh: head: not found \n Unable to determine linker type from LD=ld
Hi, My 12.0-CURRENT r320259 host is unable to complete a release.sh build of a generic world: [...] ./usr.sbin/fstyp missing (created) ./usr.sbin/makefs missing (created) ./usr.sbin/newsyslog missing (created) ./usr.sbin/nmtree missing (created) ./usr.sbin/pw missing (created) ./usr.sbin/rpcbind missing (created) ./usr.sbin/sa missing (created) mtree -deU -i -f /usr/src/etc/mtree/BSD.sendmail.dist -p //usr/obj/usr/src/release/dist/base/ ./var/spool/clientmqueue missing (created) install -l s usr/src/sys //usr/obj/usr/src/release/dist/base/sys cd //usr/obj/usr/src/release/dist/base/usr/share/man; for mandir in man*; do install -l s ../$mandir //usr/obj/usr/src/release/dist/base/usr/share/man/en.ISO8859-1/; install -l s ../$mandir //usr/obj/usr/src/release/dist/base/usr/share/man/en.UTF-8/; done cd //usr/obj/usr/src/release/dist/base/usr/share/openssl/man; for mandir in man*; do install -l s ../$mandir //usr/obj/usr/src/release/dist/base/usr/share/openssl/man/en.ISO8859-1/; done set - `grep "^[a-zA-Z]" /usr/src/etc/man.alias`; while [ $# -gt 0 ] ; do install -l s "$2" "//usr/obj/usr/src/release/dist/base/usr/share/man/$1"; if [ "yes" != "no" ]; then install -l s "$2" "//usr/obj/usr/src/release/dist/base/usr/share/openssl/man/$1"; fi; shift; shift; done set - `grep "^[a-zA-Z]" /usr/src/etc/nls.alias`; while [ $# -gt 0 ] ; do install -l s "$2" "//usr/obj/usr/src/release/dist/base/usr/share/nls/$1"; shift; shift; done cd /usr/src; COMPILER_VERSION=4 COMPILER_FEATURES=c++11 COMPILER_TYPE=clang COMPILER_FREEBSD_VERSION=126 MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= CC="cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++ -target x86_64-unknown-freebsd12.0 --sysroot=/usr/ obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/t mp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/tmp/install.hb5C6cay LD_LIBRARY_PATH=/tmp/install.hb5C6cay PATH_LOCALE=/tmp/install.hb5C6cay/locale make -f Makefile.inc1 __MAKE_SHELL=/tmp/install.hb5C6cay/sh redistribute; COMPILER_VERSION=4 COMPILER_FEATURES=c++11 COMPILER_TYPE=clang COMPILER_FREEBSD_VERSION=120 0006 MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= CC="cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++ -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj /usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/tmp/install.hb5C6cay LD_LIBRARY_PATH =/tmp/install.hb5C6cay PATH_LOCALE=/tmp/install.hb5C6cay/locale rm -rf /tmp/install.hb5C6cay sh: head: not found make[4]: "/usr/src/share/mk/bsd.linker.mk" line 42: Unable to determine linker type from LD=ld *** Error code 1 Stop. make[3]: stopped in /usr/src *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src/release *** Error code 1 Stop. make: stopped in /usr/src/release Interesting how head(1) is not found, it does exists: $ lsc -i /scratch/generic/usr/bin/head 279252 /scratch/generic/usr/bin/head To good health, Alastair ___ 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: ${src}/release/release.sh fails at makefs state
On Mon, 8 May 2017 11:47:23 AM Ngie Cooper wrote: [...] > Hi Alastair, > r317967 should allow you to build release images again. Thank you very muchly, Alastair ___ 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: ${src}/release/release.sh fails at makefs state
On Fri, 5 May 2017 11:26:44 PM Ngie Cooper wrote: > (CCing emaste) > > > On May 5, 2017, at 21:55, Alastair Hogge wrote: > … > > > Calculated size of `memstick.img.part': 485474304 bytes, 9435 inodes > > Extent size set to 8192 > > memstick.img.part: 463.0MB (948192 sectors) block size 8192, fragment size > > 1024 > > > >using 9 cylinder groups of 54.38MB, 6960 blks, 1152 inodes. > > > > super-block backups (for fsck -b #) at: > > 32, 111392, 222752, 334112, 445472, 556832, 668192, 779552, 890912, > > > > Populating `memstick.img.part' > > makefs: bread: read 8192 (684294144) returned 0: No error: 0 > > makefs failed > > *** Error code 1 > > Cheers, > -Ngie Thanks Ngie. It look like r317744 is causing the problem: https://svnweb.freebsd.org/base?view=revision&revision=317744 That is the checkout that breaks release building for me, prior revisions cause no problem. To good health, Alastair ___ 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"
${src}/release/release.sh fails at makefs state
Hi, On a r317857 amd64 host, the release.sh build fails: # cd /usr/src/release && ./release.sh [...] ===> usr.sbin/yp_mkdb (installconfig) ===> usr.sbin/yppoll (installconfig) ===> usr.sbin/yppush (installconfig) ===> usr.sbin/ypserv (installconfig) ===> usr.sbin/ypset (installconfig) ===> usr.sbin/keyserv (installconfig) ===> usr.sbin/pkg (installconfig) ===> usr.sbin/pmcannotate (installconfig) ===> usr.sbin/pmccontrol (installconfig) ===> usr.sbin/pmcstat (installconfig) ===> usr.sbin/pmcstudy (installconfig) ===> usr.sbin/edquota (installconfig) ===> usr.sbin/quotaon (installconfig) ===> usr.sbin/repquota (installconfig) ===> usr.sbin/tcpdchk (installconfig) ===> usr.sbin/tcpdmatch (installconfig) ===> usr.sbin/timed (installconfig) ===> usr.sbin/timed/timed (instal
Re: make buildworld broken at r317821 (libsysdecode)
On Fri, 5 May 2017 12:41:27 PM Kyle Evans wrote: [...] > FYI- This has now been committed as r317842. Apologies for the breakage, > and thanks for the reports! Thanks :-) ___ 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: make buildworld broken at r317821 (libsysdecode)
On Fri, 5 May 2017 12:31:41 PM Vladimir Zakharov wrote: > Hello! > > Cannot build world due to error in compiling lib/libsysdecode. Cleaning > (make clean, make cleandepend and wiping out ccache data) does not help. > > $ make -j 4 buildworld && make -j 4 buildkernel && make installkernel > ... [removed build log & host configs] I am having observing the same problem too. I updated to r317713 & rebooted the r317713 host, then I tried to build a release & it failed with the same errors. I checked out a clean copy of src at r317713 into /tmp, removed /etc/make.conf & /etc/src.conf & tried again, tho, still the same problem. I have also tried buildworld on a r317820 check out, however, this also results in the same failure. My host r317713 was built with: $ cat /etc/make.conf ALWAYS_CHECK_MAKE= YES CPUTYPE?= bdver2 DEFAULT_VERSIONS= bdb=5 gcc=6 linux=c7_64 perl5=5.24 ssl=openssl LOADER_FIREWIRE_SUPPORT= KERNCONF= DIREWOLF MALLOC_PRODUCTION= MODULES_OVERRIDE= linux linux_common linprocfs linuxkpi linux64 QT4_OPTIONS=CUPS TEX_DEFAULT=texlive WITH_NVIDIA_GL= WITH_PKG= devel WITH_SSP_PORTS= $ cat /etc/src.conf WITH_BSD_GREP= WITH_CLANG_EXTRAS= WITH_PIE= #WITH_SORT_THREADS= WITHOUT_AMD= WITHOUT_APM= WITHOUT_ATM= WITHOUT_BOOTPARAMD= WITHOUT_BOOTPD= WITHOUT_BLUETOOTH= WITHOUT_BSNMP= WITHOUT_CDDL= WITHOUT_CTM= WITHOUT_CUSE= WITHOUT_DEBUG_FILES= WITHOUT_FDT= WITHOUT_FLOPPY= WITHOUT_FMTREE= WITHOUT_FREEBSD_UPDATE= WITHOUT_FTP= WITHOUT_GCOV= WITHOUT_GDB= WITHOUT_GPL_DTC= WITHOUT_GROFF= WITHOUT_HAST= WITHOUT_HTML= WITHOUT_HYPERV= WITHOUT_INFO= WITHOUT_IPFILTER= WITHOUT_ISCSI= WITHOUT_LEGACY_CONSOLE= WITHOUT_LPR= WITHOUT_NDIS= WITHOUT_NTP= WITHOUT_PC_SYSINSTALL= WITHOUT_PF= WITHOUT_PORTSNAP= WITHOUT_PPP= WITHOUT_PROFILE= WITHOUT_RBOOTD= WITHOUT_RCMDS= WITHOUT_RCS= WITHOUT_SENDMAIL= WITHOUT_SHAREDOCS= WITHOUT_SVNLITE= WITHOUT_SYSCONS= WITHOUT_SYSINSTALL= WITHOUT_TEXINFO= WITHOUT_TESTS= WITHOUT_TFTP= WITHOUT_WIRELESS= WITHOUT_WPA_SUPPLICANT_EAPOL= ___ 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 trap 12 with interrupts disabled
On Sun, 5 Mar 2017 09:50:49 AM Andriy Gapon wrote: > On 05/03/2017 08:08, Chris H wrote: > > Thanks for the reply. > > I rebooted to kernel.old, so I could get the exact > > src revision I built this on. It's r314640 > > > > Any news as to whether it's safe to update src, and > > build a usable kernel? > > Sorry about the breakage. > The fix is in r314700. Thanks :-) ___ 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 trap 12 with interrupts disabled
On Sat, 4 Mar 2017 10:34:39 PM Chris H wrote:
> On Sun, 05 Mar 2017 14:26:31 +0800 Alastair Hogge wrote
>
> > On Sat, 4 Mar 2017 10:08:45 PM Chris H wrote:
> > > Thanks for the reply.
> > > I rebooted to kernel.old, so I could get the exact
> > > src revision I built this on. It's r314640
> > >
> > > Any news as to whether it's safe to update src, and
> > > build a usable kernel?
> >
> > I am not able to boot a kernel > r314627. I currently have a r314627
> > kernel running with a r314687 world.
>
> Looking at the output in my trap; I got the impression that
> the commit: r314636, might be to blame --
[removed commit log]
Thanks for the correct.
> I'm thinking to back that commit out, and giving world/kernel
> another shot.
I changed ${src}/sys/x86/x86/mca.c to return immediately:
--- sys/x86/x86/mca.c (revision 314698)
+++ sys/x86/x86/mca.c (working copy)
@@ -1016,6 +1016,7 @@
static void
_mca_init(int boot)
{
+return;
uint64_t mcg_cap;
uint64_t ctl, mask;
int i, skip;
I have a working & sync'd kernel + world.
___
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 trap 12 with interrupts disabled
On Sat, 4 Mar 2017 10:08:45 PM Chris H wrote: > Thanks for the reply. > I rebooted to kernel.old, so I could get the exact > src revision I built this on. It's r314640 > > Any news as to whether it's safe to update src, and > build a usable kernel? I am not able to boot a kernel > r314627. I currently have a r314627 kernel running with a r314687 world. ___ 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 trap 12 with interrupts disabled
Hi *, On Sat, 4 Mar 2017 07:38:55 PM Chris H wrote: [remove 12-CURRENT history & hardware summary] > I finished the > buildworld, and finished the build/install kernel, and > (attempted) to boot to single user. But got a trap > shortly into booting the new kernel; > > kernel trap 12 with interrupts disabled > > Fatal trap 12: page fault in kernel mode I am also experiencing a similar problem. I believe the error is caused by r314636[0]; committer CC'd. Verbose boot (r314640): /boot/kernel/kernel text=0x8e13d0 data=0xac880+0x3cd6e8 syms=[0x8+0xd6350+0x8+0xd2864] [77/1834] /boot/entropy size=0x1000 Booting... [dcons disconnected (wrong magic 0x)] [dcons connected] GDB: debug ports: dcons GDB: current port: dcons KDB: debugger backends: ddb gdb KDB: current backend: ddb Table 'FACP' at 0xbfdd1080 Table 'MSDM' at 0xbfdd8800 Table 'HPET' at 0xbfdd8880 Table 'MCFG' at 0xbfdd88c0 Table 'EUDS' at 0xbfdd8940 Table 'MATS' at 0xbfdd91a0 Table 'TAMG' at 0xbfdd9210 Table 'APIC' at 0xbfdd8740 APIC: Found table at 0xbfdd8740 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 3 ACPI ID 3: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 4 ACPI ID 4: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 5 ACPI ID 5: enabled SMP: Added CPU 5 (AP) MADT: Found CPU APIC ID 6 ACPI ID 6: enabled SMP: Added CPU 6 (AP) MADT: Found CPU APIC ID 7 ACPI ID 7: enabled SMP: Added CPU 7 (AP) Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r314640: Sat Mar 4 13:10:08 AWST 2017 root@direwolf:/tmp/direwolf/usr/src/sys/DIREWOLF amd64 FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM 4.0.0) WARNING: WITNESS option enabled, expect reduced performance. Table 'FACP' at 0xbfdd1080 Table 'MSDM' at 0xbfdd8800 Table 'HPET' at 0xbfdd8880 Table 'MCFG' at 0xbfdd88c0 Table 'EUDS' at 0xbfdd8940 Table 'MATS' at 0xbfdd91a0 Table 'TAMG' at 0xbfdd9210 Table 'APIC' at 0xbfdd8740 Table 'MATS' at 0xbfdd93c0 Table 'SSDT' at 0xbfddfaf0 Table 'IVRS' at 0xbfde1280 ACPI: No SRAT table found PPIM 0: PA=0xa, VA=0x8141, size=0x1, mode=0 VT(vga): resolution 640x480 Preloaded elf kernel "/boot/kernel/kernel" at 0x81306000. Preloaded /boot/entropy "/boot/entropy" at 0x81306ae8. Calibrating TSC clock ... TSC clock: 4018024582 Hz CPU: AMD FX(tm)-8350 Eight-Core Processor(4018.02-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x600f20 Family=0x15 Model=0x2 Stepping=0 Features=0x178bfbff Features2=0x3e98320b AMD Features=0x2e500800 AMD Features2=0x1ebbfff Structured Extended Features=0x8 SVM: Features=0x1cff,PauseFilterThreshold> Revision=1, ASIDs=65536 TSC: P-state invariant, performance statistics L1 2MB data TLB: 64 entries, fully associative L1 2MB instruction TLB: 24 entries, fully associative L1 4KB data TLB: 64 entries, fully associative L1 4KB instruction TLB: 48 entries, fully associative L1 data cache: 16 kbytes, 64 bytes/line, 1 lines/tag, 4-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB data TLB: 1024 entries, 8-way associative L2 4KB data TLB: 1024 entries, 8-way associative L2 4KB instruction TLB: 1024 entries, 8-way associative L2 unified cache: 2048 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 34359738368 (32768 MB) Physical memory chunk(s): 0x0001 - 0x0005, 327680 bytes (80 pages) 0x0007 - 0x00098fff, 167936 bytes (41 pages) 0x0010 - 0x001f, 1048576 bytes (256 pages) 0x0134 - 0xbfd9, 3198550016 bytes (780896 pages) 0x0001 - 0x00080a849fff, 30241234944 bytes (7383114 pages) avail memory = 33272029184 (31730 MB) Event timer "LAPIC" quality 100 LAPIC: ipi_wait() us multiplier 29 (r 13818693 tsc 4018024582) ACPI APIC Table: Package ID shift: 4 L3 cache ID shift: 3 L2 cache ID shift: 1 L1 cache ID shift: 0 Core ID shift: 0 INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target INTR: Adding local APIC 6 as a target INTR: Adding local APIC 7 as a target FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 8 core(s) Package HW ID = 0 Core HW ID = 0 CPU0 (BSP): APIC ID
Re: [CFT] packaging the base system with pkg(8)
Dear FreeBSD community, Thanks so much for this awesome effort. Will /usr/src/release/release.sh eventually support building base packages as an option? If possible, is it something that we could see soon? Ta, Alastair -- Why isn't there a special name for the tops of your feet? -- Lily Tomlin ___ 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: /usr/local/lib /usr/bin/ld: ø: invalid DSO for symbol
On 2013-10-10 Thu 21:51:48 +0200, Marc UBM wrote: > > Hiho! :-) Hi > Trying to compile several ports in the wake of the recent iconv change > yields the following error that I could not get rid of yet: > > > libtool: link: cc -O2 -pipe -fno-strict-aliasing -Wall > -I/usr/local/include -Wl,-rpath=/usr/local/lib > -Wl,-rpath=/usr/local/lib -o irssi gui-entry.o gui-expandos.o > gui-printtext.o gui-readline.o gui-windows.o lastlog.o mainwindows.o > mainwindow-activity.o mainwindows-layout.o statusbar.o > statusbar-config.o statusbar-items.o term.o term-dummy.o tparm.o > term-terminfo.o terminfo-core.o textbuffer.o textbuffer-commands.o > textbuffer-view.o irssi.o module-formats.o > -Wl,-R/usr/local/lib/perl5/5.14/mach/CORE -pthread -Wl,-E > -fstack-protector -Wl,--export-dynamic -pthread > -Wl,--export-dynamic ../fe-common/irc/libfe_common_irc.a > ../fe-common/irc/dcc/libfe_irc_dcc.a > ../fe-common/irc/notifylist/libfe_irc_notifylist.a > ../fe-common/core/libfe_common_core.a ../irc/libirc.a > ../irc/core/libirc_core.a ../irc/dcc/libirc_dcc.a ../irc/flood/libirc_flood.a > ../irc/notifylist/libirc_notifylist.a ../core/libcore.a > ../lib-config/libirssi_config.a ../perl/.libs/libperl_core_static.a > ../perl/.libs/libfe_perl_static.a > -L/usr/local/lib -L/usr/local/lib/perl5/5.14/mach/CORE -lperl -lm > -lcrypt > -lutil /usr/local/lib/libgmodule-2.0.so /usr/local/lib/libglib-2.0.so > /usr/local/lib/libpcre.so /usr/local/lib/libintl.so > -lssl -lcrypto -lncurses -pthread -Wl,-rpath -Wl,/usr/local/lib > -Wl,-rpath -Wl,/usr/local/lib /usr/bin/ld: ø: invalid DSO for symbol > `tgetnum' definition /usr/local/lib/libtinfo.so.5.9: could not read > symbols: Bad value > > > > Any ideas how to solve that one / if I am doing something wrong? Add the following to the offending ports' Makefile (I am upto 6): LDFLAGS+= -ltinfow > Bye > Marc Salud alastair -- Imagine there's no heaven... it's easy if you try. -- John Lennon, "Imagine" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CURRENT] unbound: zonefiles?
On 2013-09-26 Thu 11:26:48 +0200, O. Hartmann wrote: Hi, > I try my first steps with "unbound" on most recent current and snealing > through the web I find interesting things and howto's. But I realise if > I'd like to replace my office's DNS server (based on BIND as it was > part of the FreeBSD world) I run into a serious problem regarding the > zone- and authorative files keeping all the PTR and A records. As I can > see in the unbound.conf, the statements of those files (address to name > resolution, name to address resolution) is now somehow hard coded into > unbound.conf via those appropriate config tags like local-zone and > local-data. Since I have some larger files defining a local domain, > I'd expect having a data file to be loaded. Are you after include? $ man unbound.conf # Files can be included using the include: directive. It can appear any‐ # where, it accepts a single file name as argument. Processing continues # as if the text from the included file was copied into the config file # at that point. If also using chroot, using full path names for the # included files works, relative pathnames for the included names work if # the directory where the daemon is started equals its chroot/working # directory. Wildcards can be used to include multiple files, see # glob(7). I use include to configure my network at home: $ cat /usr/local/etc/unbound/local.hosts local-data: "kropotkin.local.host. IN A 10.0.0.1 local-data-ptr: "10.0.0.10 kropotkin.local.host. local-data: "berkman.local.host. IN A 10.0.0.11" local-data-ptr: "10.0.0.11 berkman.local.host." local-data: "bakunin.local.host. IN A 10.0.0.12" local-data-ptr: "10.0.0.12 bakunin.local.host." Salud, alastair -- Drug, n.: A substance that, when injected into a rat, produces a scientific paper. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysctl: unknown oid 'kern.random.sys.harvest.interrupt
On 2013-09-21 Sat 12:46:56 +0100, RW wrote:
> On Sat, 21 Sep 2013 11:14:29 +0800
> Alastair Hogge wrote:
>
> > On 2013-09-16 Mon 19:21:39 +0200, Joel Dahl wrote:
> > > Hi,
> >
> > Hi,
> >
> > > I noticed the following during boot on a machine running HEAD from
> > > today:
> >
> > I have noticed this since the recent work to /sys/dev/random
> >
> > > Entropy harvesting:sysctl: unknown oid
> > > 'kern.random.sys.harvest.interrupt': No such file or directory
> > > interruptssysctl: unknown oid 'kern.random.sys.harvest.ethernet':
> > > No such file or directory ethernetsysctl: unknown oid
> > > 'kern.random.sys.harvest.point_to_point': No such file or directory
> > > point_to_point kickstart.
> > >
> > > Known problem?
>
> It looks like /etc/rc.d/initrandom is no longer correctly checking for
> whether the software generator is in use, so it tries to set sysctls
> that don't exist. Those partiticular warnings look harmless.
>
> It might be that writing to /dev/random which occurs immediatly after is
> causing the problem. Try commenting out the following:
>
> # First pass at reseeding /dev/random.
> #
> case ${entropy_file} in
> [Nn][Oo] | '')
> ;;
> *)
> if [ -w /dev/random ]; then
> feed_dev_random "${entropy_file}"
> fi
> ;;
> esac
>
> better_than_nothing
This seems to have worked. 4 successful reboots into multiuser mode.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysctl: unknown oid 'kern.random.sys.harvest.interrupt
On 2013-09-16 Mon 19:21:39 +0200, Joel Dahl wrote: > Hi, Hi, > I noticed the following during boot on a machine running HEAD from today: I have noticed this since the recent work to /sys/dev/random > Entropy harvesting:sysctl: unknown oid 'kern.random.sys.harvest.interrupt': > No such file or directory > interruptssysctl: unknown oid 'kern.random.sys.harvest.ethernet': No such > file or directory > ethernetsysctl: unknown oid 'kern.random.sys.harvest.point_to_point': No > such file or directory > point_to_point kickstart. > > Known problem? I currently have a Supermicro X10SLM-F with an Intel Xeon E3-1240V3 that will often panic when booting into multi-user mode. Booting into single user mode to restore the filesystem will sometimes allow the host to continue to multi-user mode, tho there is still often a panic from this point. I have the system configured with gmirror which has the following GPT configuration: freebsd-boot unencrypted /bootdir encrypted swap encrypted / /boot is a soft link to the unencrypted /bootdir, inspired by: http://cgarcia.org/posts/FreeBSD-FDE-Install.html The system is an AMD64 @ 10.0-ALPHA2 r255729. I can only access single user mode via a Java IMPI console; there might be typos: GEOM_ELI: Crypto hardware Enter passphrase for mirror/gm0p5: GEOM_ELI: Device mirror/gm0p5.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: hardware Trying to mount root from ufs:mirror/gm0p5.eli []... ffclock reset: TSC-low (1700035662 Hz), time = 1379730296.5000 Setting hostuuid: ----002590d6a9dd. Setting hostid: 0x9e7aaf2b Entropy harvesting: interrupts ethernet point_to_point Fatal trap 12: page fault while in kernel mode cpuid = 6; apic id = 06 fault virtual address = 0x0010 fault code = supervisor read data, page not present instruction pointer = 0x20:0x804c0250 stack pointer = 0x28:0xfe046731c600 frame pointer = 0x28:0xfe046731c670 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 = 68 (sysctl) [ thread pid 68 tid 100102 ] Stopped at sysctl_sysctl_net_ls+0x80: movl0x10(%r12),%eax db> bt Tracing pid 68 tid 100102 td 0xf8000b5f9000 sysctl_sysctl_next_ls() at sysctl_sysctl_next_ls+0x80/frame 0xfe046731c670 sysctl_sysctl_next_ls() at sysctl_sysctl_next_ls+0x155/frame 0xfe046731c6e0 sysctl_sysctl_next_ls() at sysctl_sysctl_next_ls+0x191/frame 0xfe046731c750 sysctl_sysctl_next() at sysctl_sysctl_next_ls+0x5e/frame 0xe046731x800 sysctl_root() at sysctl_root+0x1e4/frame 0xe046731c850 userland_sysctl() at userland_sysctl+0x192/frame 0xfe046731c8f0 sys___sysctl() at sys___sysctl+0x74/frame 0xfe046731c9a0 amd64_syscall() at amd64_syscall+0x239/frame 0xfe046731cab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe046731cab0 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x80095553a, rsp = 0x7fffd768, rbp = 0x7fffd7a0 --- db> $ cat /etc/make.conf WITH_PKGNG=YES PERL_VERSION=5.16.3 MAKE_JOBS_NUMBER=9 NO_PROFILE=true CPUTYPE?=corei7-avx PERL_VERSION=5.16.3 $ cat /etc/src.conf ALWAYS_CHECK_MAKE=YES MALLOC_PRODUCTION=YES CC=clang CXX=clang++ CPP=clang-cpp # See man 5 src.conf WITH_BSDCONFIG=YES WITH_BSD_GREP=YES WITH_CLANG_EXTRAS=YES WITH_CLANG_FULL=YES #WITH_DEBUG_FILES=YES WITH_ICONV=YES WITH_LLDB=YES WITH_LIBCPLUSPLUS=YES WITH_NMTREE=YES WITH_SVNLITE=YES WITHOUT_BIND=YES WITHOUT_BIND_IDN=YES WITHOUT_BIND_LARGE_FILE=YES WITHOUT_BIND_SIGCHASE=YES WITHOUT_CTM=YES WITHOUT_CVS=YES WITHOUT_FLOPPY=YES WITHOUT_IPFILTER=YES WITHOUT_IPFW=YES WITHOUT_IPX=YES #WITHOUT_KERBEROS=YES #WITHOUT_KERBEROS_SUPPORT=YES WITHOUT_LPR=YES WITHOUT_NCP=YES #WITHOUT_NIS=YES WITHOUT_RCMDS=YES WITHOUT_SENDMAIL=YES WITHOUT_ZFS=YES $ cat /boot/loader.conf vfs.root.mountfrom="ufs:mirror/gm0p5.eli" loader_logo="beastie" kernel="kernel.DEBUG" kern.cam.ada.legacy_aliases=0 kern.cam.cd.retry_count=0 hw.ivy_rng_enable=0 # does not make any diff. to panic hw.usb.no_boot_wait=1 hw.pci.do_power_nodriver=3 $ cat /etc/rc.conf # Networking hostname="example.org" ifconfig_igb0="inet 10.0.0.2 netmask 255.255.255.0" defaultrouter="10.0.0.1" nsd_enable="NO" unbound_enable="YES" sshd_enable="YES" ftpd_enable="NO" ntpd_sync_on_start="YES" ntpd_enable="YES" nginx_enable="NO" opendnssec_enable="NO" sshguard_watch_logs="/var/log/auth.log" sshguard_enable="YES" # Firewall pflog_logfile="/var/log/pflog" pflog_enable="YES" pf_rules="/etc/pf.conf" pf_enable="YES" # Filesystem background_fsck="NO" dumpdev="AUTO" # Maintenance clear_tmp_enable="YES" clearvar_enalble="YES" populate_var="YES" # Mail sendmail_enable="NO" sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO" smtpd_flags="-v" smtpd_enable="NO" obspamd_flags="-h smtp.example.org -n spamd -v" obspamd
Re: problems with em(4) since update to driver 7.2.2
On Tue, May 03, 2011 at 11:50:53PM +0200, Michael Schmiedgen wrote: > On 03.05.2011 23:24, Jack Vogel wrote: > > If you get the setup receive structures fail, then increase the nmbclusters. > > > > If you use standard MTU then what you need are mbufs, and standard size > > clusters (2K). > > Only when you use jumbo frames will you need larger. > > > > You must configure enough, its that simple. > > I doubled the nmbclusters as well. But nothing happened. > > I have no load on this machine and nothing special > configured. > > Thanks, >Michael Just a me too. I've been following -CURRENT(r221415) but I keep /sys/dev/e1000 at r218909 to keep em0 working without problems on -CURRENT. I also tried 2x, & 4x 25600 for max mbuff clusters via kern.ipc.nmbclusters. This didn't help. -alastair ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
