+1
Very useful :)
-a
On 9 October 2013 01:55, Andriy Gapon a...@freebsd.org 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
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 pe...@holm.cc
+1.
On 28 September 2013 06:56, Ian Lepore i...@freebsd.org wrote:
On Sat, 2013-09-28 at 20:37 +1000, Peter Jeremy wrote:
I have a system with 4GB RAM and hence need to use an amd64 kernel to use
all the RAM (I can only access 3GB RAM with an i386 kernel). OTOH, amd64
processes are
On 20 September 2013 08:20, Sebastian Kuzminsky s.kuzmin...@f5.com 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
___
On 23 September 2013 14:30, Sebastian Kuzminsky s.kuzmin...@f5.com wrote:
On Sep 23, 2013, at 15:24 , Adrian Chadd wrote:
On 20 September 2013 08:20, Sebastian Kuzminsky s.kuzmin...@f5.com
wrote:
It's transparent for the kernel: all of UMA and
kmem_malloc()/kmem_free() is backed by 1
Hi!
On 22 September 2013 13:12, Alexander V. Chernikov
melif...@yandex-team.ruwrote:
I'm thinking the same way, but we're stuck with 'forwarding lookup' due
to problem with egress interface pointer, as I mention earlier. However it
is interesting to see how much it helps, regardless of
On 13 September 2013 15:43, Rick Macklem rmack...@uoguelph.ca wrote:
And any time you increase latency, that will have a negative impact on
NFS performance. NFS RPCs are usually small messages (except Write requests
and Read replies) and the RTT for these (mostly small, bidirectional)
Hi,
There's a lot of good stuff to review here, thanks!
Yes, the ixgbe RX lock needs to die in a fire. It's kinda pointless to keep
locking things like that on a per-packet basis. We should be able to do
this in a cleaner way - we can defer RX into a CPU pinned taskqueue and
convert the
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 dumbb...@freebsd.org wrote:
Author: dumbbell
Date: Sun Aug 25 12:27:15
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, Alexander
Oh look at that. It's so damned pretty.
-adrian
On 15 August 2013 18:16, Jason Hellenthal jhellent...@dataix.net wrote:
Has a release ever been nicknamed before ?
I don't recall any.
--
Jason Hellenthal
Inbox: jhellent...@dataix.net
Voice: +1 (616) 953-0176
JJH48-ARIN
On Aug
).
On Sat, Jul 27, 2013 at 12:21 AM, Adrian Chadd adr...@freebsd.org wrote:
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 h.tugrul.erdo...@gmail.com wrote:
howdy
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 h.tugrul.erdo...@gmail.com wrote:
howdy all,
At my work, I am using 10.0-CURRENT on Intel(R) Xeon(R) E5620 with
On 25 July 2013 02:51, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote:
improved with a higher kern.hz rating. Unless the future holds an emu20k2,
there will be RAM used from the motherboard.
1. I will need a real-time or a faster kernel- hence the high rate wanted-
because the devices to
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 superbisq...@gmail.com wrote:
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 leon...@leonerd.org.uk wrote:
Did we ever reach a consensus about this issue? We discussed
On 24 July 2013 16:43, Ronald F. Guilmette r...@tristatelogic.com 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 bugging me
until I do.
Hi,
Well, I've done this before. More than once. I'm glad that you've
stuck through helping me understand what nc is doing; I'm
unfortunately busy doing other things
What you end up doing is:
* tracking the state of the two sockets, both for read EOF and write EOF;
* whenever you get an EOF
Right. Yes, I had a typo. I meant that it shouldn't die on seeing a
read EOF after closing the write side of the socket.
So, what you're saying is:
* nc sees EOF on stdin
* nc decides to abort before seeing the rest of the data come in from
the remote socket (and then trying to write it, and
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.
-adrian
Wait a second. What's going on under the hood?
You _should_ be able to shutdown the write side of the socket and have
it not affect reading. It's a broken server if it does a read(), find
that the socket is returning EOF, and then not waiting for the write()
to fail before closing.
If that's
On 21 July 2013 19:02, Ronald F. Guilmette r...@tristatelogic.com wrote:
It has been some time now since I filed my PR but I think that the bottom
line is that you need to look at the code (of nc) to understand how it is
reacting to EOF on stdin.
Gah, I was kinda hoping not to look at nc,
.. i'd rather you narrow down _why_ it's performing better before committing it.
Otherwise it may just creep up again after someone does another change
in an unrelated part of the kernel.
You're using instructions-retired; how about using l1/l2 cache loads,
stores, etc? There's a lot more CPU
On 28 June 2013 08:37, Alexander Motin m...@freebsd.org wrote:
Otherwise it may just creep up again after someone does another change
in an unrelated part of the kernel.
Big win or small, TAILQ is still heavier then STAILQ, while it is not needed
there at all.
You can't make that assumption.
On 28 June 2013 09:18, m...@freebsd.org wrote:
You can't make that assumption. I bet that if both pointers are in the
_same_ cache line, the overhead of maintaining a double linked list is
trivial.
No, it's not. A singly-linked SLIST only needs to modify the head of the
list and the
On 28 June 2013 15:15, Alexander Motin m...@freebsd.org wrote:
I think it indeed may be a cache trashing. I've made some profiling for
getpbuf()/relpbuf() and found interesting results. With patched kernel using
SLIST profiling shows mostly one point of RESOURCE_STALLS.ANY in relpbuf()
--
... so run it inside hwpmc and see what the resulting CPU users are?
adrian
On 31 May 2013 07:01, Chris Rees utis...@gmail.com 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
expression I
... 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 shir...@gmail.com wrote:
Hello to
... holy crap.
On 13 May 2013 08:37, Eugen-Andrei Gavriloaie shir...@gmail.com wrote:
Hi,
Well, Paul already asked this question like 3-4 times now. Even insisting on
it. I will also ask it again:
If user code is responsible of tracking down the data associated with the
signalled entity,
of. It is not the goal, of course. Complex things are
complex things no matter how hard you try to simplify them. But this is
definitely (should) not falling into that category.
--
Eugen-Andrei Gavriloaie
Web: http://www.rtmpd.com
On May 13, 2013, at 6:47 PM, Adrian Chadd adr...@freebsd.org
On 13 May 2013 10:53, Paul LeoNerd leon...@leonerd.org.uk wrote:
[I'm not currently on the list so please forgive the manually-crafted
reply]
I'm confused as to why this is still an issue. Sure, fix the kqueue
semantics and do it in a way that doesn't break backwards
compatibility.
I
... 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
Just as a data point, I managed 50,000 + connections, at 5,000 + a
second, doing a gigabit + of traffic, mid-2000s, with the userland
management of all of the socket/disk FD stuff.
The biggest overhead at the time was actually the read/write
copyin/copyout, NOT the locking overhead of managing
.. or we could just bite the bullet and split GENERIC into GENERIC
(which would have modules for everything) and GENERIC_NOMODULES.
Then just populate a default module list that goes into /boot/loader.conf.
If you're even more evil, you could populate a module list that goes
into
On 25 April 2013 01:38, Lars Engels l...@freebsd.org 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 a default module
On 25 April 2013 02:24, Lars Engels l...@freebsd.org wrote:
Sure, but the rc.conf solution is the lower hanging fruit. :)
No it's not; think about it. You need to have a few modules loaded in
order to boot.
* usb
* maybe atkbd
* da/scsi
* ata / scsi block device drivers
* perhaps network
*
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 d...@freebsd.org wrote:
On Apr 24, 2013, at 00:03, Dimitry Andric d...@freebsd.org wrote:
On Apr 23, 2013, at 23:46, Andriy Gapon a...@freebsd.org wrote:
On 10 April 2013 13:06, Joshua Isom jri...@gmail.com 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
On 9 April 2013 11:47, Edward Tomasz Napierała tr...@freebsd.org wrote:
In order to optimize - in this case for size - we need a way to measure
what should we focus on, and it looks like we don't have it yet.
We have a good starting point. We can look at the code/data/bss from
each .o file
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 any mail to
Well, it's relatively easy to experience what it's like.
Reboot your machine with 32mb. Try to do things like bring up network
interfaces. Snark when stupid stuff occurs, like you can't allocate
enough mbufs for the driver RX path _and_ run the ifconfig command to
completion to bring said
On 8 April 2013 19:28, Kevin Day toa...@dragondata.com wrote:
Ages ago we had to make things work in 16 or 32MB of total system memory on
i386.
For the most part, disabling every compiled-in option/driver we didn't need
was 90% of the effort. Which options/drivers is going to be totally
On 2 April 2013 20:07, Julian Elischer jul...@freebsd.org wrote:
this sound somewhat like what I did back in the 90s with BSD4.3
unfortunately it was not done with TCP (or sctp of course)
what we did was to create a special shared memeory device driver.
Then we added ioctls to the disk
Why stop there?
Noone runs FreeBSD on real hardware anymore. Except, say netflix.
Let's just drop actual native hardware support and instead support
only the bare minimum needed to boot inside vmware, virtualbox and
xen.
Anyone needing real hardware support can install NetBSD and xen.
Again, no-one is going to really complain if vendors/users decide to step
up and run longer supported branches.
I personally encourage that. I _encourage_ that people who are interested
in keeping 6.x and earlier alive (and 7.x soon, and 8.x less soon) to jump
in and submit patches to backport
On 28 March 2013 14:29, Michael Wayne freebs...@wayne47.com wrote:
I'm NOT trying to start a flame war here. I'm trying to find a
viable solution to a very frustrating, real problem.
It's clear that FreeBSD has absolutely no interest in maintaining
an extended maintainence release version of
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
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 jri...@gmail.com wrote:
I have several core dumps that need debugged. All are the same problem.
The
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
Yes.
Adrian
On 22 March 2013 12:09, vasanth rao naik sabavat
vasanth.raon...@gmail.com wrote:
Hi,
Is the FreeBSD-10 kernel preemptive?
--
Thanks,
Vasanth
___
freebsd-hackers@freebsd.org mailing list
On 12 March 2013 00:52, Dimitry Andric d...@freebsd.org wrote:
On Mar 12, 2013, at 04:17 , Adrian Chadd adr...@freebsd.org 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
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:
... 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 ali_mousa...@yahoo.com wrote:
Does any body agree ?
http://forums.freebsd.org/showthread.php?p=212423#post212423 ?
Regards
On 7 March 2013 03:24, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl 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?
Adrian
On 24 February 2013 03:11, Phileas Fogg phileas-f...@mail.ru wrote:
Julian Elischer wrote:
not sure if it's relevent, but remember that updating the screen mor ethan
50
times a second is pointless.
I'm not sure if the curent video console does it but having the final copy
only
done on
On 20 February 2013 12:01, Mark Saad nones...@longcount.org wrote:
Xin
I am rebuilding now, I'll let you know how it works.
As I've said before, if someone wants to take ownership of 6.x and
backport changes / push them into STABLE_6, be my guest. Yahoo was
doing that for some unsupported old
... 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 mail to
On 12 February 2013 08:03, Ian Lepore i...@freebsd.org wrote:
I agree that for practical means, the _currently_ used compilers should
consider the tsleep() call as the sequential point. But then the volatile
qualifier cast applied for the given access would not change the code as
well.
... 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
On 30 January 2013 13:03, Andriy Gapon a...@freebsd.org wrote:
on 28/01/2013 16:30 Andriy Gapon said the following:
is there any reasonable explanation for getting an NMI while trying to read
acpi
timer register?
Note: this happens only after ACPI suspend/resume.
An update.
This happens
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?
Adrian
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 a...@freebsd.org wrote:
on 04/02/2013 23:06 Adrian Chadd said the following:
I'm not the right person for it, but I think it's worth wrapping up
.. is it actually completed?
Adrian
On 4 February 2013 18:48, Eitan Adler li...@eitanadler.com wrote:
Is the following page still useful?
Would there be any objection to me removing it?
http://www.freebsd.org/projects/c99/index.html
--
Eitan Adler
On 29 January 2013 09:46, Ian Lepore i...@freebsd.org wrote:
You can't use EOF on a read() to determine client life when the nature
of the client/server relationship is that clients are allowed to
shutdown(fd, SHUT_WR) as soon as they connect because they expect to
receive but never send any
On 18 January 2013 19:11, Dieter BSD dieter...@gmail.com wrote:
Matthew writes:
There is also no information in the original email as to which direction
the I/O was being sent.
In one of the followups, Karim reported:
# dd if=/dev/zero of=foo count=10 bs=1024000
10+0 records in
10+0
When you run gstat, how many ops/sec are you seeing?
Adrian
On 17 January 2013 20:03, Dieter BSD dieter...@gmail.com 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 is tagged
It wasn't listed anywhere in the documentation / wiki. I only found it
after I had posted that patch.
eg:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-gdb.html
I had to do a whole lot of searching to finally discover that particular option.
And yes,
Hi,
You're only doing one IO at the end. That's just plain silly. There's
all kinds of overhead that could show up, that would be amortized over
doing many IOs.
You should also realise that the raw disk IO on Linux is by default
buffered, so you're hitting the buffer cache. The results aren't
Hi,
I'd like to propose adding gdb into the cross-build target.
This way MIPS, ARM, PPC etc targets will have gdb-arch built in the
cross-build environment, so it can be (hopefully) used for cross-build
debugging of the kernel, as well as remote debugging out of the box.
Here's my example
Hi,
There doesn't seem to be a blessed way to set the baudrate from inside
gdb/kgdb. It seems to be set from '-b' on the command line.
However kgdb doesn't have this support.
This patch adds -b support so kgdb so I can override the default speed
(9600 it seems) to speak kgdb over serial to a
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 adr...@freebsd.org wrote:
Hi,
There doesn't
Please file a PR? :)
Thanks!
ADrian
On 11 January 2013 03:15, zeissoctopus cheungho...@gmail.com 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
.. 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 rsha...@richardsharpe.com wrote:
On Mon, 2013-01-07 at 22:24 -0500, Daniel Eischen wrote:
On Mon, 7 Jan 2013,
On 8 January 2013 08:15, Richard Sharpe rsha...@richardsharpe.com 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.
Yes, going forward
to ensure nothing has regressed.
Thanks,
adrian
On 5 January 2013 18:03, Adrian Chadd adr...@freebsd.org wrote:
On 5 January 2013 13:54, Jason Evans jas...@freebsd.org wrote:
Jason - any comments?
There are many variations on this class of performance problem, and the
short
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
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 nuk...@gmail.com wrote:
Hi,
FreeBSD (PCBSD) is slower compared to Linux and kFreeBSD in this
benchmark of HIMENO:
On 5 January 2013 13:54, Jason Evans jas...@freebsd.org wrote:
Jason - any comments?
There are many variations on this class of performance problem, and the short
of it is that only the application can have adequate understanding of data
structure layout and access patterns to reliably
.. 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 kient...@freebsd.org wrote:
I'm trying to understand why the transmitter for the
CPSW ethernet driver just stops
Hm, can you come up with a reproducable scenario where this happening?
A lot of times the issues with disk drivers being upset is due to
bad or incorrectly seated SATA cables.
We're willing to help you out if you're willing to delve into the
driver. Just ask questions about how it works and
Hi,
If the driver is doing something daft like DELAY(x) in a fast
interrupt handler which would lead to that behaviour, it should be
fixed.
If it's doing a DELAY(x) in a critical section, it shuld be fixed.
Otherwise, a DELAY(x) in a driver only chews CPU; the scheduler can
preempt that. I
+ marcel, who knows a little about the uart code.
Adrian
On 23 December 2012 22:54, Andriy Gapon a...@freebsd.org wrote:
on 23/12/2012 23:53 Garrett Cooper said the following:
On Sun, Dec 23, 2012 at 5:36 AM, Andriy Gapon a...@freebsd.org wrote:
Guys,
do you think that the following
On 23 December 2012 19:55, Alfred Perlstein bri...@mu.org wrote:
I had WITH_CTF=yes in my /etc/make.conf so this appears to be fallout of
WITH_CTF=yes. Basically this seems incompatible with dtrace unless I figure
it out further.
Oh god, please figure this mess out. I'll take you out for
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.
Thanks,
Adrian
On 12 December 2012 14:04, Ronald F. Guilmette r...@tristatelogic.com wrote:
In message
CAMXt9NbMFjgASZdxXFAyh97k59OTjiuXkM=o4rj8apa8d2+...@mail.gmail.com
Mark Saad nones...@longcount.org wrote:
I am wondering if anyone has seen this. I pulled down the 9.1-RELEASE
install media...
That's
I'm not seeing:
* any references to driver code that exhibits that very broken behaviour;
* any patches from you to implement NCQ on your nforce chipset;
* any offer of incentive to any developer to add that support.
Now, (1) is definitely worrying but as you've not provided any actual
Right, so the bug here is why isn't atacam attaching to the nforce4
ultra chipset.
So this has changed from FreeBSD doesn't do NCQ to FreeBSD doesn't
do NCQ on my particular desktop-aimed motherboard chipset. They're
slightly different in scope, wouldn't you agree?
Please file a PR and see if
.. the problem with Alpha is that there wasn't anyone who wanted to
support it any longer.
If someone wanted to stand up and resurrect it, support it, etc; I
doubt the FreeBSD project would complain.
The same thing is happening with ia64. Marcel still cares and he still
does a lot of ia64 heavy
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 rsha...@richardsharpe.com wrote:
Hi folks,
Our QA group (at xxx)
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 for ata_ncq_cmd().
Adrian
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 this
one.
Adrian
On 17 November 2012 23:31, Konstantin Belousov kostik...@gmail.com wrote:
Git would work well with our workflow. It supports the centralized
repository model, which the project employs right now.
It may work with your workflow, but it doesn't work with mine. :-)
Right now the source tree
On 18 November 2012 02:48, Andriy Gapon a...@freebsd.org wrote:
What you describe is not a workflow issue, but a local development
environment(s) setup issue.
Which is a workflow issue.
I mean, we could bang heads on semantics for hours on end, or we can
realise that git isn't a magic bullet
[snip]
There's a git repository. It's public. You can look at what goes into
the FreeBSD git clone to get your assurance that things aren't being
snuck in. People are using it, right now.
Honestly, I'd rather see subversion grow this kind of cryptographic
signing of each commit in the short term
On 16 November 2012 00:26, Alfred Perlstein bri...@mu.org wrote:
Adding another option to tag asserts so that it was sort of like:
KASSERT((cond, section, string)); would be interesting, then you could
turn KASSERTS on based on vfs or possibly file by file.
That's orthogonal to my
On 15 November 2012 05:27, Giovanni Trematerra
giovanni.tremate...@gmail.com wrote:
I really do think that is a very bad idea.
When a locking assertion fails you have just to stop your mind and
think what's wrong,
no way to postpone on this.
Not all witness panics are actually fatal. For a
On 15 November 2012 09:56, Warner Losh i...@bsdimp.com wrote:
Do you really think that an abusable mechanism will help here rather
It sounds like he's more worried about introducing LoRs into his wireless
code. They are harmless, for him, and he can fix them by reloading the
driver. They
On 15 November 2012 10:01, Attilio Rao atti...@freebsd.org wrote:
I think that your worries are focused more around the latter than the
former, which can be easilly shut down already today.
And frankly I will never be in favor of a patch that automatically
shutdowns lock assertion. Please
that is doing this
work?
Adrian
On 15 November 2012 09:36, Marko Zec z...@fer.hr 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 cardbus wireless devices as well
On 15 November 2012 11:55, Ian Lepore free...@damnhippie.dyndns.org wrote:
Since you've made it abundantly clear in this thread that you are not
open to anyone else's opinion and won't change your mind, I'm not going
to waste even 10 seconds explaining my perfectly valid needs.
I'll just
1 - 100 of 283 matches
Mail list logo
