On Tue, Jun 4, 2013 at 3:07 PM, hiren panchasara wrote:
> On Tue, Jun 4, 2013 at 2:42 PM, wrote:
> > I installed a new VM with 10.0 today from this .iso:
> >
> >
> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/amd64/10.0/FreeBSD-10.0-CURRENT-amd64-20130601-r251213-release.iso
> >
> > A
I installed a new VM with 10.0 today from this .iso:
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/amd64/10.0/FreeBSD-10.0-CURRENT-amd64-20130601-r251213-release.iso
And I'm behind a firewall and I'm not sure I can use pkg(1); my one attempt
failed:
# pkg install m4
Updating repository
On Wed, Mar 27, 2013 at 10:32 PM, Konstantin Belousov
wrote:
> On Wed, Mar 27, 2013 at 06:37:51PM -0700, m...@freebsd.org wrote:
>> VOP_GETEXTATTR is currently called with an exclusive lock, which seems
>> like overkill for what is essentially a read operation. I had a look
>> over the various in
VOP_GETEXTATTR is currently called with an exclusive lock, which seems
like overkill for what is essentially a read operation. I had a look
over the various in-tree filesystems and it didn't look like any of
them will have a problem if a shared-mode lock is used for
vop_getextattr.
Does anyone kn
On Fri, Jan 18, 2013 at 7:29 AM, Andre Oppermann wrote:
> The (inital?) size of the kmem_map is determined by some voodoo magic,
> a sprinkle of nmbclusters * PAGE_SIZE incrementor and lots of tunables.
> However it seems to work out to an effective kmem_map_size of about 58MB
> on my 16GB AMD64 d
On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote:
> 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf
> after it's finalised/freed.
>
> I have a similar bug showing up on ath(4) RX. :(
Compile with DEBUG_MEMGUARD in the kernel configuration, and then set
vm.memguard.desc to
On Sun, Nov 25, 2012 at 2:26 PM, Niclas Zeising
wrote:
> Hi!
> I consistently get this panic while trying to boot a kernel build from
> r243530. It happens when the entropy harvesting rc.d script starts. r243380
> worked fine, I haven't tested any revisions in between. Attached is the
> backtrace
On Thu, Nov 1, 2012 at 7:41 PM, Eitan Adler wrote:
> On 1 November 2012 10:40, Ian Lepore wrote:
>> On Wed, 2012-10-31 at 11:12 -0700, m...@freebsd.org wrote:
>>> I seem to recall a thread earlier on this limitation, but looking at
>>> actual libc/stdio sources, the 4 year old check for open(2)'s
I seem to recall a thread earlier on this limitation, but looking at
actual libc/stdio sources, the 4 year old check for open(2)'s fd being
less than SHRT_MAX is still there. I thought I saw a patch to change
this to an int, but it's not in the tree. Was this in a PR or a
mailing list thread or a
On Fri, Oct 26, 2012 at 3:24 PM, Warner Losh wrote:
>
> On Oct 26, 2012, at 1:08 PM, Garrett Cooper wrote:
>
>> On Fri, Oct 26, 2012 at 10:26 AM, wrote:
>>> Running make tinderbox locally I see failures that aren't being
>>> reported by the automated tinderbox builds. I'm curious what's
>>> dif
Running make tinderbox locally I see failures that aren't being
reported by the automated tinderbox builds. I'm curious what's
different about the environment. Failures are in the following:
arm ARMADAXP kernel failed, check _.arm.ARMADAXP for details
mips SENTRY5 kernel failed, check _.mips.SEN
mem_size_max, like 1GB or 512MB.
>> You shouldn't need to set vm_kmem_size at all. At some point the
>> added space for the memguard_map will be small enough that the
>> kmem_suballoc will work.
>>
>> Hmm, what is the min_offset and max_offset of kernel_map when the cal
On Sat, Jul 14, 2012 at 8:39 AM, Justin Hibbits wrote:
> On Jul 13, 2012, at 12:20 AM, m...@freebsd.org wrote:
>
>> On Thu, Jul 12, 2012 at 6:33 PM, Justin Hibbits
>> wrote:
>>>
>>> On Jul 12, 2012, at 9:11 PM, m...@freebsd.org wrote:
>>>
On Thu, Jul 12, 2012 at 4:43 PM, Justin Hibbits
On Thu, Jul 12, 2012 at 6:33 PM, Justin Hibbits wrote:
> On Jul 12, 2012, at 9:11 PM, m...@freebsd.org wrote:
>
>> On Thu, Jul 12, 2012 at 4:43 PM, Justin Hibbits
>> wrote:
>>>
>>> When tracking down a panic exposed by INVARIANTS, I tried setting
>>> DEBUG_MEMGUARD, so I could find the culprit th
On Thu, Jul 12, 2012 at 4:43 PM, Justin Hibbits wrote:
> When tracking down a panic exposed by INVARIANTS, I tried setting
> DEBUG_MEMGUARD, so I could find the culprit that's trashing freed memory.
> However, this causes a panic at bootup. It shows up right after the first
> WARNING: WITNESS mes
On Tue, Jun 26, 2012 at 1:59 AM, Robert Watson wrote:
> On Tue, 26 Jun 2012, Chris Rees wrote:
>
>>> as well as we don't depend of /proc for normal operation we shouldn't for
>>
>> say /proc/sysctl
>>>
>>>
>>> improvements are welcome, better documentation is welcome, changes to
>>
>> what is OK -
2012/1/17 Gleb Smirnoff :
> New panic has been introduced somewhere between
> r229851 and r229932, that happens on shutdown if
> kernel has WITNESS and doesn't have WITNESS_SKIPSPIN.
>
> Uptime: 1h0m17s
> Rebooting...
> panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @
> /usr/src
On Wed, Dec 28, 2011 at 8:54 AM, Maxim Khitrov wrote:
> On Wed, Dec 28, 2011 at 11:42 AM, Matthias Andree
> wrote:
>> Am 27.12.2011 22:53, schrieb David Thiel:
>>> I've had multiple machines now (9.0-RC3, amd64, i386 and earlier
>>> 9-CURRENT on ppc) running SU+J that have had unexplained panics
On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin wrote:
> Hmm, if these functions are expected to operate like 'write(2)' and are
> supposed to return the number of bytes written, shouldn't their return value
> be 'ssize_t' instead of 'int'? It looks like the system calls themselves
> already do the
On Tue, Dec 20, 2011 at 6:32 AM, John Baldwin wrote:
> On Tuesday, December 20, 2011 9:22:48 am m...@freebsd.org wrote:
>> On Tue, Dec 20, 2011 at 5:52 AM, John Baldwin wrote:
>> > On Saturday, December 17, 2011 10:41:15 pm m...@freebsd.org wrote:
>> >> On Sat, Dec 17, 2011 at 5:45 PM, Alexander
On Tue, Dec 20, 2011 at 5:52 AM, John Baldwin wrote:
> On Saturday, December 17, 2011 10:41:15 pm m...@freebsd.org wrote:
>> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev wrote:
>> > On Sun, 18 Dec 2011 01:09:00 +0100
>> > "O. Hartmann" wrote:
>> >
>> >> Sleeping thread (tid 100033, pid 16)
On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev wrote:
> On Sun, 18 Dec 2011 01:09:00 +0100
> "O. Hartmann" wrote:
>
>> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock
>> panic: sleeping thread
>> cpuid = 0
>>
>> PID 16 is always USB on my box.
>
> You really need to give us a ba
On Tue, Dec 13, 2011 at 3:39 PM, Ivan Klymenko wrote:
> В Wed, 14 Dec 2011 00:04:42 +0100
> Jilles Tjoelker пишет:
>
>> On Tue, Dec 13, 2011 at 10:40:48AM +0200, Ivan Klymenko wrote:
>> > If the algorithm ULE does not contain problems - it means the
>> > problem has Core2Duo, or in a piece of cod
On Mon, Dec 12, 2011 at 7:32 AM, Gary Jennejohn
wrote:
> On Mon, 12 Dec 2011 15:13:00 +
> Vincent Hoffman wrote:
>
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 12/12/2011 13:47, O. Hartmann wrote:
>> >
>> >> Not fully right, boinc defaults to run on idprio 31 so this isn't
On Fri, Dec 2, 2011 at 2:05 AM, Andriy Gapon wrote:
> on 02/12/2011 06:36 John Baldwin said the following:
>> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when kdb
>> was
>> active). But I think these two changes should cover critical_exit() ok.
>>
>
> I attempted to start
On Thu, Nov 17, 2011 at 1:08 PM, Andriy Gapon wrote:
> on 17/11/2011 23:02 m...@freebsd.org said the following:
>> Another patch related to this area we have at $WORK:
>>
>> #if defined(SMP)
>> - /*
>> - * Bind us to CPU 0 so that all shutdown code runs there. Some
>> - * sys
On Thu, Nov 17, 2011 at 12:54 PM, Attilio Rao wrote:
> 2011/11/17 Andriy Gapon :
>> BTW, it is my opinion that we really should not let the debugger code call
>> mi_switch for any reason.
>
> Yes, I agree with this, this is why the sched_bind() in boot() is
> broken (immagine calling things like d
On Tue, Nov 15, 2011 at 10:15 AM, Attilio Rao wrote:
> 2011/11/7 Kostik Belousov :
>> On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote:
>>> Ok. I'll offer one final suggestion. Please consider an alternative
>>> suffix to "func". Perhaps, "kbi" or "KBI". In other words, something
>>> t
On Mon, Nov 7, 2011 at 11:35 AM, Kostik Belousov wrote:
> On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote:
>> Ok. I'll offer one final suggestion. Please consider an alternative
>> suffix to "func". Perhaps, "kbi" or "KBI". In other words, something
>> that hints at the function's rea
On Sun, Nov 6, 2011 at 4:43 AM, Kostik Belousov wrote:
> Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has
> a lot of violations in regard of the namespaces, IMO. The __* namespace
> is reserved for the language implementation, so our freestanding program
> (kernel) ignores th
On Sat, Nov 5, 2011 at 7:13 AM, Kostik Belousov wrote:
> On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote:
>
> Below is the KBI patch after vm_page_bits_t merge is done.
> Again, I did not spent time converting all in-tree consumers
> from the (potentially) loadable modules to the n
On Fri, Oct 28, 2011 at 8:37 AM, Ryan Stone wrote:
> I'm seeing issues on a unicore systems running a derivative of FreeBSD
> 8.2-RELEASE if something calls mem_range_attr_set. It turns out that
> the root cause is a bug in smp_rendezvous_cpus. The first part of
> smp_rendezvous_cpus attempts to
On Thu, Aug 18, 2011 at 5:50 PM, Garrett Cooper wrote:
> When loading if_alc as a module on my netbook and running
> /etc/rc.d/netif restart, I can deterministically panic my netbook with
> the following message:
>
> ) at _bus_dmamap_sync+0x51
> alc_stop(c3dbb000,0,c0c51844,93a,80206910,...) at
On Mon, Aug 1, 2011 at 12:09 AM, Andrew Thompson wrote:
> Hi,
>
> Looking at,
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=159345
>
> The lock is a global variable, declared as
>
> static struct mtx lagg_list_mtx;
>
> I would expect this to be zeroed memory, is this guaranteed?
It depends
On Mon, Jul 18, 2011 at 3:15 PM, Joel Jacobson wrote:
> a few years ago (2008), i asked about the prospect of getting an sgl passed
> through struct buf / bio, and was referred to the jhb_bio branch. i never
> did figure out how to view it, though, and it fell off my radar for a while.
>
> did
On Mon, Jul 11, 2011 at 4:00 PM, Ali Mashtizadeh wrote:
> Maybe someone can setup something like reviewboard [1] for developers
> to use. This may also help folks who want to keep abreast of the
> current work in a particular subsystem or get involved into the
> development process more. At my com
On Mon, Jun 27, 2011 at 3:08 AM, Andriy Gapon wrote:
> on 26/06/2011 08:51 Warner Losh said the following:
>>
>> On Jun 25, 2011, at 8:49 AM, Andriy Gapon wrote:
>>> Does anybody actually use kern.sync_on_panic tunable/sysctl? If yes, then
>>> in what circumstances do you need it? That is, why any
On Mon, Jun 20, 2011 at 1:53 PM, Luigi Rizzo wrote:
> i recently replaced my laptop with a mac, which opens the problem on
> how do i do FreeBSD development (including kernel work) on it.
>
> the option i am trying now is running a freebsd VM in virtualbox,
> but it is slightly slow and probably e
On Mon, Jun 20, 2011 at 11:40 AM, Garrett Cooper wrote:
> On Mon, Jun 20, 2011 at 11:37 AM, FreeBSD Tinderbox
> wrote:
>> TB --- 2011-06-20 17:09:28 - tinderbox 2.7 running on
>> freebsd-current.sentex.ca
>> TB --- 2011-06-20 17:09:28 - starting HEAD tinderbox run for ia64/ia64
>> TB --- 2011-06
On Tue, Apr 19, 2011 at 11:02 AM, Doug Barton wrote:
> On 4/19/2011 9:44 AM, m...@freebsd.org wrote:
>>
>> As an aside, what kind of h/w do I need
>> for hw.acpi.thermal to show up? I don't see it on my Dell desktop...
>
> The hardware is likely to be there for any reasonably modern Dell desktop.
On Tue, Apr 19, 2011 at 7:48 AM, Taku YAMAMOTO wrote:
>> This patch works.
>>
>> FreeBSD 9.0-CURRENT #1: Tue Apr 19 10:52:58 MSD 2011
>>
>> # sysctl hw.acpi.thermal
>> hw.acpi.thermal.min_runtime: 0
>> hw.acpi.thermal.polling_rate: 10
>> hw.acpi.thermal.user_override: 0
>> hw.acpi.thermal.tz0.temp
>> hw.acpi.thermal.tz0._TC1: -1
>> hw.acpi.thermal.tz0._TC2: -1
>> hw.acpi.thermal.tz0._TSP: -1
>>
>> output from:
>> sysctl -a |grep acpi
>> is here: https://privatepaste.com/ca08d4658b
>
> I suspect it is still there, but sysctl doesn'
>> hw.acpi.thermal.tz0._TC1: -1
>> hw.acpi.thermal.tz0._TC2: -1
>> hw.acpi.thermal.tz0._TSP: -1
>>
>> output from:
>> sysctl -a |grep acpi
>> is here: https://privatepaste.com/ca08d4658b
>
> I suspect it is still there, but sysctl doesn'
On Thu, Feb 3, 2011 at 7:09 AM, John Baldwin wrote:
> On Thursday, February 03, 2011 8:05:31 am John Baldwin wrote:
>> On Tuesday, February 01, 2011 11:58:12 am m...@freebsd.org wrote:
>> > On a piece of hardware trying to verify basic build tests, we got an
>> > MCA exception that then panic'd th
On a piece of hardware trying to verify basic build tests, we got an
MCA exception that then panic'd the kernel due to WITNESS/INVARIANTS
interaction.
panic @ time 1296563157.510, thread 0xff000554: blockable
sleep lock (sleep mutex) 128 @ /build/mnt/src/sys/vm/uma_core.c:1872
Stack:
On Fri, Nov 12, 2010 at 12:25 PM, Hans Petter Selasky wrote:
> On Friday 12 November 2010 17:38:38 m...@freebsd.org wrote:
>> On Fri, Nov 12, 2010 at 6:23 AM, Hans Petter Selasky
> wrote:
>> > On Friday 12 November 2010 15:18:46 m...@freebsd.org wrote:
>> >> On Fri, Nov 12, 2010 at 12:56 AM, Hans
.freebsd.org/viewvc/base/head/sys/kern/subr_taskqueue.c
You will see quite a few commits by me. The most recent relating to
detecting if a task is running is being MFC'd today:
Revision 213813 - (view) (annotate) - [select for diffs]
Modified Wed Oct 13 22:59:04 2010 UTC (4 weeks, 1 day
On Fri, Nov 12, 2010 at 12:56 AM, Hans Petter Selasky wrote:
> On Thursday 29 April 2010 01:59:58 Matthew Fleming wrote:
>> It looks to me like taskqueue_drain(taskqueue_thread, foo) will not
>> correctly detect whether or not a task is currently running. The check
>> is against a field in the ta
On Wed, Nov 3, 2010 at 9:42 AM, Andriy Gapon wrote:
> on 03/11/2010 18:27 m...@freebsd.org said the following:
>> It's not clear to me from the man pages (perhaps I didn't look at the
>> right one?) in which environments I need a spinlock. For example, I
>> wouldn't think it's safe to use a MTX_D
It's not clear to me from the man pages (perhaps I didn't look at the
right one?) in which environments I need a spinlock. For example, I
wouldn't think it's safe to use a MTX_DEF in a hard interrupt handler
(i.e one that was registered with BUS_SETUP_INTR), but I see some code
lying around here t
I'm trying to add support for kldload of compressed modules; they work
at boot time but not at runtime.
I'm having trouble uncompressing the module in the kernel to try
processing it. The difficulty is several-fold:
1) gzip(1) doesn't seem to produce a compressed image that net/zlib.c
understand
There's explicit protection for free(NULL, M_FOO), but uma_zfree(zone,
NULL) will put NULL in the local bucket and then probably return it
later from a uma_zalloc call. Obviously it's not a good idea to call
uma_zfree(9) on NULL, but in this case it's an easy mistake to make
when e.g. converting a
On Mon, Sep 27, 2010 at 9:21 AM, Sean Bruno wrote:
> On Mon, 2010-09-27 at 08:53 -0700, Julian Elischer wrote:
>> On 9/27/10 8:26 AM, Sean Bruno wrote:
>> > Does this look like an appropriate modification to libmemstat?
>> >
>> > Sean
>> >
>> >
>> > //depot/yahoo/ybsd_7/src/lib/libmemstat/mem
I can't say I understand much about the syntax of the top part of
sys/conf/files, but this line:
aicasm optional ahc | ahd \
dependency "$S/dev/aic7xxx/aicasm/*.[chyl]" \
compile-with"CC='${CC}' ${MAKE} -f
On Fri, Sep 10, 2010 at 6:57 PM, Yuri Pankov wrote:
> Nevermind me. That's what I thought why I was getting the same gpart behavior
> switching between kernels, with and without DEBUG_LOCKS. Sorry about that.
>
> Same here, gpart hangs on:
> 3826 gpart CALL __sysctl(0x7fffa250,0x3,0,0x7fff
On Wed, Sep 8, 2010 at 9:15 AM, Rink Springer wrote:
> Hi,
>
> On Wed, Sep 08, 2010 at 08:51:57AM -0700, m...@freebsd.org wrote:
>> It seems like a large project, but OTOH sprintf(9) is mighty unsafe in
>> the kernel. It's disapproved of for user-space as being unsafe for
>> security reasons as w
Looking at the uses of kvprintf(9), only [v]sprintf(9) doesn't have a
callback function. It seems a little sketchy to me to be doing unsafe
sprintf in the kernel anyways.
Should we (and by we, I mean me) deprecate sprintf(9) and convert the
existing 1200+ uses to strcpy(9) for fixed strings (also
On Wed, Sep 1, 2010 at 6:49 AM, John Baldwin wrote:
> On Tuesday, August 31, 2010 2:53:12 pm m...@freebsd.org wrote:
>> On Tue, Aug 31, 2010 at 10:16 AM, wrote:
>> > I recorded the stack any time ts->ts_cpu was set and when a thread was
>> > migrated by sched_switch() I printed out the recorded
inned
3) have the IPI_PREEMPT handler notice the thread is pinned (and not
trying to bind) and postpone the mi_switch, just like it postpones
when a thread is in a critical section.
Except for the potential complexity of implementation, I think (2) is
the best solution.
For those who want to play a
I recorded the stack any time ts->ts_cpu was set and when a thread was
migrated by sched_switch() I printed out the recorded info. Here's
what I found:
XXX bug 67957: moving 0xff003ff9b800 from 3 to 1
[1]: pin 0 state 4 move 3 -> 1 done by 0xff000cc44000:
#0 0x802b36b4 at bug6795
On Thu, Aug 26, 2010 at 3:10 PM, Andriy Gapon wrote:
> on 27/08/2010 00:20 m...@freebsd.org said the following:
>>
>> I tried making sched_pin() a real function which used
>> intr_disable/intr_restore around saving off td->td_oncpu,
>> td->td_lastcpu and ts->ts_cpu, and the stack at the time of ca
On Thu, Aug 26, 2010 at 1:49 PM, John Baldwin wrote:
> On Thursday, August 26, 2010 4:03:38 pm m...@freebsd.org wrote:
>> Back at the beginning of August I posted about issues with sched_pin()
>> and witness_warn():
>>
>> http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032553.html
>
Back at the beginning of August I posted about issues with sched_pin()
and witness_warn():
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032553.html
After a lot of debugging I think I've basically found the issue. I
found this bug on stable/7, but looking at the commit log for C
On Thu, Aug 12, 2010 at 1:51 PM, wrote:
> The tinderbox break is my bad. I will have it fixed by the end of the day.
Actually, the amd64 break is not me, because it broke before it got to
my mistake. i386 and presumably all the other 32-bit builds are due
to my memguard(9) patch.
> :-(
> matt
The tinderbox break is my bad. I will have it fixed by the end of the day.
:-(
matthew
On Thu, Aug 12, 2010 at 3:25 AM, FreeBSD Tinderbox
wrote:
> TB --- 2010-08-12 01:30:00 - tinderbox 2.6 running on
> freebsd-current.sentex.ca
> TB --- 2010-08-12 01:30:00 - starting HEAD tinderbox run for am
On Thu, Jul 29, 2010 at 7:18 AM, John Baldwin wrote:
> On Wednesday, July 28, 2010 1:37:42 pm m...@freebsd.org wrote:
>> I have a 2 cpu virtual image of FreeBSD current. It panics during
>> boot after building in the NUMA support.
>>
>> I'll transcribe the SRAT bootverbose messages and panic mess
On Wed, Jul 28, 2010 at 11:19 AM, David Cornejo wrote:
> On Wed, Jul 28, 2010 at 7:37 AM, wrote:
>>
>> I have a 2 cpu virtual image of FreeBSD current. It panics during
>> boot after building in the NUMA support.
>>
>> I'll transcribe the SRAT bootverbose messages and panic message as best I
>>
On Wed, Jul 28, 2010 at 10:37 AM, wrote:
> I have a 2 cpu virtual image of FreeBSD current. It panics during
> boot after building in the NUMA support.
>
> I'll transcribe the SRAT bootverbose messages and panic message as best I can.
>
> Table 'SRAT' at 0xfef07f6
> SRAT: Found table at 0xfef07f
I have a 2 cpu virtual image of FreeBSD current. It panics during
boot after building in the NUMA support.
I'll transcribe the SRAT bootverbose messages and panic message as best I can.
Table 'SRAT' at 0xfef07f6
SRAT: Found table at 0xfef07f6
SRAT: Found memory domain 0 addr 0 len a: enabled
On Fri, Jun 18, 2010 at 8:11 AM, Alexander Best
wrote:
> On Mon, Jun 7, 2010 at 3:57 PM, John Baldwin wrote:
>> It can happen because the print buffer size thing is not line-buffered, it is
>> printf-invocation buffered.
>
> hmmm...can this somehow be fixed? i'm not sure this is specific to
> scs
70 matches
Mail list logo
