On Mon, 09 Aug 2021 15:45:19 +
"Dave Cottlehuber" wrote:
> On Mon, 9 Aug 2021, at 06:54, Gary Jennejohn wrote:
> > On Sun, 8 Aug 2021 18:01:18 -0400
> > Daniel Morante via freebsd-current wrote:
> > > It looks though that this issue might only happen on
ld be. I also tested it on amd64. I don't have any arm64 boxes.
Maybe you could try the test with /bin/sh -x like I did and send the
output to current@. Someone might be able to figure out what's
causing the problem.
> On 8/8/2021 3:03 AM, Gary Jennejohn wrote:
> > On Sat, 7
isto:~ # dumpon /dev/gpt/swap
> root@callisto:~ # dumpon -l
> gpt/swap
>
Works for me if I set dumpdev to AUTO.
I ran '/bin/sh -x dumpon start' and it found the swap entry in /etc/fstab,
as expected.
Does your /etc/fstab entry for swap have the correct syntax? Mine looks
like this:
/dev/ada0p5 noneswapsw 0 0
--
Gary Jennejohn
On Mon, 26 Jul 2021 08:19:41 +0200
Gary Jennejohn wrote:
> On Sun, 25 Jul 2021 19:02:29 +0200
> Gary Jennejohn wrote:
>
> > On Sun, 25 Jul 2021 09:54:35 -0600
> > Warner Losh wrote:
> >
> > > On Sun, Jul 25, 2021 at 3:30 AM Gary Jennejohn
> > >
On Sun, 25 Jul 2021 19:02:29 +0200
Gary Jennejohn wrote:
> On Sun, 25 Jul 2021 09:54:35 -0600
> Warner Losh wrote:
>
> > On Sun, Jul 25, 2021 at 3:30 AM Gary Jennejohn wrote:
> >
> > > I updated my FBSD-14 tree yesterday.
> > >
> > > una
On Sun, 25 Jul 2021 12:35:58 -0400
Dennis Clarke via freebsd-current wrote:
> On 7/25/21 11:54, Warner Losh wrote:
> > On Sun, Jul 25, 2021 at 3:30 AM Gary Jennejohn wrote:
> >
> >> I updated my FBSD-14 tree yesterday.
> >>
> >> uname -a shows FreeBS
On Sun, 25 Jul 2021 09:54:35 -0600
Warner Losh wrote:
> On Sun, Jul 25, 2021 at 3:30 AM Gary Jennejohn wrote:
>
> > I updated my FBSD-14 tree yesterday.
> >
> > uname -a shows FreeBSD 14.0-CURRENT #5 main-n248198-72f7ddb587a.
> >
> > Did a buildker
27;t exist. I got tired of
having to fix that and restart the installworld and simply created
that directory. Note that I always copy the contents of
/usr/src/etc/mtree to /etc/mtree before doing installworld, so mtree
should have created the missing directory if it were required.
--
Gary Jennejohn
_send)
--- kernel.full ---
*** [kernel.full] Error code 1
This is caused because ktls_disable_ifnet() is present in
/sys/kern/uipc_ktls.c, which is included in the kernel build
only when options kern_ktls is present in the config file.
I do not have this option set.
So, it's wrong to blind
On Wed, 7 Jul 2021 09:38:05 +0100
Edward Tomasz Napiera?a wrote:
> On 0705T1833, Gary Jennejohn wrote:
> > On Mon, 5 Jul 2021 15:04:48 +0100
> > Edward Tomasz Napiera__a wrote:
> >
> > > On 0701T1330, Gary Jennejohn wrote:
> > > > Gary Jennejoh
On Mon, 5 Jul 2021 15:04:48 +0100
Edward Tomasz Napiera__a wrote:
> On 0701T1330, Gary Jennejohn wrote:
> > Gary Jennejohn wrote:
> > > I noticed that the value of vm.debug.divisor affects what value is
> > > returned in uma_core.c:uma_dbg_kskip(), so I decided t
Gary Jennejohn wrote:
> On Wed, 30 Jun 2021 10:35:14 -0600
> Warner Losh wrote:
>
> > On Wed, Jun 30, 2021 at 6:58 AM Gary Jennejohn wrote:
> >
> > > On Wed, 30 Jun 2021 06:02:59 +0100
> > > Graham Perrin wrote:
> > >
&
On Wed, 30 Jun 2021 10:35:14 -0600
Warner Losh wrote:
> On Wed, Jun 30, 2021 at 6:58 AM Gary Jennejohn wrote:
>
> > On Wed, 30 Jun 2021 06:02:59 +0100
> > Graham Perrin wrote:
> >
> > > On 29/06/2021 10:42, Gary Jennejohn wrote:
> > > > ___
On Wed, 30 Jun 2021 06:02:59 +0100
Graham Perrin wrote:
> On 29/06/2021 10:42, Gary Jennejohn wrote:
> > ___ panic is now the result of an unaligned free.
> >
> > panic: Unaligned free of 0xf800259e2800 from zone
> > 0xfe00dc9d2000(da_ccb) slab 0xf80
zone
0xfe00dc9d2000(da_ccb) slab 0xf800259e2fd8(3)
I have the crash dump and a debug kernel in case anyone wants more info.
--
Gary Jennejohn
On Sat, 12 Jun 2021 14:10:36 +0100
Edward Tomasz Napiera__a wrote:
> On 0610T1150, Gary Jennejohn wrote:
> > On Tue, 8 Jun 2021 17:54:05 +0200
> > Gary Jennejohn wrote:
> >
> > [big snip]
>
> [..]
>
> > So, I did ``git reset --hard 8dc96b74edb844b
On Tue, 8 Jun 2021 17:54:05 +0200
Gary Jennejohn wrote:
[big snip]
> Here's the kgdb backtrace with the -O0 kernel:
>
> (kgdb) bt
> #0 0x8081d706 in doadump (textdump=0)
> at /usr/src/sys/kern/kern_shutdown.c:398
> #1 0x804ef15a in db_dump (dummy=-2
On Tue, 8 Jun 2021 06:27:04 -0600
Warner Losh wrote:
> On Tue, Jun 8, 2021 at 2:47 AM Gary Jennejohn wrote:
>
[snip old stuff]
> > Here the kgdb backtrace:
> >
> > Unread portion of the kernel message buffer:
> > panic: Duplicate free of 0xf800356b9000 fr
et to 0
and see what happens.
BTW I now have a kernel compiled with -O0 ready to test.
[snip lots of extraneous stuff]
--
Gary Jennejohn
l live in their own little box each of
> which is labeled but things happen ...)
>
I use locate for this kind of search, e.g.
locate netoptions
/etc/rc.d/netoptions
/usr/src/libexec/rc/rc.d/netoptions
--
Gary Jennejohn
On Tue, 8 Jun 2021 11:04:33 +0200
Mateusz Guzik wrote:
> Given how easy it is to reproduce perhaps you can spend a little bit
> of time narrowing it down to a specific commit. You can do it with
> git-bisect.
>
Ok, I'll give it a try.
--
Gary Jennejohn
eroes.
The ccb is enormous and really hard to parse.
--
Gary Jennejohn
On Mon, 7 Jun 2021 16:54:11 -0400
Mark Johnston wrote:
> On Mon, Jun 07, 2021 at 11:01:09AM +0200, Gary Jennejohn wrote:
> > I've seen this panic three times in the last two days:
> >
> > [first panic]
> > Unread portion of the kernel message buffer:
> &g
ps with kgdb if anyone wants more
information.
--
Gary Jennejohn
provides termcap (the old termcap definition, nothing new in there).
> if one want the terminfo database which supports alternate screen definition,
> he/shre can just pkg install terminfo-db.
>
But in March terminfo was being built and installed. Maybe he failed to
delete /
On Fri, 14 May 2021 17:05:26 +0200
Marc Veldman wrote:
> > On 14 May 2021, at 16:48, Gary Jennejohn wrote:
> >
> > On Fri, 14 May 2021 16:21:05 +0200
> > Marc Veldman wrote:
> >
> >>> On 14 May 2021, at 10:22, Henri Hennebert wrote:
> >&g
er than solved
But, the trace output indicates that you do not need the inversion flag.
Maybe your P50 (may be a later model than the P50s tested during driver
development) does not have the problem.
--
Gary Jennejohn
___
freebsd-current@freebsd.org m
th panics are "debuggable", as keyboard is working in ddb and crash dump
> could be created. And I'm not sure, that GIANT in 2021 is good thing.
>
Yeah, I was wondering about that myself when looked at the code today.
The driver was originally developed when current was
On Wed, 12 May 2021 16:44:59 +0300
Lev Serebryakov wrote:
> On 12.05.2021 16:34, Gary Jennejohn wrote:
>
> > Is sysctl debug.debugger_on_panic set to 1? You should automatically
> > land in ddb if that is set. I suppose it is, since you posted some
> > back trace in a
4 kernel.
AFAIK ddb has a command to generate a crash dump. But I can't easily
check that :(
It seems like there's a major bug when no SD card is inserted and the
driver is in the kernel. And a timing problem when a card is in the
slot at boot time.
Good to know that the module still works.
Difficult to debug without your laptop model in the hands of a developer.
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Fri, 7 May 2021 16:59:35 +0300
Lev Serebryakov wrote:
> On 07.05.2021 16:22, Gary Jennejohn wrote:
>
> >>>> Looks like there is problem with rtsx driver!
> >>> Oh, I forgot to add: disabling SD Card Reader in BIOS solves problem!
> >>>
>
le rather than
it being hard coded into the kernel.
You could then re-enable the SD card reader in the BIOS and load the
module to check whether the SD card reader works or causes a panic
when the moduke is loaded. This approach might make it possible to
get a crash d
:10:
> fatal error: 'bsm/audit.h' file not found
> #include
> ^
>
> Even defining HISTORICAL_MAKE_WORLD did not help, but then I'm not doing
> 'make world'
>
> So why is this include file missing?
>
T
; >>> net/openldap24-server | openldap-sasl-server-2.4.58 stage/runaway
> >>> (31:48:30 / 34:01:11) [40:52:52] Logs:
> >>> /pool/poudriere/data/logs/bulk/headamd64-head-default/2021-04-07_12h26m18s
> >>> ___
> >
> > [...]
> >
> > It seems, that jails on 14-CURRENT do have a strange and malfunctional
> > behaviour now.
>
> Most probably related to commit d36d68161517 check the thread at [1].
>
> A solution is being discussed in D29623 at [2].
>
>
> [1]
> https://lists.freebsd.org/pipermail/dev-commits-src-all/2021-April/005159.html
>
> [2] https://reviews.freebsd.org/D29623
>
Just FYI I was also was seeing strange hangs with dbus (polkitd was
timing out) and firefox was hung waiting for urwlck. I also saw
timeouts waiting for Xorg to shutdown (startx ended up kiliing it).
I applied the patch which kib posted and everything returned to normal.
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Wed, 17 Mar 2021 05:33:14 -0700
David Wolfskill wrote:
> On Wed, Mar 17, 2021 at 01:18:37PM +0100, Gary Jennejohn wrote:
> > On Wed, 17 Mar 2021 05:08:50 -0700
> > David Wolfskill wrote:
> > ...
> > > Indeed, it appears that the n245494-6827435548d2 change
nel now?
>
> (E.g., if I need to just skip building x11/nvidia-driver once, get
> everything installed, then build "normally" (with x11/nvidia-driver)
> -- that's fine; I just need a clue.)
>
For me trying to build nvidia-driver along with the kernel always fails
On Wed, 17 Feb 2021 18:12:39 +0100
Gary Jennejohn wrote:
> Running buildkernel after 48e62e6561b..effe8b9cb31
>
> --
> >>> stage 3.1: building everything
> -
, struct lro_ctrl *lc, struct lro_entry *le,
^
2 warnings generated.
These function declarations should be gated using #ifdef TCPHPTS.
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
d to appear.
> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
> I'm going to repull all the sources and recompile, just in
On Fri, 27 Nov 2020 07:34:32 +0100
Gary Jennejohn wrote:
> On Thu, 26 Nov 2020 20:09:41 +0100
> Michael Gmelin wrote:
>
> > > On 26. Nov 2020, at 19:21, Gary Jennejohn wrote:
> > >
> > > ___On Thu, 26 Nov 2020 10:44:19 -0700
> > > Warner Losh w
On Thu, 26 Nov 2020 20:09:41 +0100
Michael Gmelin wrote:
> > On 26. Nov 2020, at 19:21, Gary Jennejohn wrote:
> >
> > ___On Thu, 26 Nov 2020 10:44:19 -0700
> > Warner Losh wrote:
> >
> >>> On Thu, Nov 26, 2020 at 4:16 AM Michael Gmelin wrote:
>
On Thu, 26 Nov 2020 19:37:47 +0100
Dimitry Andric wrote:
> On 26 Nov 2020, at 19:21, Gary Jennejohn wrote:
> >
> > On Thu, 26 Nov 2020 10:44:19 -0700
> > Warner Losh wrote:
> ...
> >>> Example:
> >>>
> >>> /sbin/camcontrol stan
On Thu, 26 Nov 2020 10:44:19 -0700
Warner Losh wrote:
> On Thu, Nov 26, 2020 at 4:16 AM Michael Gmelin wrote:
>
> >
> >
> > On Thu, 26 Nov 2020 10:12:06 +0100
> > Gary Jennejohn wrote:
> >
> > > On Thu, 26 Nov 2020 01:14:02 -0700
> > &
On Thu, 26 Nov 2020 01:14:02 -0700
Warner Losh wrote:
> On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn wrote:
>
> > On Thu, 26 Nov 2020 00:10:40 +
> > tech-lists wrote:
> >
> > > Hi,
> > >
> > > I have a usb3-connected harddrive. dme
or shutdown. The ones relevant to USB
which I found are:
kern.cam.ada.spindown_suspend: Spin down upon suspend
kern.cam.ada.spindown_shutdown: Spin down upon shutdown
There may be commands which a user can send the disk/controller to
disable this behavior, but I didn't find any with my si
On Sun, 8 Nov 2020 00:22:26 +0100
Guido Falsi wrote:
> On 07/11/20 17:20, Gary Jennejohn wrote:
> > It seems like an entry should be added to /usr/src/UPDATING, since the
> > change made
> > to the malloc code causes panics with KMODs from ports if they haven't been
&
It seems like an entry should be added to /usr/src/UPDATING, since the change
made
to the malloc code causes panics with KMODs from ports if they haven't been
re-compiled. My nvidia-driver also caused a panic with a new kernel.
A reminder/warning would be useful.
--
Gary Jenn
ocks? Now I think it's 512 bytes,
> in contrast to df that shows diskspace in 1-KB blocks: confusing. I no
> longer track FreeBSD-11 src trees.
>
> Now I wonder how this compares to git and hg: NetBSD plans to switch from cvs
> to
of their names. The rest of the
> name is actually not really significant in keeping them apart.
>
I had the same reaction. Maybe something like rpc.tlsclntd and rpc.tlsservd?
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Thu, 20 Aug 2020 08:33:32 +0200
Gary Jennejohn wrote:
> It seems like PRINTF_BUFR_SIZE is a kernel fault waiting to happen.
>
> Only /usr/src/sys/cam/cam_xpt.c asserts that it's <= a maximum value of
> 512 bytes.
>
> /usr/src/sys/kern/tty.c uses it to malloc space
#x27;t really understand the purpose of PRINTF_BUFR_SIZE might
think "the bigger the better" and set it to be multi-megabytes in size.
I may be paranoid, but it seems like PRINTF_BUFR_SIZE should be checked
everywhere the way that cam_xpt.c does it.
--
Gary Jennejohn
_
changes in the kernel which cause the
Nvidia driver to fail at startup. I'm not willing to rebuild the Nvidia
driver to test my hypothesis.
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/
compatibility and NOT lock someone out of a
> > system who has just done an upgrade to a newer version.
> >
>
> Do you mean deprecated or depricated?
> Got confused here! Sorry English is hard for non-native speakers.
>
It's a typo - he meant deprecated.
--
G
n 2020-06-23 08:48, Gary Jennejohn wrote:
> > On Tue, 23 Jun 2020 01:14:52 +0200
> > Steffen Nurpmeso wrote:
> >
> >> Hello.
> >>
> >> Normally i do not do forums (web interface etc etc), but i was
> >> interested in ZFS encryption support
line, on a, well, pretty wide screen.
>
> [1] https://forums.freebsd.org/threads/native-encryption-of-zfs.70284/
>
> Ciao, and good night from Germany,
>
I see exactly the same bad formatting with the standard firefox port. All
vs. efi_max_resolution for
> loader.conf(8) was hard to invalidate reading vt(4) ___ still completely
> unsure how/if to change non-KMS UEFI/GOP resolution outside loader(8).
>
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Sun, 3 May 2020 14:11:09 +0100
Grzegorz Junka wrote:
> On 03/05/2020 08:05, Gary Jennejohn wrote:
> > On Sat, 02 May 2020 16:28:46 -0700
> > Chris wrote:
> >
> >>
> >>>
> >>>>> Another thing is that I don't quite understa
TO. I was distracted at the time of writing.
> Sorry.
> Does /var/crash exist?
>
> That _should_ be enough. Assuming /var/crash is writable.
>
Sorry, but read the man page for rc.conf.
This is the entry for dumpdev:
dumpdev (str) Indicates the device (usually a swap parti
On Sat, 11 Apr 2020 11:01:52 +0200
Gary Jennejohn wrote:
> On Sat, 11 Apr 2020 09:49:09 +0300
> Alexandr Krivulya wrote:
>
> > 11.04.20 03:34, Graham Perrin __:
> > > On 08/04/2020 20:23, Graham Perrin wrote:
> > >
> > > > Firefox 75
isplayed just fine and only complained about cookies. As soon as I
enabled any one of the two blocked java scripts the tab crashed. Seems
like the site is using some weird java scripts which tickle a bug in
older versions (< r359770) of FreeBSD.
--
Gary Jennejohn
__
On Thu, 9 Apr 2020 06:34:08 -0500
Justin Hibbits wrote:
> On Thu, Apr 9, 2020, 03:57 Gary Jennejohn wrote:
>
> >
> > OK, I figured it out.
> >
> > I used to have MK_CTF=no in src.conf, but I recently changed it to
> > WITH_CTF=no.
> >
>
> It s
cftconvert installed.
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Wed, 8 Apr 2020 14:51:14 -0700
John Baldwin wrote:
> On 4/7/20 11:32 PM, Gary Jennejohn wrote:
> > Has anyone else seen this error?
> >
> > I tried to build a kernel yesterday, but the build failed while compiling
> > modules because ctfconvert was not found.
>
are always installed was rather premature.
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> on real hardware. Hardware is know to be good, as it runs r349299
> rock-solid for days under load.
>
I just booted r357967 with no panic on a Ryzen 5 system with 16GB RAM.
I would guess that the error is caused by a change which somehow pessimizes
the Atom CPU.
--
Gary Jennejohn
ed to
be created, but something seems to be missing (at least on my system).
--
Gary Jennejohn
___
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"
gt;
> Also you should audit the code for zero-sized allocations, because upon
> alloc, zero-sized is not counted, while on free it is.
>
> See attached patch.
>
Yeah, the patch produces much saner output.
--
Gary Jennejohn
___
fre
er this will help, but a user posted to a forum
that he had this mainboard and couldn't boot any USB device no
matter what the tried.
His final, working solution was:
Further investigation found NOTHING would boot from USB. I
cleared CMOS, entered setup and loaded Optimized De
is measured in milliseconds, so values of 0 and 1 mean
> close to nothing. You may try to set it to some 1, if you really
> want to try to delay CAM devices attach, but I doubt.
>
This isn't aimed at anyone, but it seems like adding " in msec"
to the end of the descrip
ly with both "shutdown -r" and "shutdown
-p." It's running this version of HEAD:
FreeBSD-13.0-CURRENT-amd64-20191031-r354207-memstick.img
--
Gary Jennejohn
___
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"
y.
> So something in (recent) 13' boot layout has changed. I can boot Legacy/UEF
> I/GPT
> on 12. But cannot boot at all in recent 13.
>
I noticed that your 12 disk has Stripesize: 0 on all partitions
but 13 has Stripesize: 4096 on all partitions.
My bootable 13 disk has Str
partition for me.
> > > > > Same here. But in spite of it. The reboot proved to be unsuccessful.
> > > > > :(
> > >> I used UEFI because that was already set in the BIOS and the
> > >> computer doesn't belong to me.
> > >> L
r doesn't belong to me.
LEGACY mode should still work as long as the BIOS offers that.
My main FreeBSD 13 box uses LEGACY booting.
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-c
not
> sure. What I might do is go ahead and go to the
> /usr/ports/graphics/drm-kmod directory and make install clean, then load
> xorg and see what happens. I'm going to have a bite of super first.
>
> Clay
>
>
> _
;
Works for me with a first-generation Ryzen 5 (but in a tower, not
a laptop) and I use a graphics card from Nvidia.
X11 also starts without errors, but I use nvidia-driver and not
drm-current-kmod.
Maybe recompiling drm-current-kmod would help.
--
Gary Jennejohn
__
art.txt
> > https://people.freebsd.org/~pi/host/pciconf.txt
> > https://people.freebsd.org/~pi/host/zpool.txt
>
> What about gpart output of the pool drives?
>
> In general you would create zpools using gptids or gpt labels,
> not the devices, so you___re independ
ot;XXX A drm-current-kmod 2 /usr/local 3 drm-current-kmod 4 "
> > >
> > > suggestions welcome...
> >
> > (CCing Kyle)
> >
> > This behavior change is probably caused by r351799.
> >
> > I personally thin
, Aug 16, 2019 at 7:38 PM John Baldwin wrote:
> > > >>
> > > >> On 8/16/19 3:05 AM, Gary Jennejohn wrote:
> > > >>> I tried to build a kernel today and it failed in modules-all even
> > > >>> though I had LOCAL_MODULES="" in
lucky, you can do it in the BIOS. I disabled EFI on my
ASUS B350M-A (AMD Ryzen) that way. AFAIK the BIOS is where that
must be done.
--
Gary Jennejohn
___
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"
eeds.
The NVIDIA driver isn't open-source, but hey, it works out of the box.
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Fri, 16 Aug 2019 17:37:56 -0700
John Baldwin wrote:
> On 8/16/19 3:05 AM, Gary Jennejohn wrote:
> > I tried to build a kernel today and it failed in modules-all even
> > though I had LOCAL_MODULES="" in /etc/src.conf, as recommended by
> > jhb.
>
I tried to build a kernel today and it failed in modules-all even
though I had LOCAL_MODULES="" in /etc/src.conf, as recommended by
jhb.
That's wrong. It has to be LOCAL_MODULES=, otherwise
/sys/conf/kern.post.mk seems to conclude that there should be a
module under /usr/local/sys/modules with th
On Sun, 11 Aug 2019 08:57:04 -0600
Ian Lepore wrote:
> On Sun, 2019-08-11 at 09:04 +0200, Gary Jennejohn wrote:
> > On Sun, 11 Aug 2019 02:03:10 +
> > Rick Macklem wrote:
> >
> > > Hi,
> > >
> > > I've noticed that, if you
tion when the VOP_IOCTL() fails.
>- For SEEK_DATA, just return the offset given as argument and for SEEK_HOLE
> return the file's size as the offset.
>
> What do others think? rick
> ps: The man page should be updated, whatever is don
On Fri, 9 Aug 2019 15:38:06 +0200
Gary Jennejohn wrote:
> On Fri, 9 Aug 2019 06:49:36 -0600
> Alan Somers wrote:
>
> [snip test results]
>
> > Thanks for the report, Gary. BTW, fusefs mounts are only
> > interruptible when mounted with "-o intr". If you
t stopped pretty much immediately. I also did not use
mount but rather a direct invocation of ntfs-3g.
I suspect that ntfs-3g stops after the interrupt once it has
flushed the UBLIO buffers.
--
Gary Jennejohn (gj@)
___
freebsd-current@freebsd.org
egrity. The result was
identical for both files, so that's good news.
--
Gary Jennejohn (gj@)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Sun, 28 Jul 2019 17:09:04 +0200
Gary Jennejohn wrote:
> On Sun, 28 Jul 2019 15:56:33 +0200
> Hans Petter Selasky wrote:
>
> > On 2019-07-27 13:51, Gary Jennejohn wrote:
> > > On Sat, 27 Jul 2019 13:05:01 +0200
> > > Hans Petter Selasky wrote:
> >
On Sun, 28 Jul 2019 15:56:33 +0200
Hans Petter Selasky wrote:
> On 2019-07-27 13:51, Gary Jennejohn wrote:
> > On Sat, 27 Jul 2019 13:05:01 +0200
> > Hans Petter Selasky wrote:
> >
> >> On 2019-07-26 11:56, Gary Jennejohn wrote:
> >>> On Fri, 26 Ju
On Sat, 27 Jul 2019 13:05:01 +0200
Hans Petter Selasky wrote:
> On 2019-07-26 11:56, Gary Jennejohn wrote:
> > On Fri, 26 Jul 2019 11:25:33 +0200
> > Gary Jennejohn wrote:
> >
> >> I'm having a very strange problem with external USB disks in
> >>
On Fri, 26 Jul 2019 11:25:33 +0200
Gary Jennejohn wrote:
> I'm having a very strange problem with external USB disks in
> HEAD. I see the problem with a kernel from July 12th and also
> with one from today.
>
[snip]
> Since I'm running a custom kernel I'll try
ffected makes things really weird.
Since I'm running a custom kernel I'll try running GENERIC to
see what happens and report back.
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebs
re_delay to 1 only if ms != 0?
--
Gary Jennejohn
___
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"
most of it will not even be able to run FBSD 13.
>
> There are no 100M ed variants. There are some PC Card variants that have
> 100M MII connections, but they are limited to about 12Mbps due to bus
> limits. Even the PCI ones didn't have 100M mii connections.
>
--
Gary Jennejohn
7;t know exactly which reply, but it
should be findable in the mail-list database. AFAIK it was never
verified that it was the cause.
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Fri, 4 Jan 2019 15:24:42 +0100
Gary Jennejohn wrote:
> On Fri, 04 Jan 2019 14:41:43 +0100
> "Julian H. Stacey" wrote:
>
> > Matthias Apitz wrote:
> > > $ sh /usr/src/sys/conf/newvers.sh
> >
> > Me too. Mine also returns nothing. Ditto un
vers.c shows:
#define VERSTR "FreeBSD 13.0-CURRENT #1 r342759M: Fri Jan 4 15:17:07
CET 2019\nga...@ernst.home:/usr/obj/usr/src/amd64.amd64/sys/ernst\n"
The 'M' appears because I use a modified /sys/conf/files to prevent
including the for me useless iflib stuff.
--
Gar
t len)
^
1 error generated.
*** [strerror.o] Error code 1
I deleted /usr/obj, disabled META_MODE and ran the ``make buildworld''
with -j1.
My /usr/src is at r342569.
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
e
> impacting ARM64?
>
> CCing mmel@, because they might be interested in these bug reports.
>
No. I saw this with mplayer and also iridium when I installed them
with pkg on AMD64.
Strangely enough, mpv works, even though it shows a dependency on
libglib-2.0.so.0 when I run ldd on
On Thu, 13 Dec 2018 07:45:36 -0800
Cy Schubert wrote:
> In message <20181213113925.5f100...@ernst.home>, Gary Jennejohn writes:
> > On Thu, 13 Dec 2018 10:47:13 +0100
> > Gary Jennejohn wrote:
> >
> > > I just had two panics as a result of enabling
101 - 200 of 451 matches
Mail list logo
