+1
Very useful :)
-a
On 9 October 2013 01:55, Andriy Gapon wrote:
>
> I would like to propose to extend taskqueue API with taskqueue_drain_all.
> A potential use case: I have a private taskqueue, several kinds of tasks
> get
> executed via it and then I want to make sure that all of them are
Hi,
Please try it out on a -10 VM with something RAM limited - say, 128mb w/
GENERIC. See how it behaves.
I've successfully done buildworlds on 10-i386 with 128mb RAM. Let's try not
to break that before releng/10 is cut.
thanks,
-adrian
On 7 October 2013 23:34, Peter Holm wr
implies anything that
> > uses libkvm) probably needs to match the kernel.
> >
> > Has anyone investigated this approach?
> >
>
> Why are you ignoring PAE? It's been working for me for years.
>
Yeah, if there's PAE issues in -HEAD (read: there are,
On 23 September 2013 14:30, Sebastian Kuzminsky wrote:
> On Sep 23, 2013, at 15:24 , Adrian Chadd wrote:
>
> > On 20 September 2013 08:20, Sebastian Kuzminsky
> wrote:
> >
> > It's transparent for the kernel: all of UMA and
> kmem_malloc()/kmem_f
On 20 September 2013 08:20, Sebastian Kuzminsky wrote:
> It's transparent for the kernel: all of UMA and kmem_malloc()/kmem_free()
> is backed by 1 gig superpages.
>
.. not entirely true, as I've found out at work. :(
-adrian
his is better for forwarding
workloads. I'd like to characterize it though. So, what's it doing that's
better? better locking? better caching behaviour? less memory lookups? etc.
Thanks,
-adrian
___
freebsd-hackers@freebsd.org mailing li
a whole lot of design stars to align. And I'm still knee
deep elsewhere, so I haven't really finished getting up to speed with what
everyone else has done / said about it..
-adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.fre
like per-packet latency as
well as top-level processing overhead (ie, CPU_CLK_UNHALTED.THREAD_P /
lagg0 TX bytes/pkts, RX bytes/pkts, NIC interrupts on that core, etc.)
Thanks,
-adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.fr
Hi!
I'd just like to publicly thank you for all your hard work on improving the
DRM2 support. This is something that's been sorely lacking lately.
So, thank you!
-adrian
On 25 August 2013 05:27, Jean-Sebastien Pedron wrote:
> Author: dumbbell
> Date: Sun Aug 25 12:
Oh look at that. It's so damned pretty.
-adrian
On 15 August 2013 18:16, Jason Hellenthal wrote:
> Has a release ever been nicknamed before ?
>
> I don't recall any.
>
> --
> Jason Hellenthal
> Inbox: jhellent...@dataix.net
> Voice: +1 (616) 953-0176
&
Cool!
I assume you've run this with full witness debugging enabled, to catch lock
ordering issues?
This is great. I look forward to per-CPU, pinned, completion threads that I
can do interesting things with (like schedule aio-sendfile completions..)
-adrian
On 15 August 2013 14:40, Alex
Cool, what's the PR number?
It sounds like something is odd. Email -current with the PR details
(number, how you reproduce it, etc) and let's see if we can get one of
the VM/UMA gurus to look into it.
Thanks,
-adrian
On 27 July 2013 00:26, Tugrul Erdogan wrote:
> I have jus
Hi
Have you filed a PR? This should get fixed.
Also, being -ve is a problem. Is the value really negative? Is it
wrapping badly?
-adrian
On 25 July 2013 07:57, Tugrul Erdogan wrote:
> howdy all,
>
> At my work, I am using 10.0-CURRENT on Intel(R) Xeon(R) E5620 with 16GB
> ram.
o make up the slack, etc.
Is it a busted halt loop, which is being papered over with hz ticks?
Have you tried -10 on that kit, with the more aggressive clock/timer
code that won't interrupt unless it needs to? Has that changed things?
-adrian
___
I now work at a place where I have to care about this.
So, if someone provides me with a sane implementation and API
description, I'll review and commit it.
-adrian
On 24 July 2013 09:48, Paul LeoNerd wrote:
> Did we ever reach a consensus about this issue? We discussed it
> s
On 24 July 2013 16:43, Ronald F. Guilmette wrote:
>
> Thank you.
>
> Please consider yourself bugged.
> (1/2 :-)
:-)
I'm currently trying to figure out ixgbe and lagg bugs (separately and
together.) Once I've done that, I'll look at nc. Just keep bu
Well, why is it reducing latency? That's the thing you should investigate.
Is it because processes aren't getting enough time? or too much time?
Or the audio device isn't getting enough time to run? etc.
-adrian
On 24 July 2013 15:35, Super Bisquit wrote:
> http://lists.fre
7;t commit either your fix, or
rearchitect it to do what I said above (and then test it, obviously :)
-adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Right, and your patch just stops the shutdown(), right? Rather than
teaching nc to correctly check BOTH socket states before deciding to
close things.
I'd personally rather see nc taught to check to see whether it can
possibly make ANY more progress before deciding to shut things down.
-a
te it, and aborting if it
sees EOF on stdin _and_ EOF/error on writing to stdout)
Right?
-adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-h
it's done a shutdown(fd, WR) - then it shouldn't error out on EOF
events on writes to the FD
* But it shouldn't get a read EOF on the socket until the remote side
signifies it.
Is nc seeing EOF on reading form the server side prematurely?
If that's actually what's going on - if you can verify that indeed its
not some local broken handling of shutdown(fd, WR) then yes, I think
it's worth changing nc. And I do think it's worth adding a "call
shutdown(fd, WR) once the sender is finished" option for people that
k release. It looks
> like the cache line is constantly erased by something.
Can you narrow down the resource stall check to each of the sub-types?
See which one/ones it is?
-adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.
ersion still has to modify more entries that
> are not contiguous.
Good point.
-adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
hange until you absolutely, positively know why it's
actually being helpful. It's way way too "voodoo" right now.
Thanks,
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
x27;s a lot more CPU counters available.
You have a very cool problem to solve. If I could reproduce it locally
I'd give you a hand.
Thanks,
-adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hac
... so run it inside hwpmc and see what the resulting CPU users are?
adrian
On 31 May 2013 07:01, Chris Rees wrote:
> Hi all,
>
> I think I've discovered a strange behaviour of sed perhaps triggered
> by the length of a regex passed to it. I noticed that a certain
> expr
this stuff. Why?
Because I architected the HTTP side of things to specifically pin FDs
to threads, and not allow arbitrary threads to deal with arbitrary
FDs. This removed the need for almost all of the state locking that
people are concerned about here.
Adrian
... also, want to code up a test implementation?
And some stress testing cases to throw in the regression tree?
I'll help shephard this in if this all works out.
thanks,
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebs
to
again, damned HTTP proxies!) and I would love to have better
semantics here.
I just want to make sure it doesn't cause weird things for the
non-socket case - ie, files (local, NFS) and signals.
Adrian
___
freebsd-hackers@freebsd.org m
ack. Until that is done, I think
you have no excuse to get your code working as needed.
Don't blame kqueue because what (iirc) is not defined behaviour isn't
defined in a way that makes you happy :)
Adrian
On 13 May 2013 09:36, Eugen-Andrei Gavriloaie wrote:
> Hi Adrian,
>
>
#x27;ve written network apps with kqueue that
scales to 8+ cores and (back in mid-2000's) gigabit + of small HTTP
transactions. This stuff isn't at all problematic.
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
... or you could just track the per-descriptor / per-object stuff in
userland, and use the FD/signal as an index into the state you need.
adding thread happiness on top of that is trivial.
Done/done.
Adrian
On 13 May 2013 08:19, Eugen-Andrei Gavriloaie wrote:
> Hello to all,
>
> I
vga/vesa
* perhaps acpi_* for your laptop device
.. those can't be in rc.conf .
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebs
On 25 April 2013 01:38, Lars Engels wrote:
> On Thu, Apr 25, 2013 at 01:25:46AM -0700, Adrian Chadd wrote:
>> .. or we could just bite the bullet and split GENERIC into GENERIC
>> (which would have modules for everything) and GENERIC_NOMODULES.
>>
>> Then just populate
great GSoC project.
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Hah, nice catch! You guys rock.
Scratch one less weird shit thing with FreeBSD on VMWARE.
Adrian
On 23 April 2013 16:03, Dimitry Andric wrote:
>
> On Apr 24, 2013, at 00:03, Dimitry Andric wrote:
>
>> On Apr 23, 2013, at 23:46, Andriy Gapon wrote:
>>> on 23/04/2013
On 10 April 2013 13:06, Joshua Isom wrote:
>
> I upgraded my system with 32Gb for a reason.
Yes, yes you did.
TO force me to fix ath(4) and busdma. ;-)
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/li
odule, the underlying
size is almost the same anyway.
Thanks,
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
gt; a kernel with everything modularized as possible isn't small enough, FreeBSD
> probably isn't going to work for you for other reasons.
The MIPS kernels I'm producing are pretty bare. There's not a lot of
options to disable at this point.. :(
Adrian
__
at's a lot of both code and bss just for mutex handling, don't you
think? Do we really need 59KiB of code and 48KiB of BSS just for mutex
handling?
textdata bss dec hex filename
184 0 12160 123443038 sc_machdep.o
.. 8 consoles? 12k of BSS? again, not mu
Hi,
Your idea is interesting, but it doesn't fix the underlying problem -
there's just too much code. :(
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send a
driver layer to write named
> blocks of memory from that device to the raw device (we didin't use a
> filesystem).
Funny that. I have to do something like this for this software radio
NIC, that does a hundred or so megabytes a second of DMA.
Eek.
Adrian
_
d xen.
Adrian
On 31 March 2013 21:48, Eitan Adler wrote:
> Hi,
>
> I am writing this email to discuss the i386 architecture in FreeBSD.
>
> Computers are getting faster, but also more memory intensive. I
> can not find a laptop with less than 4 or 8 GB of RAM. Modern
> browsers,
Participate in FreeBSD development and offer to
support branches for longer. But please don't complain to a bunch of
volunteers who look after stuff in their spare time, or companies who fund
work for FreeBSD branches that they're using.
The 'project' does
smaller project
> might exist to fill this need.
It's actually in line with our philosophy. If people are willing to
pay for it, then grab a company to do it. :)
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
It's because there are kernel structures which kgdb needs to get its
grubby fingers into when decoding things.
I wish things weren't so tightly coupled though..
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.o
Hi,
Do you rebuild the world _and_ kernel together, or do you have them out of sync?
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-ha
You need to use 'bt' to see the stack trace, then 'frame X' to go into
that frame.
Post 'bt' output and I'll show you what you're looking for.
Adrian
On 24 March 2013 10:23, Joshua Isom wrote:
> I have several core dumps that need debugged.
Yes.
Adrian
On 22 March 2013 12:09, vasanth rao naik sabavat
wrote:
> Hi,
>
> Is the FreeBSD-10 kernel preemptive?
>
> --
> Thanks,
> Vasanth
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebs
On 12 March 2013 00:52, Dimitry Andric wrote:
> On Mar 12, 2013, at 04:17 , Adrian Chadd wrote:
>> In file included from
>> /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib/sys/dev/ath/ath_hal/ar9300/ar9300_eeprom.c:21:
>> /usr/home/adrian/work/fre
I've hit this rather amusing clang behaviour:
In file included from
/usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib/sys/dev/ath/ath_hal/ar9300/ar9300_eeprom.c:21:
/usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib/sys/dev/ath/ath_hal/a
... you need to post a more useful/descrptive title and/or body in
your request. Most people won't look at the post. :-)
Adrian
On 9 March 2013 14:41, ali mousa wrote:
> Does any body agree ?
> http://forums.freebsd.org/showthread.php?p=212423#post212423 ?
>
>
&g
On 7 March 2013 03:24, Wojciech Puchar wrote:
> are there any scalability limits in case of lots of network interfaces.
> i am asking for ca 800 tun(4) interfaces active but no more than 250Mbit/s
> over them total.
Do you hit CPU limits at that point?
having the final copy
>> only
>> done on 50Hz ticks can save a lot of copying.
>>
>
> Right, but then you have to handle VSYNC hardware interrupts and copy
> framebuffer data from system memory to video memory.
Which you likely should do anyway, right? if you're g
ases for a while.
They'd still stay unsupported.. well, as long as there's not a big
group of 6.x users standing up and taking ownership.
(Same can be said of what's going to happen to 7.x soon.)
Adrian
___
freebsd-hacker
... why don't we just mark tsleep() as a barrier point and be done with it?
Same as the wakeup call?
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any ma
ines to tell the compiler to invalidate local
copies of memory structures.
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
... why aren't you using atomics? or read/write barriers?
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
.. is it actually completed?
Adrian
On 4 February 2013 18:48, Eitan Adler wrote:
> Is the following page still useful?
>
> Would there be any objection to me removing it?
>
> http://www.freebsd.org/projects/c99/index.html
>
ome corner case of optimisation that's
screwing him, or a bad choice of instruction for his given platform,
etc, etc.
Adrian
On 4 February 2013 13:09, Andriy Gapon wrote:
> on 04/02/2013 23:06 Adrian Chadd said the following:
>> I'm not the right person for it, but I think it&
I'm not the right person for it, but I think it's worth wrapping up
all my requested details in a PR so Those Who Know can take a peek.
Especially if it boils down to the choice of compiler. Who knows what
other weird corner issues people will see with clang compiling their
drivers
esults in some
> incorrect I/O access that later leads to NMI. Too many unknowns and guesses
> here, obviously.
Do you have stack traces showing where it's happening?
Posting that and the disassembly from those areas may shed a clue.
Adrian
__
any data.
>
> On the other hand, Alfred's suggestion of using poll(2) rather than
> select(2) worked perfectly. Polling with an events mask of zero results
> in it returning POLLHUP in revents if the client has closed the socket.
Just make su
records in
> 10+0 records out
> 1024 bytes transferred in 19.615134 secs (522046 bytes/sec)
>
> 522 KB/s is pathetic.
When this is running, use gstat and see exactly how many IOPS/sec
there are and the average io size is.
Yes, 522kbytes/sec is really pathetic, but there's a
When you run gstat, how many ops/sec are you seeing?
Adrian
On 17 January 2013 20:03, Dieter BSD wrote:
>> I am thinking that something fancy in that SAS drive is
>> not being handled correctly by the FreeBSD driver.
>
> I think so too, and I think the something fancy
d yes, it'd be nice to have -b so I can use -b and -r to instantly
open up a remote gdb session.
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "
Also, I found 'set remotebaud' and 'set debug remote 1' to do this.
I'd like to add the code just to support the same -b flag as gdb (so
-r can also be used with a non-standard serial port.)
Thanks,
Adrian
On 15 January 2013 21:15, Adrian Chadd wrote:
> Hi,
&g
gdb over serial to a 115200 console MIPS
device.
The MIPS stuff has other issues; I'll talk about those later.
Thanks,
Adrian
Index: gnu/usr.bin/gdb/kgdb/main.c
===
--- gnu/usr.bin/gdb/kgdb/main.c (revision 245281)
+++ gn
mple patch. Thanks!
Adrian
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 245281)
+++ Makefile.inc1 (working copy)
@@ -1211,6 +1211,7 @@
${_clang_libs} \
${_clang} \
${_binutils} \
+gnu/u
. The results aren't going
to match, not unless you exhaust physical memory and start falling
behind on disk IO. At that point you'll see what the fuss is about.
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailm
Please file a PR? :)
Thanks!
ADrian
On 11 January 2013 03:15, zeissoctopus wrote:
> Dear All,
>
> My dirty hack just works but not perfect.
>
> --- /usr/src/sys/dev/asmc/asmcvar.h.original2013-01-11
> 09:36:53.0 +
> +++ /usr/src/sys/dev/asmc/asmcvar.h
libevent doesn't do disk IO.
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
hen do a bunch of testing
to ensure nothing has regressed.
Thanks,
adrian
On 5 January 2013 18:03, Adrian Chadd wrote:
> On 5 January 2013 13:54, Jason Evans wrote:
>
>>> Jason - any comments?
>>
>> There are many variations on this class of performance problem,
On 8 January 2013 08:15, Richard Sharpe wrote:
> On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote:
>> .. or you could abstract it out a bit and use freebsd's
>> aio_waitcomplete() or kqueue aio notification.
>>
>> It'll then behave much saner.
>
> Y
.. or you could abstract it out a bit and use freebsd's
aio_waitcomplete() or kqueue aio notification.
It'll then behave much saner.
adrian
On 7 January 2013 22:26, Richard Sharpe wrote:
> On Mon, 2013-01-07 at 22:24 -0500, Daniel Eischen wrote:
>> On Mon, 7 Jan 2013, R
s it's
very likely not the only workload that exhibits this kind of cache
unhappiness.
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
I've CC'ed jasone on this as it's an interesting side-effect of memory
allocation logic.
Jason - any comments?
Adrian
On 5 January 2013 07:38, Hakisho Nukama wrote:
> Hi,
>
> FreeBSD (PCBSD) is slower compared to Linux and kFreeBSD in this
> benchmark of HIMENO:
&g
.. run a tcpdump, see if it's sending an individual frame or two and
getting the TX watchdog confused?
Try a different switch?
Adrian
On 1 January 2013 21:30, Tim Kientzle wrote:
> I'm trying to understand why the transmitter for the
> CPSW ethernet driver just stops somet
estions about how it works and you'll likely get
help :)
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
bout.
The next time it happens, please break into the debugger and grab some
debugging output. Show alllocks, ps, should be a good couple of things
to start with.
Alternately - please find a currently actively maintained SATA chipset.
(Or Alternatively - step up and help migrate th
+ marcel, who knows a little about the uart code.
Adrian
On 23 December 2012 22:54, Andriy Gapon wrote:
> on 23/12/2012 23:53 Garrett Cooper said the following:
>> On Sun, Dec 23, 2012 at 5:36 AM, Andriy Gapon wrote:
>>>
>>> Guys,
>>>
>>> do
ke you out for drinks if
you get dtrace kernel+user debugging working out of the box in -HEAD
and stable/9.
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to &
Hi,
Wow, I didn't even know this existed!
Would you mind filing a doc PR with this information, along with how
you figured out it was a HPA?
I'm sure this is going to come up from time to time and it'd be great
if someone would take the doc PR and turn it into a FAQ entry.
Th
on't announce that images are available once
they're uploaded. otherwise you may install an image that is actually
pulled and replaced before the release..
adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/list
ng, you have to step up.
Adrian
On 11 December 2012 12:43, Dieter BSD wrote:
>>>Ronald writes:
>>>> the last Alpha to be produced was shipped way back in 2004... eight years
>>>> ago... with a top speed of 1.3 GHz I now have a cheap little media player
>&g
heavy lifting.
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
n scope, wouldn't you agree?
Please file a PR and see if that can get resolved. I personally have
no idea about the storage side of things so I don't know if it's a
device id or whether there's something more complicated than that.
Thanks,
Adrian
___
Hi,
Yes. atacam supports NCQ.
The older IDE/ATA code doesn't support NCQ. The CAM ATA code (ie,
atacam) supports it if the drive supports it.
So, the "FreeBSD doesn't do NCQ" point is incorrect.
If you don't believe me - look in sys/cam/ata/ata_da.c, look fo
Hi,
If this is a real leak, please file a PR so it doesn't get lost.
*cough* let me rephrase that - so the eager PR beavers can keep
chasing it iup.
But, wow. Nice catch!
Adrian
On 8 December 2012 10:13, Richard Sharpe wrote:
> Hi folks,
>
> Our QA group (at xxx) using Samba
The reason I haven't yet committed it is I'd like to sit down with
Attilio one-on-one and figure out the _right_ way to do this.
There's a time for shit-stirring and a time for getting stuff done;
this is neither of those times. I don't mind taking my time on
for FreeBSD development.
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
git
trees. No, using git on a USB/CF/etc card doesn't work very well
either I'm afraid.
I'm sure there are other use cases.
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hack
it in the short term then migrate everyone over to
git.
Those who want to use git can use it, right now. Honest.
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail
hat's orthogonal to my developer-focused request. I'm also a big fan
of correctly using asserts/panics - ie, asserts shouldn't replace
correct error handling.
(Yes, I'm guilty of this in ath(4), but I have plans soon to rectify this.)
Adrian
_
#x27;ll just keep hacking the code up to not panic when I need to.
I agree with Attilio - any driver or subsystem that's causing witness
panics need to be fixed.
But I think my change is invaluable for development, where you want to
improve and debug the locking an
doing this
work?
Adrian
On 15 November 2012 09:36, Marko Zec wrote:
> On Thursday 15 November 2012 07:18:31 Adrian Chadd wrote:
>> Hi,
>>
>> Here's what I have thus far. Please ignore the device_printf() change.
>>
>> This works for me, both for hotplug
atch your local code to do so but
> don't add any generic/upstream/all-around mechanism for that.
Would a comprimise be ok? Ie, if I pushed everything but the sysctl
upstream, and just defaulted it to always panic?
That way my diff wouldn't have to be a big thing; I
river. They are only harmful if he loses a race.
LOR's and lock assertions. Ie, I want to find out at run time that a
lock wasnt' held at a certain position but continue soldiering on.
That's how I've been finding out all of the races in net80211/ath, as
there wasn'
ings aren't being correct. Having to reboot upon _every_
lock assertion quickly got old.
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to &qu
1 - 100 of 465 matches
Mail list logo
