Hi everyone,
Speaking on behalf of Core, i wanted to let you know that 13.0 RC4 might be
delayed. Glen has an emergency to attend to, and might be unavailable or slow
to respond for a few more days. You’re still encouraged to email re@ with
requests and questions. Anything urgent can be dire
rt for that there.
>> With UDEV it might work?
>
> On current, for now I'm using the standard xorg-server from pkg, built
> with UDEV according to [1], so apparently that is not working either. At
> least in my case.
>
> Will dig futher into it.
>
>>
&
> On Nov 15, 2020, at 1:05 PM, Stefan Esser wrote:
>
> Am 15.11.20 um 20:41 schrieb Kyle Evans:
>> This is a separate (valid) problem, but not directly related to
>> Scott's work here. sysctlbyname now goes directly to the kernel with
>> no chance for the user.* sysctls to intercept. That shoul
> On Nov 15, 2020, at 12:41 PM, Kyle Evans wrote:
>
> On Sun, Nov 15, 2020 at 1:33 PM Guy Yur wrote:
>>
>> On 15/11/20 8:55 pm, Scott Long wrote:
>>> This is fixed in revision 367701
>>>
>>> Scott
>>
>> Hi,
>>
>> I
This is fixed in revision 367701
Scott
> On Nov 15, 2020, at 11:52 AM, Manfred Antar wrote:
>
> pkg.c revision 367687 breaks pkg :
>
> (pkg)5052}pkg
> The package management tool is not yet installed on your system.
> Do you want to fetch and install it now? [y/N]:
>
> This is after upgradi
> On Apr 17, 2020, at 3:07 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>
> Scott Long wrote on 04/17/2020 23:04:
>>> On Apr 17, 2020, at 2:45 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>>>
>>> Scott Long wrote on 04/17/2020 22:17:
>>
> On Apr 17, 2020, at 3:13 PM, Mel Pilgrim
> wrote:
>
> On 2020-04-17 8:50, Warner Losh wrote:
>> On Fri, Apr 17, 2020 at 9:39 AM Scott Long wrote:
>>> Can you send me the output of ‘pciconf -llv’, either in 12-STABLE or
>>> 13-CURRENT? Also,
> On Apr 17, 2020, at 2:45 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>
> Scott Long wrote on 04/17/2020 22:17:
>>> On Apr 17, 2020, at 1:47 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>>>
>>> Kurt Jaeger wrote on 04/17/2020 21:44:
>>
> On Apr 17, 2020, at 1:47 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>
> Kurt Jaeger wrote on 04/17/2020 21:44:
>> Hi!
pciconf -lBc pcib12
pciconf -lBc pcib13
>>>
>>> Printscreen attached.
>> Attachments are stripped from the list -- can you put them somewhere
>> online ?
>
> He
Is the intention to eventually replace the zfs code in src/ ? What will be the
long-term relationship between src/ and ports/ for this?
Scott
> On Apr 17, 2020, at 12:35 PM, Ryan Moeller wrote:
>
> FreeBSD support has been merged into the master branch of the openzfs/zfs
> repository, and t
> On Apr 17, 2020, at 11:46 AM, Miroslav Lachman <000.f...@quip.cz> wrote:
>
> Scott Long wrote on 04/17/2020 18:17:
>> You are correct about Intel vs AMD. Comparing the full output of pciconf
>> from FreeBSD with the fragment of lspci from Linux suggests that ther
linux?
Thanks,
Scott
> On Apr 17, 2020, at 9:54 AM, Scott Long wrote:
>
> Would that be the Intel VMD/VROC stuff? If so, there’s a driver for FreeBSD,
> but it’s not well tested yet. Will have to dig in further.
>
> Scott
>
>
>> On Apr 17, 2020,
Would that be the Intel VMD/VROC stuff? If so, there’s a driver for FreeBSD,
but it’s not well tested yet. Will have to dig in further.
Scott
> On Apr 17, 2020, at 9:50 AM, Warner Losh wrote:
>
>
>
> On Fri, Apr 17, 2020 at 9:39 AM Scott Long wrote:
> Can you sen
Can you send me the output of ‘pciconf -llv’, either in 12-STABLE or
13-CURRENT? Also, can you send me the output of ‘dmesg’?
Thanks,
Scott
> On Apr 17, 2020, at 5:23 AM, Miroslav Lachman <000.f...@quip.cz> wrote:
>
> I already asked on stable@ but as I tried it on 13-CURRENT with the same
>
> On Apr 10, 2020, at 12:57 AM, Poul-Henning Kamp wrote:
>
>
> In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri Pankov
> writes:
>> Trond Endrestøl wrote:
>>> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
>>>
OK, I figured it out.
I used to
I’m 99% sure that the boot breakage is due to this commit:
Author: jkim
Date: Tue Jul 9 18:02:36 2019
New Revision: 349863
URL: https://svnweb.freebsd.org/changeset/base/349863
Log:
MFV: r349861
Import ACPICA 20190703.
I have two systems now that are affected, and both of them
are “fixed”
> On Jun 21, 2019, at 4:37 PM, Warner Losh wrote:
>
> On Fri, Jun 21, 2019, 3:33 PM Conrad Meyer wrote:
>
>> On Fri, Jun 21, 2019 at 2:55 PM Alan Somers wrote:
>>> I would've thought that immediately following a sync(8), the
>>> filesystem would be consistent. Why do I still see errors afte
> On Jun 21, 2019, at 3:49 PM, Don Lewis wrote:
>
> On 21 Jun, Scott Long wrote:
>>
>>> On Jun 21, 2019, at 2:09 PM, Alan Somers wrote:
>>>
>>> On Fri, Jun 21, 2019 at 1:56 PM Scott Long wrote:
>>>>
>>>>
>>>>
> On Jun 21, 2019, at 2:09 PM, Alan Somers wrote:
>
> On Fri, Jun 21, 2019 at 1:56 PM Scott Long wrote:
>>
>>
>>
>>> On Jun 21, 2019, at 1:49 PM, Alan Somers wrote:
>>>
>>> I panic my development VM regularly. Each time, I need to fsc
> On Jun 21, 2019, at 1:49 PM, Alan Somers wrote:
>
> I panic my development VM regularly. Each time, I need to fsck the
> file system. Even if I had run sync(8) just before the panic, I
> frequently find corruption. What should I change to make sync(8)
> work, or at least to make corruptio
> On Jun 17, 2019, at 7:46 PM, Julian H. Stacey wrote:
>
>>>
>>> Stop.
>>> make[3]: stopped in /usr/src/usr.bin/mkesdb_static
>>>
>>> A double waste of CPU & human time & power in a hot office.
>>> Commit bits used to be suspended for un-buildable code. I'll boot
>>> stable.
>>
>> Since you
> On Jan 26, 2017, at 5:22 PM, Jung-uk Kim wrote:
>
> On 01/26/2017 19:17, Alex Deiter wrote:
>> Hello,
>>
>> patch:
>>
>> Index: sys/cam/cam_xpt.h
>> ===
>> --- sys/cam/cam_xpt.h (revision 312851)
>> +++ sys/cam/cam_xpt.h (wo
> On Nov 6, 2016, at 11:01 AM, Michael Tuexen wrote:
>
>> On 6 Nov 2016, at 15:39, Konstantin Belousov wrote:
>>
>> On Sun, Nov 06, 2016 at 02:17:45PM +0100, Michael Tuexen wrote:
On 6 Nov 2016, at 13:28, Konstantin Belousov wrote:
On Sun, Nov 06, 2016 at 12:50:12PM +0100, Mic
> On May 9, 2016, at 4:30 PM, Wolfgang Zenker wrote:
>
> * Scott Long [160503 16:27]:
>>> On May 3, 2016, at 12:20 AM, Mark Johnston wrote:
>>> [..]
>>> This was causing problems on one of my amd64 systems, so it's not
>>> specific to pow
> On May 3, 2016, at 12:20 AM, Mark Johnston wrote:
>
> On Mon, May 02, 2016 at 08:55:58PM -0400, Steve Wills wrote:
>> Hi,
>>
>> On 05/ 2/16 09:32 AM, Steve Wills wrote:
>>> Hi,
>>>
>>> Just did my monthly update and r298785 seems to be leaking wired memory
>>> rather rapidly. My system has 8
> On Mar 2, 2016, at 2:25 PM, Kenneth D. Merry wrote:
>
>>
>>
>> void scsi_ata_pass(struct ccb_scsiio *csio, u_int32_t retries,
>> void (*cbfcnp)(struct cam_periph *, union ccb *),
>> u_int32_t flags, u_int8_t tag_action,
>> struct
Hi Ken,
I’m against changing the function signature of scsi_ata_pass_16(). Even
if you manage to get things right with symbol versioning, it still leads to
problems of code compatibility. Maybe pre-existing binaries will work, but
source code will forever have to include an #if __FreeBSD_version
> On Feb 9, 2016, at 3:00 PM, John Baldwin wrote:
>
> On Tuesday, February 09, 2016 05:45:38 PM Sreekanth Reddy wrote:
>> Hi,
>>
>> While debugging more, I got one more clue,
>>
>> ---
>> static driver_
> On Jan 19, 2016, at 8:25 AM, Kenneth D. Merry wrote:
>
>
>>> In the ada(4) case, we need to add the register to struct ccb_ataio and
>>> add support in one or more of the underlying SATA drivers, e.g. ahci(4).
>>
>> I believe that changes the size of the CCB, so I tried to avoid
>> that sinc
gt; Ryan is exactly right. There was a thread a while ago, with a proposed patch
> from Kostik:
>
> https://lists.freebsd.org/pipermail/freebsd-arch/2014-July/015584.html
>
> As I recall, Scott Long also ran into this a few months ago.
>
> It happens for any NMI: enter
> On Jan 2, 2015, at 12:00 AM, Ed Maste wrote:
>
> On 1 January 2015 at 23:13, Steven Hartland wrote:
>>
>> On 02/01/2015 01:23, Bjoern A. Zeeb wrote:
>>>
>>> Hi,
>>>
>>> you need the next line of source to see that while the union only defines
>>> Simple[1], the comparison goes up to SG_LIS
On Oct 29, 2013, at 12:14 AM, Yonghyeon PYUN wrote:
>>
>> I tested the 0x4c0 on real hardware. an MSI Z87I motherboard. The rest
>> came from looking at the linux driver. That driver is structured very
>> differently (and better, IMHO) than the FreeBSD one, so there's a lot that
>> wasn
On Sep 28, 2013, at 1:34 AM, O. Hartmann wrote:
> On Sat, 28 Sep 2013 01:10:08 -0600
> Scott Long wrote:
>
>>
>> On Sep 27, 2013, at 9:07 AM, O. Hartmann
>> wrote:
>>
>>>>>>
>>>>>> reverting those two commits solved
On Sep 27, 2013, at 9:07 AM, O. Hartmann wrote:
reverting those two commits solved the issue.
>>>
>>> In my case just rebuilding and restarting of sysutils/hal helped.
>>
>>
>> Interesting. I didn't test hal, probably should have. The compat
>> shims I put in place should have ma
On Sep 27, 2013, at 7:38 AM, Boris Samorodov wrote:
> 27.09.2013 16:59, Pietro Cerutti пишет:
>> On 2013-Sep-27, 05:57, Scott Long wrote:
>>>
>>> On Sep 27, 2013, at 5:52 AM, Sergey V. Dyatko
>>> wrote:
>>>
>>>>>>
>>
On Sep 27, 2013, at 6:13 AM, Sergey V. Dyatko wrote:
> On Fri, 27 Sep 2013 05:57:01 -0600
> Scott Long wrote:
>
>>
>> On Sep 27, 2013, at 5:52 AM, Sergey V. Dyatko
>> wrote:
>>
>>>>>
>>>>> yes, these messages disappe
On Sep 26, 2013, at 11:36 PM, Sergey V. Dyatko wrote:
> On Thu, 26 Sep 2013 16:07:18 +0300
> Konstantin Belousov wrote:
>
>> On Thu, Sep 26, 2013 at 03:40:26PM +0300, Sergey V. Dyatko wrote:
>>> On Thu, 26 Sep 2013 08:53:26 +0200
>>> "O. Hartmann" wrote:
>>>
Rebooting into CURRENT r255
On Sep 27, 2013, at 5:52 AM, Sergey V. Dyatko wrote:
>>>
>>> yes, these messages disappeared after revert 255870 and r255871
>>>
>>
>>
>> Hi,
>>
>> Nothing that I changes should have affected the ahci driver. In
>> fact, I tested this driver specifically during my development. Can
>> you
On Sep 15, 2013, at 8:17 PM, Yonghyeon PYUN wrote:
> On Sat, Sep 14, 2013 at 08:47:06PM -0600, Scott Long wrote:
>> Index: sys/dev/re/if_re.c
>> ===
>> --- sys/dev/re/if_re.c (revision 255582)
>
Hi Thomas,
I recommend getting ahold of the pfsense guys with this question.
Scott
On Sep 15, 2013, at 2:35 AM, Thomas Guldener wrote:
> Is it also possible to get a working kernel in FreeBSD 8.3 for PFSense
> support?
>
> g.
> Thomas
>
>
> On 15 Sep 2013, at
Index: sys/dev/re/if_re.c
===
--- sys/dev/re/if_re.c (revision 255582)
+++ sys/dev/re/if_re.c (working copy)
@@ -234,6 +234,10 @@
{ RL_HWREV_8168E_VL, RL_8169, "8168E/8111E-VL", RL_JUMBO_MTU_6K},
{ RL_HWREV_8168F, RL_
On Aug 29, 2013, at 7:42 AM, John Baldwin wrote:
> On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote:
>> There are a number of other places in the kernel where migration to an
>> rmlock
>> makes sense -- however, some care must be taken for four reasons: (1) while
>> read locks don
On Aug 24, 2013, at 12:14 PM, Alfred Perlstein wrote:
> On 8/24/13 10:47 AM, Robert N. M. Watson wrote:
>> On 24 Aug 2013, at 17:36, Alfred Perlstein wrote:
>>
We should distinguish "lock contention" from "line contention". When
acquiring a rwlock on multiple CPUs concurrently, the c
On Aug 12, 2013, at 1:43 PM, Sean Bruno wrote:
> http://people.freebsd.org/~sbruno/10_i386_vmfault.txt
>
> I can never tell if stuff like this is because I'm not nerfing the
> system RAM correctly or if this is i386 bit-rot.
>
> I set hw.physmem="2g" in loader.conf to try and get the system
All,
Subversion rev 250418 affected approximately 63 drivers by making them
vulnerable to resource allocation failures on motherboards with buggy BIOSes.
The revision itself is good, but it needs to address these drivers and bring
them up to what is, in effect, a modified way for drivers to ma
Yup, it's an incredibly unsafe pattern. It also leads to the pattern where
auxiliary processing is handed off to a taskqueue, which then interleaves
the lock ownership with the ithread and produces out-of-order packet
reception.
Scott
On Aug 8, 2013, at 5:18 PM, Adrian Chadd wrote:
> .. and it
On Aug 7, 2013, at 10:16 PM, Warner Losh wrote:
>
> On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote:
>
>> .. and I bet it's not a design pattern, and this is total conjecture on my
>> part:
>>
>> * the original drivers weren't SMP safe;
>> * noone really sat down and figured out how to corre
On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote:
> .. and I bet it's not a design pattern, and this is total conjecture on my
> part:
>
> * the original drivers weren't SMP safe;
> * noone really sat down and figured out how to correctly synchronise
> all of this stuff;
> * people did the mini
On Aug 5, 2013, at 2:23 AM, Luigi Rizzo wrote:
> i am slightly unclear of what mechanisms we use to prevent races
> between interface being reconfigured (up/down/multicast setting, etc,
> all causing reinitialization of the rx and tx rings) and
>
> i) packets from the host stack being sent out;
On Jul 11, 2013, at 11:48 AM, Konstantin Belousov wrote:
> On Thu, Jul 11, 2013 at 11:44:32AM -0700, Scott Long wrote:
>>
>> On Jul 10, 2013, at 11:17 PM, Konstantin Belousov
>> wrote:
>>
>>> On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote
On Jul 11, 2013, at 2:56 AM, Konstantin Belousov wrote:
> On Thu, Jul 11, 2013 at 02:39:00AM -0700, Adrian Chadd wrote:
>> On 11 July 2013 02:36, Konstantin Belousov wrote:
>>
>>> No, it is not disk I/O which is problematic there. It is socket I/O
>>> e.g. wait for the socket buffers lomark in
On Jul 10, 2013, at 11:17 PM, Konstantin Belousov wrote:
> On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote:
>> Hiya,
>>
>> I've started writing an aio_sendfile() syscall.
>>
>> http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff
>>
>> Yes, the diff is against -HEAD
On Apr 15, 2013, at 1:27 PM, Cy Schubert wrote:
> In message , Scott Long
> writes:
>>
>> On Apr 15, 2013, at 11:48 AM, Cy Schubert wrote:
>>
>>> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo
>>> writes:
>>
On Apr 15, 2013, at 11:48 AM, Cy Schubert wrote:
> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo
> writes:
>> 2013/04/15 9:55$B!"(BCy Schubert
>> $B$N%a%C%;!<%8(B:
>>
>>> I've been planning on taking on IP Filter for quite some time.
>>> Unfortunately I've left
The desire to remove it stems from the inability to give it adequate
engineering
service as the network stack evolves. Simply taking it out of a kernel config
file
doesn't address that problem at all. If it's going to stay in FreeBSD at all,
it
needs to be maintained. This could be set about
On Apr 14, 2013, at 7:20 AM, Joe wrote:
> Rui Paulo wrote:
>> On 2013/04/12, at 22:31, Scott Long wrote:
>>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
>>>
>>>> On 2013/04/11, at 13:18, Gleb Smirnoff wrote:
>>>>
>>>>&g
On Apr 13, 2013, at 11:43 AM, Rui Paulo wrote:
> On 2013/04/13, at 5:03, Scott Long wrote:
>> You target audience for this isn't people who track CURRENT, it's people who
>> are on 7, 8, or 9 and looking to update to 10.x sometime in the future.
>
> Yes, I&#
On Apr 13, 2013, at 12:33 AM, Rui Paulo wrote:
> On 2013/04/12, at 22:31, Scott Long wrote:
>
>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
>>
>>> On 2013/04/11, at 13:18, Gleb Smirnoff wrote:
>>>
>>>> Lack of maintainer in a near fu
On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
> On 2013/04/11, at 13:18, Gleb Smirnoff wrote:
>
>> Lack of maintainer in a near future would lead to bitrot due to changes
>> in other areas of network stack, kernel APIs, etc. This already happens,
>> many changes during 10.0-CURRENT cycle were
On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz wrote:
> On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
>> Hi.
>>
>> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
>> stack, using only some controller drivers of old ata(4) by having
>> `options ATA_CA
On Mar 29, 2013, at 2:58 PM, Konstantin Belousov wrote:
>>
> I think this is definitely a feature that should be set by a flag to
> either file descriptor used for aio_read, or aio_read call itself.
> Adding a flag to aio_read() might be cumbersome from the ABI perspective.
>
Fine if you thin
On Mar 27, 2013, at 4:13 PM, Matthew Jacob wrote:
> On 3/27/2013 2:22 PM, Alexander Motin wrote:
>> Hi.
>>
>> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
>> stack, using only some controller drivers of old ata(4) by having `options
>> ATA_CAM` enabled in all kernels
On Mar 28, 2013, at 8:00 AM, Ian Lepore wrote:
> On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote:
>> On 28.03.2013 02:43, Adrian Chadd wrote:
>>> My main concern with the new stuff is that it requires CAM and that's
>>> reasonably big compared to the standalone ATA code.
>>>
>>> It'd b
On Mar 27, 2013, at 6:43 PM, Adrian Chadd wrote:
> My main concern with the new stuff is that it requires CAM and that's
> reasonably big compared to the standalone ATA code.
>
>From a code execution standpoint? No, it's not.
> It'd be nice if we could slim down the CAM stack a bit first; it
On Aug 31, 2012, at 2:43 AM, Dimitry Andric wrote:
> On 2012-08-31 09:34, deeptec...@gmail.com wrote:
>> /usr/src/sys/modules/amr/../../dev/amr/amr.c:970:1: error: function
>> 'amr_periodic' is not needed and will not be emitted
>> [-Werror,-Wunneeded-internal-declaration]
>
> The o
On Aug 18, 2012, at 3:43 PM, Matthew Jacob wrote:
> On 8/18/2012 2:36 PM, Poul-Henning Kamp wrote:
>> In message <50300540.9060...@feral.com>, Matthew Jacob writes:
>>
>>> [...] that there might be a measurable
>>> difference for having to copy 4K (unaligned) than 1K (unaligned) to
>>> kernel s
On Aug 6, 2012, at 12:06 PM, Gleb Smirnoff wrote:
> Michael,
>
> On Sat, Aug 04, 2012 at 12:49:49PM -0400, Michael Butler wrote:
> M> Something in -current and recently MFC'd to -stable is causing all of my
> M> gmirror drives to rebuild on reboot :-(
> M>
> M> Being remote and these being pr
On Aug 2, 2012, at 12:23 AM, Kevin Oberman wrote:
> Doug makes some good points.
No, he doesn't. He and Arnould being argumentative and accusatory where none
of that is warranted.
I used to run the devsummits, and we did tele-conference lines for remote
people to participate. After I stepp
On Jul 20, 2012, at 8:04 PM, Julian Elischer wrote:
> Is anyone looking at PCIe hotplug support?
>
> I'm especially interested if anyone has a strategy for device re-insertion
> and reassociating
> the reinserted device with its old device_t so that it gets the same unit
> number..
> (assumes
- Original Message -
> From: John Baldwin
> To: curr...@freebsd.org
> Cc: sco...@freebsd.org; Peter Jeremy
> Sent: Thursday, July 12, 2012 7:40 AM
> Subject: Adding support for WC (write-combining) memory to bus_dma
>
> I have a need to allocate static DMA memory via bus_dmamem_alloc
On Jun 19, 2012, at 4:31 PM, Adrian Chadd wrote:
> I bet the answer is something like "Get FreeBSD up on it or work with
> someone who can help you do that."
>
> It's a catch-22 just like GPU - unless ${COMPANY} has customers using
> it, they're not likely to dedicate resources, and no users will
On Mar 1, 2012, at 2:39 PM, Devin Teske wrote:
>
> I'm interested in which path you would choose amongst what I've seen mentioned
> thus far:
>
> a. Modifying the boot menu to offer fine-grain control over each aspect of
> Safe
> Mode (wherein perhaps the Safe Mode option becomes a hook for a s
On Mar 1, 2012, at 9:52 AM, Devin Teske wrote:
>
>
>> -Original Message-
>> From: Andriy Gapon [mailto:a...@freebsd.org]
>> Sent: Thursday, March 01, 2012 12:39 AM
>> To: Devin Teske
>> Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; De
On Feb 28, 2012, at 6:46 AM, John Baldwin wrote:
> On Tuesday, February 28, 2012 1:23:11 am Scott Long wrote:
>> I still think that it's useful to be able to disable ACPI. Just because
> ACPI works well on modern hardware doesn't mean that everything crummy from
On Feb 28, 2012, at 6:44 AM, John Baldwin wrote:
> On Monday, February 27, 2012 2:03:21 pm Scott Long wrote:
>>
>> On Feb 27, 2012, at 3:45 AM, Andriy Gapon wrote:
>>
>>> on 30/01/2012 18:59 Andriy Gapon said the following:
>>>>
>>>> F
On Feb 27, 2012, at 3:38 PM, Andriy Gapon wrote:
>>
>> Turning off the APIC turns off SMP in a very efficient, clean manner. I
>> added this not to isolate the APIC code, but to turn off SMP. That's why
>> it's there, and I'd like the ability to turn off SMP to stay there in some
>> form.
>
>
On Feb 27, 2012, at 3:45 AM, Andriy Gapon wrote:
> on 30/01/2012 18:59 Andriy Gapon said the following:
>>
>> First, I think that this proposal/discussion could have been more useful
>> before
>> the 9.0. Maybe the RE would be interested in adding another item to their
>> pre-release checklist
On Feb 22, 2012, at 1:22 AM, Alexander Leidinger wrote:
> Quoting Scott Long (from Tue, 21 Feb 2012 17:45:04 -0700):
>
>> On Feb 21, 2012, at 7:56 AM, Alexander Leidinger wrote:
>>
>>> Hi,
>>>
>>> is there a specific reason that the following N
On Feb 21, 2012, at 10:51 AM, Navdeep Parhar wrote:
> On Tue, Feb 21, 2012 at 03:56:56PM +0100, Alexander Leidinger wrote:
>> Hi,
>>
>> is there a specific reason that the following NICs are not (or shall
>> not be) in GENERIC (at least on i386)?
>
> No specific reason for these two:
>
>> -
On Feb 21, 2012, at 7:56 AM, Alexander Leidinger wrote:
> Hi,
>
> is there a specific reason that the following NICs are not (or shall not be)
> in GENERIC (at least on i386)?
> - if_cas: is compiled as a module, Sun hardware, non-x86 only?
> - if_gem: is compiled as a module, Apple/Sun, non-x8
On Feb 1, 2012, at 9:49 PM, Cy Schubert wrote:
> Other than nooptions ATA_CAM, is there a fix or circumvention to allow
> smartmontools to work correctly under 9.0 and -CURRENT?
>
> slippy# smartctl -a /dev/ad0
> smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-STABLE i386] (local build)
> Copyright
On Jan 11, 2012, at 10:10 AM, Ian Lepore wrote:
> On Wed, 2012-01-11 at 09:59 -0700, Scott Long wrote:
>>
>> Where barriers _are_ needed is in interrupt handlers, and I can
>> discuss that if you're interested.
>>
>> Scott
>>
>
> I'd
On Jan 11, 2012, at 10:00 AM, Ian Lepore wrote:
>
> I've wished (in the ARM world) for the ability to sync a portion of a
> map. I've even kicked around the idea of proposing an API extension to
> do so, but I guess if FreeBSD went out of its way to remove that
> functionality that idea probabl
On Jan 11, 2012, at 9:29 AM, Luigi Rizzo wrote:
> On Wed, Jan 11, 2012 at 10:05:28AM -0500, John Baldwin wrote:
>> On Tuesday, January 10, 2012 5:41:00 pm Luigi Rizzo wrote:
>>> On Tue, Jan 10, 2012 at 01:52:49PM -0800, Adrian Chadd wrote:
On 10 January 2012 13:37, Luigi Rizzo wrote:
>
An old controller in the aac driver family had a variation of this problem back
when the FreeBSD contigmalloc algorithm started from the bottom of memory
instead of the top. I worked around it at driver init time by basically
assuring that page 0 (and page 1) were allocated and thrown away; it
On Jan 10, 2012, at 2:37 PM, Luigi Rizzo wrote:
> I was glancing through manpages and implementations of bus_dma(9)
> and i am a bit unclear on what this API (in particular, bus_dmamap_sync() )
> does in terms of memory barriers.
>
> I see that the x86/amd64 and ia64 code only does the bounce bu
On Dec 29, 2011, at 4:02 PM, David Thiel wrote:
> On Wed, Dec 28, 2011 at 12:57:31AM -0700, Scott Long wrote:
>> So, there's an assumption with SUJ+fsck that SU is keeping the filesystem
>> consistent. Maybe that's a bad assumption, and I'm not trying to discr
On Dec 28, 2011, at 12:34 AM, David Thiel wrote:
> On Tue, Dec 27, 2011 at 11:54:20PM -0700, Scott Long wrote:
>> The first run of fsck, using the journal, gives results that I would
>> expect. The second run seems to imply that the fixes made on the
>> first run didn&#
On Dec 27, 2011, at 10:14 PM, David Thiel wrote:
> On Tue, Dec 27, 2011 at 02:48:22PM -0800, Xin Li wrote:
- use journalled fsck; - use normal fsck to check if the
journalled fsck did the right thing.
>
> Ok, here is the log of fsck with and without journal.
>
> http://redundancy.redu
On Nov 8, 2011, at 7:52 AM, O. Hartmann wrote:
> Am 11/08/11 14:31, schrieb Chuck Burns:
>> On Tuesday, November 08, 2011 02:12:58 PM Niclas Zeising wrote:
>>> From my understanding of things, the DEFAULTS kernel configuration file
>>> is automatically included into the build by config(8). There
On Jul 25, 2011, at 11:36 AM, Freddie Cash wrote:
> On Sun, Jul 24, 2011 at 11:51 PM, Bruce Cran wrote:
>
>> On 25/07/2011 06:01, Freddie Cash wrote:
>>
>>> Thank goodness. The worst thing about sysinstall was that it tried to be a
>>> Swiss Army knife doing everything, yet not doing any one t
On Jun 23, 2011, at 11:18 PM, Scott Long wrote:
>
> On Jun 23, 2011, at 9:01 PM, Justin T. Gibbs wrote:
>
>> On 6/22/11 4:09 PM, Kenneth D. Merry wrote:
>>> On Wed, Jun 22, 2011 at 08:13:25 +0400, Andrey Chernov wrote:
>>>> On Tue, Jun 21, 2011 at 09:5
On Jun 23, 2011, at 9:01 PM, Justin T. Gibbs wrote:
> On 6/22/11 4:09 PM, Kenneth D. Merry wrote:
>> On Wed, Jun 22, 2011 at 08:13:25 +0400, Andrey Chernov wrote:
>> > On Tue, Jun 21, 2011 at 09:54:04PM -0600, Kenneth D. Merry wrote:
>> >> These two are interesting:
>> >>
>> >>> http://img825.ima
On Jun 21, 2011, at 1:13 PM, Garrett Cooper wrote:
> On Tue, Jun 21, 2011 at 11:22 AM, Andrey Chernov wrote:
>> On Tue, Jun 21, 2011 at 08:51:02PM +0300, George Kontostanos wrote:
>>> Fresh installation and after world && kernel update I get these messages
>>> during boot:
>>>
>>> xpt_action_de
On Jun 15, 2011, at 6:44 PM, Julian Elischer wrote:
>> If this was to be extended with cached global syscall information like
>> gettimeofday, would we want that to be in a separate page that is marked
>> non-executable? Is there any way to trick the kernel into leaking arbitrary
>> (and thus e
If this was to be extended with cached global syscall information like
gettimeofday, would we want that to be in a separate page that is marked
non-executable? Is there any way to trick the kernel into leaking arbitrary
(and thus executable) code? Also, would it matter for jails? Per-process
On Apr 23, 2011, at 10:36 AM, sth...@nethelp.no wrote:
>> In other words, "ada" isn't the problem here, it's that we all still think
>> in terms of the 1980's when systems didn't autoconfigure and device names
>> were important hints to system functionality. That time has thankfully
>> passed,
On Apr 20, 2011, at 2:50 PM, Alexander Motin wrote:
> Ulrich Spörlein wrote:
>> Can we then please get the "ad" device prefix back? I seem to remember
>> that when they were introduced they were thought to be a temporary thing
>> ...
>>
>> Unless both stacks can run in parallel, I don't see a prob
On Apr 18, 2011, at 9:47 AM, Alexander Kabaev wrote:
> On Mon, 18 Apr 2011 06:37:10 -0700 (PDT)
> "Pedro F. Giffuni" wrote:
>
>>
>> --- On Mon, 4/18/11, Scott Long wrote:
>> ...
>>>> Yeah it's too outdated to be of any use.
>>&g
On Apr 17, 2011, at 12:33 PM, Pedro F. Giffuni wrote:
> Yeah it's too outdated to be of any use.
>
> IMHO, you can axe libf2c too...
>
Honest question here, is there a newer version of libf2c that lives in ports
and is adopted by people who use fortran? The one that I find in the base
system
1 - 100 of 328 matches
Mail list logo
