| From | Subject | Date |
|---|---|---|
| Andriy Gapon | sysctls in kern_shutdown: add twin tunables
http://people.freebsd.org/~avg/kern_shutdown-tunables.diff
The above patch adds twin tunables for the following (R/W) sysctls:
- debug.debugger_on_panic
- debug.trace_on_panic
- kern.sync_on_panic
This seems useful to me, but I am not sure if I am not missing something
important. E.g. security-wise.
It seems that I am not paranoid enough often times.
--
Andriy Gapon
_______________________________________________
freebsd-current@freebsd.org mailing ...
| Sep 30, 11:19 am 2010 |
| Robert N. M. Watson | Re: sysctls in kern_shutdown: add twin tunables
This change seems fine to me. Our trust model assumes that loader.conf will be properly protected (or rather, that if you don't protect loader.conf properly, you should expect unfortunate results).
Robert_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
| Sep 30, 11:49 am 2010 |
| Ivan Voras | Re: Examining the VM splay tree effectiveness
The property of splay tree requiring *writes* for nearly every read
really is a thorn in the eye for SMP. It seems to me that even if the
immediate benefits from converting to something else are not directly
observable, it will still be worth doing it.
It's a shame that RCU is still a patent minefield :/
http://mirror.leaseweb.com/kernel/people/npiggin/patches/lockless/2.6.16-rc5/radix-int...
Slightly off-topic: a scare-mongering topic on ...
| Sep 30, 10:51 am 2010 |
| Roman Divacky | Re: Examining the VM splay tree effectiveness
there's a little something:
http://wiki.freebsd.org/MayurShardul/VM_Algorithm_Improvement
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
| Sep 30, 10:49 am 2010 |
| Andre Oppermann | Re: Examining the VM splay tree effectiveness
I just took a look (not in-depth though) at the patch and can't follow
your conclusion. It is not ready to go into svn in its current state.
Even though it is called a radix trie it doesn't look like one. On first
impression it looks much more like an AA tree. A radix trie, which we
already have in our network routing table code, is a variable length
(mask) tree that does path compression. See net/radix.[ch] and
http://en.wikipedia.org/wiki/Radix_tree
Extrapolating in a complete ...
| Sep 30, 2:44 pm 2010 |
| Freddie Cash | Re: Examining the VM splay tree effectiveness
For the curious, DragonflyBSD went through this back in 2005. All the
gory details are in the thread with Subject: "splay tree and red-black
tree for vm_map entry lookups" [1] While things are most likely
different now between the FreeBSD VM and the DragonflyBSD VM, it may
be worthwhile checking out what they did, and why. They considered
the FreeBSD splay-tree and compared it to red-black tree, and went
with red-black.
There's mention in that thread that NetBSD uses red-black trees. ...
| Sep 30, 3:50 pm 2010 |
| Andre Oppermann | Re: Examining the VM splay tree effectiveness
I remember that there was this project but I never saw any numbers
or other outcome of it. Haven't checked p4 to look at the code
though.
--
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
| Sep 30, 10:46 am 2010 |
| Roman Divacky | Re: Examining the VM splay tree effectiveness
and the actual patch + userspace implementation + benchmarking suite
is here:
http://code.google.com/p/google-summer-of-code-2008-freebsd/downloads/detail?name=Mayu...
it looks like a solid work with solid results to me
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
| Sep 30, 11:04 am 2010 |
| Andre Oppermann | Re: Examining the VM splay tree effectiveness
Thinking more about this I can't see any advantage of the radix trie
becoming useful for the vmmap. The index of the vmmap is the address
range and can't be expressed in a path compressable power of 2 quantity
and is non-overlapping. The key for the trie, a pointer, has a fixed
small size and can't be optimized away. And it is not a balanced tree.
Many keys in the same region lead to long node traversals.
In short: VMmap and a radix trie have an impedance mismatch and are unfit
for each ...
| Sep 30, 3:06 pm 2010 |
| Roman Divacky | Re: Examining the VM splay tree effectiveness
are you aware of Summer of Code 2008 project by Mayur Shardul?
quoting: http://www.freebsd.org/projects/summerofcode-2008.html
Project: VM Algorithm Improvement
Student: Mayur Shardul
Mentor: Jeff Roberson
Summary:
A new data structure, viz. radix tree, was implemented and used for management of the resident pages. The
objective is efficient use of memory and faster performance. The biggest challenge was to service insert requests
on the data structure without blocking. Because of this ...
| Sep 30, 10:24 am 2010 |
| Attilio Rao | Re: Examining the VM splay tree effectiveness
The final code (Jeff took Mayur initial patches and further refined)
resulted in a very variadic performance for simple tests, so I think
that the last posted codes had the same performance, overall, than the
splay tree.
I recall, however, that there were still rooms for improvement. Ask
Jeff about the last patches.
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-current@freebsd.org mailing ...
| Sep 30, 2:05 pm 2010 |
| Doug Barton | Re: letting glabel recognise a media change
Sorry, I'm being too terse. What I'm saying is that we have an existing
"notifications" model that third party apps already know how to deal
with. If we're considering developing a notifications model of our own
then we are well served by looking at the work that has gone before
(without violating copyright issues, yadda yadda).
hth,
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence ...
| Sep 30, 2:38 pm 2010 |
| Dimitry Andric | Re: letting glabel recognise a media change
Please read this first: https://wiki.ubuntu.com/Halsectomy :)
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
| Sep 30, 2:29 pm 2010 |
| Andriy Gapon | Re: letting glabel recognise a media change
Would this require some reverse-path from SIM driver to peripheral driver to
I agree.
--
Andriy Gapon
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
| Sep 30, 1:45 pm 2010 |
| Doug Barton | Re: letting glabel recognise a media change
Right, especially the bits about moving the functionality into the kernel.
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to ...
| Sep 30, 2:34 pm 2010 |
| Matthew Jacob | Re: letting glabel recognise a media change
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
| Sep 30, 5:45 am 2010 |
| Ivan Voras | Re: letting glabel recognise a media change
It doesn't have to be a heavy "announcement API". Basically, something
would have to re-trigger GEOM tasting on existing devices, probably by
marking them "spoiled" first.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
| Sep 30, 2:59 am 2010 |
| Andriy Gapon | Re: letting glabel recognise a media change
In fact, I am not sure anymore :-)
I had in mind some technical difficulties (like potential races with "normal"
usage), but I think that they all are not very hard to overcome.
Another question I had was how to poll, i.e. what command(s) to issue to cover
different possibilities and hardware capabilities.
--
Andriy Gapon
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, ...
| Sep 30, 1:49 pm 2010 |
| Matthew Jacob | Re: letting glabel recognise a media change
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
| Sep 30, 5:53 am 2010 |
| Doug Barton | Re: letting glabel recognise a media change
To what extent is HAL relevant here? I was sort of ambivalent about
using it in FreeBSD, but my recent experimentation with ubuntu is
starting to change my mind.
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
_______________________________________________
freebsd-current@freebsd.org mailing ...
| Sep 30, 2:07 pm 2010 |
| Alexander Motin | Re: letting glabel recognise a media change
Yes we do. SATA PMP driver (it looks like usual peripheral driver from
this point) already receives and handles AC_SCSI_AEN messages sent to it
via xpt_async() mechanism.
--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
| Sep 30, 2:00 pm 2010 |
| Alexander Motin | Re: letting glabel recognise a media change
SATA specification defines concept of Asynchronous Notification. It is
already used by port multipliers to report about PHY events. It is also
supposed to be used by CD drives to report media change. I haven't seen
such devices yet, but hope they may appear sometimes.
And even without AN support it would be nice to implement proper
handling for SCSI "UA - media changed" errors within CAM. It still won't
be perfect without using polling, but probably still something.
--
Alexander ...
| Sep 30, 10:46 am 2010 |
| Garrett Cooper | Re: letting glabel recognise a media change
The problem is that the current system proposed for Device Kit is
based on file system notification. I know we can do this with kqueues
to some degree, but we do some of our best work via sysctls, and using
other methods of attack, so it would be nice if these were
`abstracted' out into generic events with OS specific callback
handlers.
Anyhow, just something to toss around, but honestly apart from the
disc tasting I see via hald whenever I insert a CD or DVD, I could
really care less ...
| Sep 30, 3:20 pm 2010 |
| Andriy Gapon | Re: letting glabel recognise a media change
Not sure what kind of API you mean and if anything really needs to be added.
I am not sure about this.
Because, e.g. I don't see an easy way to know that media is changed in scsi_cd
driver. That is, without polling. I don't consider polling to be an easy way for
a number of reasons.
--
Andriy Gapon
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to ...
| Sep 30, 4:22 am 2010 |
| Alexander Motin | Re: Safe-mode on amd64 broken
There are too many reports about different lost interrupts problems on
different controllers of MCP5x. I don't know the reason. Attached patch
should disable using regular HPET interrupts on NVidia chipsets. I hope
it will work as workaround. May be it is too aggressive, but better to
be safe then sorry. I assume that legacy_route mode may still work fine
This is strange, as my Acer with the same ICH8M works fine in all
possible modes. Also IMHO stray interrupts are not a reason to ...
| Sep 29, 10:23 pm 2010 |
| David Naylor | Re: Safe-mode on amd64 broken
I assume you mean hint.hpet.0.legacy_route=1? I'll give that a try later
today on both machines.
See http://markmail.org/message/smxnofrdmmkxyvnd for my previous email that
includes the backtrace from that panic. When I booted in i386 safe mode the
kernel reported stray interrupts on irq7. vmstat -i shows irq7 as "stray
irq7".
Is there anything else you are looking for?
| Sep 29, 10:55 pm 2010 |
| Alexander Motin | Re: Safe-mode on amd64 broken
By default - effectively yes. But it still allows to configure
I am not sure "stray irq7" related here. Instead more suspicious looks
probable irq20 interrupt sharing between HPET and uhci0 and the fact
that system panicked during interrupt handler registration by uhci0. I
can't be sure what IRQ was used by HPET there, as in only present dmesg
it was disabled, but as soon as HPET registered early, I think it
grabbed first possible - irq20. On my system HPET also uses irq20, but
uhci0 lives ...
| Sep 29, 11:52 pm 2010 |
| David Naylor | Re: Safe-mode on amd64 broken
legacy_route worked on the desktop but not on the laptop (boot stalled).
Here is vmstat using default settings for the desktop:
interrupt total rate
irq1: atkbd0 64 0
irq12: psm0 756 3
irq14: ata0 1255 5
irq16: vgapci0 13576 54
irq17: dc0 1546 6
irq18: hpet0 456756 ...
| Sep 30, 8:43 am 2010 |
| Sergey Kandaurov | Re: [PATCH] Netdump for review and testing -- preliminar ...
Hi.
Thank you, that helped fixing it.
2nd and further netdumps work now.
Some more numbers below
[hosts are on diff. switches connected
with STP on same 1Gb MTU1500 LAN]
packets errs bytes packets errs bytes colls
[avg:]
3488 0 4109874 4002 0 704800 0
[at the end:]
3484 0 4076816 3989 0 680710 0
3510 0 4086756 4066 0 712280 0
3552 0 4136112 4107 0 ...
| Sep 29, 11:10 pm 2010 |
| Sergey Kandaurov | Re: [PATCH] Netdump for review and testing -- preliminar ...
The 1st error is caught :).
Prior actions was triggering netdump, leaving db>
and entering again, then trigger netdump once more.
Dumping 1146 MB: 1131 1115 1099 1083 1067 1051 1035 1019 1003 987 971
955 939 923 907 891 875 859 843 827 811 795. . . . . . . . . . .
** DUMP FAILED (ERROR 60) **
Failed to dump the actual raw datas
Then I was able to leave ddb back to the working system.
P.S.
What about to start netdumpsrv from rc.d ? It's very simple.
%%%
#!/bin/sh
#
# ...
| Sep 29, 11:22 pm 2010 |
| Derek Tattersall | Re: Clang now builds world and kernel, on i386 and amd64
Super! Thanks very much for this rapid fix. And perldoc -f works
again.
--
Best regards,
Derek Tattersall
dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
| Sep 29, 5:18 pm 2010 |
| previous day | today | next day |
|---|---|---|
| September 29, 2010 | September 30, 2010 | October 1, 2010 |
