On Tue, 4 May 2021 at 11:52, Mark Millard wrote:
>
> > As far as the utf-8 issues go, diffoscope requires a utf-8 locale and
> > I suspect that is the issue. If you don't have LANG set already, try
> > setting LANG=C.UTF-8 in your environment.
>
> That is not the issue for the UnicodeDecodeError:
On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
>
> But I'll note that I've built and stalled py37-diffoscope
> (new to me). A basic quick test showed that it reports:
>
> W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh" module
> is unavailable.
I just looked up tlsh - its
On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
wrote:
>
> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and
> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and
> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ
> Fi
On Tue, 6 Apr 2021 at 06:49, Robert Blayzor via freebsd-stable
wrote:
>
> I have several servers running 11.4 and 12.2 that do nightly portsnap
> updates and the last time they've seen anything new is 3/31/2021, since
> then, nothing.
>
> This seems highly unusual since seems like there was always
On Sat, 3 Apr 2021 at 16:39, Ed Maste wrote:
>
> I propose deprecating the ftpd currently included in the base system
> before FreeBSD 14, and opened review D26447
> (https://reviews.freebsd.org/D26447) to add a notice to the man page.
I posted this as a proposal for community f
I propose deprecating the ftpd currently included in the base system
before FreeBSD 14, and opened review D26447
(https://reviews.freebsd.org/D26447) to add a notice to the man page.
I had originally planned to try to do this before 13.0, but it dropped
off my list. FTP is not nearly as relevant no
On Thu, 25 Mar 2021 at 15:09, Chris wrote:
>
> I can only state that I use it only occasionally, and that when I do. I
> have had no problems with it. I'm glad that it's there when I need it.
Thanks for the reply. Can you comment on your use cases - in
particular, did you use mirror, stripe, or r
Vinum is a Logical Volume Manager that was introduced in FreeBSD 3.0,
and for FreeBSD 5 was ported to geom(4) as gvinum. gvinum has had no
specific development at least as far back as 2010 and it is not clear
how well it works today. There are open PRs with reports of panics
upon removing disks, et
On Fri, 26 Feb 2021 at 12:10, Helge Oldach wrote:
>
> A shallow tree is about 1.6G. If you want to patch source (say, from
> a SA or EN) you certainly also need space for an object tree which is
> about 4.5G. The total is >6G.
>
> I'd say relative to the total required to build, the 1.1G "savings"
On Thu, 25 Feb 2021 at 15:58, Warner Losh wrote:
>
> The problem, though, can happen when you run a shallow clone or gitup to
> get the sources and build from that. In that case the v number is bogus
> (hmmm, we should omit it when we have a shallow clone maybe).
I want to clarify one point here
On Thu, 25 Feb 2021 at 16:57, Karl Denninger wrote:
>
> The time (and present items) on a given machine to know whether it is
> covered by a given advisory under the "svn view of the world" is one
> command, and no sources. That is, if the advisory says "r123456" has
> the fix, then if I do a "un
On Thu, 25 Feb 2021 at 02:42, Kevin Oberman wrote:
>
> Thanks, Ed, but where do I find this? uname -a" gives me stable/13-007101f87.
> For a while I was seeing a hyphenated number prefixed with a 'c' and I had
> assumed that that number was the sequence.
It is (was) - we changed from 'c' to avo
On Wed, 24 Feb 2021 at 12:35, Kevin Oberman wrote:
>
> In the svn days, I could just look at my svn revision to check on whether a
> security patch was required. Now I have a git hash. I have no idea how to
> tell if my system running 13-STABLE of a few days ago has the patch.
Thanks for posting
On Thu, 18 Feb 2021 at 15:29, Ed Maste wrote:
>
> The git-svn stable/12 mirror is currently stuck. It encountered an
> issue with the OpenSSL 1.1.1j import (e3a8c0df593b) and hasn't been
> able to make progress past it. It's under investigation and will
> hopefully be
The git-svn stable/12 mirror is currently stuck. It encountered an
issue with the OpenSSL 1.1.1j import (e3a8c0df593b) and hasn't been
able to make progress past it. It's under investigation and will
hopefully be resolved soon.
(I think the git-svn converter is trying to cherry-pick each of the
ve
On Fri, 12 Feb 2021 at 23:11, tech-lists wrote:
>
> I saw on cgit that stable/12 was there. These older systems weekly
> update their sources via svn till now, in a cron job. At the time I wrote
> my message, I saw that svn still works, so was wondering which to use,
> which has the latest updates
On Sat, 13 Feb 2021 at 01:04, Dewayne Geraghty
wrote:
>
> Is there a timeline when svn for stable-12 /usr/src disappears?
stable/11 and stable/12 will exist in svn for at least as long as the
branches are supported - stable/12 expected EOL is June 30,2024. If
you're tracking stable you don't need
On Thu, 31 Dec 2020 at 02:50, Helge Oldach wrote:
>
> The only sensible way out is to retire mergemaster and switch to
> etcupdate. This would affect any stable/1? users building from source.
stable/11 and stable/12 users can continue to update via svn and have
$FreeBSD$ expanded, for the life of
FreeBSD has used ELF binaries/libraries for decades, but still has
support for legacy a.out binaries. Portions of this have been retired
over time, and I propose removing the remaining pieces before FreeBSD
13. I'm not proposing making any change to kernel a.out support, but
users needing userland
Adding the FreeBSD-stable list to CC for more visibility.
On Wed, 2 Dec 2020 at 12:43, Ed Maste wrote:
>
> I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to
> switch the GDB knob to default to NO in the near future. If the
> crashinfo utility and related man pages do
On Mon, 21 Sep 2020 at 10:04, Ed Maste wrote:
>
> On Mon, 21 Sep 2020 at 03:42, Walter von Entferndt
> wrote:
> >
> > At Sonntag, 20. September 2020, 14:00:00 CEST, Ed Maste
> > wrote:
> > > Until pkgbase is in place the most straightforward way to address t
On Mon, 21 Sep 2020 at 03:42, Walter von Entferndt
wrote:
>
> At Sonntag, 20. September 2020, 14:00:00 CEST, Ed Maste
> wrote:
> > Until pkgbase is in place the most straightforward way to address this
> > issue will probably be for us to ship a new kernel even if not
&
On Thu, 17 Sep 2020 at 18:45, Dan Langille wrote:
>
> I understand why this occurs. I have reported it before:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245878
Until pkgbase is in place the most straightforward way to address this
issue will probably be for us to ship a new kernel eve
On Wed, 8 Jul 2020 at 17:08, FreeBSD Errata Notices
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> =
> FreeBSD-EN-20:14.linuxkpi Errata Notice
>
On Tue, 10 Mar 2020 at 19:15, Andy Farkas wrote:
>
> Is it just a matter of putting "syscons=[sc|vt]" in loader.conf
> to select whatever driver?
Have a look at sc(4) and vt(4) - in loader.conf:
kern.vty=sc
or
kern.vty=vt
And sysctl kern.vty will let you know which you're using.
On Mon, 9 Mar 2020 at 15:15, Andy Farkas wrote:
>
> On 2020-03-10 01:04, Konstantin Belousov wrote:
> > Take a look at r334530.
>
> "or the user really hates this feature and can't wait to turn it off"
So to confirm, your issue is with sc(4), not vt(4)?
___
On Mon, 2 Mar 2020 at 14:03, Ed Maste wrote:
>
> On Sat, 29 Feb 2020 at 15:57, Warner Losh wrote:
> >
> > Given the ~15 years of nothing but API changes to these cards, and the lack
> > of testing of those changes, and the large technology transitions in net
> >
On Sun, 8 Mar 2020 at 17:13, Andy Farkas wrote:
>
> Is anyone actually working on the vt(4) driver? Will it ever
> become feature-parity with the old sc(4) driver?
Yes, and yes. What specific missing functionality are you affected by?
> I've noticed some weird things happening on my console rec
On Sat, 29 Feb 2020 at 15:57, Warner Losh wrote:
>
> Given the ~15 years of nothing but API changes to these cards, and the lack
> of testing of those changes, and the large technology transitions in net and
> tty layers of the system, I'd honestly be surprised if these drivers still
> work.
D
Is anyone using sync serial drivers ce, cp, ctau, or cx? NYCBUG's
dmesg didn't turn up any entries. I suspect these are obsolete and
ought to be removed.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
On Sun, 23 Feb 2020 at 12:48, Gerard E. Seibert
wrote:
>
> Until they squash that bug, they should not be in a rush to push out
> the door another defective model.
Unfortunately complaining that there's a bug in 12.0 or 12.1 or
providing additional reports of this will do nothing to help resolve
On Tue, 18 Feb 2020 at 05:37, Tomasz CEDRO wrote:
>
> Maybe its a time to give OpenBSD a try..
I really don't understand this comment, either. Certainly give OpenBSD
a try and if it fits your needs better that's great.
As far as I'm aware OpenBSD issues a release every six months and
supports th
On Mon, 17 Feb 2020 at 22:24, Tomasz CEDRO wrote:
>
> Why so short End-Of-Life? Why so many fast and short releases? What for?
>
> Why pushing problems to production? What was wrong with having one
> well tested stable system for a long time?
I really don't understand this - FreeBSD 12 is support
On Mon, 6 Jan 2020 at 16:17, Alexander Koeppe wrote:
>
> Hi,
>
> since I've upgraded to FreeBSD 12, I don't find a package providing the
> lightweight geoip database API incl. GeoIP.h and libGeoIP.so.
>
> I only find `geoipupdate` which is the non-free variant of the API.
Looking at ports history
On Fri, 6 Dec 2019 at 22:54, O'Connor, Daniel wrote:
>
> With respect to the man page, I find it difficult to know what a given value
> for each sysctl will do, as evidenced by my confusion above about IBRS.
scottl recently moved these sysctls to machdep.mitigations in r355436,
but they've kept
On Thu, 19 Sep 2019 at 18:30, David Cross wrote:
>
> There are a set of commits in head that have not been pulled into the
> stable/12 branch. Many of these are marked as MFC (and are quite old).
I'm looking at the WITH_PIE / WITH_BIND_NOW changes, and am looking
for re@'s opinion. I'll merge th
, we talked about methods for making for more training
material available.
Partnerships and Commercial User Support
We help facilitate collaboration between commercial users and FreeBSD
developers. We also meet with companies to discuss their needs and
bring that information back to the Project. In Q2,
On Fri, 26 Jul 2019 at 22:44, Jeremy Chadwick via freebsd-stable
wrote:
>
> TL;DR for lazy folks:
>
> stable/11 r350330 world + minimal clang = 1:29:34
> stable/11 r350330 world + full clang= 1:46:31
> stable/11 r350252 world + minimal clang = 56:52
> stable/11 r350252 world + full clang
On Wed, 15 May 2019 at 00:03, Ed Maste wrote:
>
> On Wed, 15 May 2019 at 15:09, wintellect Auser
> wrote:
> >
> > Hi all,
> >
> > Wanted to make you aware of an issue I have encountered, sorry if this is
> > the wrong list.
>
> This is the right pl
On Wed, 15 May 2019 at 15:09, wintellect Auser wrote:
>
> Hi all,
>
> Wanted to make you aware of an issue I have encountered, sorry if this is
> the wrong list.
This is the right place and thank you for reporting. Looking into it.
___
freebsd-stable@fr
On Tue, 19 Mar 2019 at 16:54, Dan Allen wrote:
>
> That is why I think the check is flawed!
The check works as intended, as suggested by the non-booting kernel
produced with the checks removed.
To help track this down can you run `make buildenv` and then in the
resulting shell collect the output
On Mon, 18 Mar 2019 at 13:03, Dan Allen wrote:
>
> The buildworld and buildkernel steps both immediately fail due to the linker
> not supporting ifuncs.
By default FreeBSD/i386 uses lld as the bootstrap linker (i.e., the
linker used for building the kernel, libraries, and userland binaries)
but
On Thu, 28 Feb 2019 at 09:33, Rodney W. Grimes
wrote:
>
> LD?=ld.lld in the right place(s)?
Perhaps, I seem to recall some issue with that, but not the specifics.
> And is this still an issue for stable/12 i386?
> or has ld been changed to ld.lld?
stable/12 i386 still has GNU ld as /usr/bin/ld
On Thu, 28 Feb 2019 at 08:26, Rodney W. Grimes
wrote:
>
> Are you really rally expecting a user to rebuild the world that
> he just installed that should be exactly the same world he gets
> build (reproduceable builds and all??).
I'm expecting that a user will either follow the directions in the
> > Let me guess. You use 'make' in sys/i386/build/YOUR_KERNEL ?
> > Then you need to use 'LD=ld.ldd make'. The proper way of
> > 'make buildkernel' from top-level src handles it automatically.
> >
> If you back up in the thread you would also see the output
> is the same for cd /usr/src; make bu
On Thu, 28 Feb 2019 at 03:50, Rodney W. Grimes
wrote:
>
> Now the begging question, why isnt the toolchain as shipped
> already properly built?
The required toolchain is included in 12.0-RELEASE i386 - the linker
is /usr/bin/ld.lld. It just needs to be specified explicitly if build
via a method o
On Wed, 9 Jan 2019 at 15:23, Kurt Jaeger wrote:
>
> Hi!
>
> > > Credits:Mark Johnston
> > > Affects:FreeBSD 11.2
> > > Corrected: 2019-11-24 17:11:47 UTC (stable/11, 11.2-STABLE)
> >
> > Should this be 2018 or is this yet in the future?
>
> And why does fbsd-update fail like t
On Wed, 9 Jan 2019 at 15:03, Cy Schubert wrote:
>
> > Corrected: 2019-11-24 17:11:47 UTC (stable/11, 11.2-STABLE)
>
> Should this be 2018 or is this yet in the future?
Yes, this should be 2018-11-24. Gordon's updating it.
___
freebsd-stable@freebsd
On Thu, 27 Dec 2018 at 17:20, Warner Losh wrote:
>
> > Yes, you should update to the latest stable/11. More details, you need
> > to have host clang which includes the r339284 commit.
>
> We either need to fix this problem, or we need to bump the minimum in
> Makefile.inc1.
amd64_get_fsbase.c sh
The lmc(4) driver supports hardware for a number of legacy interfaces,
including EIA612/613, T1/E1, T3, etc. The driver's license is ambiguous
and attempts to contact the author failed.
I would like to remove this driver from 12.0, and have a deprecation
notice in review D15182 [1]; I would appre
FreeBSD password databases (/etc/pwd.db, /etc/spwd.db) can contain
records in one or both of two versions:
* v3, a legacy architecture-dependent format
* v4, the current architecture- and endian-independent format
When v4 support was added in 2003 (r113596) pwd_mkdb emitted both v3 and
v4 record
On 14 April 2018 at 07:31, Magnus Ringman wrote:
> Hi Brooks, this MFC missed your r331077
> (https://reviews.freebsd.org/D14706) thus stable buildkernel currently
> breaks on missing those two macros.
Thanks for identifying the missing commit Magnus. I've now merged it in r332502.
__
Background
--
A number of issues relating to speculative execution were found last
year and publicly announced January 3rd. A variety of techniques used to
mitigate these issues have been committed to FreeBSD-CURRENT and have
been merged to the stable/11 branch.
The changes will be merged
On 30 January 2018 at 19:48, Mike Tancsa wrote:
>>
> I also just tried upgrading to the latest HEAD with a generic kernel and
> same / similar lockups although procstat -kk gives some odd results
>
>
> root@amdtestr12:/home/mdtancsa # procstat -kk 6067
> PIDTID COMMTDNAME
On 30 August 2017 at 01:12, Xin LI wrote:
> I think emaste@ have fixed it in r321293. MFC?
Thanks for the note, now merged in r323044.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe,
On 27 July 2017 at 07:02, David Wolfskill wrote:
> /usr/src/usr.sbin/acpi/acpidump/acpi.c:1089:6: error: use of undeclared
> identifier 'ACPI_SRAT_TYPE_GIC_ITS_AFFINITY'; did you mean
> 'ACPI_SRAT_TYPE_GICC_AFFINITY'?
Sorry about that, reverted in r321617.
__
On 12 June 2017 at 00:43, Warner Losh wrote:
>
> aarch64 support isn't completely integrated into FreeBSD 11 yet.
A clarification: arm64/aarch64 support has been available as of
FreeBSD 11.0 for Cavium ThunderX, and the SoftIron arm64 hardware is
also supported now.
What we don't have yet is a p
FreeBSD-update has outdated release lifetime data, and is emitting a
false warning that the End-of-Life date for FreeBSD 11.0-RELEASE-p8 is
approaching.
| WARNING: FreeBSD 11.0-RELEASE-p8 is approaching its End-of-Life date.
| It is strongly recommended that you upgrade to a newer
| release within
2014 at 11:26, Ed Maste wrote:
> vgl(3) is a graphics library for syscons(4) that provides some basic
> graphics operations (e.g. some mode setting, bitmaps, boxes,
> ellipses). Right now it does not support the newer vt(4) console.
>
> In order to help determine the priority of a
On 7 January 2016 at 16:53, Ed Schouten wrote:
> Hi Oliver,
>
> 2016-01-07 19:32 GMT+01:00 Oliver Pinter :
>> We got this error during the jenkins build: "cc: error: no such file
>> or directory:
>> '/usr/obj/jenkins/workspace/HardenedBSD-10-STABLE-unstable-amd64/sys/boot/efi/loader/../../ficl/li
On 13 May 2015 at 03:02, Marko Turk wrote:
> Hi,
>
> after r282823, new vt_is_cursor_in_area is, in some cases, returning
> different values than the old function.
>
> For example:
> If (my + vd->vd_mcursor->height) is equal to (area->tr_begin.tp_row),
> old function will return 1 and new function
On Tue, Jun 16, 2009 at 07:03:34PM +0400, pluknet wrote:
> As for allpcpu, I often see the picture, when one CPU runs the "irq17:
> bce1 aacu0" thread
> and another one runs arcconf. I wonder if that might be a source of
> bad locking or races, or..
> The arcconf utility uses ioctl that goes into
On Fri, Dec 12, 2008 at 12:16:26PM -0600, Paul Taulborg wrote:
> Both of these have an Adaptec AIC-9410 SAS controller in them, that is
> apparently not detected (or supported?) by FreeBSD (amd64) (7.0 or 7.1
> RC1)
No verison of FreeBSD has support for the AIC-9410, and I am not aware
of any w
On Wed, Sep 17, 2008 at 09:25:37AM -0700, Jeremy Chadwick wrote:
> On Wed, Sep 17, 2008 at 07:36:46AM -0400, Stephen Clark wrote:
> > I am trying to get a crash dump but am unable to with FreeBSD 6.3-RELEASE-p2
> >
> > [...]
> > reboot -d
> > ...
> > dumping 255M 2 chunks
> >
> >
> > Then nothing
On Fri, Nov 10, 2006 at 11:42:40AM -0500, Vivek Khera wrote:
> I have just built a new SunFire X4100 server with an Adaptec 2230SLP
> RAID card using FreeBSD 6.2-PRE kernel (from September 20).
> Everything is working extremely well except I cannot run the aaccli
> utility on this controller
On Wed, Apr 02, 2008 at 10:16:17AM -0700, Chris Timmons wrote:
> Ed,
>
> Your work-around works on 7-stable as of this morning.
Excellent! I've actually committed a better fix to HEAD now (aac.c
revision 1.137). The diffs[1] should apply cleanly to RELENG_7 and
RELENG_6 I believe, and I plan t
On Wed, Jan 02, 2008 at 03:54:50AM -0500, Mike Andrews wrote:
> On RELENG_7 dated 2007-12-15 (BETA4), aaccli fails with the following
> error; arcconf continues to work fine:
>
>Command Error: current AFAAPI.DLL.>
I suspect Adaptec has a firmware bug relating to the RequestAdapterInfo
a
On Sat, Mar 29, 2008 at 03:20:49PM -0700, Jeremy Chadwick wrote:
> Also, I'd like to know what USB serial adapter you're using (brand,
> model, and a website of it if possible), for unrelated reasons. Thanks!
The "Cables Unlimited" USB-Serial adapter from TigerDirect[1] is based on
the FTDI chip
On Fri, Feb 01, 2008 at 11:15:56AM -0800, Hiroshi Nishida wrote:
> Does the 'polling' mode for network devices work with a 7.0-RC1's SMP
> kernel?
>
> According to http://info.iet.unipi.it/~luigi/polling/, it seems not on
> FreeBSD 4.
> What about 7.0?
Polling works with SMP as of FreeBSD 6.x.
On Tue, Jan 29, 2008 at 11:09:13AM -0800, Jeremy Chadwick wrote:
> I spent 7-8 hours yesterday working on accomplishing ${SUBJECT}, and in
> the process wrote a document on it. There are scattered docs all over
> the Web describing how to do this, but all of them are either outdated
> or incorrec
On Wed, Jan 02, 2008 at 10:19:15AM -0500, Vivek Khera wrote:
> On Jan 2, 2008, at 3:54 AM, Mike Andrews wrote:
>
> > Command Error: >the current AFAAPI.DLL.>
>
> In my experience, this was caused by the firmware rev of the adaptec
> card. Basically, the combination of FreeBSD, amd64, and Ad
itted.
- Polling's major advantage is the avoidance of livelock on UP systems,
and not improved performance.
What level of traffic are you putting through this box? Is it routing/
bridging, or an endpoint like a web server?
Ed Maste
_
On Mon, Jun 26, 2006 at 01:06:14PM +0100, Gavin Atkinson wrote:
> On Mon, 2006-06-26 at 08:55 -0300, Marc G. Fournier wrote:
> > For the server that I'm fighting with right now, where Dmitry pointed out
> > that it looks like a deadlock issue ... I have dumpdev/savecore enabled,
> > is there som
On Mon, Jun 26, 2006 at 01:06:14PM +0100, Gavin Atkinson wrote:
> On Mon, 2006-06-26 at 08:55 -0300, Marc G. Fournier wrote:
> > For the server that I'm fighting with right now, where Dmitry pointed out
> > that it looks like a deadlock issue ... I have dumpdev/savecore enabled,
> > is there som
On Mon, Feb 27, 2006 at 11:07:35AM -0500, Vivek Khera wrote:
> I get a 9600 baud console with the following after upgrade from 5.4:
This is what I'm planning on putting in UPDATING:
The i386 loader(8) now defaults to the serial speed set by the
previous boot stage, if the comcons
On Mon, Feb 27, 2006 at 12:01:08PM -0500, Rong-En Fan wrote:
> Which way is preferred: setting comconsole_speed, -S in
> boot.config, or using harded code BOOT_COMCONSOLE_SPEED in make.conf?
> If now the most preferred way is to using -S or
> comconsole_speed in loader.conf, please update that in
On Sun, Feb 26, 2006 at 09:19:35PM +0100, Dimitry Andric wrote:
> > comconsole_speed= in /boot/loader.conf
> > existing speed, if comconsole is already set by previous stage
> > BOOT_COMCONSOLE_SPEED compile time default
>
> Well, the last item will simply never be hit, since there is ALWAYS a
>
On Sun, Feb 26, 2006 at 02:37:08AM +0100, Dimitry Andric wrote:
> Ed Maste wrote:
> > What's in your /boot.config?
>
> In my case, I use -P, because I usually don't have a keyboard hooked up,
> but ocasionally do use it. Additionally, I had console="comc
On Sun, Feb 26, 2006 at 02:40:17AM +0100, Dimitry Andric wrote:
> Ian Dowse wrote:
> > The problem may be that your boot blocks were compiled with
> > BOOT_COMCONSOLE_SPEED set to 9600. Try reinstalling them with e.g.
> > `disklabel -B ad0s1' (make sure you get the right device name -
> > it shoul
On Sun, Feb 26, 2006 at 12:23:59AM +0100, Dimitry Andric wrote:
> > comconsole_speed="115200" in loader.conf should override it
> > if you don't want to replace boot2 or change /boot.config.
>
> Yes, I've tried this, but it didn't work, or maybe I just didn't try
> hard enough. :) I'll try it ag
On Sat, Feb 25, 2006 at 10:55:01PM +0100, Dimitry Andric wrote:
> Hi,
>
> I believe this MFC commit:
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/libi386/comconsole.c?rev=1.10.10.1&content-type=text/x-cvsweb-markup
> broke the speed-setting of the serial console at boot time, for REL
I've been backmerging to RELENG_5 the IP multicast address locking work
done by Robert Watson in HEAD and RELENG_6. This prevents various panics
and corruption that happens when configuring multicast addresses.
The first two parts [1][2] of the MFC are complete, and all that remains
is to have dr
I tried to build a kernel with options NET_WITH_GIANT and discovered
that debug_mpsafenet is still set to 1. It seems that when this was
MFC'd the #include "opt_net.h" was missed; the attached patch should
correct this.
--
Ed Maste, Sandvine Incorporated
p
= 0x9fbfecd8 ---
--
Ed Maste, Sandvine Incorporated
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Tue, May 24, 2005 at 04:01:31PM -0700, John-Mark Gurney wrote:
> yes, the reason I made _stat return ENXIO is that _read and _write are
> not supported by kqueue, and so _stat provided useless information.
> When I added locking, it would only be reading a value that would
> immediately be able
On Tue, May 24, 2005 at 01:36:48PM -0400, Ed Maste wrote:
> On Tue, May 24, 2005 at 12:59:07PM -0400, Ed Maste wrote:
>
> > We discovered a kqueue leak when running one of our 4.x applications on
> > FreeBSD 5.3 using the compat libc_r. It turns out it's caused by libc_
On Tue, May 24, 2005 at 12:59:07PM -0400, Ed Maste wrote:
> We discovered a kqueue leak when running one of our 4.x applications on
> FreeBSD 5.3 using the compat libc_r. It turns out it's caused by libc_r's
> close() failing.
I've attached a patch which stops libc_r
ailure and continue
on with the close.
== kqueue.c ==
#include
#include
#include
#include
int main()
{
struct stat sb;
int kq=kqueue();
printf("fstat returns %d (%d)\n", fstat(kq, &sb), errno);
printf("close returns %d (%d)\n", close(kq), errno);
}
e before. The crash
only showed up on one nightly testrun out of dozens though, so I'm not
certain it fixes the underlying issue.
I'll let you know if anything else turns up.
--
Ed Maste, Sandvine Incorporated
___
freebsd-stable@freebsd
a0723ddf in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:263
--
Ed Maste
Sandvine Inc.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
A colleague of mine reported on a hang during boot on a SuperMicro board
(with ACPI off):
http://lists.freebsd.org/pipermail/freebsd-current/2004-March/023045.html
with some more analysis:
http://lists.freebsd.org/pipermail/freebsd-current/2004-July/030827.html
as it turns out it doesn't actual
91 matches
Mail list logo
